Cascada vs Agile
Hace unos días, en las noticias, una persona de la Administración se quejaba de que están quedando desiertas licitaciones. En concreto hablaba de obras que se quedan sin que se presentara ninguna empresa.
Esta persona atribuía esta falta de ofertas a la subida de los precios de las materias primas, al precio de la electricidad, la crisis de transporte etcétera.
Pero ¿realmente es solo eso? o tendríamos que cambiar el planteamiento que se está haciendo respecto a determinadas cuestiones.
Esto me ha hecho reflexionar sobre cómo se afrontaban los proyectos cuando yo empecé a trabajar como ingeniera hace más de veinte años y cómo ahora en un momento en el que las condiciones del entorno son muy inestables.
La diferencia entre afrontar un proyecto con una visión en cascada o desde un punto de vista de filosofía agile.
Hace 20 o 30 años nos enfrentábamos a los proyectos con un enfoque en cascada. Se definían muy bien las especificaciones entre el cliente y el suministrador en reuniones en las que finalmente se llegaba a definir lo que se quería y luego venían una serie de etapas hasta la entrega al cliente.
Si todo estaba de acuerdo a lo que el cliente quería, fenomenal, pero como no solía ser así pues vuelta a empezar.
En estas etapas, iba pasando mucho tiempo entre una y la siguiente y los departamentos involucrados son bastante estancos. Esta forma de trabajar se demora mucho en el tiempo y asumimos el riesgo que cuando le entregamos algo al cliente no sea lo que quiere porque no le hemos entendido bien o la circunstancias han cambiado de manera que lo que necesita el cliente en este momento es algo diferente.
En contraposición a este sistema de trabajo están las formas de trabajo ágiles en las cuales cualquier proyecto se subdivide en tareas con funcionalidades pequeñas y se va trabajando mediante sucesivas iteraciones.
Por ejemplo en desarrollo de software con este tipo de metodologías se van entregando en distintas etapas diferentes funcionalidades al cliente.
De este modo se está interactuando continuamente con el cliente. Desarrollamos una primera funcionalidad con las mismas fases, diseño, pruebo y se entrega al cliente. En el caso de que el cliente esté satisfecho seguimos adelante y si no volvemos a la primera fase.
Al subdividir el proyecto en funcionalidades que podemos ir entregando a nuestro cliente, lo que hacemos es reducir el riesgo inherente a cualquier proyecto. Además dedicamos menos recursos y menos tiempo a desarrollar cada una de las funcionalidades parciales de lo que vamos entregando al cliente.
Por este motivo, volviendo a la noticia de la que hablaba, quizás no solo debamos plantearnos cómo desarrollamos los proyectos sino también cómo se piden.
En este caso el cliente es la administración que está pidiendo algo y lo está pidiendo como lo quiere ahora pero tiene que satisfacer las necesidades dentro de cinco o diez años y ni siquiera sé cuál va a ser el escenario en ese tiempo.
Si por ejemplo está pidiendo la construcción de un hospital pero ni siquiera sabe cómo van a operar los cirujanos dentro de un tiempo, de forma presencial o en remoto. Quizas la realidad aumentada y virtual han evolucionado tanto que necesito otro tipo de instalaciones o de edificaciones.
Mi reflexión es que quizás tengamos también que plantearnos desde el punto de vista de cliente como pedimos los proyectos. Si tiene sentido pedir de una manera tan ambiciosa cuando las condiciones del entorno en cuanto a sociedad y en cuanto a evolución de la tecnología son tan cambiantes.
os cirujanos dentro de un tiempo, de forma presencial o en remoto. Quizas la realidad aumentada y virtual han evolucionado tanto que necesito otro tipo de instalaciones o de edificaciones.
Mi reflexión es que quizás tengamos también que plantearnos desde el punto de vista de cliente como pedimos los proyectos. Si tiene sentido pedir de una manera tan ambiciosa cuando las condiciones del entorno en cuanto a sociedad y en cuanto a evolución de la tecnología son tan cambiantes.