domingo, 6 de noviembre de 2011

¿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.

7 comentarios:

  1. Hola muy buenas tardes,

    Trabajo en una pequeña empresa de desarrollo de software en México somos unas 15 personas entre desarrolladores y de soporte y de casualidad caí en tu blog y me pareció muy interesante ya que se refiere a algo que estoy viendo en este momento en mi trabajo, me solicitaron que hiciera una carta para entregarle a nuestros clientes al finalizar un proyecto o después de darles algún soporte de mantenimiento a modo de que estén ellos de acuerdo del trabajo realizado en sus empresas y sea firmado por ellos al momento que esta carta sea entregada por el personal de soporte al finalizar el servicio, no sé si me podrías decir si conoces alguna página o de algún formato que conozcas en el que yo me pudiera basar para hacer este documento, agradezco cualquier ayuda que me puedas brindar ya que desconoce estos temas de calidad, gracias.

    ResponderEliminar
    Respuestas
    1. Hola, te agradezco el comentario. En primer lugar me sorprende el que no tengáis a nadie de calidad. La metodología no es un lujo. Trabajar sin procesos es como ir en el coche sin frenos, sin dirección...falta lo básico.

      Centrándonos en tu problema, te diré que me es difícil darte una respuesta directa sin violar mis restricciones de confidencialidad. Pero trataré de encaminarte en una solución.

      Si no he entendido mal, tienes varios tipos de problemas a resolver, y que tienen poco que ver:
      a) Carta de aceptación.
      b) Informe de fin de proyecto
      c) Informe de fin de mantenimiento.

      Prepararé uno o varios posts en los próximos días que espero que respondan a tu duda.

      Eliminar
    2. Se me olvidaba. Mientras preparo posibles respuestas, puedes ojear los excelentes enlaces que encontrarás en "Sitios amigos", y en tu caso, sobre todo los de BerriProcess y el blog de Teodora Bozheva.

      Por supuesto, echa un ojo en mi blog a los artículos relacionados con métricas, pueden orientarte.

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

    ResponderEliminar
    Respuestas
    1. Hola, tengo un poco abandonado este Blog, lo siento. A ver si lo retomo. Sobre tu pregunta, en este blog me centraba en un caso particular, y es el cierre de proyectos de implantación o desarrollo en su período de garantía. Evidentemente, hay un criterio evidente que es el contractual. Pero es habitual poner en los contratos cláusulas en las que se exige al proveedor de desarrollo que te siga dando soporte post-implantación. Es decir, una vez entregado el software, hay incluido por contrato un período de soporte. Al hablar de factores cuantitativos, me refiero a que se pueden incluir cláusulas en el contrato que establezcan esas fórmulas o criterios de estabilidad de la solución entregada, en lugar de basar el cierre del proyecto simplemente en una fecha. De esa forma, el comprador se asegura de que el vendedor no deja pasar el tiempo (dejándote un software que no funciona), sino que hay un indicador cuantitativo/cualitativo de que el software es estable funcionalmente, etc.

      Eliminar