Lo que no se comunica no existe.

Este primer post de la serie tratará acerca de la comunicación como eje articulador del desarrollo de software. Esta disciplina humana requiere que las personas seamos capaces de establecer lazos de comunicación con el fin de resolver algún problema o satisfacer alguna necesidad, ya sea una necesidad empresarial, personal o simplemente la curiosidad de establecer alguna forma de trabajar.

El ser humano es un ser netamente social: necesitamos del otro para poder meditar, pensar, aplicar y resolver problemas de esta índole o de otra especie de problemas. Desde siempre, yendo a nuestros ancestros, el ser humano ha estado organizándose en tribus o en clanes para poder sobrevivir. Antiguamente era para que los depredadores no nos comieran; actualmente es para estar insertos en la sociedad y progresar en conjunto (o al menos eso se supone…).

¿Qué implica comunicarse en el desarrollo de software?

La comunicación es un elemento básico para las relaciones humanas. El nacimiento de un sistema, pantalla o elemento de software siempre nace de la necesidad de alguien más, ya sea por automatizar un proceso manual, mejorar flujos de trabajo o resumir un gran volumen de información para obtener resultados que le ayuden en su toma de decisiones.

El hecho de comunicarse en el desarrollo de sistemas tiende a verse solo como escuchar lo que debo hacer, pero no sé cómo hacerlo ni qué implica hacerlo. Esto guarda un peligro a la hora de implementar una solución, ya que las personas tienden a tener áreas de conocimiento diversas, lo que varía desde el tipo de lenguaje usado, más o menos profesional, hasta el detalle de lo que buscan. Cada persona entiende y comprende el mundo de distintas formas: no es lo mismo un gerente de ventas que un vendedor. Mientras el primero requiere conocer volúmenes de ventas, stock de productos y tendencias de mercado, el segundo solamente debe operar la caja, sin importarle demasiado los demás detalles.[1]

Si un desarrollador de software no es capaz de escuchar y entender las necesidades de un usuario, no será capaz de crear un sistema que satisfaga las necesidades de sus usuarios.

Contrapartes y ánimos

Siempre en una conversación existen dos personas, entidades o seres que intercambian palabras, es decir, mensajes, que afectan las respuestas al ambiente: las famosas respuestas a los estímulos. En esta relación existe una interdependencia entre ambas partes, en la que las dos quieren lograr algo: los desarrolladores quieren entender qué deben hacer con el sistema, mientras que las personas usuarias quieren solucionar su problema o mejorar su calidad de vida laboral con esta implementación. Los roles están claros.

Al tener este grado de interdependencia, existe una especie de dominación implícita por dominio de conocimiento: el informático sabe más de computación, por lo que tiene la razón. Esta suerte de dinámica de poder es contraproducente en ciertos ambientes o situaciones donde la autorregulación es clave para que ambas partes ganen. En “The Successful Software Manager” de Herman Fung[2], se dice que una de las habilidades blandas que debe poseer el líder de un equipo es la capacidad de negociación.

Esto implica que tanto desarrolladores como usuarios deben tener el ánimo y la intención de querer escucharse y hablar entre sí, independiente del lenguaje usado o las competencias que posea cada uno.

Construyendo un camino juntos

Debido a que debemos practicar una escucha activa a las personas que colaboran en este camino, no solo a nuestros clientes o usuarios, sino también a nuestros colegas, podemos comenzar a edificar un camino juntos para resolver problemas.

La confianza es un camino bastante frágil que debe construirse todos los días, en cada reunión, en cada compromiso adquirido. Los lazos comunicativos pueden perderse rápidamente en caso de que alguna de las partes incumpla sus compromisos o ignore las recomendaciones indicadas por la otra persona que está dando a conocer sus problemas para que sean resueltos.

El respeto hacia las personas es un sentimiento que debemos guardarle a todas las personas, independientemente de la posición que ocupen en la organización y cuál sea su involucramiento en el desarrollo del software. Grandes sistemas se han caído porque son socavados por las personas que lo operan, no por quienes lo crean.

Cuando las personas se comunican de forma abierta y honesta, es más probable que se construya confianza y respeto mutuos, y por tanto, será más fácil crear o mejorar cualquier cosa o problema, no tan solo en software.

¿Qué podemos hacer para mejorar la comunicación?

Por lo general, cuando se lee que “hay problemas de comunicación”, la respuesta suele ser generar más canales de comunicación. Sin embargo, lo que realmente se necesita es hacer un par de preguntas claves:

• ¿Cuál es el mensaje que tengo que entregar?
• ¿Está suficientemente claro para las personas que lo reciben? ¿A cuáles personas?
• Esas personas, ¿realmente deben ser informadas o notificadas?
• Mi mensaje, ¿tiene un llamado a la acción o es informativo?

Los problemas de comunicación no derivan necesariamente de la ausencia de canales, sino de la falta de prolijidad del mensaje y el formato de emisión del mensaje.

Por ejemplo, si estamos en una reunión y se toman decisiones importantes, si no quedan escritas y se socializan, los acuerdos serán retomados en función de la memoria de cada persona, en lugar de poder recurrir a un medio persistente donde las personas que intervienen son las indicadas para hacer alguna acción con la conversación.

Por tanto, la invitación que sacamos de este pequeño texto es a interactuar adecuadamente con las personas, apoyarlas y forjar una relación sincera y cordial para lograr el objetivo de ambas partes.

Resumen (por Bard)

Para mejorar la comunicación en el desarrollo de software, es importante:

• Entender las necesidades de las partes interesadas.
• Ser claro y conciso en la comunicación.
• Escuchar activamente a las demás personas.
• Ser respetuoso y abierto a las opiniones de los demás.

Notas

[1] Demás está notar que hay personas que aman esos detalles, pero por lo general son tareas totalmente separadas.
[2] Libro en Google Play