La gestión de riesgos en entornos ágiles.

La gestión de riesgos es una práctica archiconocida que tradicionalmente ha formado parte de la gestión de proyectos en cascada o waterfall donde comenzamos con las fases de planificación, análisis y diseño y terminamos con el testing y la puesta en producción. Para aquellos que os habéis formado principalmente en entornos Agile, mejor empezamos echando un vistazo a la definición de riesgo.

Según la RAE, es “la posibilidad o proximidad de un daño”. Dentro del contexto del desarrollo de software podemos decir que es una incertidumbre que podría llegar a generar una situación comprometida y, por tanto, llevarnos al fracaso. Pero no hay nada más ilustrativo que ver ejemplos. ¿Estos riesgos lo son realmente?:

• [NO] Un problema en el entorno de producción nos está impidiendo hacer releases.
• [NO] La funcionalidad que estamos desarrollando depende de que otro equipo termine su parte.
• [SÍ] Contamos con un único desarrollador frontend en el equipo.
• [SÍ] El ritmo de entrega del equipo no es suficiente para entregar el MVP dentro de fechas.

El primer ejemplo no es un riesgo. Quizá lo fue en el pasado pero ahora se ha convertido en una realidad y, por tanto, en este caso, hablamos de bloqueo.

El segundo ejemplo tampoco lo es y de hecho nos da pistas. Lo que tenemos es un impedimento que nos está ralentizando debido a una dependencia sin resolver. La gestión de dependencias es otra práctica muy recomendada sobre la que podría escribir largo y tendido en otra publicación.

Los dos últimos ejemplos sí encajan en la descripción de riesgo. Tenemos dos afirmaciones que con mayor o menor probabilidad podrían derivar en un impacto en el proyecto. Por ejemplo, cuando ese único desarrollador frontend abandone el equipo.

Ahora que entendemos qué es un riesgo, vamos a analizar las razones y necesidades de hacer una gestión de riesgos.

¿Por qué gestionar riesgos?

La pregunta sería más bien por qué no hacerlo. La gestión de riesgos consiste básicamente en registrarlos cuando se detectan, revisar su estado a lo largo del tiempo y acordar acciones correctivas que ayuden a evitarlos o, al menos, mitigarlos. No es aparentemente una ardua tarea que, sin embargo, nos reporta muchos beneficios a la hora de gestionar un proyecto. Entre esos beneficios destacan los siguientes:

• Anticipación a los problemas: pasamos de ser reactivos a ser proactivos, lo cual aumenta la probabilidad de éxito.
• Mayor alineamiento con el cliente: trabajamos los riesgos regularmente y proponemos mejoras o acciones correctivas en común.
• Gestión de las expectativas con el cliente: con la gestión de riesgos aportamos transparencia y compartimos una visión más realista del estado del proyecto, lo cual nos ayuda a centrarnos en colaborar en lugar de tener que convencer o justificarse continuamente.
• Gestión de la incertidumbre: es inevitable e inherente a un proyecto y va reduciéndose a medida que avanza dicho proyecto. Haciendo una buena definición y seguimiento de riesgos reducimos la incertidumbre desde el inicio.

Si, por el contrario, ignoramos los riesgos y no hacemos que desaparezcan, además, estaremos ciegos. Hay algo característico de los proyectos de software en el presente siglo y es el famoso entorno VUCA (Volatility, Uncertainty, Complexity y Ambiguity), donde ya de por sí no es fácil alcanzar el éxito de un proyecto. Si, además, ignoramos o menospreciamos ciertas prácticas, la posibilidad de fracaso se dispara.

Por establecer una comparativa sencilla de entender: supongamos que nuestro proyecto es un barco que navega por el océano. Pese a que conocemos el destino final, la ruta y llevamos el timón, si no hacemos una buena gestión de riesgos es como si no disponemos de un sónar que analiza el fondo marino en busca de obstáculos.

