¿Cuándo se puede dar por terminado un proyecto?

Vaya. Esta vez he dejado pasar unos cuantos días desde mi último blog. Y es que mi últimos proyectos me estaban absorbiendo por completo.

Vamos a tratar un tema que tanto en las metodologías, como en los distintos entornos de trabajo, siempre se da por supuesto, y se deja un poco al azar. Y es que ¿tenéis claro cuándo se puede cerrar un proyecto?

Parece algo trivial, ¿no? Cuando el proyecto se termine...se habrá acabado y por tanto, se cierra. Pues no.Vamos a introducir algunos conceptos para entender de qué hablamos:

• Cierre: se denomina cierre de un proyecto, al final del desarrollo. En realidad, el desarrollo no termina cuando se produce la subida al entorno de producción. Un desarrollo termina...cuando así lo determina el contrato. Y es que por contrato (y así lo suelen recoger las metodologías), se incorpora un período de soporte distinto del de mantenimiento. Se le suele llamar soporte post-implantación (aunque el nombre puede variar según la metodología que tratemos).
• Soporte: como acabamos de comentar, se llama soporte al período posterior a la puesta en producción (el Go-Live en tecnologías SAP). El soporte lo realiza el mismo equipo de desarrollo, y aunque sus actividades suelen ser similares a las de mantenimiento, existen diferencias con la fase de mantenimiento. Por ejemplo, no aplican los ANS.
• ANS: acrónimo de "Acuerdos de Nivel de Servicio". Son las condiciones de servicio que por contrato, estipulan la forma de colaboración entre el proveedor del servicio y el contratista. Suele incluir penalizaciones y/o bonificaciones en función de varios parámetros como pueden ser el tiempo de respuesta, la calidad del servicio, etc.
• Mantenimiento: es la fase del ciclo de vida del software que tiene lugar tras el cierre (no tras la puesta en producción). Tras la puesta en producción, hay un período de soporte en el que el proveedor del desarrollo software ha estabilizado la solución, se produce el hito del cierre, y después, el inicio de la fase de mantenimiento. Esta fase de mantenimiento la puede llevar a cabo un proveedor distinto del de desarrollo (otra empresa diferente).

Y tras este rodeo de explicaciones, volvamos al tema. Tras el desarrollo, hay un período de soporte, normalmente de tiempo limitado. Pero...¿debemos dejar que un software erróneo, inadecuado o inestable pase a la fase de mantenimiento? ¿Cómo sabe el cliente que el producto que ha recibido y que ya está en producción, está como para dar salida al proveedor de desarrollo? Recordemos que es en este punto cuando suele terminar de cobrar el proveedor de desarrollo. El cliente no querrá terminar de pagar por un producto hasta que este no esté correcto, pero...¿qué entendemos por correcto?

Es en esta situación, en la que un proceso de cierre entra en acción, definiendo una serie de parámetros que permitan de forma cuantitativa identificar si la solución desarrollada está Ok o no. No se trata de que no tenga errores. De eso, ya se encarga el mantenimiento que se hace tras el cierre del proyecto. Se trata de demostrar estabilidad y madurez tanto en la solución desarrollada, como en su implantación.

Normalmente, en todas las metodologías, la forma de realizar verificaciones (peer review, auditorías, milestone reviews, etc) es mediante checklists de control. Sin embargo, estas checklists de control no suelen incluir factores cuantitativos. Aquí es donde las métricas suelen venir al rescate, incorporando factores cuantitativos.