Una vez puesto en marcha el proyecto, conviene seguir algunas normas básicas para su seguimiento. Una forma habitual de hacerlo es mediante las reuniones de seguimiento. El que más y el que menos ha pasado y pasa por unas cuantas (muchas) de estas reuniones que, salvo en proyectos pequeños, son un clásico. De nuestras experiencias en todos los proyectos eh que hemos participado, a continuación os dejamos un pequeño listado de lo que más solemos echar en falta en una reunión de seguimiento.
No nos alargaremos mucho, pero si durante no más de una hora, cada Viernes (el día habitual para las reuniones de seguimiento …), revisas los siguientes puntos, minimizarás la posibilidad de llevarte un susto y de que existan cosas que estén bajo tu control.
1. Riesgos y su estado
No nos referimos a unos riesgos genéricos, obsoletos, y puestos por cumplir con la tarea de identificarlos. Nos referimos a unos riesgos reales, con su probabilidad de materializarse y un plan de mitigación e impacto.
2. Avance del proyecto
Esto puede parecer una obviedad, pero falla en la mayoría de los proyectos: conocer el avance del proyecto con un mínimo grado de realismo. Lo cual excluye completamente la consideración de porcentajes tentativos a partir de diagramas de Gantt: Diagramas Gantt cómo arma de destrucción masiva de proyectos. Por favor, no los utilicéis.
Hasta ahora la manera más fiable que ha descubierto la humanidad de calcular el avance (real) de un proyecto es fijándose en la funcionalidad entregada (programada, probada y lista para pasar a producción).
3. Estado de la calidad del software
Rara vez un informe de seguimiento de proyecto tienen en cuenta cuál es la calidad del producto desarrollado hasta el momento. Y la mejor forma de saberlo es disponer de un informe cuantitativo, extraído directamente de la información que hay en los ficheros que contienen el código fuente del proyecto. Es decir, utilizar cualquiera de las herramientas existentes para obtener de forma automática métricas del código fuente. Lo demás olvidadlo: la verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más.
Bueno, estamos dando por hecho (y en ocasiones esto es mucho suponer), que quien lleva el seguimiento del proyecto sabe dónde están los fuentes y accede a ellos con cierta frecuencia (cosa que no siempre ocurre), no sólo los ve al final de proyecto. Bueno, pues dando por sentado que efectivamente esto fuera posible, para controlar la calidad bastará con seleccionar un par de métricas clave, y registrar su evolución en el tiempo con una simple gráfica.
4. Una demo de la funcionalidad real implementada
Nada de presentaciones de PowerPoint o similares. Ni siquiera videos. Hablamos de demos reales en pre-producción (o producción si fuera posible) que se muestran en cada reunión de seguimiento.