La comunicación en los Proyectos

Últimamente he leído varios artículos sobre metodologías de trabajo en proyectos de desarrollo software o de ingeniería en general. Existen dos grandes familias de alternativas: las metodologías tradicionales y las metodologías ágiles. Unas se caracterizan por basarse en procesos de desarrollo (creación de documentación, ciclos de prueba, etc.) y las otras por el desarrollo rápido y de forma adaptable sin preocuparse en principio por aspectos como el costo o la mantenibilidad.

¿Por qué necesitamos una metodología de trabajo?

Usamos metodologías de trabajo porque tenemos miedo. Miedo a a desarrollar un mal producto de mala calidad, miedo a los retrasos...

dice Robert Martin

Normalmente, cada empresa tiene su propia metodología de trabajo basada en alguna más estandarizada, intentando adaptarla al funcionamiento interno. Por lo tanto, existen múltiples variantes y tipos de formas de trabajo. Sin embargo, existe una cosa común a todas que es la mayor causa de fracaso en los proyectos: la comunicación.

Comunicación:
¿Por qué es común la comunicación en todas las metodologías de trabajo? Obviamente porque los proyectos se desarrollan por personas independientes, cada una con su perfil y sus cualidades. Independientemente de cómo trabajemos (tradicionales, XP, FDD,...) el equipo de trabajo estará compuesto por múltiples personas que trabajarán en partes del proyecto, tendremos uno o varios clientes, jefes de proyecto, entendidos de la materia, jefes técnicos, desarrolladores, testeadores, etc. y todos deben ir en la misma dirección.

De todas formas, hablando se entiende la gente, dicen. Sí, pero siempre que hablen el mismo idioma. El problema reside en que lo que el cliente necesita debe ser implementado por el desarrollador, pero en medio de ellos existe mucha gente por la que el mensaje se cambia y al final el cliente no obtiene lo que necesita. Pero vamos a ir paso a paso en la cadena de comunicación:

La cadena de comunicación:
Lo normal que tengamos en un proyecto son los siguientes perfiles:

• Cliente: es el destinatario final del producto, normalmente sabe lo que quiere, o tiene una idea aproximada, pero no suele saber comunicarlo en lenguaje técnico y hay que interpretarlo.
• Jefe de Proyecto: es el encargado de hablar con el cliente, interpretar lo que quiere, evaluar lo que conviene hacer y lo que no (a su libre albedrío normalmente) y comunicarle lo que se va a hacer al Jefe Técnico.
• Jefe Técnico: es el que debe traducir el lenguaje no técnico con el que le habla el Jefe de Proyecto de lo que le ha contado el Cliente al lenguaje técnico que entienden los desarrolladores o técnicos. En medio también mete una criba de lo que se debe hacer por "dificultades técnicas".
• Desarrollador: hace lo que le ha dicho el Jefe Técnico y se lleva los marrones cuando el cliente ve que lo que le han hecho no es lo que él quería.
  

Consecuencias de la mala comunicación:

Aparte del posible fracaso de un proyecto, se deriva una consecuencia, si cabe peor: la desmotivación del equipo de trabajo. Un jefe sin el apoyo de los empleados no tiene poder para sacar ningún trabajo, por lo que un equipo de trabajo desmotivado que no trabajo con ilusión es la perdición de un responsable y su ruina. En cambio, un equipo de trabajo motivado, ilusionado con sus trabajo y partícipe del diseño y desarrollo de las soluciones podrá superar las expectativas del cliente y obtener un producto de calidad. Se mejorará la comunicación entre las diferentes partes (al haber mayor confianza) y se aportarán más ideas (enriqueciendo el producto final).

Espero que os haya gustado este artículo y que se reflexione sobre él para intentar mejorar la comunicación y la confianza dentro de los proyectos.