Gestión de proyectos
Gestión de riesgos para equipos pequeños
En una línea: gestión de riesgos para equipos pequeños no son matrices 50×50 ni workshops de dos días. Es una lista de 5-10 riesgos con impacto probable, una acción concreta para mitigar cada uno, y 15 minutos por semana para revisar si algo cambió. La mayoría de los proyectos que se rompen no lo hacen por una catástrofe impredecible — se rompen por un riesgo que nadie anotó y por lo tanto nadie monitoreó.
Qué es un riesgo (y qué no es)
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.
Cómo identificar riesgos (sin workshop)
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.
Cómo priorizar (impacto vs probabilidad)
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.
| Riesgo | Impacto | Probabilidad | Puntaje |
|---|---|---|---|
| Cliente pide cambios de diseño a mitad | 5 | 4 | 20 ★ |
| Aprobación regulatoria se demora | 5 | 3 | 15 ★ |
| Developer se enferma semana clave | 4 | 3 | 12 |
| Corte de luz en server lanzamiento | 5 | 1 | 5 |
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.
Cómo mitigar (y cuándo aceptar el riesgo)
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.
Revisión semanal: 15 minutos que te ahorran semanas
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.
Preguntas frecuentes
- ¿Cuántos riesgos hay que tener en la lista?
- Entre 5 y 10 es lo ideal para equipos pequeños. Menos de 5 es muy pocó; más de 10 se vuelve inmanejable y deja de ser útil. Si tenés más de 15, priorizá más agresivamente.
- ¿Los riesgos positivos (oportunidades) también se gestionan?
- Sí, pero suelen tener menos prioridad que los riesgos negativos. Si identificás una oportunidad real (por ejemplo, un nuevo canal de marketing que aparece), la acción es aprovecharla, no mitigarla.
- ¿Hay alguna herramienta que simplifique esto?
- Una hoja de cálculo con columnas de riesgo, impacto, probabilidad, puntaje y acción de mitigación es suficiente para la mayoría de los equipos pequeños. Lo importante no es la herramienta, es la disciplina de revisarlo cada semana.