Cierre y aprendizaje organizacional

📐 Fundamento

Actividades de cierre:

1. Verificar entregables: ¿se entregó lo prometido en el scope?
2. Aceptación del cliente: firma formal de que está conforme.
3. Documentación final: manuales, runbooks, arquitectura.
4. Handoff a operaciones: ¿quién mantiene esto ahora?
5. Cierre administrativo: facturas, contratos.
6. Liberación de recursos: equipo, presupuesto, infraestructura.
7. Lessons learned: documentar lo aprendido.
8. Celebración: reconocer al equipo.

Lo más importante (y lo más olvidado): handoff a operaciones.

El proyecto puede terminar pero el sistema sigue corriendo. Si nadie sabe cómo mantenerlo, en 6 meses estará caído.

Runbook ejemplo:

# Runbook: La Esquina Cloud — API de Pedidos

## Descripción
API REST que maneja CRUD de pedidos. Stack: FastAPI, PostgreSQL, Redis.

## Owners
- Tech Lead: ana@laesquina.com
- On-call rotation: ver PagerDuty schedule "API team"

## URLs
- Producción: https://api.laesquina.com
- Staging: https://staging.api.laesquina.com
- Docs: https://wiki.laesquina.com/api

## Cómo deployar
[steps...]

## Cómo rollback
[steps...]

## Alertas comunes y respuesta
- "High latency P99 > 2s": revisar dashboard X, verificar BD
- "Error rate > 5%": ver logs en CloudWatch [link]
- "DB connection exhausted": escalar pool, ver query slow

## Dependencias externas
- Stripe (pagos): si cae, fallback a PayPal
- SendGrid (emails): no-blocking, retry con SQS

## Contactos de emergencia
- Stripe support: [link]
- AWS Premium Support: [phone]

Lessons Learned database:

Mantener una base de conocimientos por proyecto/incidente. Búsqueda accesible. Lectura obligatoria al iniciar proyectos similares.

ID: LL-2026-042
Proyecto: Migración monolito → microservicios
Categoría: Arquitectura

Aprendizaje:
"Subestimamos el tiempo de migración de datos en 3x. La razón:
no contemplamos el tiempo de validación post-migración, que tomó
tanto como la migración misma."

Recomendación:
"Para futuras migraciones, presupuestar 2x para migración + 1x
para validación + 0.5x buffer."

Aplicabilidad: cualquier migración de datos > 1TB

📐 Fundamento

Retrospectiva ≠ Postmortem:

• Retrospectiva: regular (cada sprint, cada release). Mejora continua.
• Postmortem: después de un incidente o proyecto importante. Aprendizaje específico.

Estructura clásica de retrospectiva (Esther Derby, "Agile Retrospectives"):

1. Set the stage      (5 min)   — temperatura del equipo, reglas
2. Gather data        (15 min)  — qué pasó (hechos, sentimientos)
3. Generate insights  (15 min)  — por qué pasó
4. Decide what to do  (10 min)  — qué cambiamos (concreto)
5. Close              (5 min)   — agradecer, una palabra final

Total: ~50 min para sprint de 2 semanas.

Formatos populares:

1. Start / Stop / Continue:

START doing            STOP doing           CONTINUE doing
- Pair programming     - Reuniones de 1h    - Daily de 15 min
- Code reviews async   - Deploy los viernes - Demo semanal
- Documentar ADRs      - Skip retros        - Auto pair-up

2. 4 L's (Liked / Learned / Lacked / Longed for):

LIKED                  LEARNED              LACKED          LONGED FOR
- Buen ambiente        - GraphQL N+1        - Tests E2E     - Más tiempo
- Pair programming     - K8s pod limits     - PO disponible - Better tools

3. Sailboat (más visual):

🪨 ROCKS (problemas que casi nos hunden)
⚓ ANCHORS (cosas que nos retienen)
💨 WIND (cosas que nos impulsan)
🏝️ ISLAND (objetivo / visión)

4. Mad / Sad / Glad:

😡 MAD          😢 SAD              😊 GLAD
- Tests rotos   - PO se fue         - Lanzamos en tiempo
- Build lento   - Bug crítico viernes - El equipo mejoró

Reglas críticas para que funcionen:

1. Safe space: sin culpas, blameless.
2. Action items concretos: "mejorar comunicación" → no sirve. "Crear canal #arquitectura para discusiones técnicas" → sirve.
3. Owners y deadlines: cada acción tiene responsable y fecha.
4. Verificar acciones del sprint anterior: "¿hicimos lo que dijimos? Si no, ¿por qué?"
5. No siempre el mismo formato: rotar formatos para mantener interés.

Anti-patrón: retros donde se dice "no hay nada que cambiar, todo bien". Casi nunca es cierto. Significa: el equipo no se siente seguro, o el facilitador no profundiza.

Facilitador:

• No participa con opiniones (puede sesgar).
• Hace preguntas: "¿alguien quiere agregar?", "¿qué pasaría si...?".
• Time-box estricto.
• Asegura que todos hablen (no solo los más vocales).

📐 Fundamento

Estructura de postmortem (basada en Google SRE):

# Postmortem: Caída de la API de pagos — 2026-05-15

