Modo Crise — Quando o Urgente Engole o Importante

O que fazer quando a demanda crítica/urgente supera a demanda normal — quando o time passa mais tempo apagando incêndio do que construindo, e a manutenção corretiva devora a capacidade que deveria ir para prevenir os próximos incêndios.

Este é o estado que o resto do framework existe para evitar. Se você está aqui agora, comece por este documento: primeiro estanque o sangramento, depois volte aos pilares e ao roadmap.

Você está em modo crise se...

Não é sobre ter um incidente ruim. É sobre o urgente virar o estado permanente. Sinais:

O time não consegue mais planejar — o dia é definido pelo que quebrou
Trabalho planejado escorrega de sprint em sprint "porque surgiu uma urgência"
Toda tarefa vira "prioridade máxima" (e quando tudo é prioridade, nada é)
As pessoas estão exaustas, em alerta constante, e a rotatividade começa a subir
Você conserta o mesmo tipo de problema repetidas vezes
Ninguém lembra a última vez que fez algo preventivo

Se você marcou a maioria, a demanda urgente já superou a normal. O objetivo aqui é inverter essa balança — não com heroísmo, mas com decisões estruturais.

Diagnóstico: o ciclo vicioso

O apaga-incêndio se retroalimenta. É uma espiral, não um evento isolado:

        ┌──────────────────────────────────────────────┐
        │                                              │
        ▼                                              │
   Incidente/urgência                                  │
        │                                              │
        ▼                                              │
   Corretiva consome                                   │
   toda a capacidade                                   │
        │                                              │
        ▼                                              │
   Não sobra tempo                                     │
   para preventiva  ──────►  Dívida técnica cresce ────┘
                            (mais fragilidade → mais incidentes)

Cada volta na espiral deixa o sistema mais frágil, o que gera mais incidentes, que consomem mais capacidade — e assim por diante. Sem uma intervenção deliberada, ela não se corrige sozinha.

Por que o urgente sempre ganha do importante

A corretiva tem prazo visível; a preventiva, não. Um checkout fora do ar grita agora. Refatorar um módulo frágil "pode esperar" — até virar o próximo incêndio.
Urgência sequestra a atenção. O cérebro (e a organização) prioriza a ameaça imediata, mesmo quando o importante tem retorno muito maior.
A pressão externa é assimétrica. Cliente e vendas cobram o que veem quebrado; ninguém cobra a manutenção que teria evitado a quebra.

⚠️ A armadilha: quanto mais você cede ao urgente, mais urgente o futuro se torna. Priorizar só o que grita é escolher acumular gritos.

Priorização sob pressão (quando tudo é "urgente")

No modo crise, "priorizar por importância" não basta — tudo parece urgente. Você precisa de filtros mais grosseiros e rápidos.

Filtro 1 — Matriz de Eisenhower (urgente × importante)

	Urgente	Não urgente
Importante	🔴 Faça agora — incidentes SEV1/2, risco real ao negócio	🟢 Agende e proteja — preventiva, refatoração, testes (é aqui que se sai da crise)
Não importante	🟡 Delegue/automatize — interrupções, pedidos "urgentes" de baixo impacto	⚪ Elimine — ruído, pedidos que não movem nada

A crise vive no quadrante 🔴. A saída está no 🟢 — o quadrante que a crise nunca deixa você visitar. Escapar = roubar capacidade dos outros quadrantes para blindar o verde.

Filtro 2 — Triagem por severidade

Nem toda urgência é uma emergência. Classifique rápido (mesma escala do postmortem):

Sev	Critério	Resposta
SEV1	Sistema crítico fora do ar / perda de dados / receita parando	Largar tudo, war room
SEV2	Degradação séria, com contorno possível	Tratar no dia, mas sem parar o time todo
SEV3	Incômodo, sem impacto real imediato	Entra na fila normal — não é urgência

Metade do que chega rotulado como "urgente" é SEV3. Reclassificar já devolve fôlego.

Filtro 3 — A pergunta que corta

Para qualquer pedido "urgente": "O que acontece de concreto se eu não fizer isso hoje?" Se a resposta é "nada de grave", não era urgente.

