What is Framework de Gestión de Riesgos?

Identifica, evalúa y mitiga riesgos de proyecto proactivamente para prevenir que los problemas descarrilen la entrega.

What is Identificación de Riesgos?

Identifica, evalúa y mitiga riesgos de proyecto proactivamente para prevenir que los problemas descarrilen la entrega.

What is Riesgos Comunes de Proyecto?

CATEGORÍAS DE RIESGO ════════════════════ RIESGOS TÉCNICOS: RIESGOS DE RECURSOS: RIESGOS DE CRONOGRAMA: RIESGOS EXTERNOS:

What is Evaluación de Riesgos?

Identifica, evalúa y mitiga riesgos de proyecto proactivamente para prevenir que los problemas descarrilen la entrega.

Gestionando Riesgos de Proyecto Efectivamente

Todo proyecto tiene riesgos—incógnitas que podrían descarrilar la entrega. La diferencia entre proyectos exitosos y fracasos frecuentemente se reduce a cómo se gestionan los riesgos. La gestión proactiva de riesgos significa identificar temprano, evaluar honestamente y mitigar sistemáticamente.

Framework de Gestión de Riesgos

Fase	Actividad	Output
Identificar	Encontrar problemas potenciales	Lista de riesgos
Evaluar	Evaluar probabilidad × impacto	Riesgos priorizados
Planear	Crear estrategias de mitigación	Planes de respuesta
Monitorear	Rastrear y actualizar	Estado actual
Responder	Ejecutar cuando se activan	Resueltos o escalados

Identificación de Riesgos

Riesgos Comunes de Proyecto

CATEGORÍAS DE RIESGO
════════════════════

RIESGOS TÉCNICOS:
─────────────────────────────────────
├── Nueva tecnología (curva de aprendizaje)
├── Complejidad de integración
├── Incógnitas de performance
├── Vulnerabilidades de seguridad
├── Impacto de deuda técnica
└── Decisiones de arquitectura

RIESGOS DE RECURSOS:
─────────────────────────────────────
├── Persona clave se va
├── Brechas de habilidades
├── Disponibilidad del equipo
├── Prioridades competidoras
├── Dependencia de contractors
└── Restricciones de presupuesto

RIESGOS DE CRONOGRAMA:
─────────────────────────────────────
├── Timeline no realista
├── Scope creep
├── Dependencias de otros equipos
├── Retrasos de aprobación
├── Tiempo de testing subestimado
└── Cambios de requisitos

RIESGOS EXTERNOS:
─────────────────────────────────────
├── Confiabilidad de servicios terceros
├── Entrega de vendor
├── Cambios regulatorios
├── Cambios de mercado
├── Disponibilidad de cliente
└── Estabilidad de API externa

Técnicas de Identificación de Riesgos

MÉTODOS DE DESCUBRIMIENTO DE RIESGOS
════════════════════════════════════

1. BRAINSTORMING DEL EQUIPO:
─────────────────────────────────────
Sesión: "¿Qué podría salir mal?"
Cada persona escribe 3-5 riesgos
Discutir y consolidar
Resultado: 15-20 riesgos identificados

2. ANÁLISIS HISTÓRICO:
─────────────────────────────────────
Revisar proyectos similares pasados:
├── ¿Qué problemas ocurrieron?
├── ¿Qué fue inesperado?
├── ¿Qué harías diferente?
└── Aplicar aprendizajes

3. REVISIÓN DE DEPENDENCIAS:
─────────────────────────────────────
Para cada dependencia:
├── ¿Qué pasa si se retrasa?
├── ¿Qué pasa si no funciona?
├── ¿Qué pasa si la persona se va?
└── Identificar riesgos de dependencia

4. EVALUACIÓN DE TECNOLOGÍA:
─────────────────────────────────────
Para cada elección tecnológica:
├── ¿El equipo tiene experiencia?
├── ¿Está probada a escala?
├── ¿Cuáles son los problemas conocidos?
└── Identificar riesgos técnicos

