El martes por la mañana, el responsable del producto te avisa de que la fecha de lanzamiento corre peligro. Para la hora del almuerzo, el líder de integración informa que el proveedor ha modificado su API y que el equipo deberá rehacer parte del trabajo. Al final de la jornada, el equipo de QA pregunta qué pruebas descartar, dado que el cronograma se ha comprimido. El analista de seguridad añade que, debido a la reducción del plazo de pruebas, es probable que los hallazgos surjan una vez congelado el código. Como gestor del proyecto, te enfrentas a una decisión difícil: mantener el alcance, posponer la fecha o aceptar una merma en la calidad. Cada hora que pasa aumenta el coste de la decisión final, ya que los equipos siguen trabajando basándose en premisas distintas.
Antes de preparar una diapositiva de estado, necesitas tener clara una distinción fundamental. Un riesgo es un evento futuro incierto que podría afectar a los objetivos. Un problema (o incidencia) es una situación adversa que ya está ocurriendo. El cambio en la API del proveedor constituye un problema una vez que se produce; la posibilidad de que ocurriera era, previamente, un riesgo. Este curso te proporciona el criterio y las herramientas necesarias para mantener esa distinción clara y útil, empleando un registro de riesgos operativo, un resumen de una página sobre objetivos y tolerancia al riesgo, enunciados de riesgo claros con sus respectivos desencadenantes, y un sistema de seguimiento ágil que permita detectar la incertidumbre con la antelación suficiente para actuar.
Para empezar, repasa la secuencia de acontecimientos e identifica el momento exacto en que el proyecto pasó de la incertidumbre a la realidad.
Cuando los equipos discuten si algo constituye un riesgo que merece la pena monitorizar, a menudo están discutiendo sobre otra cosa. Discuten sobre qué aspecto está optimizando el proyecto, qué suposiciones se dan por válidas y qué restricciones son inamovibles. Si estos puntos no están claros, cualquier conversación sobre riesgos termina con consejos vagos, como “hay que vigilarlo”.
Un marco práctico cabe en una sola página y comienza con los objetivos. El objetivo de plazos podría ser lanzar el producto antes de que termine el trimestre. El objetivo de costes podría ser mantenerse dentro de un presupuesto fijo asignado al proveedor. El objetivo de calidad podría ser no tener hallazgos de seguridad críticos en el momento del lanzamiento. A partir de ahí, se enumeran las suposiciones que se consideran ciertas a efectos de planificación (por ejemplo, que la API del proveedor mantenga la compatibilidad con versiones anteriores) y las restricciones no negociables (como un plazo límite normativo). Luego se añade el apetito de riesgo, que define cuánta variación tolerará el patrocinador antes de esperar que el asunto se eleve a instancias superiores para tomar una decisión. El apetito no es lo mismo que el optimismo; es un límite para la acción.
Un error común: el instinto equivocado es establecer un único nivel de apetito general, como “tenemos un perfil de bajo riesgo”. Parece una decisión firme, pero conlleva compensaciones ocultas: el equipo protege los plazos eliminando pruebas sin la aprobación del patrocinador, o protege la calidad retrasando la fecha de entrega sin informar al departamento de ventas.
Elige niveles de apetito que se ajusten al contexto del proyecto, no a tus preferencias personales.