Noção de error budget

Perfeição absoluta é cara e desnecessária. Defina um limite tolerável de falha (ex: 99,9% de disponibilidade) — o error budget é o quanto você pode falhar dentro da meta. Enquanto está dentro do orçamento, é permitido investir em evolução/preventiva em vez de caçar cada micro-falha. Quando o orçamento estoura, aí sim a estabilidade vira prioridade. Isso troca o "tudo é urgente" por um critério objetivo.

Plano de escape: saindo do modo reativo

Sair da crise exige uma intervenção estrutural — não "trabalhar mais". Cinco passos:

1. Estancar — pare de piorar

Congelar temporariamente features não-críticas (menos mudança = menos incidente novo)
Comunicar o congelamento ao negócio antes (ver seção de comunicação)

2. Proteger capacidade — blindar parte do time

Designar um "bombeiro do dia" (rotativo) que absorve as urgências
O resto do time fica blindado do apaga-incêndio para trabalhar na saída
Rotação evita burnout e espalha o conhecimento de operação

Este é o passo-chave. Sem blindar capacidade, os passos 3–5 nunca acontecem — o urgente comeria todo o tempo de novo.

3. Sprint (ou semana) de estabilização

Um timebox dedicado só a reduzir a origem dos incêndios
Foco no que dá mais alívio por esforço (use a matriz de priorização)
Formalize com o Plano de Estabilização

4. Limites de WIP (Work In Progress)

Reduzir o número de coisas em andamento ao mesmo tempo
Menos troca de contexto = mais coisa realmente terminada = menos frentes abertas
Cortar a maior fonte de interrupção: se o suporte drena o time a cada dúvida, veja Conhecimento Preso

5. Atacar as causas-raiz recorrentes

Listar os incidentes que se repetem (o mesmo bug, o mesmo tipo de falha)
Resolver a causa de fundo de 1–2 deles elimina uma fatia grande da demanda urgente
Cada causa-raiz resolvida é uma volta a menos na espiral

Estes passos são, na prática, uma entrada acelerada na Fase 1 — Estabilizar do roadmap: ganhar visibilidade e controle mínimo. A diferença é a urgência — aqui você faz sob fogo.

Comunicação com o negócio / board

O modo crise é, no fundo, um problema de expectativa: o negócio espera features enquanto o time precisa estabilizar. Alinhar isso é responsabilidade do CTO.

Torne visível o custo invisível. O board não vê a dívida técnica — vê features atrasadas. Traduza:

"Estamos gastando X% do time só corrigindo o que quebra. Cada nova feature em cima dessa base aumenta a taxa de quebra. Não é falta de esforço — é a base que precisa ser estabilizada."

Apresente o trade-off honestamente, com dados:

"Hoje podemos entregar features ou parar de quebrar — não os dois ao mesmo tempo. Proponho N semanas focadas em estabilizar. O retorno é velocidade sustentável depois."

Use métricas concretas (DORA, % de tempo em corretiva) para sair do "acho que" e entrar no "os números mostram".

Reframe essencial: estabilizar não é parar de entregar valor — é investir em velocidade futura. Um time em crise permanente entrega cada vez menos; um time estabilizado acelera. O gasto de curto prazo compra vazão de longo prazo.

Critérios de saída (voltando ao normal)

Você saiu do modo crise quando:

✅ A demanda urgente cabe no "bombeiro do dia" — não sequestra mais o time todo
✅ O time voltou a planejar e a cumprir o planejado
✅ Os incidentes recorrentes que mais doíam foram eliminados na causa-raiz
✅ Você consegue proteger uma fatia estável de capacidade (~20%) para preventiva

A partir daí, o jogo deixa de ser "sobreviver" e volta a ser "evoluir": retome o roadmap de maturidade na Fase 1/2 e blinde os ~20% com o Pilar 7 — Priorização & Equilíbrio para não cair na espiral de novo.

➡️ Relacionado: Roadmap — Fase 1: Estabilizar · Pilar 7 — Priorização · Template: Plano de Estabilização · Métricas

Gerado por build.py · atualize os .md e rode de novo.