Seguro que has oído hablar de las metodologías ágiles en la gestión de proyectos y has pensado – “eso no es para mí”. Pero te equivocas
Tú puedes ser ágil también.
Bueno tu no. Tu eres un palo de escoba con patas.
Pero puedes ser ágil en tus proyectos o en tu empresa.
Así que, si quieres saber cómo la agilidad te puede ayudar en tu negocio no dejes de escuchar este episodio porque hoy vamos a hablar sobre agilidad. Pero agilidad en empresas de arquitectura e ingeniería.
Hola a todos y bienvenidos al episodio número venticinco de “Buscando el proyecto perfecto” un podcast basado en hechos reales.
Yo soy José Luis de la Rocha y algunas veces trabajo de arquitecto y otras de delineante, de director de proyectos o Ceo de mi empresa, pero siempre disfrutando de cada momento.
En este podcast os voy a contar mi experiencia sobre algunas cosas que podéis hacer para mejorar el resultado de los proyectos y de vuestra empresa.
ÍNDICE
01:24. Introducción.
03:36 Manifiesto ágil.
04:00. Valores.
05:10. Principios.
07:45. Ciclos de vida.
09.30. Ejemplo de sistema predictivo vs adaptativo.
14:42. Despedida
INTRODUCCIÓN
Bueno, y esto de la agilidad ¿qué es?
Pues te voy a contar desde el principio.
Desde que el hombre es hombre, se ha embarcado en el desarrollo de proyectos pequeños y grandes.
Para esos proyectos más grandes hacía falta un sistema que permitiera controlar que se consiguieran los objetivos esperados.
Durante muchos años, se han ido aprendiendo a hacer mejor los proyectos y los maestros fueron enseñando a otros esas técnicas.
Para más información sobre el tema escuchar el capítulo 9 “sobre project management”
La cuestión es que, durante la segunda mitad del siglo XX, se comenzaron a desarrollar metodologías muy completas para gestionar proyectos que iban cada vez perfeccionándose más y completándose más.
A esto se le junta que a final del siglo pasado aparece un nuevo sector de producción que antes no existía, apoyado en las nuevas tecnologías, y que se extiende de forma muy rápida: el desarrollo de software.
Imagínate un sector lleno de frikis informáticos a los que les das procesos y herramientas para organizar el trabajo.
Pues cuajó, de forma muy inmediata, la utilización de todas estas metodologías de gestión de proyectos.
Pero se encontraron con un problema que generaba los tradicionales sistemas de gestión de proyectos. Que eran muy rígidos para las necesidades de la informática.
Estos sistemas tradicionales se basaban en el modelo en cascada. Es decir, un enfoque secuencial y predictivo (quédate con esta palabra) en el que había que tenerlo todo definido durante la planificación, pero era muy complejo de gestionar cuando en los proyectos había que hacer cambios. Principalmente cambio de alcances.
Es decir, un cliente necesitaba una aplicación que hiciera tal y cual cosa, y cuando la programaban y la implementaban resultaba que no era funcional la forma en la que se había programado por lo que había que volver a programarlo todo. Esto generaba mucha carga de trabajo y desmotivación tanto en el equipo como en el cliente.
MANIFIESTO ÁGIL.
En esta situación surge en 2001 el “Manifiesto Ágil” que lo firman unos informáticos perezosos que no querían trabajar en planificación.
Este manifiesto es un conjunto de valores y principios para desarrollar software de calidad.
Concretamente son 4 valores y 12 principios que son los siguientes:
- Valores
- Individuos e interacciones sobre procesos y herramientas.
- Software funcionando sobre documentación extensiva.
- Colaboración con el cliente sobre negociación contractual.
- Respuesta ante el cambio sobre seguir un plan.
- Principios:
- Máxima prioridad es satisfacer al cliente
- Los cambios aportan valor
- Entregas con frecuencia.
- Desarrollo y negocio juntos todo el tiempo
- Confianza y autonomía de trabajadores
- Conversar cara a cara
- Trabajo que funciona es la medida del progreso
- Desarrollo sostenible
- Atención a la excelencia técnica y el buen diseño
- La simplicidad es esencial
- Equipos auto-organizados
- Reflexión y ajuste continuo.
CICLOS DE VIDA
Y tú te estarás preguntando.
¿Y a mí qué? Si yo hago proyectos de arquitectura.
Bueno, déjame seguir un poco desarrollando los conceptos de agilidad y veremos si tienen cabida en la arquitectura.
Siguiendo con la historia.
La implosión del manifiesto ágil en el sector del software hizo que se acogiera como enfoque principal de trabajo y comenzaron a desarrollarse metodologías que se basaban en estos principios como Scrum, Kanban, Extreme programming, etc…
Y a nivel práctico, este manifiesto trajo un cambio de paradigma en muchas áreas de aplicación de los proyectos, pero principalmente en el enfoque en el ciclo de vida.
Se pasó de desarrollar proyectos con una metodología predictiva (método de cascada) en el que se organizaba en base a un ciclo de vida completo del proyecto a un sistema de ciclo corto y más dinámico. Un ciclo de vida adaptativo.
Estos ciclos de vida de los proyectos se dividieron en tres tipos:
- Iterativo. Son ciclos cortos que se repiten durante el proyecto. La idea es ir mostrando la entrega cada vez con más funcionalidades y recibir retroalimentación de si vamos por el buen camino o no.
- Incremental. Es un ciclo en el que en cada vuelta se entrega un entregable terminado que el cliente puede utilizar.
- Ágil. Es una combinación de ambos. Sirve para proporcionar al cliente visibilidad del servicio e ir ganando confianza y control sobre el producto final.
Frente a esto está el sistema predictivo que ofrece un ciclo único y completo con toda la definición y funcionalidad del producto y que el cliente no podrá usar hasta terminarlo todo completo.
Para que lo entendáis mejor os voy a poner un ejemplo.
Imaginar un proyecto que consiste en preparar la comida para un día completo de senderismo en el campo.
En este proyecto sabemos cual va a ser el camino que vamos a realizar, cuanto tiempo estimado vamos a tardar y nuestra forma física.
El cliente nos pide que le preparemos un bocadillo (es nuestro entregable).
Como tenemos conocimiento de todo el esfuerzo que va a suponer el viaje vamos a poder validad fácilmente el volumen del bocadillo.
Le preguntamos al cliente que va querer en el bocadillo y tenemos una cantidad de ingredientes base como queso, jamón york, tomate, chorizo, etc (que serían nuestros costes, calidades, plazos, etc de un proyecto real) y todo lo vamos a integrar en un pan.
Cuando cerramos la planificación del proyecto (nuestro bocadillo) tenemos la garantía que el cliente lo va a necesitar completo para todo el camino.
Tanto el cliente como nosotros no tenemos incertidumbre sobre si el bocadillo se lo va a comer completo, la única duda es si le gustará.
Esto sería un ejemplo de un proyecto en el que la metodología predictiva aporta valor al entregable.
Pero pongamos otro tipo de proyectos.
Imagina que el cliente ha estado el día antes en una boda y se ha levantado tarde, sobre las 12.
Tiene hambre, pero no sabemos cuanta.
Si nos pide que le demos de comer, en este caso hacerle un bocadillo podría suponer un gasto excesivo, tanto de tiempo nuestro como de material porque pudiera ser que no tuviera mucha hambre o sí. No lo sabemos y le preguntamos al cliente y dice que no sabe, tampoco nos da muchas pistas de qué quiere.
En este caso probamos un enfoque ágil y preparamos un ciclo corto.
En vez de preparar un bocadillo le damos un zumo de naranja. Solo medio vaso, a ver que tal.
El cliente lo bebe y le preguntamos.
Nos pide algo de comer.
Le preguntamos por si quiere manzana o croissant.
El cliente le parece bien la manzana. Pero después nos pide algo más contundente. Nos dice que se tomaría otro zumo y algo más dulce.
Le preparamos otro medio vaso de zumo y le ofrecemos una tostada con mermelada o un trozo de tarta de chocolate.
Se decanta por la tarta.
Al final queda satisfecho y no hemos desperdiciado nada de comida.
Nos hemos adaptado al hambre y satisfacción del cliente.
Si le hubiéramos preparado el bocadillo nos hubiéramos equivocado seguro, en cambio con el sistema ágil hemos entregado valor rápidamente y el cliente se ha sentido parte del proceso.
Es verdad que, en el sector de construcción, nuestro producto principal: un edificio, por ejemplo. No podemos entregarlo parcialmente para que el cliente lo use y decida si quiere implementar cambios. O entregarlo sin ventanas a ver si le gusta al cliente.
En la fase de construcción es muy difícil implementar metodologías ágiles.
Pero en la fase de proyecto si, y en la de anteproyecto todavía más.
El sector de la construcción está abierto a trabajar con sistemas híbridos (mezcla de sistemas predictivos y adaptativos) de manera que se obtenga lo mejor de cada uno para optimizar lo más importante que no debemos olvidar nunca: la entrega de valor al cliente.
DESPEDIDA
Con esto llegamos al final del capítulo.
Si te ha gustado el concepto de agilidad en próximos capítulos iré desarrollando cómo son los directores de proyectos ágiles, como es una organización ágil y otros conceptos que seguro que podemos sacar partido para mejorar nuestro estudio.
Por último, quiero recordarte que además del podcast tengo una newsletter semanal donde hablo sobre estos temas, pero en píldoras más pequeñas. Si te interesa probar suscríbete en la web de https://arquitecturaeficiente.es/suscripcion/ y con esto podrás acceder también al canal de Discord.
Si te ha gustado, no olvides seguirme y recomendar este podcast a otros compañeros que también lo necesiten.
Y sin más me despido y nos vemos en el próximo programa.
FINAL
El otro día se me cayó un suscriptor de la newsletter.
Una pena.
Aunque ya son 90 y estoy muy contento con los seguidores todo va muy despacio.
Así no me llega para el Tesla.
Y el problema es la cantidad de gente que se está perdiendo estos capítulos y las newsletter por tu culpa.
Como diría Gandalf: “Compartir insensatos”