He encontrado otro ¡bien!. Desde hace unas semanas, te he estado dejando guiones adaptados de Matrix, que hice hace unos 2 años, con el objetivo de ayudar a la difusión de buenas prácticas de gestión, prácticas ágiles, management 3.0, peopleware, la hoy tan nombrada transformación digital, etc. Nunca llegué a liberar aquel material, que estaba prácticamente perdido y que estoy liberando para compartirlo contigo… en un disco duro si que no hace nada de nada.
He encontrado otro de esos guiones, así que lo podemos añadir a los anteriores 3 post, en los que te dejé los siguientes guiones adaptados:
– Agilidad y transformación digital contada con guiones de Matrix (1) La importancia del software en cualquier negocio actual
– Agilidad y transformación digital contada con guiones de Matrix (2) Deuda Técnica
– Agilidad y transformación digital contada con guiones de Matrix (3). Management 3.0, Peopleware
En este caso el guión deriva de esta súper mítica secuencia de Matrix y la adaptación, en este caso, va sobre el peligro de llevar al software la gestión de proyectos clásica…
.
.
—MORFEO: Smith, lo que te han contado en Mátrix, de que la gestión un proyecto software debe ser similar a como se gestionan proyectos en la industria o en la arquitectura… es una ilusión y un error que nos han hecho creer.
—SMITH: ¿Ilusión? la gestión de un proyecto software debería ser igual, deberíamos imitar a aquellos que saben construir coches o casas… Para construir bien cualquier cosa, incluso en software, necesitamos, como hacen los arquitectos con sus edificios, de un diseño previo a la construcción, y para ello de unos requisitos cerrados para para empezar a trabajar
—MORFEO: Este es un error que hemos arrastrado desde la primera conferencia sobre ingeniería software, en 1968. Desde entonces hemos copiado los modelos de gestión de otras profesiones, como la arquitectura o la industria. Es el ciclo de vida en cascada Smith. Una mala copia del modelo de gestión de la arquitectura y la industria. Gestión predictiva, fases que se hacen una única vez con el intento de predecir lo que pasará en las siguientes.
—SMITH: Para gestionar software debe haber un plan, un Gantt por ejemplo, detallando qué se va a hacer durante el proyecto y qué se esperaba ir obteniendo. El plan se hace antes de empezar el proyecto. Y para hacer un plan hay que saber qué se quiere obtener, es decir, hay que tener requisitos cerrados. Y, listo el plan, el éxito del proyecto se basa en cumplir tiempos y presupuesto.
—MORFEO: Maravilloso… sino fuera por una cosa, listo tu plan, concentrado exclusivamente en cumplir tiempos y presupuestos, pasas por alto si aquellos requisitos en los que te basaste… eran correctos. O si han cambiado mientras el proyecto se desarrollaba. Esto incluso te puede llevar a situaciones absurdas, como cumplir tiempos y presupuestos… habiendo creado un producto que nadie quiere, requisitos erróneos.
—SMITH: No obstante, durante años y años, innumerables proyectos han trabajado así. Requisitos cerrados, luego una planificación, obteniendo un plan, y basándose en el cumplimiento de tiempos y de presupuesto. Y los productos, en mayor o menor medida, cumplían requisitos.
—MORFEO: Cierto, hasta que llegó un momento en que cambiaron cosas. La primera es que la variabilidad de los requisitos se disparó y se disparó porque los negocios se basan cada vez más en innovación de base tecnológica, productos y negocios cada vez más innovadores, de los que es muy difícil “cerrar” requisitos. Si el plan depende de los requisitos y queremos tener éxito… ¿qué opciones hay?
—SMITH: Una es cerrar los requisitos…
—MORFEO: Sí, aún hoy algunos proyectos se empeñan en ello… pero cada vez es más difícil. Los desarrollos de hoy en día son cada vez más innovadores. Pero hay otra opción obvia… que los planes no dependan de los requisitos, que los planes puedan cambiar. Si hay requisitos cambiantes… debe haber planes adaptables.
—SMITH: ¿Y cómo pretendes entonces obtener los requisitos?
—MORFEO: El usuario sabe lo que quiere cuando lo ve. Cambiar requisitos lo más tarde posible incluso es una ventaja competitiva. En vez de encabezonarse en cerrarlos… ¿por qué no aprovecharlo para sacar partido? Saquemos prototipos operativos rápidamente, con pocos requisitos, enseñémoslos y que sea el usuario quién diga qué quiere. Mucho más efectivo, eficiente y rentable.
—SMITH: ¿Algo más? ¿Más razones que justifiquen el cambio?
—MORFEO: Sí, que “sí hoy no te mueves a la velocidad del mercado ya estás muerto”, y la velocidad ha aumentado mucho. Y esto, entre otros, ha pasado porque llegó la época cloud, las aplicaciones móviles, etc., hoy no hay excusa para demorar meses la entrega de una nueva, pequeña, aparentemente mínima funcionalidad, como se hacía en el cascada.
—SMITH: ¿y qué propones?
—MORFEO: Requisitos que puedan cambiar y, por ello, planes adaptables, que el éxito no sólo se mida en tiempo y presupuesto, y que entre en juego hacer algo que valga para algo. Y entregar funcionalidad muy rápido, en días, para no ser expulsado del mercado, para además captar rápidamente verdaderas necesidades…
—SMITH: ¿Y qué necesitaríamos para ello?
—MORFEO: Muchas cosas, pero voy a poner dos en lo alto de la lista. La primera, un ciclo de vida basado en prototipos potencialmente entregables, operativos, iterativo e incremental, con iteraciones lo más cortas posibles, semanas o menos, lo que algunos llaman ciclo de vida ágil. La segunda, equipos altamente productivos y basados en talento. Una nueva manera diferente de trabajar en la que incluso la palabra planificación pierde sentido. Un cambio cultural asentado en buenas prácticas.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024