"The readiness is all" (La preparación lo es todo). - Hamlet V:ii:215
Un proyecto, como la vida, es incierto. Identificamos los riesgos, no por su propia naturaleza, sino para anticiparnos
a ellos y mitigarlos, si es posible, o para responder a ellos cuando nuestras estrategias de mitigación se quedan
cortas.
Los riesgos se derivan de los planes de iteración; las iteraciones se planifican alrededor de la gestión de riesgos
específicos, intentando limitar el riesgo o reducirlo. La lista de riesgos se revisa periódicamente para evaluar la
eficacia de las estrategias de mitigación de riesgos, que a su vez dirige las revisiones del plan de proyecto y los
planes de iteración consiguientes.
La clave para gestionar el riesgo es no esperar hasta que el riesgo se materialice (y se convierta en un
problema o una anomalía) para decidir qué hacer al respecto. Así como un cambio de pocos grados en la vía de acceso de
un vuelo intercontinental tiene un amplio efecto en dónde aterriza el avión, gestionar los riesgos pronto es, casi
siempre, menos costoso y doloroso que solucionarlo posteriormente.
Existen tres estrategias principales [BOE91]:
-
Elusión del riesgo. Reorganice el proyecto para que el riesgo no pueda afectarle.
-
Transferencia de riesgos. Reorganice el proyecto para que otra persona u otro objeto se haga cargo del
riesgo (cliente, proveedor, banco, otro elemento, etc.) Una estrategia específica de la elusión de riesgo.
-
Aceptación de riesgos. Decida convivir con el riesgo como una contingencia. Controle los síntomas del
riesgo, y decida un plan de contingencia sobre qué hacer si surge un riesgo.
Si decide aceptar el riesgo, todavía desea mitigar el riesgo, es decir, emprenda alguna acción inmediata para
reducir el impacto.
Es importante distinguir entre riesgos directos e indirectos. Sencillamente, sobre un riesgo directo tenemos un cierto
grado de control; los riesgos indirectos son los que no podemos controlar.
Si bien no se deben ignorar los riesgos indirectos, tienen pocas consecuencias en un sentido práctico: como no se
pueden cambiar, no se gana demasiado preocupándose sobre ellos. A pesar de que el mundo puede acabar mañana,
también puede no acabar, y si no lo hace, es mejor que nos pongamos a trabajar.
A veces, un riesgo indirecto puede ser en realidad un riesgo directo disfrazado. Por ejemplo, podemos depender de un
proveedor externo para un componente o conjunto de componentes. Esto aparece como riesgo indirecto, pero teniendo
planes de contingencia para estos componentes, podemos controlar el riesgo: podemos escoger proveedores alternativos, o
podemos elegir desarrollar la funcionalidad nosotros mismos. En muchos casos, tenemos más control del que imaginamos.
Con los riesgos indirectos, tiene que determinar como ganar un cierto control sobre los riesgos, o simplemente tomar
nota de ellos y continuar. No tiene sentido preocuparse sobre lo que no puede cambiar.
Organización
-
¿Existe suficiente compromiso con este proyecto (incluyendo gestión, verificadores, QA, y otras partes externas
pero implicadas)?
-
¿Es este el proyecto más grande que ha intentado la organización?
-
¿Existe un proceso bien definido de ingeniería de software? ¿Captura de requisitos y gestión?
Fondos
-
¿Los fondos están listos para completar el proyecto?
-
¿Los fondos se han asignado para formación y mentores?
-
¿Existen limitaciones de presupuesto para que el sistema se deba entregar a un coste fijo o que esté sujeto a
cancelación?
-
¿Las previsiones de coste son precisas?
Personas
-
¿Están disponibles suficientes personas?
-
¿Tienen las habilidades y la experiencia adecuadas?
-
¿Han trabajado juntos anteriormente?
-
¿Creen que el proyecto puede tener éxito?
-
¿Hay representantes de los usuarios disponibles para las revisiones?
-
¿Están disponibles expertos en el dominio?
Tiempo
-
¿La planificación es realista?
-
¿La funcionalidad se puede gestionar en el ámbito para que cumpla la planificación?
-
¿Cuál es la criticidad de la fecha de entrega?
-
¿Hay tiempo para "hacerlo bien"?
-
¿Qué pasa si la competencia alcanza el mercado antes?
-
¿Qué pasa si los fondos de proyecto están en peligro (otro modo de ver esto es preguntar "qué puede asegurar unos
fondos adecuados")?
-
¿El valor proyectado del sistema es superior al coste proyectado? (asegúrese de registrar el valor en tiempo del
dinero y el coste de capital).
-
¿Qué sucede si no se pueden realizar contratos con los proveedores clave?
-
¿Se puede medir el éxito?
-
¿Existe acuerdo sobre cómo medir el éxito?
-
¿Los requisitos son medianamente estables y bien comprendidos?
-
¿El ámbito del proyecto es firme o sigue creciendo?
-
¿Las escalas de tiempo de desarrollo del proyecto son breves e inflexibles?
-
¿La tecnología se ha probado?
-
¿Los objetivos se reutilización son razonables?
-
Un producto de trabajo debe utilizarse una vez antes de poderlo reutilizar.
-
Puede tardar varios releases de un componente antes de que sea suficientemente estable para reutilizarse
sin cambios significativos.
-
¿Los volúmenes de transacción de los requisitos son razonables?
-
¿Los cálculos de índice de transacción son creíbles? ¿Son demasiado optimistas?
-
¿Los volúmenes de datos son razonables? ¿Se pueden mantener en los sistemas principales disponibles actualmente o,
si los requisitos le conducen a creer que una estación de trabajo o un sistema departamental formará parte del
diseño, los datos se pueden mantener allí razonablemente?
-
¿Existen requisitos técnicos inusuales o complicados que requieren que el equipo del proyecto afronte problemas con
los que no está familiarizado?
-
¿El éxito depende de productos, servicios o tecnologías nuevos o no probados, hardware, software o técnicas nuevos
o no probados?
-
¿Existen dependencias externas a interfaces de otros sistemas, incluyendo los que están fuera de la empresa?
¿Las interfaces necesarias existen o se deben crear?
-
¿Existen requisitos de disponibilidad y de seguridad extremadamente inflexibles (por ejemplo, "el sistema no debe
fallar nunca")?
-
¿Los usuarios del sistema no tienen experiencia con el tipo de sistema que se está desarrollando?
-
¿Existe un riesgo aumentado debido al tamaño o la complejidad de la aplicación o la novedad de la tecnología?
-
¿Existe un requisito de soporte de idioma nacional?
-
¿Es posible diseñar, implementar y ejecutar este sistema? Algunos sistemas son demasiado grandes o complejos
incluso para funcionar adecuadamente.
-
¿El proyecto depende del desarrollo de otros proyectos (paralelos)?
-
¿El éxito depende de los productos asequibles o de los componentes desarrollados externamente?
-
¿El éxito depende de la integración satisfactoria de las herramientas de desarrollo (herramientas de diseño,
compiladores, etc.) las tecnologías de implementación (sistemas operativos, bases de datos, mecanismos de
comunicación interproceso, etc.). ¿Dispone de un plan de copia de seguridad para entregar el proyecto sin estas
tecnologías?
La experiencia muestra que el 85% de los riesgos tiene un impacto directo o indirecto en la planificación y, por lo
tanto, implícitamente, en el coste. Quizás un 5% tiene sólo impacto en el coste. El resto no tiene impacto directo en
el coste o en la planificación, sino en la calidad, por ejemplo.
Si la hora límite es desfavorable, enfóquela calmadamente con entregas incrementales. Evite una entrega masiva en un
intento de cumplir la planificación.
Algunos proyectos tienen horas límite realmente extremas. El software que analiza en vivo el resultado de las
elecciones durante la noche de las elecciones, por ejemplo, tiene poco valor si llega la semana después de las
elecciones. O bien el software puede quedar obsoleto por la competencia: lanzan un producto mejor que el suyo cuando
usted está a la mitad de su construcción. De repente, ya no participa en el juego - y no puede hacer nada al respecto.
En general, sin embargo, pocos proyectos tienen una hora límite tan crítica. Los retardos afectan principalmente el
coste.
En general, realice el compromiso de planificación igual que la mejor estimación, con una contingencia razonable.
compromiso = estimación + contingencia
Otros recomiendan configurar las expectativas de planificación igual que la estrategia de alternativa, es decir,
basarlas en los planes de contingencia, pero esto es demasiado pesimista porque no todos los riesgos se
materializarán.
Los riesgos de planificación se integran en las herramientas de estimación y de coste. Por ejemplo, en el modelo
COCOMO, muchos de los controladores de costes como:
-
complejidad (cplx)
-
restricciones de tiempo real (time)
-
restricciones de almacenamiento (stor)
-
experiencia (Vexp)
-
disponibilidad de buenas herramientas (tool)
-
presión de la planificación (sced)
son realmente factores de riesgo.
Las técnicas más sofisticadas de gestión de riesgos implican la utilización de la simulación Monte Carlo, en que
grandes números de "casos de ejemplo" se ejecutan con una herramienta de simulación para computar los riesgos globales
y las contingencias [KAR96].
|