Richard E. Fairley en un artículo para la IEEE "Why the Vasa Sank: 10 problems and some antidotes for software projects" presenta un análisis de las razones del naufragio del "Vasa" y cómo ciertas consideraciones en la gestión de proyectos hubiesen cambiado el escenario fatal. En este artículo revisamos esos problemas con las soluciones desde el punto de vista de
CMMI.
Naufragio del Vasa, problemas con el proyecto
Vasa fue una nave de guerra sueca construida para el rey Gustavo II Adolfo de Suecia, que naufragó en su primer viaje en 1628 en el puerto de Estocolmo. El hundimiento fue provocado por un leve viento que hizo volcar la pesada nave de 80 toneladas, que al parecer no llevaba bien amarrada la carga y que finalmente sosobró.
La nave fue construida con presiones de tiempo, cambios constantes y nula planificación. Las innovaciones que consideraba no fueron adecuadamente probadas e integradas con las restricciones técnicas. Como resultado, un navío impresionante digno de un rey pero que era incapaz de navegar.
Soluciones a problemas con CMMI
La presión excesiva para cumplir compromisos en tiempo se puede compensar con una adecuada planificación (PP) que considere una estimación precisa y realista que permita controlar el proyecto y detectar desviaciones que pueden afectar los resultados, asignar más recursos para compensar el esfuerzo que se requiere y establecer un ciclo de vida que considere mayor certeza sobre el entregable. En cuanto a los requisitos (REQM) es importante definir prioridades para los requisitos y diferenciar los que no son necesarios.
Los constantes cambios a requisitos deben ser considerados en la selección del ciclo de vida (PP) que permita evolucionar el producto en la medida que se "descubren" las nuevas necesidades o los cambios. Es vital llevar control de los cambios (REQM y CM) así como gestión de componentes por medio de líneas base que controlen la evolución de los mismos. De igual forma la gestión continua de riesgos (RSKM) y el establecimiento de la arquitectura (TS) que permita integrar nuevas necesidades en la medida que evoluciona y se va entendiendo el producto.
La carencia de especificaciones técnicas se adolece cuando el producto se hace más complejo y eventualmente lo será, con lo cual el mantenimiento se dificulta y se incrementan los costos por lo que no habrá oportunidad de generarla. El establecimiento de las especificaciones en las etapas iniciales del desarrollo, tanto a nivel de los requisitos (RD) como de la arquitectura de solución (TS), es importante para acomodar las actualizaciones posteriores y controlar los cambios que van a surgir.
La falta de un plan de proyecto es causado por la confianza en que el proyecto es familiar y avanzará sin problemas, pero la realidad es otra. Una adecuada planificación cuando todo parece sencillo es mucho más fácil que cuando empieza la crisis y no hay tiempo de planificar. Establecer y actualizar el plan de proyecto (PP) con un seguimiento efectivo para identificar desviaciones (PMC) como parte de las funciones del responsable de proyecto permiten tener el control sobre los resultados y evitar sorpresas no previstas.
El descontrol de las innovaciones puede resultar en un proyecto fracasado. Es importante acomodar las innovaciones en relación con los requisitos establecidos y garantizar la autoridad para alinearlas con la arquitectura establecida para mantener la visión e integridad del producto. El adecuado control de la evolución del producto mediante líneas base (CM) y la evaluación del impacto de los cambios en la arquitectura propuesta garantizan el control de la innovación, así como la gestión continua de riesgos (RSKM) que puede anticipar problemas en el futuro.
La falta de control sobre los parámetros técnicos afecta el desarrollo del producto y el análisis del impacto que los cambios pueden tener en su desempeño. Es importante establecer los atributos de calidad (RD), considerarlos en las especificaciones técnicas del producto (TS) e irlos revisando en la medida que se construye y evoluciona el producto (VER y VAL)
En todos los casos el sentido común puede ayudar a identificar y evitar esos problemas, la comunicación efectiva dentro del equipo y con los interesados, escuchar los puntos de vista y las señales que se están mandando durante el desarrollo del producto. Todo ello cobijado con una visión del negocio, los intereses del grupo y un código de ética y valores que caractericen el comportamiento de los individuos puede marcar la diferencia entre un desarrollo exitoso y un terrible "naufragio" del proyecto.
Que problema!
ResponderEliminarÉxitos con el blog!
Saludos!
Fernando.
marketing btl
Muchas gracias por el comentario.
ResponderEliminar