Gobernanza Operativa de Ingeniería
1. Objetivo
Definir cómo se toman decisiones técnicas y operativas, con rituales fijos, responsables claros y evidencia auditable.
2. Estructura mínima
| Foro | Participantes | Frecuencia | Decisiones |
|---|---|---|---|
| Comité técnico-operativo | Tech Lead, Backend Lead, Frontend Lead, QA Lead | Semanal | Riesgos, bloqueos, deuda técnica |
| Comité de release | Tech Lead, QA Lead, PO | Por release | Go/No-Go, plan de rollback |
| Revisión de incidentes | Incident Commander, DevOps, owners | Por incidente SEV1/SEV2 | Acciones correctivas |
| Revisión de madurez | Tech Lead + PO | Mensual | Scorecard y plan de mejora |
3. Agenda estándar (semanal)
- Estado de KPIs (SLO, fallas, lead time, freshness docs).
- Excepciones técnicas abiertas y próximas a vencer.
- Cambios de contrato API y compatibilidad.
- Incidentes de la semana y acciones.
- Riesgos de release y decisiones pendientes.
4. Acta obligatoria por sesión
Fecha:
Foro:
Asistentes:
Decisiones:
- DEC-###: descripcion | owner | fecha
Riesgos:
- RSK-###: descripcion | impacto | mitigacion | owner
Acciones:
- [ ] ACC-### | descripcion | owner | fecha compromiso
5. Derechos de decisión
| Tipo de decisión | Decide | Requiere consulta |
|---|---|---|
| Arquitectura y diseño técnico | Tech Lead | Backend/Frontend Lead |
| Priorización funcional | Product Owner | Tech Lead |
| Go/No-Go release | Tech Lead + QA Lead | Product Owner |
| Excepciones de seguridad | Security/Tech Lead | Product Owner |
6. Reglas de disciplina operativa
- Ninguna decisión crítica queda solo en chat; debe quedar en acta o ADR.
- Toda acción debe tener owner y fecha concreta.
- Riesgos sin mitigación activa pasan a prioridad P0/P1 en backlog técnico.
- Si no hay acta, la sesión se considera no válida para auditoría.