Agilidad y transformación digital contada con guiones de Matrix (4). El peligro de la gestión de proyectos clásica

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.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.

Latest posts by jgarzas (see all)

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *