Deadlines de Proyecto Realistas | GitScrum
Crea cronogramas alcanzables usando estimación bottom-up, pronósticos basados en velocidad y gestión de buffers.
9 min de lectura
Los deadlines irrealistas preparan proyectos para el fracaso desde el día uno. Los equipos se agotan corriendo para cumplir metas imposibles, la calidad sufre y la confianza se erosiona cuando las fechas se deslizan. GitScrum proporciona las herramientas basadas en datos para crear cronogramas realistas basados en capacidad real del equipo, rendimiento histórico y evaluación honesta de riesgos.
El Problema del Deadline
Por qué los deadlines fallan y sus consecuencias:
| Causa Raíz | Resultado |
|---|---|
| Establecer fecha top-down | Deadline existe antes de entender scope |
| Ignorar capacidad equipo | Más trabajo que horas disponibles |
| Sin datos históricos | Estimaciones basadas en esperanza, no realidad |
| Dependencias ocultas | Trabajo bloqueado por otros no considerado |
| Sin buffers | Un solo retraso cascada hasta fecha final |
| Scope asumido fijo | Nuevos requerimientos no factorizados |
Estimación Bottom-Up
Estimación por Story Points
PROCESO DE ESTIMACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ PASO 1: DESCOMPONER EPICS EN STORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Epic: Sistema de Autenticación de Usuario │
│ ├── Story: UI formulario login (3 pts) │
│ ├── Story: Validación contraseña (2 pts) │
│ ├── Story: Generación token JWT (5 pts) │
│ ├── Story: Gestión de sesión (5 pts) │
│ ├── Story: Flujo reset contraseña (5 pts) │
│ ├── Story: Integración OAuth (8 pts) │
│ ├── Story: Configuración MFA (8 pts) │
│ └── Story: Bloqueo de cuenta (3 pts) │
│ TOTAL: 39 puntos │
│ │
└─────────────────────────────────────────────────────────────┘
PASO 2: SESIÓN DE ESTIMACIÓN DEL EQUIPO:
┌─────────────────────────────────────────────────────────────┐
│ RESULTADOS PLANNING POKER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Story: Integración OAuth │
│ │
│ Votos desarrolladores: │
│ @Alex: 8 @Kim: 5 @Sam: 8 @Pat: 13 @Jordan: 8 │
│ │
│ Discusión: @Pat explica 13 por peculiaridades API LinkedIn │
│ Equipo acuerda agregar tarea investigación │
│ │
│ Estimación revisada: 8 puntos + 2 puntos spike LinkedIn │
│ │
│ Final: 10 puntos total │
│ │
└─────────────────────────────────────────────────────────────┘
Pronóstico Basado en Velocidad
CÁLCULO DE VELOCIDAD:
┌─────────────────────────────────────────────────────────────┐
│ VELOCIDAD EQUIPO (Últimos 6 Sprints) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sprint │ Comprometido │ Completado │ Velocidad │
│ ──────────┼──────────────┼────────────┼────────── │
│ Sprint 19 │ 45 │ 38 │ 38 │
│ Sprint 20 │ 40 │ 42 │ 42 │
│ Sprint 21 │ 42 │ 40 │ 40 │
│ Sprint 22 │ 45 │ 44 │ 44 │
│ Sprint 23 │ 42 │ 41 │ 41 │
│ Sprint 24 │ 44 │ 43 │ 43 (en progreso) │
│ ──────────┴──────────────┴────────────┴────────── │
│ │
│ VELOCIDAD PROMEDIO: 41 puntos/sprint │
│ RANGO: 38-44 puntos/sprint │
│ │
│ RECOMENDACIÓN: │
│ ├── Planificación optimista: 44 pts/sprint │
│ ├── Planificación realista: 41 pts/sprint ← USAR ESTA │
│ └── Planificación conservadora: 38 pts/sprint │
│ │
└─────────────────────────────────────────────────────────────┘
CÁLCULO TIMELINE PROYECTO:
┌─────────────────────────────────────────────────────────────┐
│ PROYECTO: Portal Cliente v2 │
├─────────────────────────────────────────────────────────────┤
│ │
│ TRABAJO TOTAL ESTIMADO: 245 story points │
│ VELOCIDAD EQUIPO: 41 puntos/sprint (sprints 2 semanas) │
│ │
│ CÁLCULO: │
│ 245 puntos ÷ 41 puntos/sprint = 5.97 sprints │
│ │
│ ESCENARIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Optimista (44 pts): 245 ÷ 44 = 5.6 sprints = 11 sem ││
│ │ Realista (41 pts): 245 ÷ 41 = 6.0 sprints = 12 sem ││
│ │ Conservador (38 pts): 245 ÷ 38 = 6.4 sprints = 13 sem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RECOMENDACIÓN: 12-13 semanas (6-6.5 sprints) │
│ BUFFER AGREGADO: +2 semanas (15% contingencia) │
│ DEADLINE PROPUESTO: 14-15 semanas desde inicio │
│ │
└─────────────────────────────────────────────────────────────┘
Gestión de Buffers
Tipos de Buffers
ESTRATEGIA DE BUFFERS:
┌─────────────────────────────────────────────────────────────┐
│ TIPOS DE BUFFER Y ASIGNACIÓN │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. BUFFER INCERTIDUMBRE ESTIMACIÓN (10-20%) │
│ Para: Complejidad desconocida, nueva tecnología │
│ Regla: Mayor para trabajo nuevo, menor para familiar │
│ │
│ Ejemplo: 245 pts × 15% = ~37 puntos adicionales │
│ Tiempo: +1.5 semanas │
│ │
│ 2. BUFFER CAMBIO SCOPE (10-15%) │
│ Para: Cambios inevitables, clarificaciones │
│ Regla: Mayor para clientes externos, menor internos │
│ │
│ Ejemplo: 245 pts × 10% = ~25 puntos adicionales │
│ Tiempo: +1 semana │
│ │
│ 3. BUFFER RIESGO (5-15%) │
│ Para: Riesgos conocidos que podrían materializarse │
│ Regla: Basado en evaluación registro riesgos │
│ │
│ Ejemplo: 2 riesgos altos = 10% buffer │
│ Tiempo: +1 semana │
│ │
│ 4. BUFFER INTEGRACIÓN/DEPLOYMENT (1-2 semanas) │
│ Para: Testing final, prep deployment, documentación │
│ Regla: Tiempo fijo, no porcentaje │
│ │
│ Tiempo: +1.5 semanas │
│ │
│ TIMELINE TOTAL PROYECTO: │
│ ├── Trabajo core: 12 semanas │
│ ├── Buffer estimación: +1.5 semanas │
│ ├── Buffer scope: +1 semana │
│ ├── Buffer riesgo: +1 semana │
│ └── Integración: +1.5 semanas │
│ ════════════════════════════ │
│ TOTAL: 17 semanas │
│ │
└─────────────────────────────────────────────────────────────┘
Niveles de Confianza
FRAMEWORK CONFIANZA DEADLINE:
┌─────────────────────────────────────────────────────────────┐
│ COMUNICACIÓN BASADA EN CONFIANZA │
├─────────────────────────────────────────────────────────────┤
│ │
│ En lugar de: "Estará listo el 15 de abril" │
│ Decir: "Tenemos 80% confianza de entregar para el 15 abril" │
│ │
│ NIVELES DE CONFIANZA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 50% Confianza: 1 Abril (optimista, sin buffers) ││
│ │ 70% Confianza: 8 Abril (realista, buffer mínimo) ││
│ │ 80% Confianza: 15 Abril (compromiso recomendado) ││
│ │ 90% Confianza: 22 Abril (conservador, más buffers) ││
│ │ 95% Confianza: 29 Abril (muy seguro, max buffers) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMUNICACIÓN STAKEHOLDER: │
│ │
│ "Basado en la velocidad de nuestro equipo y el scope │
│ definido, tenemos 80% confianza de entregar para el 15. │
│ │
│ Esto asume: │
│ - Sin adiciones mayores de scope │
│ - Estabilidad del equipo (sin partidas) │
│ - Dependencias entregadas a tiempo │
│ │
│ Si necesitas mayor certeza, el 22 de abril nos da 90% │
│ confianza con buffer adicional para desconocidos." │
│ │
└─────────────────────────────────────────────────────────────┘
Gestión de Dependencias
Mapeo de Dependencias
VISUALIZACIÓN DEPENDENCIAS:
┌─────────────────────────────────────────────────────────────┐
│ MAPA DEPENDENCIAS PROYECTO │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 │
│ ────────────────────────────────────────────────────────── │
│ │
│ [Sistema Auth]───────┐ │
│ │ │
│ [Diseño BD]──────────┼────►[Desarrollo API]─────────────┐ │
│ │ │ │
│ [Componentes UI]─────┼────►[Dashboard UI] │ │
│ │ │ │ │
│ │ ▼ ▼ │
│ └────►[Integración]────────►[Testing] │
│ │
│ CAMINO CRÍTICO: BD → API → Integración → Testing │
│ Duración: 5 semanas (mínimo con ejecución perfecta) │
│ │
│ DEPENDENCIAS AGREGANDO RIESGO: │
│ ├── Externa: Acceso sandbox API Pagos (Semana 2) │
│ ├── Interna: Infraestructura DevOps lista (Semana 1) │
│ └── Cliente: Aprobación contenido/copy (Semana 4) │
│ │
└─────────────────────────────────────────────────────────────┘
Alineación con Stakeholders
Negociación de Deadline
ESCENARIOS DE NEGOCIACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ ESCENARIO: STAKEHOLDER QUIERE DEADLINE ANTES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stakeholder: "Necesitamos esto para 15 marzo, no 22 abril." │
│ │
│ FRAMEWORK DE RESPUESTA: │
│ │
│ 1. RECONOCER LA NECESIDAD │
│ "Entiendo que el 15 de marzo es importante para la │
│ conferencia de ventas. Veamos qué es posible." │
│ │
│ 2. PRESENTAR TRADE-OFFS │
│ "Para lograr 15 marzo, necesitaríamos ajustar scope. │
│ Aquí hay tres opciones:" │
│ │
│ Opción A: Reducir scope │
│ ├── Quitar: Módulo reportes, OAuth │
│ ├── Mantener: Auth core, Dashboard, Pagos │
│ └── Timeline: 10 semanas → 15 marzo alcanzable │
│ │
│ Opción B: Aumentar equipo │
│ ├── Agregar: 2 contractors por 8 semanas │
│ ├── Costo: +$40,000 │
│ └── Timeline: Quizás 22 marzo (mejora 1 semana) │
│ │
│ Opción C: Release por fases │
│ ├── 15 Marzo: MVP (Auth, Dashboard básico) │
│ ├── 22 Abril: Release completo │
│ └── Conferencia: Demo MVP, prometer completo abril │
│ │
│ 3. DEJAR QUE STAKEHOLDER DECIDA │
│ "¿Qué opción se ajusta mejor a tus necesidades?" │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
Anti-Patrones de Deadline
QUÉ NO HACER:
✗ DEADLINES DE PENSAMIENTO DESIDERATIVO
"Trabajaremos más duro" / "Lo resolveremos"
Realidad: Equipos no pueden sostener crunch
✗ DEADLINE PRIMERO, SCOPE DESPUÉS
"Lanzamiento es 1 junio, háganlo funcionar"
Realidad: Scope o calidad sufrirán
✗ IGNORAR DATOS DE VELOCIDAD
"Este equipo debería hacer 60 puntos, no 41"
Realidad: Datos históricos son mejor predictor
✗ SIN BUFFERS
"Cada día está contabilizado perfectamente"
Realidad: Algo siempre sale mal
✗ DEADLINES OCULTOS
"Diles abril pero realmente necesitamos marzo"
Realidad: Destrucción de confianza al descubrir