El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático no es que vaya con mucho retraso. O que multiplique por tres el coste presupuestado. O que el cliente esté muy enfadado.
Eso ocurre en el 80% de los proyectos, tal como anticipa Pareto y nos confirma The Standish Group en sus informes ‘Chaos Report’
El peor escenario para un proyecto informático es la lluvia ácida. Y el Jefe de Proyecto es el único responsable.
Bienvenido a una sesión de méntoring de novanotio.
La lluvia ácida
Pero, ¿Qué es la lluvia ácida? Es la situación en que la resolución de incidencias interrumpe continuamente los trabajos de desarrollo.
Por supuesto, siempre hay incidencias en los entornos de producción. Por eso hay equipos de operaciones encargados de monitorizar los procesos, levantar las aplicaciones o corregir entradas inconsistentes en las bases de datos.
Cuando el equipo de operaciones no es capaz de restablecer el servicio, se produce una incidencia crítica que el equipo de desarrollo debe atender de manera urgente.
De la atención de incidencias a la lluvia ácida
Todos los desarrolladores hemos tenido que atender incidencias de producción en algún momento.
El problema aparece cuando esas incidencias son tan frecuentes que fagocitan el tiempo del equipo de desarrollo. He visto grupos dedicar mas del 70% de su jornada a solucionar incidencias.
Cómo se origina la lluvia ácida
La lluvia ácida tiene la misma dinámica que la bola de nieve que rueda ladera abajo. Crece y crece hasta convertirse en un monstruo ingobernable.
Es sencillo entender el hilo de pensamientos del Jefe de Proyecto que desemboca en esta situación:
- Quiero que mi cliente esté satisfecho.
- Y necesito que el proyecto no se retrase todavía mas.
- Así que, tenemos que solucionar rápidamente esta incidencia de producción.
- Y, además, hay que cumplir la planificación que hemos acordado.
Es una línea argumental con la que todos estaríamos de acuerdo, salvo por dos importantes detalles:
- Hagas lo que hagas, el 80% de los proyectos multiplicarán por tres su plazo y su coste. Lo predice Pareto. Lo confirman año tras año las estadísticas de nuestro sector. No puedes escapar del principio de Pareto como no puedes escapar de la ley de la gravedad.
- La cuarta ley nos advierte que alcance, plazo y calidad están interrelacionados, de forma que si fijas dos de ellos el tercero se degrada. Si mantienes el plazo y amplías el alcance (todo lo planificado más la resolución de las incidencias), la calidad se degrada.
La lluvia ácida aparece cuando sacrificas la calidad
El origen de la lluvia ácida es un Jefe de Proyecto que, presionado por su cliente, sacrifica la calidad.
Ese código desarrollado a toda prisa y que se pone en producción sin apenas pruebas, va a generar nuevas incidencias en producción, que poco a poco, van a consumir el tiempo disponible para el desarrollo.
Por eso, introduciendo presión en el equipo de desarrollo, no aceleramos los trabajos, sino todo lo contrario.
Por no hablar del incremento de la rotación, que aparecerá como un nueva causa de retrasos del proyecto.
Cómo soluciona Scrum el problema de la lluvia ácida
Scrum soluciona el problema de la lluvia ácida mediante dos mecanismos.
- El primero consiste en planificar dentro de cada sprint un cierto tiempo para atender incidencias en producción.
- El segundo es obligar a que sólo se entreguen al cliente los desarrollos que superen las pruebas funcionales.
Scrum asume que hay que atender incidencias y que no se van a completar todos los trabajos planificados para el sprint. Pero se asegura que aquello que se entregue esté convenientemente probado.
Scrum evita la aparición de la lluvia ácida asegurando la calidad.
Y para asegurar la calidad sacrifica el alcance . Es decir, aplica la cuarta ley de gestión de proyectos informáticos.
Resumen
La posición de Jefe de Proyecto no es sencilla. Con independencia de tu experiencia o la de tus desarrolladores, el 80% de tus proyectos van a sufrir importantes retrasos y sobrecostes.
Si intentas acelerar los proyectos metiendo presión a tus equipos, vas a empeorar la situación.
No solo ralentizarás los desarrollos porque los programadores están cansados. Aparecerán efectos de segunda ronda como la lluvia ácida y la rotación, que dilatarán todavía más tu planificación.
Si has seguido las sesiones de méntoring de novanotio, ya sabes cómo evitar la aparición de la lluvia ácida:
- Garantiza la calidad, sacrifica el alcance (4ª ley de gestión de proyectos informáticos).
Y además:
- Quita presión a tus equipos de trabajo (3ª ley de gestión de proyectos informáticos).
- Prioriza los desarrollos que mas valor aportan (Principio de Pareto).
- Y gestiona las expectativas de tu cliente (1ª ley de gestión de proyectos informáticos).
La metodología Scrum puede ayudarte a conseguir todos estos objetivos.
Gracias por compartir el artículo si te ha parecido interesante y nos vemos en la próxima sesión de méntoring de novanotio.