La Gestión de la Comunicación es siempre complicada porque no depende enteramente de una única persona, sino de dos o más partes. En tu mano está mejorar una comunicación, facilitarla, dejarla registrada por escrito… Pero no puedes obligar a una persona a que te entienda mejor 
ni a que se explique mejor
Permitidme un ejemplo para ilustrar lo que ha sido la comunicación en este proyecto.
Antes de marcharme de vacaciones realicé una estimación (informada, con todos los requisitos en la mano ya que era realizar prácticamente otro desarrollo igual que ya habíamos hecho) de un nuevo desarrollo con un socio, y di tres cifras en función de las entregas de este socio: 65, 70 ó 90 jornadas. Estas cifras eran conocidas por mi equipo, el comercial, y por el departamento de IT.
A la vuelta me encuentro con que se ha vendido (y comprado) en 30 jornadas cerradas… Como era prácticamente igual (según operaciones e IT) que un desarrollo previo, empezaron a quitar tareas y a dividir por dos el tiempo, achantando a mi backup. Fue francamente desagradable tener que abroncar tanto al cliente como al comercial.
En este proyecto y a pesar de mis muchos esfuerzos, la comunicación ha sido caótica e informal porque al resto de partes implicadas le interesaba. En nuestro equipo al menos he mantenido las entradas lo más centralizada que he podido en mí, para cumplir que únicamente haya una entrada de trabajo y descargar al resto del equipo de este caos y lo que antes era blanco ahora es negro…
Por supuesto, no existe nada parecido a un Plan de Comunicaciones.
Comunicación caótica
Comunicación caótica porque el elevado número de interlocutores, que no ha hecho más que aumentar con el tiempo. Podríamos pensar en que la comunicación en un principio sería simple, únicamente entre dos partes (el cliente y nosotros como proveedores), y que luego simplemente se añadió otra parte (Mutua Madrileña como socio) con la que no deberíamos de tener contacto directo, y más adelante otros productos y socios…
La realidad ha sido diferente. Primero el cliente era el departamento de IT, y el usuario el departamento de operaciones, cada uno con intereses contrapuestos : el cliente quiere pagar lo menos posible y el usuario quiere las máximas funcionalidades y servicios. Esta dualidad ha sido un auténtico lastre en las negociaciones y en toda conversación, siendo la causa de que siempre ha habido más trabajo del que se puede completar, y por tanto uno de los orígenes de los problemas de indefinición del alcance, planificaciones imposibles de cumplir y calidad deficiente.
La comunicación con el departamento de IT comenzó siendo a través de un único interlocutor, pero ante su temprana saturación de trabajo que le convertían en un cuello de botella que nos impidiería cumplir con las fechas previstas, y el hecho de que nosotros como proveedores estábamos físicamente en la misma sala que el departamento de IT, comenzamos a atacar directamente a cada reponsable de nuestras necesidades (SQL Server, Sistemas, Host…) descargando a la persona responsable de estas gestiones. Es decir comenzamos a realizar trabajo que no era nuestro, además de aumentar el número de personas involucradas directamente en el proyecto, complicando la comunicación y llegando a asumir la gestión incluso del trabajo del personal del cliente.
Pronto las excepciones se convirtieron en norma, y yo de Jefe del Proyecto dentro de nuestra empresa en Jefe de Proyecto a secas. Fue surrealista recibir una bronca por no obligar a una persona del cliente a priorizar una tarea nuestra.
Con la irrupción de socios la comunicación también se complicó, ya que la comunicación no se realizaba de una única persona a otra única persona, sino que nuestro departamente de IT conversaba con su departamento de IT, operaciones con su departamento de operaciones…
Finalmente, con la puesta en producción del aplicativo aumentamos la complejidad, ya que duplicamos las conversaciones : ahora tenemos desarrollos nuevos y tenemos mantenimiento de producción. Y también operaciones, que mantenía un único punto de entrada, pasa a tener varios ya que los gestores de cada producto nos atacaban a nostros directamente.
Suficiente caos? Alguna cosilla más había por ahí, ya que nos llamaban a nosotros en lugar de a IT en cada problema de comunicación, nuevos productos…
Comunicación informal en un sentido, formal en otro.
La informalidad ha sido otra gran carga de profundidad, y lo que más me ha molestado a mi en lo personal por el doble juego : el cliente tiene carta blanca para decir y desdecirse, y a nosotros se nos busca una cifra optimista con sólo el 10% de los requisitos definidos para luego exiguirnos compromiso sobre ella sin un mínimo análisis de riesgos y aumentando el alcance constantemente.
Dentro del equipo esta falta de comunicación única provocaba que las soluciones no se reutilizasen, diseños diferentes, estilos heterogéneos…
Almacenaje
Los documentos de requisitos eran diferentes en el cliente y en nuestro equipo, almacenados en diferentes sistemas, con diferentes versiones y desactualizados con el tiempo. Costó meses poner fin a esto y unificar la documentación. Imposible hacer análisis ni diseños en un ambiente tan cambiante. Respecto a los casos de pruebas, peticiones que caen en el olvido al llegar a los usuarios.
Reuniones de seguimiento
Esto ha sido lo más parecido a un Plan de Comunicaciones, reuniones semanales (semanas sí, semanas no) para evaluar el estado del proyecto. A nivel personal, han sido lo más desagradable del proyecto.
Cada reunión se planificaba el trabajo para el desarrollo de la siguiente semana, y constantemente esta programación se incumplía (como todas las planificaciones de todos los proyectos que gestiona este cliente). Las causas, más que identificadas:
- Por supuesto ha habido retrasos achacables a mí y a mi equipo, sin lugar a dudas. Pero echando la vista atrás, suponen una inmensa minoría.
- En otras ocasiones se retrasaba el desarrollo por la entrada prioritaria de trabajo sin planificar, principalmente mantenimiento de producción, que al ser tan inestable la aplicación es impredecible estimar la entrada de la semana siguiente.
- Pero la gran mayoría de los retrasos se debían a retrasos en las entregas del propio cliente. Pero claro, yo no puedo escudarme en un retraso de IT para justificar que una tarea no está completada, porque se enfadan si les saco los colores delante de operaciones (las mayores broncas que he recibido han sido por esto); y viceversa. Baste decir que llevamos 8 meses, OCHO, esperando a que nos definan una tabla, UNA. Y a día de hoy seguimos esperando.
- Y por supuesto, una planificación en la que no se hace ningún análisis de riesgos no puede llamarse planificación. Ya sabéis que todos los días son buenos, nadie enferma, nadie se va de vacaciones, nadie deja la empresa, nadie se retrasa, no nos topamos con problemas al desarrollar sobre una aplicación inestable…
De paso comentar que estoy plenamente convencido en que utilizar los Test como métrica de progreso de un proyecto es lo más realista, además de las ventajas que aporta ya de por sí una adecuada gestión de la Calidad. En este proyecto, sin Test unitarios ni de integración durante gran parte de su vida, ha sido imposible llevar TDD a la práctica.
Las actas de reunión una utopía inútil ya que sólo servían para recordarnos nuestros compromisos que se nos exigía cumplir a rajatabla y los compromisos del cliente casi inexistentes y rompibles (antes de llegar aquí me parecía un buen chiste, ahora es que me parto el pecho).
Éxitos
- Arroz para todos. Al arrancar el proyecto, el resto de partes implicadas disfrutaban las ventajas de una comunicación caótica e informal mientras mi equipo era el único que sufría las consecuencias.
Oportunidades de mejora
- Formalizar la comunicación en momentos clave, aún retrasando o parando el proyecto.
Imprescindible para el futuro
- Retrospective, o cierres de proyecto. Sacar las lecciones aprendidas individualmente es bueno, pero en grupo es mejor.
La segunda parte se centra en explicar por qué tienes que atraer a la gente, y su respuesta es la Ley de la Difusión de la Innovación : para que la mayoría de personas adopten una innovación debe de haber sido adoptada y probada previamente por una minoría de gente innovadores. 
Un aspecto clave del éxito de un proyecto son las personas que participan en él, especialmente cuando los procesos son inexistentes y las herramientas escasean. En este escenario, la Gestión de los Recursos Humanos es crítica para convertir una idea en realidad. 
