5 min lectura • Guide 128 of 877
Manejando Solicitudes Urgentes Sin Descarrilar Planes
Solicitudes urgentes amenazan foco del equipo y compromisos de sprint cuando cada nueva petición se trata como emergencia. Sin un sistema para evaluar y manejar interrupciones, equipos rechazan trabajo urgente legítimo (dañando relaciones con stakeholders) o aceptan todo (perdiendo objetivos de sprint). Workflows flexibles de GitScrum y features de visibilidad ayudan a equipos a distinguir emergencias reales de solicitudes de prioridad regulares y manejar ambas apropiadamente.
El Problema de Urgencia
Por Qué Todo Parece Urgente
INFLACIÓN DE URGENCIA:
┌─────────────────────────────────────────────────────────────┐
│ EL PATRÓN "TODO ES URGENTE" │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEMANA TÍPICA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Lunes: ││
│ │ Ventas: "Cliente necesita esta feature urgentemente" ││
│ │ CEO: "Necesitamos arreglar homepage para miércoles" ││
│ │ ││
│ │ Martes: ││
│ │ Soporte: "Bug crítico afectando 3 clientes" ││
│ │ PM: "Demo inversores adelantada, necesitamos ASAP" ││
│ │ ││
│ │ Miércoles: ││
│ │ Ventas: "Diferente cliente amenazando con cancelar" ││
│ │ Marketing: "Lanzamiento campaña necesita integración" ││
│ │ ││
│ │ Viernes: ││
│ │ Todos: "¿Por qué no terminamos trabajo del sprint?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EL PROBLEMA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cuando todo es urgente: ││
│ │ • Nada se prioriza ││
│ │ • Objetivos sprint pierden significado ││
│ │ • Equipo se quema por cambio de contexto ││
│ │ • Paradójicamente, cosas urgentes no se hacen bien ││
│ │ • Calidad cae cuando todo es trabajo apresurado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Clasificación de Urgencia
Definiendo Verdaderas Emergencias
MATRIZ URGENCIA:
┌─────────────────────────────────────────────────────────────┐
│ CLASIFICANDO SOLICITUDES ENTRANTES │
├─────────────────────────────────────────────────────────────┤
│ │
│ CRITERIOS CLASIFICACIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 🔴 EMERGENCIA (Dejar todo): ││
│ │ • Sistema producción caído ││
│ │ • Brecha seguridad activa ││
│ │ • Pérdida datos ocurriendo ││
│ │ • Deadline cumplimiento legal (real, no percibido) ││
│ │ • Bug bloqueando ingresos cliente importante ││
│ │ ││
│ │ 🟡 URGENTE (Este sprint, repriorizar): ││
│ │ • Bug afectando muchos clientes (workaround existe) ││
│ │ • Solicitud con deadline (deadline externo real) ││
│ │ • Bloqueador para otro equipo ││
│ │ • Escalación cliente con riesgo retención ││
│ │ ││
│ │ 🟢 IMPORTANTE (Próximo sprint): ││
│ │ • Solicitud feature de ventas ││
│ │ • "Nice to have" para deadline próximo ││
│ │ • Solicitudes mejora ││
│ │ • Preferencia stakeholder ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Configuración GitScrum
Manejando Trabajo Urgente
WORKFLOW PARA SOLICITUDES URGENTES:
┌─────────────────────────────────────────────────────────────┐
│ GESTIONANDO INTERRUPCIONES EN GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ SISTEMA LABELS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ urgente/emergencia - Dejar todo (rojo) ││
│ │ urgente/este-sprint - Debe caber en sprint (naranja) ││
│ │ urgente/prox-sprint - Importante, puede esperar (amarillo)││
│ │ urgente/declinado - Solicitado urgente, no es urgente ││
│ │ ││
│ │ Trackear "urgente/declinado" para identificar ││
│ │ solicitantes que frecuentemente exageran urgencia ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUFFER CAPACIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Enfoque planificación sprint: ││
│ │ ││
│ │ Capacidad total equipo: 160 horas ││
│ │ ││
│ │ Reservado para trabajo planificado: 128h (80%) ││
│ │ Reservado para interrupciones: 32h (20%) ││
│ │ ││
│ │ Compromiso sprint dimensionado a 80%, no 100% ││
│ │ ││
│ │ Si no ocurren interrupciones: ││
│ │ → Jalar stretch goals o items próximo sprint ││
│ │ ││
│ │ Si interrupciones exceden buffer: ││
│ │ → Intercambiar items planificados explícitamente ││
│ │ → Documentar para retrospectiva ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Marco Comunicación
Respondiendo a Solicitudes Urgentes
MANEJANDO SOLICITUDES DIPLOMÁTICAMENTE:
┌─────────────────────────────────────────────────────────────┐
│ PLANTILLAS RESPUESTA │
├─────────────────────────────────────────────────────────────┤
│ │
│ PARA EMERGENCIAS GENUINAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Entendido. Estamos repriorizando ahora. Sarah tomará ││
│ │ esto inmediatamente. Tendremos que diferir [X] al ││
│ │ próximo sprint para hacer espacio. Te actualizo en ││
│ │ 2 horas con progreso." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PARA URGENTE PERO NO EMERGENCIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Entiendo que esto es importante. Déjame revisar ││
│ │ nuestros compromisos del sprint. Podemos: ││
│ │ ││
│ │ A) Incluir esto moviendo [X] al próximo sprint ││
│ │ B) Empezar esto el lunes como primer item ││
│ │ ││
│ │ ¿Qué funciona mejor para tu timeline?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PARA NO REALMENTE URGENTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Gracias por mencionarlo. Basado en el timeline (fin ││
│ │ de mes), podemos planificar esto apropiadamente para ││
│ │ próximo sprint. Esto nos da tiempo para hacerlo bien. ││
│ │ ││
│ │ Lo agregué al backlog y priorizaremos el jueves." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