9 min lectura • Guide 49 of 877
Estableciendo Deadlines de Proyecto Realistas
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