5. PRE-MORTEM:
─────────────────────────────────────
"Imagina que el proyecto fracasó. ¿Por qué?"
El equipo escribe escenarios de falla
Trabajar hacia atrás para identificar riesgos
Técnica poderosa para riesgos ocultos

Evaluación de Riesgos

Matriz Probabilidad × Impacto

MATRIZ DE EVALUACIÓN DE RIESGOS
═══════════════════════════════

          │  BAJO IMPACTO  │ MEDIO IMPACTO  │  ALTO IMPACTO
──────────┼────────────────┼────────────────┼──────────────
ALTA      │    MEDIO       │     ALTO       │   CRÍTICO
PROB      │   Monitorear   │ Planear mitig. │  Top prioridad
──────────┼────────────────┼────────────────┼──────────────
MEDIA     │     BAJO       │    MEDIO       │     ALTO
PROB      │   Aceptar      │   Monitorear   │ Planear mitig.
──────────┼────────────────┼────────────────┼──────────────
BAJA      │     BAJO       │     BAJO       │    MEDIO
PROB      │   Aceptar      │   Aceptar      │   Monitorear

SCORING:
─────────────────────────────────────
Probabilidad:
├── Baja: < 20%
├── Media: 20-60%
└── Alta: > 60%

Impacto:
├── Bajo: Retraso menor, workaround existe
├── Medio: Retraso significativo, trabajo extra
└── Alto: Retraso mayor, fracaso potencial

Score de Riesgo = Probabilidad × Impacto

Registro de Riesgos

REGISTRO DE RIESGOS DEL PROYECTO
════════════════════════════════

┌────────────────────────────────────────────────────────────┐
│ ID │ Riesgo            │ Prob │ Imp │ Score │ Owner │Estado│
├────────────────────────────────────────────────────────────┤
│ R1 │ API externa inest.│ Alto │ Alto│ Crít  │ @alex │Activo│
│ R2 │ Dev senior se va  │ Med  │ Alto│ Alto  │ @mgr  │Watch │
│ R3 │ Scope creep       │ Alto │ Med │ Alto  │ @pm   │Activo│
│ R4 │ Performance DB    │ Med  │ Med │ Med   │ @dba  │Watch │
│ R5 │ Retraso de vendor │ Bajo │ Alto│ Med   │ @pm   │Watch │
│ R6 │ Browser compat.   │ Med  │ Bajo│ Bajo  │ @fe   │Accept│
└────────────────────────────────────────────────────────────┘

Estrategias de Mitigación

Tipos de Respuesta

ESTRATEGIAS DE RESPUESTA A RIESGO
═════════════════════════════════

EVITAR:
─────────────────────────────────────
├── Eliminar la causa del riesgo
├── Cambiar plan para evitar riesgo
├── Ejemplo: Usar tecnología probada
│   en lugar de experimental
└── Mejor cuando: Riesgo alto + evitable

MITIGAR:
─────────────────────────────────────
├── Reducir probabilidad o impacto
├── Acciones preventivas
├── Ejemplo: Documentación para
│   reducir riesgo bus factor
└── Mejor cuando: Riesgo reducible

TRANSFERIR:
─────────────────────────────────────
├── Pasar riesgo a otra parte
├── Seguros, contratos, SLAs
├── Ejemplo: Vendor asume riesgo
│   de entrega con penalidades
└── Mejor cuando: Otro puede manejar mejor

ACEPTAR:
─────────────────────────────────────
├── Reconocer y monitorear
├── No tomar acción preventiva
├── Tener plan contingente listo
├── Ejemplo: Bug menor, workaround existe
└── Mejor cuando: Costo de mitigación > riesgo

Plan de Mitigación Detallado

TEMPLATE DE PLAN DE MITIGACIÓN
══════════════════════════════

RIESGO: API externa inestable
ID: R1
Score: Crítico (Alta prob × Alto impacto)
Owner: @alex

