Comunicación en equipos de software

Comunicación en equipos de software
Por Joaquin Gracia
17 de Julio de 2004

La dificultad en el desarrollo de un proyecto de software no radica en lo técnico si no en lo sociológico, y mas concretamente en la comunicación.

La mayor parte de los proyectos de software que fracasan lo hacen por cuestiones de comunicación. Voy a poner un ejemplo sacado de "The Mythical Man-month", ¿Por qué falló la construcción de la Torre de Babel? Analicemos el problema.

• Tenían unos requisitos concretos y claros. Su objetivo era crear una torre para llegar al cielo. No deja de ser una idea un estúpida pero la idea era clara.
• Tenían suficiente mano de obra. Parece ser que mucha gente estaba dispuesta a trabajar en ello.
• Tenían suficientes materiales. Bueno, no se nos dice lo contrario así que parece que si.
• Tiempo. No tenían restricciones de tiempo.
• Tecnología adecuada. Parece que empezaron con una torre cónica, así que en principio no era mala idea, además el proyecto falló antes de que llegasen a limitaciones técnicas.

Con todo esto parece ser que el proyecto iba para adelante a buen ritmo, pero a Dios no le gustaba la idea de que hicieran una torre que llegara al cielo, así que hizo que cada uno de ellos hablase un idioma distinto.Hablando cada uno un idioma diferente no se podían comunicar los unos con los otros, como consecuencia de esto se creó una completa desorganización y el proyecto fracasó.

Por eso una de las más importantes tareas del director de equipo y del gestor del proyecto es que la información fluya en todas las direcciones. No solo que la comunicación se produzca de arriba hacia abajo si no, que también se produzca de abajo hacia arriba. Es muy frecuente que los programadores identifiquen problemas o indicios de problemas que más tarde pueden revelarse como críticos. Una correcta gestión de la información puede provocar que los incipientes problemas se solucionen antes de que estos se conviertan en decisivos ytengamos que lamentarnos por ello. Por eso si estás a cargo de una serie de programadores debes estar muy atento a los problemas que te planteen. No debes cerrar los ojos ante ellos o ignorarlos porque no los consideras importantes. Hay que tener mucho cuidado antes de desechar un problema porque piensas que no es importante, una de las razones que por la cual la información no fluye correctamente es porque alguien en la cadena de la información desestimó erróneamente un problema.

Un actitud típica es el síndrome "No-problem" cuando uno está afectado por este síndrome tiende a desestimar los problemas, normalmente porque no lo ha escuchado o le da mucha pereza el esfuerzo necesario para entenderlo. Si quieres saber si alguien o tú mismo estás afectado por
el síndrome del "No-problem" has la siguiente prueba:

1. Plantea un problema complicado.
2. Tu interlocutor te responde "No problem !!"
3. Dile que te describa el problema que le acabas de plantear.

En este punto hay dos opciones:

• Si te describe el problema, aunque sea erróneamente, no está afectado por el síndrome del "No-problem". Solo es un optimista.
• Si directamente te da una supuesta solución a lo que estás planteando, entonces estás perdido, esta afectado.

El síndrome del "No-problem" está directamente relacionado con la capacidad de escuchar. Lamentablemente también se produce el fenómeno que cuanto más alto se está en la jerarquía menos se escuchan los problemas y mas frecuente es el síndrome del "No-problem". Recuerda esto para cuando estés arriba, escucha los problemas de los demás.

Una vez preparado para escuchar debes fomentar la comunicación del grupo, piensa que cada miembro del equipo es una fuente de información. Los miembros del grupo no son iguales, unos son más expertos en una cosa y otros en otra.

Dedica tiempo a todos los miembros del equipo, escúchalos a todos y no dejes aislado a nadie, fomenta la participación, de esta forma consigues que se sientan responsables de parte del proyecto porque algunas de sus ideas suyas son aceptadas.

Se generoso con esto, se muy generoso, es muy fácil y se obtiene grandes recompensas en cuanto a participación, haz saber a todos que la idea ha sido de esta persona o de aquella, eso la motivará para que participe mucho más, porque estás alimentando su ego dándole el reconocimiento dentro del grupo.

Por otra parte, también tienen entender que no todas sus ideas van a ser adoptadas o que no es el momento adecuado para ellas.

Desde el punto de vista del director de equipo es muy importante tener claro que no siempre lo mejor es lo mejor, quiero decir, que a veces hay que ceder o adoptar una idea aunque sepas que no es la mejor, pero con ello consigues que alguien obtenga reconocimiento, eso es bueno para el equipo.

Si el equipo funciona el proyecto saldrá adelante.
Y a ti como responsable se te valorará por el resultado del proyecto.

Fuente: http://www.ingenierosoftware.com/