Curva del coste del cambio

¿Por qué sube el coste de un cambio a lo largo del proyecto?

La razón está en la cantidad de trabajo que se apoya en una decisión. Mientras un requisito solo figura en el concepto, cambiarlo afecta a un documento. Si ya está en el diseño, afecta al diseño y a todo lo derivado de él. Si está implementado y aceptado, se añaden el retrabajo, una nueva verificación, la documentación y la comunicación. Por eso la curva no sube de forma lineal, sino aproximadamente exponencial.

¿De dónde viene la curva y sigue vigente?

Las cifras se remontan a Barry Boehm, que las dedujo de datos de proyectos en «Software Engineering Economics» en 1981. Para proyectos clásicos con una ejecución cara, por ejemplo en construcción, en ingeniería de plantas o en eventos, la relación sigue vigente. Lo que se cambia en la obra cuesta muchas veces más de lo que habría costado el cambio en la planificación.

En el desarrollo de software la curva se ha aplanado notablemente. Las pruebas automatizadas, la integración continua y las entregas pequeñas reducen mucho el coste de un cambio tardío. Kent Beck formuló a partir de ahí la tesis contraria: si la curva es plana, fijar las cosas pronto deja de compensar, porque entonces se puede decidir en el momento en que más se sabe.

La forma que adopta la curva depende por tanto del proyecto, no del método. Sube con fuerza donde la ejecución es cara y los resultados se apoyan unos en otros, como en construcción o en migraciones. Se mantiene plana donde las correcciones son baratas y se pueden verificar de forma automatizada. La pendiente determina en qué fase del ciclo de vida del proyecto una decisión conserva su valor.

¿Qué implica la curva para la planificación del proyecto?

• Aclarar los requisitos pronto: Una declaración de trabajo por escrito y una revisión antes de cada cambio de fase llevan la aclaración allí donde cuesta poco.
• Cerrar las fases con hitos: En el desarrollo en cascada, cada hito marca una decisión sobre la que se apoya la fase siguiente.
• Cuantificar los cambios tardíos: Cada cambio desplaza coste, plazo o alcance dentro de la triple restricción. Cuantifique ese efecto antes de aprobarlo.

Ejemplo: Durante la construcción de un edificio de oficinas, el promotor quiere mover un tabique. En la fase de diseño, el arquitecto cambia un plano. Si el tabique ya está levantado, se suman la demolición, un tabique nuevo, la instalación eléctrica, el enlucido y la pintura, además de una nueva fecha para la recepción.

¿Cómo deja constancia de las decisiones en Merlin Project?

Para aprovechar la curva, necesita ver más tarde qué estaba planificado en el momento de una decisión. Merlin Project guarda todo el historial del proyecto en cada documento y trabaja con una línea base dinámica. No necesita guardar una línea base a mano.

1. Coloque un hito al final de cada fase con Insertar › Hito (Alt+Cmd+M), por ejemplo «Diseño aprobado».
2. Tras un cambio, abra Archivo › Ajustes del proyecto (Cmd+;) e introduzca la fecha de la aprobación en el campo Fecha de referencia.
3. Todos los campos planificados muestran ahora los valores de ese día. En el diagrama de Gantt aparecen como barras de referencia grises junto a las barras actuales.
4. Las vistas Comparación planificado/real (tiempo) y Comparación planificado/real (coste) muestran las desviaciones en forma de tabla.

Así ve qué ha desplazado un cambio tardío en plazos y costes. La línea base dinámica y las vistas de comparación solo están en Merlin Project, no en Merlin Project Express.