Visualización de riesgos en el desarrollo de software

Para empezar a hablar de la visualización de riesgos primero tenemos que entender qué es un riesgo. En el desarrollo de software solemos asociar los riesgos a las dependencias, pero son cosas diferentes.

Un riesgo es algo que pensamos que puede no salir como esperamos y  que nos puede ocasionar un problema con un cierto margen de incertidumbre.

A la hora de definir o levantar un riesgo hay que hablar como mínimo de dos variables:

• Impacto: Un riesgo suele venir asociado a un valor económico. Suele implicar un coste.
• Probabilidad: Es la probabilidad de que ocurra o se materialice el riesgo en una realidad.

Ejemplo de riesgo:

Por otro lado están las dependencias y su pequeña diferencia con los riesgos.

Una dependencia es una necesidad que tenemos de otro equipo o producto sin la que no se puede continuar o no nos permite valernos por nosotros mismos.

La diferencia es sutil, prácticamente semántica. Podríamos pensar que la dependencia es un riesgo en sí mismo, sin embargo la dependencia es la que nos genera un riesgo, pero no el riesgo en sí. La dependencia es lo que tiene que resolver otro equipo para que nosotros podamos continuar. El riesgo asociado es el impacto y la probabilidad de que la dependencia no se resuelva en un tiempo concreto y no podemos continuar. 

Para entenderlo mejor la única acción que podemos hacer por nuestra parte con las dependencias es esperar, más allá de evidenciar y visualizar las dependencias. Con los riesgos tenemos diferentes opciones para enfrentarnos a ellos.

Veamos un ejemplo para entender la diferencia entre riesgo y dependencias:

Imaginad que vamos a saltar en paracaídas. ¿Qué ocurre si no tengo paracaídas? ¿Qué ocurre si el paracaídas no se abre? La primera pregunta es una dependencia. Si no tengo paracaídas no puedo saltar en paracaídas, es una certeza, no tiene sentido siquiera empezar el ascenso en el avión. La segunda pregunta responde a un riesgo. El hecho de que no se abra el paracaídas, que algo falle, nos genera un problema, pero implica una incertidumbre más que una realidad. El riesgo podemos tratarlo de diferentes formas, podemos actuar sobre él para eliminar la incertidumbre.

Con los riesgos ocurre que no siempre se les puede dar una solución completa, a veces tenemos que mitigar su efecto y reducir la probabilidad o el impacto que tienen. Esta es otra diferencia con las dependencias, una dependencia es absoluta, la tienes o no, la resuelves o no. Un riesgo puede plantearse en términos de porcentaje tanto en su impacto como en su probabilidad.

Si hablamos de desarrollo de software una dependencia es por ejemplo una funcionalidad que tiene que desarrollar otro equipo, y que el mío la necesita para continuar un cierto desarrollo. Esto impide que pueda hacer mi trabajo de una manera concreta. Sin embargo esta dependencia genera diferentes riesgos asociados:

• ¿Y si no la resuelven a tiempo?
• ¿Y si no funciona correctamente?
• ¿Y si no tiene la calidad adecuada?

Para ello planteamos un par de formas para empezar a abordar los riesgos y poder trabajarlos para solucionarlos.

Modelo ROAM

El modelo de gestión de riesgos ROAM se basa en visualizar los riesgos que detectemos y conseguir ser conscientes del estado en el que se encuentran.

Básicamente consiste en un panel de visualización con cuatro secciones.

Resolved (Resuelto): El riesgo ha sido resuelto o eliminado y por lo tanto ya no supone un problema. Por ejemplo, teniendo un riesgo que va a asociado a una dependencia, el riesgo se resuelve cuando se resuelve la dependencia.

Owned (En posesión): Este riesgo está identificado y se ha informado y está en posesión de una persona o equipo. Esta persona o equipo asume la responsabilidad de hacer algo con este riesgo para resolverlo o al menos mitigarlo.

Accepted (Aceptado): Se es consciente del riesgo y se acepta que puede ocurrir. En este caso la acción asociada al riesgo es la inacción.

Mitigated (Mitigado): En este punto el riesgo no se ha resuelto, pero el impacto que causará si se hace realidad se ha visto mitigado y por lo tanto no es tan grave como al principio.

El flujo de trabajo con este modelo es muy sencillo. Cada vez que se identifica y se levanta un riesgo, este entra en el sistema. Una vez dentro del sistema lo lógico es rápidamente asignarle la propiedad a alguien que será quien se encargará de resolver/mitigar el riesgo. Es decir, pasa al estado Owned dentro de nuestro sistema. De ahí el riesgo puede pasar a cualquiera de los otros estados pasado un tiempo. Es decir, podemos Aceptarlo como riesgo una vez analizado, podemos encontrar un camino para mitigarlo o podemos directamente hacer alguna acción que nos resuelva dicho riesgo. Además podría moverse entre los diferentes estados a medida que va a avanzando el tiempo. Por ejemplo, pasar de mitigado a Resuelto porque ha aparecido una nueva funcionalidad que nos lo resuelve.

Impact / Probability Matrix

A pesar de tener claros los riesgos e incluso de usar una visualización como ROAM, podemos tener necesidad de priorizar aquellos riesgos que pueden ser más problemáticos que otros. Para ello podemos usar una matriz de Impactos y probabilidades que nos ayudará a clasificar los riesgos para intentar poner foco en aquellos que puedan ocasionarnos más problemas. Con este tipo de matriz podemos decidir fácilmente en qué riesgos poner más esfuerzos, yendo desde tener que dedicar todo nuestro esfuerzo en resolver un riesgo, o por el contrario aceptar que algunos riesgos existen y es asumible que pueden ocurrir.

Para usar esta matriz sólo tenemos que indicar el grado de impacto en una escala que decidamos y la probabilidad de que el riesgo ocurra. En base a eso podemos clasificar los riesgos a través de una matriz como la de la imagen y poder priorizar sobre qué riesgos poner nuestros esfuerzos.

Conclusiones

Cualquier de estos modelos de visualización, u otros, son útiles solamente si vienen acompañados de una gestión de riesgos adecuada y continuada en el tiempo. Cualquiera de estos modelos se quedaría en una mera anécdota si no los revisamos cada cierto tiempo para comprobar en qué estado se encuentran. Siempre hay que reservar un tiempo para comprobar si los riesgos han cambiado de estado, criticidad, impacto, probabilidad, etc. Si no nos podemos encontrar que hemos detectado el riesgo correctamente por ejemplo al principio del proyecto y luego se ha materializado y no hemos sido capaces de hacer nada al respecto.

En cualquier proyecto / producto que hagamos siempre vamos a tener riesgos. Tenemos que intentar que estos no nos afecten. Además hay que tener cuidado con no caer en una parálisis por analizar o poner demasiado esfuerzo en eliminar todos los riesgos. Un buen producto sobrevive no solo por ser una buena idea, si no por tener una buena reacción a la incertidumbre.

Imagen: Unsplash | @loicleray