Esta falta de control y de previsión provocará que estemos ciegos frente a una realidad de proyecto que nos es ajena. Inevitablemente, perderemos la iniciativa, pasaremos a ser reactivos y poco a poco iremos perdiendo credibilidad con nuestro cliente. La falta de credibilidad nos llevará a una falta de confianza y provocará que nuestro plan de proyecto se ponga en duda. En el momento en que aparezca un iceberg o un peñón con el que impactar, el barco en el que tanto esfuerzo hemos puesto se irá a pique. En nuestro caso, ese iceberg es un riesgo no gestionado que se ha convertido en un impacto real. A cada legua que avancemos, nos hundiremos un poco más. Ya reposando en el fondo marino, haremos retrospectivas y aprenderemos multitud de lecciones pero lo habremos hecho tarde.

¿Cómo encaja la gestión de riesgos en un entorno ágil?

Aquellos que tengáis conocimientos sobre esta práctica probablemente sea por metodologías como PMP, PRINCE2 u otras. Sin embargo, y por lo general, en el mundo ágil no se menciona aunque obviamente sí aparecerán riesgos como en cualquier otro tipo de proyecto o enfoque. Desde el Manifiesto Ágil, pasando por Lean, Scrum o Kanban, se busca seguir un enfoque de entrega iterativa e incremental en ciclos cortos que nos va a permitir recoger feedback y pivotar la solución. De esta manera, optimizamos la previsibilidad y controlamos los riesgos.

Este enfoque de entrega temprana, por naturaleza, minimiza riesgos pero no te aclara cómo proceder cuando se detectan y, peor aún, cuando se convierten en un impacto real. Además, este enfoque puede ser bastante viable para una compañía que desarrolle su propio producto y se pueda permitir experimentar. A bote pronto se me ocurre una startup con una gran idea y que ha encontrado un nicho de mercado o una gran compañía tecnológica con mucha capacidad y márgenes de error. Pero en el mundo de la consultoría, algunos de nuestros clientes no pueden permitirse seguir un modelo puramente ágil debido a su situación de mercado, su contexto cultural, sus hitos u otras razones. A menudo siguen apareciendo proyectos con tiempo, alcance y coste cerrados (el famoso triángulo de hierro) donde, a pesar de buscar esa entrega temprana y frecuente, debemos buscar alternativas que eliminen la incertidumbre.

Así que os pregunto: ¿por qué no combinar la filosofía Agile con alguna de las prácticas tradicionales de la gestión de proyectos? En algunos casos concretos podría no aportar mucho dependiendo de la naturaleza del proyecto o del producto pero nunca nos penalizará. Si tomamos el ejemplo de Scrum, tenemos una guía de mínimos, es decir, todo aquello que debes respetar para que el framework sea beneficioso y aporte un valor añadido. Pero en ningún caso nos censura a la hora de complementarlo con otras prácticas. Desde aquí os animo a que incorporéis herramientas y prácticas aunque su origen no sea Agile. El método debería ser un medio y no un fin, lo que cuenta es que nuestro proyecto tenga éxito.

La gestión de riesgos, una práctica necesaria

Termino recordando que, usemos el framework ágil que usemos, nadie nos impide complementarlo con herramientas y prácticas que nos ayuden a tener una mejor visión. A menudo nos limitamos a aplicar al dedillo ese método que aparentemente tanto nos va a ayudar, pero a veces conviene levantar la vista y pararnos a pensar qué es lo mejor para nuestro proyecto. Una de esas cosas es sin duda la gestión de riesgos.

Ni la mejor de las herramientas va a hacer que nuestro proyecto se desarrolle sin ningún incidente. Está en nuestra mano ser previsores, comunicar eficazmente y sobre todo perseguir que no tengan lugar.

¿Quieres saber cómo hacemos la gestión de riesgos en Paradigma? No pierdas de vista nuestro blog.