Riesgos
Un riesgo es un evento potencial que puede o no ocurrir; si el evento se materializa, habrá un impacto negativo en el proyecto ya sea causando demoras, sobrecostos y/o afectando la calidad del producto.
El objetivo de la gestión de riesgos es tener en cuenta los aspectos inciertos de un proyecto para mitigarlos y que no se conviertan en problemas graves. Es un enfoque proactivo: evitar que el riesgo se presente o prepararse para disminuir las consecuencias si se llega a presentar.
Las actividades relacionadas con la Gestión de Riesgos se pueden organizar en dos grandes grupos: 1) Identificar y estimar los riesgos, y 2) Controlar los riesgos.
Identificar y estimar los riesgosEl objetivo de esta actividad es producir una lista de riesgos capaces de romper la planificación del proyecto. Algunos ejemplos clásicos son:
- Planificaciones demasiado optimistas
- Planificación con tareas innecesarias
- Presupuestos bajos
- El ciclo de revisión/decisión de las directivas es más lento de lo esperado
- Cambio de requerimientos
- Mal funcionamiento de las herramientas de desarrollo
- Espacios de trabajo inadecuados
- Curva de aprendizaje de las nuevas tecnologías es más larga de lo esperado
- Escatimar en la calidad
- Diseño inadecuado
- Personal no adecuado o no bien capacitado
- Pérdida de motivación del personal
- Falta de trabajo en equipo
- Error en la contratación
- Diferencias entre el personal de desarrollo y el cliente
- Falta de participación de los usuarios finales
Son muchos los riesgos potenciales que se pueden presentar en un proyecto de desarrollo de software. Para poder hacer una gestión adecuada, los riesgos se deben priorizar y seleccionar los más críticos para hacerles seguimiento y control. La criticidad de un riesgo depende de dos factores que hay que estimar: la probabilidad del evento y el impacto que pueda causar si el evento ocurre. De manera general, cada riesgo puede formularse de la siguiente manera para separar claramente el evento de la consecuencia:
Importante**Si evento entonces **impacto.
Por ejemplo:
_ Si_ La curva de aprendizaje de las nuevas tecnologías es más larga de lo esperado
**entonces **habrá retrasos importantes en el cronograma del proyecto.
Es difícil medir cuantitativamente la probabilidad del evento. Por esta razón, la probabilidad es una percepción subjetiva que debe ser contrastada entre los integrantes del grupo para obtener un valor de consenso. La probabilidad del evento la mediremos en: Alta, Media y Baja.
Para entender la probabilidad asignada al evento de un riesgo es importante definir claramente el contexto en el que puede ocurrir y las razones para esa probabilidad. Por ejemplo, supongamos que al riesgo anterior le asignamos una probabilidad baja:
Ejemplo 1| Riesgo |
| Si La Curva de aprendizaje de las nuevas tecnologías es más larga de lo esperado entonces se tendrá retrasos importantes en el cronograma del proyecto. |
| Probabilidad |
| Baja |
| Justificación |
| Si bien la tecnología es nueva, todos entienden la importancia de realizar los talleres, tutoriales y estudiar los ejercicios. Todos los integrantes han trabajado anteriormente con tecnologías parecidas. |
Ejemplo 2| Riesgo |
| Si El quipo no trabaja de manera organizada y coordinado entonces el proyecto no cumplirá los requerimientos, tendrá retrasos importantes, mala calidad y el equipo no estará motivado… |
| Probabilidad |
| Alta |
| Justificación |
| El equipo no tiene ninguna experiencia trabajando juntos. No están familiarizados con herramientas de planeación y seguimiento. No están físicamente juntos sino en pocos momentos de la semana. |
Si el riesgo se materializa, es decir, el evento ocurre, habrá un impacto sobre el proyecto. El valor de este impacto también es subjetivo y puede clasificarse en: Catastrófico, Moderado y Leve.
La valoración del impacto, tiene que considerarse en el contexto particular del proyecto. Por ejemplo, un riesgo asociado con la calidad del producto, el impacto es distinto si se trata de un software del que dependen vidas humanas a si se trata de un software más de apoyo a algún proceso de negocio. En el primer caso el impacto se puede considerar catastrófico mientras que en el segundo podría ser moderado.
- Si el equipo no tiene un entendimiento suficiente sobre la arquitectura y las tecnologías del proyecto,** entonces** habrá retrasos, mala calidad en lo que se entrega y poca motivación del equipo.
- Si el equipo no entiende los requerimientos , entonces se desarrollará una aplicación de mala calidad porque no va a satisfacer los requerimientos del cliente y todo el trabajo se perderá.
- Si el equipo no trabaja de manera organizada y coordinada, entonces: el proyecto no cumplirá los requerimientos, tendrá retrasos importantes, mala calidad y el equipo no estará motivado.
- Si el producto tiene mala calidad, entonces: el cliente no estará satisfecho.
La cantidad de riesgos que pueden surgir en una lluvia de ideas del equipo de desarrollo puede ser alta. Clasificarlos y priorizarlos permite enfocarse en los que el equipo encontró como los más críticos y que vale la pena tener en cuenta. De esta manera, el esfuerzo se invierte a conciencia de la importancia de cada riesgo, así, el equipo se compromete activamente a evitar que el riesgo se materialice en un problema, o en estar listo para enfrentarlo.
La importancia de un riesgo está en la combinación entre probabilidad del evento e impacto. Claramente un riesgo de probabilidad alta e impacto catastrófico debe ser manejado por el equipo de desarrollo. La lista de los riesgos que se van a manejar puede variar a lo largo del proyecto ya que no todos los riesgos se pueden identificar al comienzo del proyecto. Algunos pueden surgir por el camino.
El equipo de desarrollo decidirá cuántos riesgos podrá controlar y hacer seguimiento.
El control de riesgos se refiere a las acciones que debe definir y realizar el equipo de desarrollo para evitar que el riesgo se materialice (mitigación) o para actuar de forma adecuada si el riesgo se materializa (contingencia).
Para cada riesgo que se decida controlar se debe definir un conjunto de planes o acciones de mitigación. El objetivo puede ser disminuir la probabilidad del evento asociado con el riesgo o de disminuir el impacto que tendrá en el proyecto si el evento se vuelve realidad.
Las acciones de mitigación deben incluirse en el plan del ciclo del proyecto. Para cada acción se debe tener claro cuál es el resultado esperado, debe tener responsables, participantes, estimaciones, etc. Por ejemplo, ante el riesgo de que el desconocimiento de la tecnología retrase el proyecto, el plan de mitigación puede ser estudiar la tecnología. sin embargo esto es muy general y no se puede medir avance, así que se deben buscar acciones más concretas del estilo:
- Cada desarrollado realiza el tutorial xyz (1h de trabajo)
- Juan y José definen un modelo de arquitectura con la nueva tecnología para validar con el grupo (2h de trabajo)
- etc.
Si el riesgo se materializa, el equipo debería tener un plan de contingencia. Este consiste en acciones que se deben llevar a cabo para minimizar las consecuencias. No siempre esto es posible y no queda más remedio que aceptarlas. Por ejemplo, si había un riesgo que tenía como consecuencia no terminar a tiempo y si este ocurre, es probable que no quede más remedio que aceptar las consecuencias y pagar una multa o perder el contrato. Un plan de contingencia puede ser intentar renegociar con el cliente, o negociar la forma de pagar la multa.
Adicional a los planes de mitigación se debe hacer seguimiento a los riesgos. Esta es la actividad más importante de la gestión de riesgos. Realizar un seguimiento permite darse cuenta de la efectividad de los planes de mitigación, y del acierto en la identificación y clasificación que se realizó de los riesgos del proyecto. El seguimiento debe ser corto de manera que los recursos invertidos sean mínimos. Ante proyectos complejos o con más probabilidad de riesgos el equipo debe invertir más cantidad de tiempo en hacer seguimiento.
Esta actividad se evalúa continuamente los siguientes puntos:
- Los planes de mitigación puestos en marcha, junto con su efectividad.
- Los posibles nuevos riesgos que aparecen.
- Los riesgos que de manera positiva desaparecen.
Durante cada ciclo de desarrollo se hace una rápida revisión del avance de los planes de mitigación y se recogen impresiones de riesgos que acechan el proyecto. Los integrantes del equipo a través de las iteraciones desarrollan habilidades para estar atentos a posibles nuevos riesgos.
Un riesgo es un problema potencial que puede o no ocurrir pero si sucede, éste causará demoras, sobre costos y/o afectará la calidad en el desarrollo del proyecto. El objetivo de la administración de riesgos es tener en cuenta los aspectos inciertos de un proyecto para mitigarlos y que no se conviertan en problemas graves. Es un enfoque proactivo: evitar que el riesgo se presente o prepararse para disminuir las consecuencias si se llega a presentar.
Las actividades relacionadas con la Administración de Riesgos se pueden organizar en dos grandes grupos: 1) Identificar y estimar los riesgos, y 2) Controlar los riesgos.
Si el equipo no tiene un entendimiento suficiente sobre la arquitectura y las tecnologías del proyecto,** entonces** habrá retrasos, mala calidad en lo que se entrega y poca motivación del equipo.
Si el equipo no entiende los requerimientos , entonces se desarrollará una aplicación de mala calidad porque no va a satisfacer los requerimientos del cliente y todo el trabajo se perderá.
Si el equipo no trabaja de manera organizada y coordinada, entonces: el proyecto no cumplirá los requerimientos, tendrá retrasos importantes, mala calidad y el equipo no estará motivado.
Si el producto tiene mala calidad, entonces: el cliente no estará satisfecho.
