Cinco meses de retraso o como NO gestionar proyectos.

Es curioso como en la vida profesional se puede pasar en unos pocos meses de tener un EXITO con palabras mayúsculas a estar metido en un tarro de melaza, empujando y luchando contra todo y contra todos para sobreponerse a un FRACASO.

Y, como hice hace unos meses, quisiera dejar una pequeña lista de antiDecisiones (palabrejo que me acabo de inventar) que quisiera evitar volver a sufrir en ningún otro proyecto en el que esté implicado. Sea en el rol que sea.

1. Inestabilidad de la plataforma tecnológica.
Acostumbrado a la plataforma .NET en donde desde la versión 2003 hasta la 2010 se puede poner la mano en el fuego que un response.write va a funcionar correctamente, el trabajar en una plataforma que en cada revisión significa que el proyecto pende de un hilo y muy seguramente se paralice una semana, es desesperante.

2. Inestabilidad en la asignación de personal.
Es imposible cumplir los tiempos y la calidad si las personas asignadas a desarrollar  la aplicación va menguando en el tiempo, en sus horas asignadas o simplemente el equipo se queda sin desarrolladores  - aún teniendo recursos económicos asignados al proyecto.

3. Falta de experiencia y conocimientos del equipo.
Es un salto al vacio el asignar a un proyecto un equipo AL COMPLETO sin experiencia. Ni en la plataforma de desarrollo, ni en el lenguaje, ni en la tecnología, ni en la metodología. Es decir, desde el Jefe de Proyecto (quien escribe estas líneas) hasta el programador, todos sin experiencia en la plataforma tecnológica en la que se va a desarrollar.

4. Desarrollo “caja negra”.
Un auténtico proyecto “caja negra”. El cliente lo único que ha visto es un análisis funcional sobre los requisitos iniciales. Y cuatro meses después, mi experiencia personal es que puede acabar con un “muy bonito pero no es lo que quiero” como una catedral.

5. Aquí decide hasta el tato (menos el cliente).
Dos coordinadores, un gerente y un director. Todos opinando sobre la aplicación, todos decidiendo sobre la aplicación, todos forzando cambios en requisitos y desarrollos de ultimísima hora… ¿y la voz del cliente?.

6. Documentación antes que producto.
Un CMMI mal entendido, o aplicado. CMMI es una metodología de madurez. Implementas una serie de procedimientos que aumentan la visibilidad y trazabilidad de los procesos para encontrar donde se puede o debe mejorar. No es el objetivo es la herramienta.

Si pones al frente de un proyecto a un Jefe de Proyecto que nunca ha trabajado en CMMI, y no le echas una mano, pero le haces repetir cuatro y cinco veces cada documentación de cada una de las fases obtienes tres cosas:

1. Un retraso importante en el proyecto, hasta que la documentación se cumplimenta correctamente de acuerdo a todos (y son unos cuantos) cargos superiores que lo revisan y lo mandan a rehacer o retocar (a veces ni tan siquiera indicando de forma clara qué es lo que está mal). Añadiendo a ello, por supuesto, que las revisiones han sido realizadas totalmente fuera del plazo previsto (3 semanas para la primer revisión cuando no debe pasar más de un día en realizarse una vez realizada la documentación según la la implementación de CMMI).

2. El jefe de proyecto, desesperado, se salta la metodología y realiza la documentación por detrás. Por lo cual se pierde la trazabilidad y la visibilidad de los procesos y llegamos a la conclusión en que el primer proceso a madurar es la propia implementación de CMMI.

3. Caída de la motivación. Se convierte en una merienda de negros donde el Jefe de Proyecto, seguido a muerte por su equipo, tira pa’ lante del proyecto –picando código, adoptando todos los roles o lo que sea necesario - con la mirada puesta en la entrega y con ganas de “terminar la pesadilla”.  Lo cual casi siempre redunda negativamente en la calidad.

Moralejas:

• Que fácil es observar y criticar desde mi posición de Jefe de Proyecto. Y aún más fácil es echarle la culpa al Jefe de Proyecto por parte de los responsables superiores. Y que lejos está la labor de un Jefe de Proyecto desde la percepción de la dirección.
• Se aprende mucho de los éxitos pero MUCHO mas de los fracasos. Las correcciones son obvias y estoy mucho más preparado que antes para gestionar proyectos.