DESCRIPCIÓN:
─────────────────────────────────────
La API del vendor de pagos ha tenido
3 outages en el último mes. Si falla
durante peak, perdemos ventas.

IMPACTO SI OCURRE:
─────────────────────────────────────
├── Usuarios no pueden completar compras
├── Pérdida de revenue estimada: $50K/hora
├── Daño a reputación
└── Tickets de soporte aumentan 10x

ESTRATEGIA: Mitigar
─────────────────────────────────────

ACCIONES PREVENTIVAS:
├── Implementar circuit breaker (Sprint 3)
├── Cache de tokens de pago (Sprint 3)
├── Dashboard de monitoreo de API (Sprint 2)
└── Alertas en Slack cuando latency > 2s

PLAN DE CONTINGENCIA:
─────────────────────────────────────
Si API falla:
├── Circuit breaker activa fallback
├── Mostrar mensaje "Intente más tarde"
├── Queue de reintentos automáticos
├── Escalar a vendor inmediatamente
└── Considerar vendor backup si > 4h

TRIGGER DE ACTIVACIÓN:
─────────────────────────────────────
├── Latency promedio > 5s
├── Error rate > 5%
└── Outage confirmado por vendor

Monitoreo Continuo

Dashboard de Riesgos

DASHBOARD DE RIESGOS EN GITSCRUM
════════════════════════════════

RESUMEN DE RIESGOS:
┌─────────────────────────────────────────────────┐
│  Total: 12 riesgos rastreados                   │
│                                                 │
│  Por severidad:                                 │
│  ├── 🔴 Críticos: 2                             │
│  ├── 🟠 Altos: 4                                │
│  ├── 🟡 Medios: 3                               │
│  └── 🟢 Bajos: 3                                │
│                                                 │
│  Por estado:                                    │
│  ├── Activos (mitigando): 4                     │
│  ├── Watch (monitoreando): 5                    │
│  ├── Aceptados: 2                               │
│  └── Cerrados: 1                                │
└─────────────────────────────────────────────────┘

ATENCIÓN REQUERIDA:
┌─────────────────────────────────────────────────┐
│  🔴 R1: API externa - Mitigación en progreso    │
│     Próxima acción: Deploy circuit breaker (Vie)│
│                                                 │
│  🔴 R3: Scope creep - Requiere decisión         │
│     Próxima acción: Reunión con stakeholders    │
│                                                 │
│  🟠 R2: Dev senior - Probabilidad aumentó       │
│     Próxima acción: Revisar plan de retención   │
└─────────────────────────────────────────────────┘

Revisión Regular de Riesgos

CADENCIA DE REVISIÓN DE RIESGOS
═══════════════════════════════

SEMANAL (Sprint Planning):
─────────────────────────────────────
├── Revisar riesgos activos (5 min)
├── Actualizar estados
├── Identificar nuevos riesgos
├── Asignar actions para el sprint
└── Parte de agenda estándar

BI-SEMANAL (Steering):
─────────────────────────────────────
├── Presentar top 5 riesgos a stakeholders
├── Decisiones que requieren aprobación
├── Recursos adicionales si necesario
└── Ajustar tolerancia de riesgo

MENSUAL (Revisión Profunda):
─────────────────────────────────────
├── Revisión completa del registro
├── Cerrar riesgos resueltos
├── Re-evaluar scores
├── Lecciones aprendidas
└── Actualizar documentación

Soluciones Relacionadas con GitScrum

Conclusión

La gestión proactiva de riesgos es la diferencia entre proyectos que entregan y proyectos que fracasan. GitScrum proporciona las herramientas para mantener un registro de riesgos vivo, rastrear acciones de mitigación como tareas normales, y dar visibilidad a stakeholders sobre el estado de riesgos. Al identificar temprano, evaluar honestamente y mitigar sistemáticamente, los equipos pueden navegar la incertidumbre y entregar exitosamente.