Sitrep (Relatório de Situação)

O que Sitrep (Relatório de Situação) faz?

Relatórios de situação são para a pessoa que não estava na sala. Escreva para ela.

Um sitrep não é um diário de atividades. É uma imagem comprimida e acionável do estado atual. Três perguntas: o que está feito, o que está bloqueado, o que vem a seguir. Qualquer coisa que não responda a uma dessas três perguntas não pertence ao sitrep.

Quando usar

• Síntese de daily standup a partir de logs de trabalho, commits ou estado de tickets
• Resumo de fim de sprint para stakeholders
• Relatório de situação de incidente durante ou após um incidente ativo
• Resumo de handoff ao mudar de contexto ou entregar trabalho para outro agente ou pessoa
• Quando um stakeholder pergunta "onde estamos?" e a resposta honesta é "está complicado"

Procedimento

1. Reúna o estado atual do trabalho — leia a partir das fontes disponíveis:

   • Issues / tickets abertos e fechados recentemente
   • Commits recentes (últimas 24-48 horas para um standup; último sprint para um resumo de sprint)
   • Documentos de status do projeto e roadmap (ex.: docs/operating-model/PROJECT-OPERATING-PROFILE.md, docs/ROADMAP.md ou equivalente conforme estrutura do projeto)
   • Quaisquer flags de bloqueio, registros de risco ou notas de escalação

2. Classifique os itens em três categorias:

   • Feito (Done) — concluído e verificavelmente encerrado (testes passando, ticket fechado, implantado)
   • Bloqueado (Blocked) — trabalho que não pode progredir sem uma dependência específica não resolvida (nomeie o bloqueador precisamente)
   • Próximo (Next) — os itens de maior prioridade que serão trabalhados a seguir (ordenados por prioridade)

3. Redija o sitrep — estrutura:

   ## Sitrep — <data> [<escopo: sprint / incidente / handoff>]
   
   **Feito**
   - <item> — <uma frase sobre o que foi entregue e sua evidência>
   
   **Bloqueado**
   - <item> — bloqueado por <dependência específica / responsável / ETA se conhecido>
   
   **Próximo**
   - <item> — <ordem de prioridade, mais importante primeiro>
   
   **Riscos / flags** (opcional — somente se relevante)
   - <risco> — <impacto se não resolvido> — <responsável>
   

4. Aplique o teste de compressão — para cada linha: se removê-la não muda nada que o leitor precise agir, remova-a.

5. Nomeie bloqueadores precisamente — "bloqueado no backend" não é uma entrada de bloqueador. "Bloqueado no contrato da API para /v2/orders — aguardando @responsável, ETA desconhecido" é.

6. Não editorialize o progresso — "fez um bom progresso" é ruído. "Entregou X, que desbloqueia Y" é sinal.

Saídas

• Um sitrep no formato acima
• Opcional: um resumo executivo de um parágrafo para stakeholders que precisam de ainda menos

Guardrails

• Sem relato de atividade. "Trabalhei no módulo de autenticação" não é uma entrada de sitrep. "Módulo de autenticação: validação JWT concluída, renovação de token falhando sob carga — investigando" é.
• Bloqueado significa bloqueado. Se algo está lento mas não está efetivamente bloqueado, pertence a "Próximo" com uma nota, não a "Bloqueado".
• Feito significa feito. "95% concluído" não está feito. Se não está verificavelmente completo, é "Próximo".
• Tamanho não é qualidade. Um sitrep de cinco linhas que responde às três perguntas é melhor do que um de vinte linhas que não responde.