Plan de ejecución a 90 días para una organización de ingeniería
Este es el último de tres posts basados en un trabajo de consultoría que hice para una fintech de pagos en LATAM. Los nombres, datos y detalles fueron modificados. En el primer post hice el diagnóstico organizacional. En el segundo, la estrategia de métricas. Aquí va el plan para poner todo en marcha.
Un diagnóstico sin ejecución es solo un documento bonito. El plan de 90 días es donde las decisiones se convierten en acciones concretas.
Rituales de squad
Los rituales no son reuniones por cumplir — son los puntos de contacto mínimos para que el equipo se mantenga alineado sin perder tiempo.
Antes del sprint
- Refinement (45min) — describir tickets, aclarar scope, estimar
- Sprint Planning (1h) — decidir qué entra al sprint
Semanal
- Sync lunes, miércoles y viernes (15min) — tres veces por semana, no cinco. Los días sin sync son para que los desarrolladores tengan bloques largos de concentración. Un daily de 15 minutos parece poco, pero cinco al hilo fragmentan la semana más de lo que parece.
Bi-semanal
- 1:1 con cada ingeniero (30min)
Fin de sprint
- Retro por squad (30min)
- Retro de ingeniería general (30min) — esta reunión, en mi experiencia, es donde realmente se alinea el equipo. Se comparten problemas, soluciones y contexto entre squads. Genera más colaboración que cualquier documento.
- Demo para interesados del negocio (30min)
Planning basado en métricas
Estimación
La escala sigue la secuencia de Fibonacci (1, 2, 3, 5, 8) — los saltos entre números reflejan que mientras más grande es algo, más incertidumbre tiene.
| Puntos | Significa | Ejemplo |
|---|---|---|
| 1 | Trivial, < 2 horas | Fix typo, cambio de config |
| 2 | Simple, medio día | Bug claro, ajuste menor |
| 3 | Moderado, 1-2 días | Feature pequeña, refactor acotado |
| 5 | Complejo, 3-4 días | Feature completa, integración |
| 8 | Muy complejo, 1 semana | Sistema nuevo, mucha incertidumbre |
| > 8 | Se divide | Demasiado grande |
La votación en refinement importa — el contexto de quien ya trabajó en algo y la experiencia de los seniors tiene peso. Si hay diferencia mayor a 3 puntos entre votos, se discute. Ahí es donde salen las dependencias y riesgos que nadie vio.
Capacidad
- Velocity histórica (promedio últimos 3 sprints) como tope
- Commitment al 80% de la capacidad
- Buffer de 20% para interrupciones
- WIP limit: máximo 2 tickets por persona
Composición target del sprint
- Mínimo 50% features
- Máximo 25% bugs
- Máximo 15% interrupciones
Estos números son una guía, no una regla rígida. Se ajustan según el contexto del squad y el momento.
Sistema de priorización
Para el backlog (en refinement)
Score = (Revenue Impact × Confidence) / Effort
- Revenue Impact (1-5) = qué tanto afecta ingresos
- Confidence (1-5) = qué tan claro está el scope
- Effort (1-5) = esfuerzo estimado
| Ticket | Revenue Impact | Confidence | Effort | Score | Prioridad |
|---|---|---|---|---|---|
| Fix crash en Payout Service | 4 | 5 | 2 | 10 | P1 |
| Migrar endpoint | 2 | 5 | 3 | 3.3 | P2 |
| Feature de reportes | 3 | 3 | 5 | 1.8 | P3 |
Para el sprint
- P0: Incidentes de producción → interrumpe sprint, se atiende ya
- P1: Revenue directo → entra al próximo sprint
- P2: Mejoras → backlog priorizado
- P3: Nice to have → backlog
Para lo que llega fuera de planning
- P0: Producción caída → interrumpe sprint
- P1: Cliente bloqueado → mismo día
- P2: Todo lo demás → va al backlog, se prioriza en el próximo planning
P0 y P1 entran en el 20% de buffer que se reserva en el sprint para interrupciones.
Fixes de proceso
Entrada de trabajo
- Todo request entra por un canal único
- El EM hace triage el mismo día
- Si es urgente (P0/P1): entra al sprint actual
- Si no es urgente: va al backlog para el próximo planning
Scoping
- Tickets sin criterios de aceptación no entran a sprint
- Ticket mayor a 8 puntos se divide
- Dependencias identificadas antes de planning
Escalaciones
- Ingeniero → Senior/EM: cuando está bloqueado o necesita una decisión técnica
- Senior/EM → CTO: cuando hay riesgo de negocio (cliente afectado, revenue en peligro)
Gestión de outages
- Postmortem sin culpa dentro de 48 horas
- Template: qué pasó, timeline, impacto, causa raíz, acciones a tomar
- Compartir aprendizajes en la retro de ingeniería
- Seguimiento de las acciones hasta que se cierren
Releases
- Diagnosticar arquitectura y deuda técnica de los proyectos
- Mejorar la forma de probar los releases — QA por los mismos desarrolladores del flujo completo
- Validar salidas a producción durante 15-30 minutos
- Crear alertas de comportamiento y errores en los servicios
Reporting
Semanal al CTO
- Status: On Track / At Risk / Blocked
- Métricas vs targets
- Decisiones que necesitan input
- Pronóstico de las próximas 2 semanas
Fin de sprint a interesados del negocio
- Qué se completó
- Qué se movió y por qué
- Próximo sprint
Mensual
- Review de OKRs
- Planificación de capacidad del siguiente mes
- Ajustes basados en aprendizajes
Targets de mejora con DORA Metrics
Para saber si estás mejorando necesitas targets claros. DORA Metrics es un framework del equipo de DevOps Research and Assessment de Google que clasifica el rendimiento de los equipos de ingeniería en cuatro niveles.
Benchmark DORA
| Métrica | Elite | High | Medium | Low |
|---|---|---|---|---|
| CFR | <5% | 5-10% | 10-15% | >15% |
| MTTR | <1h | <1 día | 1d-1 semana | >1 semana |
| Deploy Frequency | Múltiples/día | Diario-semanal | Semanal-mensual | Mensual+ |
| Lead Time | <1h | 1d-1 semana | 1 semana-1 mes | 1-6 meses |
Targets para esta organización
| Métrica | Actual | Target 30d | Target 90d | Objetivo |
|---|---|---|---|---|
| CFR Payout Service | 23% (Low) | 15% | <10% | Low → Medium → High |
| CFR Split Engine | 9% (High) | 8% | <5% | High → Elite |
| Flow Eff. Payouts | 13% | 20% | >30% | Reducir tiempo de espera |
| Flow Eff. Payments Core | 27% | 30% | >35% | Más tiempo productivo |
| Cycle Time P75 Payouts | 19.7d | 14d | <10d | Que quepa en un sprint |
| Cycle Time P75 Payments Core | 10.2d | 9d | <8d | Margen en sprint |
| Sprint Completion | ~60% | 70% | >80% | Predictibilidad |
| % Interrupciones | ~30% | 20% | <15% | Proteger roadmap |
Salud del equipo y cultura
Las métricas miden el sistema. Pero detrás del sistema hay personas. Si no cuidas al equipo, ninguna métrica mejora.
Mes 1 — escuchar y diagnosticar
- 1:1 con cada ingeniero para conocerlos
- Identificar riesgo de burnout, especialmente en Payouts (2 personas con 57% de trabajo reactivo)
- Implementar "Maker Time" — bloques de 4 horas sin reuniones para que los desarrolladores puedan concentrarse
Mes 2-3 — actuar
- Tech talks opcionales para compartir conocimiento
- Compartir aprendizajes entre squads
- Evaluar si las mejoras están funcionando con datos concretos
- Proponer siguientes pasos basados en lo aprendido
Career ladder
Un equipo necesita saber hacia dónde puede crecer. Sin un career ladder claro, la retención se vuelve un problema.
Niveles
| Nivel | Scope Técnico | Scope Impacto | Scope Liderazgo |
|---|---|---|---|
| Junior (L1) | Tareas definidas, código guiado | Feature individual | Aprende de otros |
| Mid (L2) | Features completas, diseño con guía | Squad | Mentee activo, pide feedback |
| Senior (L3) | Sistemas end-to-end, define el approach | Multi-squad | Mentor, toma decisiones técnicas |
| Staff (L4) | Arquitectura organizacional, estrategia técnica | Empresa | Multiplicador, define el estándar de contratación |
Dimensiones de evaluación
- Technical Excellence — calidad del código, decisiones arquitectónicas, conocimiento del dominio
- Delivery — cumplimiento, predictibilidad, capacidad de destrabar
- Teamwork & Communication — colaboración, documentación, comunicación clara
- Business Acumen — entender el impacto de negocio de las decisiones técnicas
Implementación
- Evaluar a cada ingeniero para saber dónde está
- Definir roles claros por nivel
- Identificar qué le falta a cada persona para crecer
- Armar un plan de desarrollo individual, coordinado con People, Finanzas y el CTO para evaluar presupuesto, condiciones y tiempos
Este es un primer approach con contexto reducido. Al entrar en la organización y conocer de cerca a los equipos, los procesos y la cultura, puedes ajustar cada parte de este plan. Pero como punto de partida, ya te da una estructura para pasar del diagnóstico a la acción.
La clave no es seguir el plan al pie de la letra — es tener un sistema que te permita medir, ajustar y mejorar de forma continua.
Si quieres profundizar en las métricas que usé como referencia, revisa el framework DORA.