Contexto

Roberto ha decidido comprar un auto último modelo con los ahorros que ha hecho en los últimos 5 años. Después de comparar precios y hacer algunas pruebas de manejo, selecciona el auto que mejor se adapte a sus necesidades y presupuesto. Justo antes de realizar la compra, su papá le recomienda una empresa para asegurar su automóvil con una cobertura amplia, que incluye daños generados por algún fenómeno natural, robo y responsabilidad civil. Sin embargo, Roberto considera que contratar este tipo de pólizas aumenta su costo de la póliza en 75% y está indeciso. Su papá le insiste en que vale la pena considerar este tipo de seguros por si acaso sucede algo. Roberto decide sólo contratar el seguro con cobertura de responsabilidad civil porque considera que es muy poco probable que su auto termine en manos de delincuentes o dañado por causa de algún terremoto o inundación, ya que vive en una zona que no ha registrado alguna catástrofe en más de veinte años. Al igual que la situación de Roberto, en los proyectos de desarrollo de software existen eventos adversos que ponen en riesgo el resultado o producto esperado. El equipo de desarrollo debe realizar un análisis de riesgos para determinar cuáles debe considerar y tratar de mitigar.

¿Cuál es el proceso de análisis de riesgos en un proyecto de desarrollo de software? ¿Cómo evaluar y decidir cuáles son los eventos que pueden poner en riesgo el resultado del proyecto? ¿Quién debería hacerse responsable de la gestión de riesgos? ¿Cuáles son las respuestas que se pueden dar a un riesgo?

Explicación

8.1 Importancia de la administración del riesgo

Los proyectos de software que requieren de un esfuerzo considerable incurren en costos igualmente proporcionales. Cajeros automáticos de banco, hasta las computadoras incluidas en automóviles, requieren de varios miles de líneas de código. Todo este trabajo de desarrollo se ve afectado por eventos que pueden poner en riesgo la confiabilidad, seguridad, calidad y efectividad del producto.

Un riesgo es la probabilidad de que suceda un evento no deseado. En todo proyecto de desarrollo de software existen riesgos que se tienen que administrar. Cualquier evento que comprometa la calidad, la fecha de entrega o el presupuesto estimado, constituye un riesgo para el proyecto.

Según Humphrey (2006), la administración del riesgo es importante por tres aspectos fundamentalmente:

Gestión de riesgos

El objetivo primordial de la gestión del riesgo es prevenir que un riesgo se materialice o encontrar las acciones para mitigar al máximo los posibles efectos en caso de presentarse.

Anticiparse a los problemas suele ser una buena estrategia para evitar que sucedan, sin embargo, rara vez existe un análisis proactivo de las cosas que pueden salir mal en un proyecto de software, cualquier acción reactiva a un problema tomará más tiempo y recursos para solucionarlo.

“Las personas que conocen los riesgos frecuentemente fallan al tomar las acciones para evitarlos” (Humphrey, 2006).

Otra estrategia es hacer que las personas adecuadas estén conscientes de los riesgos de un proyecto y asignar la responsabilidad de monitorear los elementos que pueden causar el riesgo y notificar al equipo cuando exista la certeza de que se puedan presentar, afectando el resultado del proyecto.

Principios de la gestión de riesgos

TSP establece los siguientes principios como parte de la gestión de riesgos:

Aprenda de errores pasados. Cada proyecto tiene sus propios riesgos, sin embargo, existe una gran posibilidad que se presenten riesgos similares de otros proyectos. Una buena práctica al finalizar el proyecto es documentar las acciones que se llevaron a cabo al presentarse un problema que ha impactado los objetivos o metas de un proyecto. Este listado de problemas sin duda puede ser un riesgo latente para el siguiente proyecto. Al inicio de cualquier proyecto es una buena práctica realizar una reunión con los involucrados para solicitarles su opinión y experiencia en otros proyectos que permitan identificar riesgos, incluso preguntarle al cliente puede ofrecer una perspectiva diferente de los posibles riesgos del proyecto.

Cualquier miembro del equipo saber qué hacer. La administración del riesgo no debe ser una labor exclusiva de una persona, sino de cada elemento del equipo, ya que hacer conciencia de los posibles riesgos puede generar acciones individuales que permitan anticiparse o mitigar sus consecuencias.

Empoderar a cada miembro a gestionar el riesgo. La gestión del riesgo debe ser parte fundamental del proceso de administración del proyecto. Si los involucrados sienten que el proyecto es suyo, trabajaran por cuidar que nada les impida llegar a la meta propuesta.

Cada riesgo considerado como significativo se le debe asignar un responsable. Los riesgos que se consideran tiene un mayor impacto al proyecto deben ser asignados a una persona con el objetivo de vigilar que no se presente y en caso de presentarse, gestionar las acciones necesarias para amortiguar el impacto a tiempo. Es más fácil que una persona se enfoque a los indicadores de un solo riesgo que asignar a una sola persona todos los riesgos.

