Gestión de riesgos

170 Ilustración 69 - Dedicación horaria a gestión y coordinación

Se destaca que nunca se pasó del 15%, empezando las mediciones en valores cercanos a él, lo que tiene sentido en etapas iniciales de un proyecto.

Luego se ve que disminuye notoriamente debido a que el equipo se adaptó a la forma de trabajo y además se encontraba en una modalidad mayormente enfocada en desarrollo.

Por último, se termina con una tendencia al aumento lo que se justifica con el cierre del proyecto.

171 Por lo tanto, en este proyecto los riesgos fueron clasificados en distintas categorías y para cada uno de ellos se identificó su magnitud en conjunto con la estrategia del equipo para gestionarlo.

Durante todo el proyecto, los riesgos se evaluaron de forma periódica haciéndose reuniones mensuales. En cada seguimiento se analizaba la evolución de los riesgos existentes y también se evaluaba el surgimiento de nuevos elementos a considerar.

9.9.1. Identificación

La primera identificación de riesgos se realizó en la etapa inicial del proyecto mediante la técnica de lluvia de ideas.

Los riesgos identificados se clasificaron en las siguientes categorías:

• Técnico: Fueron los riesgos relacionados estrictamente con la parte técnica del proyecto.

• Gestión de proyecto: Eran los riesgos que afectaron el desarrollo normal de las distintas etapas del proyecto.

• Gestión del equipo: Los riesgos que involucraron a las personas que integraron el equipo.

• Externo: Eran los riesgos ajenos al equipo.

A continuación, se listan los riesgos identificados por el equipo.

En esta lista se encuentran categorizados los riesgos iniciales y los identificados en las reuniones de gestión mensuales posteriores.

Id Riesgo Categoría

R1 Falla en los sistemas de repositorios remotos (Drive, Github, etc.).

Externo R2 Pérdida de interés por parte del cliente. Externo

172 R3 Falta de comunicación fluida con el cliente. Externo R4 Indisponibilidad de un integrante del equipo por más de una

semana a causa de enfermedades (coronavirus, gripe, etc.).

Externo R5 Alta incertidumbre, por parte del cliente, en cuanto a decisiones

de producto concretas.

Externo R6 Falta de comunicación fluida entre el equipo. Gestión del

equipo R7 Escasez de tiempo para dedicarle la atención necesaria. Gestión del

equipo

R8 Conflictos interpersonales. Gestión del

equipo R9 Choque de roles (genera retrabajo, y puede generar conflicto). Gestión del

equipo R10 Relevar los requerimientos de manera incorrecta. Gestión de

proyecto R11 No lograr llegar a una velocidad confiable (que nos permita

estimar/pronosticar).

Gestión de proyecto R12 Gran diferencia entre lo estimado y lo realizado durante el

sprint.

Gestión de proyecto R13 Falta de conocimiento de las tecnologías acordadas con el

cliente para el desarrollo.

Técnico R14 No llegar a deployar la aplicación en un ambiente productivo. Técnico R15 No contar con los recursos tecnológicos necesarios para el

desarrollo del sistema.

Técnico R16 No cumplir las expectativas del cliente, en cuanto a calidad del

software, por malas decisiones de arquitectura.

Técnico R17 No lograr compilar y ejecutar código de terceros. Técnico R18 Que no se use el software por mala UX/UI. Técnico R19 No lograr un sistema seguro (a prueba de trampas). Técnico R20 Subestimar el tiempo necesario para documentar. Gestión de

proyecto

173 R21 Cliente insatisfecho con código o arquitectura interna del

sistema.

Técnico R22 Tener inconsistencia entre capítulos de la documentación final. Gestión de

proyecto R23 Perder mucho alcance en funcionalidades dedicando tiempo a

mejorar calidad del código.

Gestión de proyecto Tabla 23 - Riesgos identificados en el proyecto

Los riesgos del 1 al 18 surgieron de la lluvia de ideas inicial, mientras que los siguientes fueron surgiendo en el seguimiento a lo largo del proyecto.

9.9.2. Magnitud

En las reuniones de gestión de riesgos, el equipo le asignaba una magnitud a cada riesgo para ese mes del proyecto. Para calcular esa magnitud se tenían en cuenta dos variables:

Probabilidad de ocurrencia Rango [0.25, 0.50, 0.75].

• 0 no existe ya que sería un riesgo que no tiene probabilidad de materializarse.

• 1 no existe ya que no sería un riesgo, sino algo que ya se materializó.

Impacto sobre los objetivos del proyecto Rango 1 a 5.

• Indica qué tan perjudicial sería para el proyecto que ese riesgo se materialice.

La magnitud se calculó como probabilidad por impacto, y se utilizó como indicador de prioridad del riesgo según la siguiente tabla.

174 Tabla 24 - Matriz de probabilidad e impacto

Los riesgos más importantes para un mes dado eran aquellos con magnitud en rojo según la anterior tabla, es decir de magnitud mayor o igual a 2.

Para estos riesgos se fueron definiendo planes de contingencia y respuesta en cada iteración de gestión de riesgos con el fin de actuar según la estrategia definida y estar preparados ante una eventual ocurrencia.

9.9.3. Estrategias, planes de contingencia y respuesta

Para cada riesgo se definieron distintas estrategias ya que existían riesgos que eran imposibles de evitar y hubo que aplicar otro enfoque.

Las estrategias que se tuvieron en cuenta fueron:

• Evitar

El equipo actúa para eliminar la amenaza o proteger al proyecto de su impacto.

• Transferir

El equipo traslada el impacto de una amenaza a un tercero junto con la responsabilidad de la respuesta.

• Mitigar

El equipo actúa para reducir la probabilidad de ocurrencia y/o el impacto de un riesgo.

175

• Aceptar

El equipo decide reconocer el riesgo y no tomar ninguna medida a menos que el riesgo se materialice.

Con la premisa de trabajar en la gestión de riesgos con un enfoque ágil el equipo fue definiendo planes de respuesta y contingencia solamente para los riesgos de alta prioridad en cada reunión de evaluación de riesgos. Dado que se prefería evitar el uso de tiempo en definir planes que en el corto plazo sería muy poco probable o de muy bajo impacto tener que usarlos.

Plan de respuesta

Este plan incluía las tareas que el equipo debía realizar para disminuir la probabilidad de que ese riesgo ocurra.

Plan de contingencia

Una vez que el riesgo ocurría o estaba a punto de materializarse, el plan de contingencia detallaba las acciones a realizar para reducir el impacto de este sobre el proyecto.

El listado completo de riesgos con su estrategias y planes para los que aplican se encuentra en el Anexo 32 – Plan de riesgos.

9.9.4. Evolución

A continuación, se representa la evolución de cinco de los riesgos que consideramos fueron más importantes durante el proyecto. La evolución completa se encuentra en el Anexo 33 – Evolución de riesgos.

Cabe destacar que en ningún momento se materializó completamente un riesgo identificado, por lo que no se llegó a aplicar ningún plan de contingencia.

Además, muchos riesgos fueron siendo eliminados durante el proyecto, como por ejemplo se ve el R17 en la siguiente gráfica, que fue mitigado tempranamente

176 gracias al desarrollo de la prueba de concepto, y a partir de ese momento el mismo pasó a tener una magnitud de 0.

Ilustración 70 - Evolución de los riesgos más importantes

177