Gestión de riesgos para equipos pequeños

Un riesgo es un evento incierto que, si ocurre, impacta el proyecto — positivamente (oportunidad) o negativamente (amenaza). No es lo mismo que un problema: un problema es algo que ya pasó; un riesgo es algo que puede pasar.

Ejemplos de riesgos reales: "El cliente puede pedir cambios en el diseño a mitad del desarrollo" (alto impacto, alta probabilidad). "Puede haber un corte de luz en el server la semana del lanzamiento" (alto impacto, baja probabilidad). "El equipo de desarrollo puede terminar antes de tiempo" (impacto positivo, baja probabilidad).

La distinción importa porque los riesgos se gestionan antes de que ocurran; los problemas se gestionan después. La buena gestión de riesgos reduce la cantidad de problemas que aparecen, no hace que desaparezcan todos.

No hace falta una sesión de lluvia de ideas formal. Pedí a cada persona del equipo que escriba 3-5 cosas que puedan salir mal — apuntá todo, sin filtrar. Agrupalos por categoría (tecnología, personas, clientes, externos) y eliminá duplicados. Con equipos de 3-5 personas, esto no te toma más de 20 minutos.

Fuente de riesgos que casi siempre se olvidan: dependencias externas (aprobaciones de terceros, APIs que pueden cambiar, proveedores que pueden atrasarse). Marcalas en la lista con una estrella — suelen ser los que más rompen proyectos.

Para cada riesgo, asigná dos valores del 1 al 5: impacto (qué tan malo sería si ocurre) y probabilidad (qué tan probable es que ocurra). El producto te da un puntaje (1-25). Ordená la lista por puntaje y trabajá solo el top 5-10 — el resto es ruido.

En este ejemplo, trabajás los dos riesgos con estrella (cambio de diseño y aprobación) porque el puntaje te dice que son los que más riesgo real representan para el proyecto.

Para cada riesgo priorizado, definí una acción de mitigación concreta — no "revisar el riesgo periódicamente", eso no es una acción. Ejemplos:

• Cliente pide cambios de diseño: mitigación = mostrar el diseño y pedir aprobación por escrito antes de arrancar desarrollo. Aceptación residual: queda el riesgo de que el cliente cambie de opinión después; esa es la parte que aceptás.
• Aprobación regulatoria se demora: mitigación = iniciar el trámite con 2 meses de anticipación y asignar a alguien responsable de seguirlo semanalmente. Aceptación residual: puede seguir demorándose; tenés un plan B (fase 2 sin esa aprobación).
• Developer se enferma: mitigación = tener documentación actualizada del código y al menos otra persona familiarizada con las partes críticas. Aceptación residual: siempre hay riesgo de que la enfermedad coincida con una fecha clave; esa parte se acepta.

Regla de oro: no intentás mitigar todo. Los riesgos de bajo puntaje se aceptan — están anotados, pero no dedicás tiempo a ellos.

Una lista de riesgos que nunca se revisa es peor que no tenerla. Cada semana, en la misma reunión donde repasás el estado del proyecto, dedicá 15 minutos a: (1) ¿Algún riesgo nuevo apareció? (2) ¿Algún riesgo priorizado cambió de probabilidad o impacto? (3) ¿Las acciones de mitigación se están cumpliendo?

Esto conecta directo con la fase de seguimiento del proyecto: el seguimiento no es solo verificar si vamos a tiempo con las tareas, también es monitorear si el paisaje de riesgos cambió. Un riesgo que era improbable puede volverse probable una semana, y si no lo revisás, te sorprende.