No sé, creo que esto debo haberlo contado como 60 veces en mi vida, o más. Pero es cierto, sí, no está demás volver a repetirlo. Y, sí, también es cierto que aunque está contado por el blog, en muchos sitios, no está en un único post dedicado, para dejarlo clarito. Vale. Y van dos post, de 100 que podrían ser, el de hoy y mañana.
La planificación clásica, la tradicional, la heredada de la gestión de la construcción de cosas físicas (coches, casas, etc.), se basaba, y basa, porque aún en tecnología es la más usada, precisamente en eso, en tener un plan.
Para ello, había una fase, se dedicaba un tiempo, a planificar y como resultado salía un plan (que hasta incluso, a veces, se pintaba en un Gantt, de esos peligrosos). Un plan de qué se iba a hacer durante el proyecto y qué se esperaba ir obteniendo. Lógico ¿no?
El plan se hacía antes de la ejecución del proyecto. El plan era una predicción, una proyección al futuro, de qué se supone que pasará durante el proyecto y qué habría que hacer.
Para hacer el plan del proyecto había que saber qué se quería obtener con el miso, lógico, es decir, había que tener requisitos. Cerrados los requisitos, se planificaba y se obtenía un plan. Y, listo el plan, el éxito del proyecto se basaba en cumplirlo, es decir, cumplir los tiempos y el presupuesto.
Dicho lo anterior, todo se preveía maravillosamente, sino fuera por una cosa que solía llevar al traste a los proyectos, o siendo más exactos, a los productos resultantes de los mismos. Tan concentrados estábamos en cumplir tiempos y presupuesto que en ocasiones pasamos por alto si los requisitos eran los que debían ser o si habían cambiado mientras el proyecto se desarrollaba.
Esto incluso llevaba a situaciones sin sentido, cumplimientos de tiempos y presupuestos, es decir, “éxito” del proyecto… pero habiendo creado productos que nadie quería, requisitos erróneos.
No obstante, el tiempo pasó, durante años y años innumerables proyectos trabajaban así. Requisitos, planificación, plan, cumplimiento de tiempos y de presupuesto. Los productos en mayor o menor medida cumplían requisitos, muchos erróneos o otros no. Pero ahí íbamos, tirando. Ya hasta nos habíamos acostumbrado a trabajar así. No era lo mejor pero bueno, había experiencia en ello.
Hasta que llegó un momento en que pasaron tres cosas, tres cosas ya sabidas desde hace años, pero que se dispararon…
1 – La variabilidad de los requisitos se disparó
La primera es que la variabilidad de los requisitos se disparó y se disparó porque los negocios se basaban cada vez más en innovación sobre tecnología, productos y negocios cada vez más innovadores, de los que era muy difícil “cerrar” requisitos.
Si el plan dependía de los requisitos y queríamos tener éxito en el plan había dos opciones. La primera, que es la que la mayoría intentó, cerrar los requisitos, estabilizarlos. Pero, aunque aún hoy algunos se empeñan en ello… era imposible. Los desarrollos de hoy en día son cada vez más innovadores. La segunda opción era obvia… que los planes no dependieran de los requisitos, que los planes pudieran cambiar.
Si había requisitos cambiantes… debería haber planes cambiantes o adaptables. Lógico.
2 – La mejor manera de descubrir los requisitos era enseñando prototipos operativos al usuario
La segunda era otra que ya se sabía desde hace años, pero que incluso llegó a estar censurada. Era la de que un usuario realmente sabía lo que quería cuando lo veía. Era la de que meter nuevos requisitos lo más tarde posible incluso era una ventaja competitiva. Era, como decía Steve Jobs, aquello de que el usuario sabe lo que quiere cuando lo ve.
Así que algunos, astutos, en el problema vieron la oportunidad. Si los requisitos cambiaban, y eran en los últimos años cada vez más inciertos, en vez de encabezonarse en cerrarlos para volver al patrón de éxito igual a tiempo y presupuesto… ¿por qué no aprovecharse para sacar partido?
En vez de tener analistas cerrando papeles de requisitos que al final acababan fallando… saquemos prototipos operativos rápidamente, con pocos requisitos, enseñémoslos y que sea aquel quien usará, o comprará, el producto quién me diga qué quiere. Mucho más efectivo y eficiente (y rentable).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Planificación ágil: no revista mediante técnicas psicológicas de autoridad a nadie. La autoridad emana de la competencia de cada cual: cuanto (no contra, por favor, que a ninguno nos enseñaron eso en clase de lengua, por muy incompetente que fuera el profesor) más competente eres más autoridad tienes.
Ahora. Puedes ser competente de dos formas: currando o viendo como se lo curran los demás. A mí la última me toca bastante las narices y desde luego no me motiva una shit y más por cacahuetes.
Está claro que las metodologías Ágile han solucionado algunos problemas. ¿Pero cómo se presupuesta con estas metodologías? Todavía no di respuesta a esa pregunta.
Tienes claro lo que hay que presupuestas, los requisitos? ¿y tienes claro que son esos, que no faltan y que no van a cambiar?