## Resumen ejecutivo
El 15 de mayo entre las 20:32 y 21:18 UTC (46 minutos), la API de pagos
estuvo caída, afectando ~3,200 transacciones (~$45,000 en ventas).

## Severidad
P1 (crítico — afectó pagos en producción)

## Impacto
- 3,200 pedidos no se pudieron procesar
- ~$45,000 en revenue perdido
- 12 quejas en redes sociales
- Deploy automático de hotfix corrigió el problema

## Timeline
20:32 — Deploy de feature "tarjetas múltiples" (release 2.45.1)
20:34 — Spike de 5xx errors en métricas
20:35 — Alerta de PagerDuty al on-call
20:38 — On-call (Carlos) confirma el problema
20:42 — Identifican que el deploy es la causa
20:45 — Inician rollback
20:48 — Rollback completo
20:52 — Métricas vuelven a normal
21:18 — Confirman que no hay efecto residual

## Causa raíz
El nuevo código tenía un bug en el manejo de tarjetas con formato europeo
(comas como decimal en lugar de puntos). En producción, ~5% de transacciones
desde IPs europeas usaban este formato y fallaron, pero la cascada de retries
saturó el pool de conexiones a la BD, derribando el servicio para todos.

## Causas que contribuyeron
1. Tests no incluían formatos de tarjeta no-US.
2. No había circuit breaker entre servicio de pagos y BD.
3. Pool de conexiones no tenía límite explícito → acumuló > 10K conexiones.
4. No había canary deploy → 100% del tráfico fue al código nuevo de inmediato.

## Lo que funcionó bien
- Alertas detectaron el problema en < 4 minutos.
- On-call respondió en 1 minuto.
- Rollback funcionó como esperado.

## Lo que no funcionó bien
- No detectamos el bug en review ni en testing.
- El blast radius fue total (debería haber sido parcial).
- Comunicación a clientes tardó 2 horas (debería ser < 30 min).

## Action Items

| # | Acción                                              | Owner | Fecha     | Status |
|---|-----------------------------------------------------|-------|-----------|--------|
| 1 | Agregar tests con formatos internacionales          | Ana   | 22-05     | DONE   |
| 2 | Implementar canary deploy (5% → 25% → 100%)         | SRE   | 30-05     | TODO   |
| 3 | Circuit breaker pagos↔BD                           | Tech  | 15-06     | TODO   |
| 4 | Status page público + auto-update                   | PM    | 30-05     | DOING  |
| 5 | Pool de conexiones con límite y monitoreo           | SRE   | 22-05     | DONE   |

## Lecciones aprendidas
1. **Las features que parecen "trivial" pueden tener bugs catastróficos.** Toda feature debe pasar por canary deploy.
2. **Tests deben cubrir variedad real de inputs**, no solo el caso US.
3. **Los timeouts y circuit breakers son tan importantes como el código de happy path.**

## Sin culpas
Nadie en este equipo causó esta falla intencionalmente. El sistema permitió
que un bug llegue a producción. Vamos a fortalecer el sistema, no buscar
culpables.

Reglas blameless:

• Hablar de "el código" en lugar de "X persona escribió".
• Preguntar "¿por qué fue posible que esto ocurriera?" en lugar de "¿de quién es la culpa?".
• Asumir que cada decisión tuvo sentido en su momento.
• Si la única explicación es "X fue negligente", el problema es mayor: ¿por qué el sistema permite esa negligencia?

Five Whys: profundizar repetidamente.

Problema: la BD se cayó.
¿Por qué? Pool de conexiones agotado.
¿Por qué? Servicios crearon más conexiones de las soportadas.
¿Por qué? No había límite configurado.
¿Por qué? El dev no sabía que era importante.
¿Por qué? No estaba en el checklist de despliegue.

→ Causa raíz sistémica: falta de checklist de readiness.
→ Acción: crear checklist de Production Readiness Review.

📐 Fundamento

Kaizen — el ciclo japonés de mejora continua:

Pequeñas mejoras consistentes >> grandes cambios esporádicos

PDCA (Plan-Do-Check-Act, Deming):

PLAN  → diseñar cambio
DO    → implementarlo (small scale)
CHECK → medir resultado
ACT   → escalar si funciona, ajustar si no
   ↺

The Three Ways (DevOps, "The Phoenix Project"):

1. Flow: acelerar entrega de valor.
2. Feedback: loops rápidos para detectar problemas.
3. Learning: experimentación y aprendizaje continuo.

Indicadores de organización que aprende:

• Postmortems publicados internamente, leídos por todos.
• Lessons learned database accesible y actualizada.
• "Game days" — simulación de incidentes para practicar.
• Tiempo dedicado explícitamente a mejorar (no solo features).
• Errores discutidos abiertamente sin estigma.

Indicadores de organización que NO aprende:

• Mismos errores se repiten.
• "No tenemos tiempo para retrospectivas/postmortems".
• Culpa individual cuando hay incidentes.
• Postmortems vagos sin acciones concretas.
• Acciones de retros nunca se completan.

The Learning Organization (Peter Senge):

5 disciplinas:

1. Systems thinking: ver el todo, no solo partes.
2. Personal mastery: desarrollo individual continuo.
3. Mental models: cuestionar nuestras suposiciones.
4. Shared vision: dirección común.
5. Team learning: aprender colectivamente.