Comunica... ¿QUÉ?

En varios posts (por ejemplo aquí y tangencialmente en muchos otros) hablé sobre la importancia de la comunicación en el equipo de desarrollo. De hecho, el trabajo en equipo es básicamente comunicación, y realmente poco más que eso.

El desarrollo de un sistema de software es muy sensible a los problemas de comunicación, a los malentendidos y confusiones en todo nivel: desde los requerimientos hasta el mantenimiento. Tal vez esta sensibilidad tenga que ver con que es la traducción de un proceso de negocio a varios lenguajes, desde los menos estructurados (relación con el cliente, análisis funcional, gestión del proyecto) hasta los más estructurados (lenguajes de programación, de consulta a la base de datos, de diseño de interfaz con el usuario).

Usualmente, para cada uno de esos lenguajes tenemos uno o varios profesionales en el equipo, y de alguna manera tienen que encontrar una base para entenderse. Pensemos por un segundo en qué diferente es el sistema visto desde el usuario, desde el líder de proyecto, el experto en base de datos, los programadores, los diseñadores, y nos parecerá casi un milagro que todas esas miradas logren coordinarse de alguna manera (cuando lo hacen).

En resumen, ya bastante difícil es la coordinación entre profesionales de una misma área (dentro del equipo de programadores, digamos), y se complica muchísimo más entre profesionales de distintas áreas.

Entonces, veamos el mismo problema desde dos puntos de vista diferentes. Es intersante ver que hay que pensar un rato para darse cuenta de que es el mismo problema.

Tomemos entonces "El éxito depende de tres cosas: comunicación, comunicación, comunicación" de Mejores Proyectos (un blog justamente orientado a líderes de proyecto).

Y por otro un aporte de Cerebrado, que creo que resume bastante bien cómo son caracterizados -a veces- esos "otros niveles" de un equipo de desarrollo.

ACTO I.

• Líder (L): El reporte tiene que tener mas o menos éstos campos.
• Programador (P): ¿Tiene o no tiene que tener el campo “X”?
• L: Y... si hay lugar ponélo.

ACTO II. Dos meses después.

• L: ¿Gente, por qué no está el campo “X” en el reporte?
• B: porque no había espacio para ponerlo.
• L: Pero... se suponía que tenía que estar.
• B: ¿En qué charco está escrito que tenía que estar?

... continúan líder y programador en un sinfín de si-no.

ACTO III.

• L: Listo, en ésta semana terminamos el módulo prometido.
• Jefe máximo que paga los sueldos de todos (DIOS): la semana pasada me dijiste lo mismo
• L: (Y la semana que viene le diré lo mismo, me parece) Sí, pero ésta vez ya está terminado.
• DIOS: (Ya no te creo nada.) Bueno. ¿Le comunico al cliente que estamos instalando el viernes?
• L: (El viernes me quiero ir temprano...) Mejor el lunes, por cualquier cosa.

ACTO IV. Ese viernes a las 18.00.

• L: Muchachos, el lunes instalamos.
• P: ¿Cómo? ¿Qué? ¿Cuándo? ¿Por qué? ¿Quién?
• L: Sí, el jefe máximo dio directivas claras, pero no se preocupen, en mi planilla figura que estamos en término.
• P: ¿Y cuando vimos nosotros esa planilla?
• L: Ni hace falta que la vean, para eso estoy yo.
• P: (¿Para qué era exactamente que estabas vos?)...

P llama a A (amigo) y le pregunta si el lugar donde labura está bueno. Como A es nuevo en ese trabajo le dice que sí. B manda el CV.

(TELÓN)

Mientras acomodaba todo esto pensaba "los programadores deberíamos leer más blogs de líderes de proyectos, analistas y emprendedores que de otros programadores", para acortar la brecha, para entender un poco más la mirada del otro lado (en la que somos los programadores los que quedamos siempre mal parados).

¿Alguien conoce?