5 min leitura • Guide 128 of 877
Lidando com Solicitações Urgentes Sem Descarrilar Planos
Solicitações urgentes ameaçam foco do time e compromissos de sprint quando cada novo pedido é tratado como emergência. Sem um sistema para avaliar e lidar com interrupções, times rejeitam trabalho urgente legítimo (danificando relacionamentos com stakeholders) ou aceitam tudo (perdendo objetivos de sprint). Workflows flexíveis do GitScrum e features de visibilidade ajudam times a distinguir emergências reais de solicitações de prioridade regulares e lidar com ambas apropriadamente.
O Problema de Urgência
Por Que Tudo Parece Urgente
INFLAÇÃO DE URGÊNCIA:
┌─────────────────────────────────────────────────────────────┐
│ O PADRÃO "TUDO É URGENTE" │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEMANA TÍPICA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Segunda: ││
│ │ Vendas: "Cliente precisa desta feature urgentemente" ││
│ │ CEO: "Precisamos arrumar homepage até quarta" ││
│ │ ││
│ │ Terça: ││
│ │ Suporte: "Bug crítico afetando 3 clientes" ││
│ │ PM: "Demo investidores adiantada, precisamos ASAP" ││
│ │ ││
│ │ Quarta: ││
│ │ Vendas: "Cliente diferente ameaçando cancelar" ││
│ │ Marketing: "Lançamento campanha precisa integração" ││
│ │ ││
│ │ Sexta: ││
│ │ Todos: "Por que não terminamos trabalho da sprint?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ O PROBLEMA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Quando tudo é urgente: ││
│ │ • Nada é priorizado ││
│ │ • Objetivos sprint perdem significado ││
│ │ • Time se queima por troca de contexto ││
│ │ • Paradoxalmente, coisas urgentes não são feitas bem ││
│ │ • Qualidade cai quando tudo é trabalho apressado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Classificação de Urgência
Definindo Verdadeiras Emergências
MATRIZ URGÊNCIA:
┌─────────────────────────────────────────────────────────────┐
│ CLASSIFICANDO SOLICITAÇÕES ENTRANTES │
├─────────────────────────────────────────────────────────────┤
│ │
│ CRITÉRIOS CLASSIFICAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 🔴 EMERGÊNCIA (Largar tudo): ││
│ │ • Sistema produção fora do ar ││
│ │ • Brecha segurança ativa ││
│ │ • Perda dados ocorrendo ││
│ │ • Deadline compliance legal (real, não percebido) ││
│ │ • Bug bloqueando receita cliente importante ││
│ │ ││
│ │ 🟡 URGENTE (Esta sprint, repriorizar): ││
│ │ • Bug afetando muitos clientes (workaround existe) ││
│ │ • Solicitação com deadline (deadline externo real) ││
│ │ • Bloqueador para outro time ││
│ │ • Escalação cliente com risco retenção ││
│ │ ││
│ │ 🟢 IMPORTANTE (Próxima sprint): ││
│ │ • Solicitação feature de vendas ││
│ │ • "Nice to have" para deadline próximo ││
│ │ • Solicitações melhoria ││
│ │ • Preferência stakeholder ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Configuração GitScrum
Lidando com Trabalho Urgente
WORKFLOW PARA SOLICITAÇÕES URGENTES:
┌─────────────────────────────────────────────────────────────┐
│ GERENCIANDO INTERRUPÇÕES NO GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ SISTEMA LABELS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ urgente/emergencia - Largar tudo (vermelho) ││
│ │ urgente/esta-sprint - Precisa caber na sprint (laranja)││
│ │ urgente/prox-sprint - Importante, pode esperar (amarelo)││
│ │ urgente/declinado - Solicitado urgente, não é urgente││
│ │ ││
│ │ Rastrear "urgente/declinado" para identificar ││
│ │ solicitantes que frequentemente exageram urgência ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUFFER CAPACIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Abordagem planejamento sprint: ││
│ │ ││
│ │ Capacidade total time: 160 horas ││
│ │ ││
│ │ Reservado para trabalho planejado: 128h (80%) ││
│ │ Reservado para interrupções: 32h (20%) ││
│ │ ││
│ │ Compromisso sprint dimensionado a 80%, não 100% ││
│ │ ││
│ │ Se não ocorrem interrupções: ││
│ │ → Puxar stretch goals ou itens próxima sprint ││
│ │ ││
│ │ Se interrupções excedem buffer: ││
│ │ → Trocar itens planejados explicitamente ││
│ │ → Documentar para retrospectiva ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Framework Comunicação
Respondendo a Solicitações Urgentes
LIDANDO COM SOLICITAÇÕES DIPLOMATICAMENTE:
┌─────────────────────────────────────────────────────────────┐
│ TEMPLATES RESPOSTA │
├─────────────────────────────────────────────────────────────┤
│ │
│ PARA EMERGÊNCIAS GENUÍNAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Entendido. Estamos repriorizando agora. Sarah vai ││
│ │ pegar isso imediatamente. Teremos que adiar [X] para ││
│ │ próxima sprint para abrir espaço. Atualizo em 2h." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PARA URGENTE MAS NÃO EMERGÊNCIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Entendo que isso é importante. Deixa eu verificar ││
│ │ nossos compromissos da sprint. Podemos: ││
│ │ ││
│ │ A) Incluir isso movendo [X] para próxima sprint ││
│ │ B) Começar isso segunda como primeiro item ││
│ │ ││
│ │ O que funciona melhor para seu timeline?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