Realice una revisión periódica de los riesgos. Los propietarios de cada uno de los riesgos deben realizar una revisión frecuente con el equipo. La periodicidad de la revisión dependerá de la severidad y la urgencia del riesgo.

8.2 Proceso de gestión de riesgos

Según Humphrey, Chick, Nichols y Pomeroy-Huff (2010), la metodología TSP establece un proceso de administración del riesgo mediante los siguientes pasos:

Haz clic en cada paso para conocer más detalles

Cierre

Realizar un análisis de riesgos es una parte inherente de cualquier proyecto, y los proyectos de desarrollo de software no son la excepción. Es una actividad que debe hacerse al inicio del proyecto con los principales involucrados, ya sea a partir de una reunión de lluvia de ideas, grupos de enfoque, cuestionarios o la técnica Delphi. El objetivo principal a considerar en el análisis de riesgos es identificar lo antes posible eventos que puedan afectar el resultado esperado de un proyecto. Se seleccionan los riesgos que se deben monitorear porque tiene mayores probabilidades de ocurrencia y además generan un alto impacto. La organización puede decidir dar una respuesta: aceptarlo, mitigarlo, transferirlo o evitarlo.

De la misma manera que existe el riesgo de que te roben tu automóvil, podrías decidir aceptar el riesgo y no hacer nada hasta que suceda; evitar el riesgo al no tener un automóvil; mitigarlo ya sea adquiriendo una alarma o bastón, o bien puedes transferir el riesgo de robo mediante la contratación de una póliza de seguro de auto.
Cuando en los proyectos de software se tienen identificados los riesgos de mayor impacto con suficiente anticipación, es posible crear planes de mitigación que puedan ser aplicados para asegurar los factores de éxito del proyecto: tiempos de entrega, calidad, y mantenerse dentro de presupuesto.

Checkpoint

Asegúrate de poder:

Reconocer la importancia de realizar un análisis de riesgos en los proyectos de software en los que participes.
Aplicar el proceso de gestión de riesgos para identificar, evaluar y dar seguimiento a los posibles eventos que puedan poner en peligro un proyecto de desarrollo de software.
Generar planes de mitigación de riesgos para minimizar el posible impacto negativo a un proyecto de software.

Referencias

ISACA. (2013). CISA Review Manual. USA: ISACA.
El-Haik, B. y Shaout, A. (2010). Software Design for Six Sigma: A Roadmap for Excellence. USA: John Wiley & Sons.
Humphrey, W. (2006). TSP(SM) Coaching Development Teams. USA: Pearson.
Humphrey, W., Chick, T, Nichols, W, & Pomeroy-Huff, M. (2010). Team Software Process (TPS) Body of Knowledge. USA: SEI

Glosario

Riesgo: contingencia o proximidad de un daño.

Mitigar: moderar, aplacar, disminuir, o suavizar algo rugoso o áspero.

No	Nombre del riesgo y descripción	Impacto	Probabilidad	Asignación	Periodicidad de revisión
1
2
3

	Impacto
Probabilidad	Bajo	Medio	Alto
Alto	Medio	Alto	Alto
Medio	Bajo	Medio	Alto
Bajo	Bajo	Bajo	Medio

	Nivel de Riesgo
Rojo	Alto	Requiere de una acción inmediata.
Amarillo	Medio	Puede requerir una acción, debe estarse monitoreando.
Verde	Bajo	No requiere atención por el momento.

El siguiente paso es determinar en quién debe recaer la responsabilidad de monitorear y gestionar cada uno de los riesgos y establecer cada cuándo se realizará una revisión del riesgo.

Los riesgos más importantes son los que tienen un impacto alto / medio, así como una probabilidad alta / media. Los riesgos con bajo impacto y baja probabilidad pueden ser descartados.

Es recomendable que la asignación se realice entre los participantes de la sesión, preferentemente según el rol que están desempeñando. Es decir, si existe un riesgo en relación con el ambiente de pruebas, la responsabilidad debería recaer en el gerente de verificación y validación, o si se trata de un riesgo relacionado con la interfaz del usuario, podría ser asignado al gerente de Ingeniería de requerimientos.

	Riesgos
Rol o puesto	R1	R2	R3	R4	R6	R7	R8
Gerente del proyecto	R	I		I	A		A
Administrador de Bases de datos		A		C		S
Gerente de testing	A		S		R		I
…

Una organización debe establecer un plan de mitigación para los riesgos que se consideren importantes como una práctica proactiva de respuesta. Este plan contiene las acciones necesarias para amortiguar el impacto del riesgo de un evento o incluso evitarse.

Por ejemplo, si existe un riesgo de un posible retraso del análisis del sistema debido la falta de disponibilidad de los stakeholders asignados por el cliente, es posible que en la siguiente reunión con el cliente se le haga saber del posible retraso en número de días y el consecuente riesgo de aumentar los costos del proyecto si no se cuenta con su participación. El cliente puede dar la instrucción a sus empleados y evitar así ese posible impacto.