O status único que mente para o cliente e para o time
Por William Pereira ·
Uma slide única tenta servir a dois senhores: o sponsor quer saber o que saiu; o time quer saber onde o fluxo emperra. Quando os dois números moram no mesmo quadro, alguém perde — ou o cliente vê custo interno irrelevante, ou o time esconde fila atrás de um percentual confortável.
Duas ideias complementares ajudam: dois públicos de métrica e limite de trabalho em progresso. Uma organiza a conversa; a outra organiza o sistema.
Um status vs dois públicos
| Status único | Progresso (cliente) + Ops (time) | |
|---|---|---|
| Pergunta | “Como estamos?” | “O que entregamos?” / “Onde emperra?” |
| Conteúdo | Percentual + desculpas + custo interno | Status de entrega vs idade de fila e tempo de ciclo |
| Risco | Politizar o número errado | Disciplina de manter duas fontes |
| Ação típica | “Acelera” | Priorizar valor / cortar gargalo |
Referências que seguram a abordagem
Goodhart: quando uma medida vira meta, deixa de ser boa medida. Em engenharia isso aparece como velocity inflada ou cobertura cosmética. Por isso ops interno não deve ser a “nota” do time na call com o cliente — e progresso externo não deve ser o único termômetro de saúde do fluxo. Ver discussões aplicadas, por exemplo em métricas de qualidade no InfoQ.
Outcome over output (Martin Fowler): contar features ou pontos não prova valor. O relatório de progresso deveria aproximar-se de resultado para o usuário; o de ops, de atrito do sistema. Ver Outcome Over Output.
Little’s Law e Kanban: em sistema estável, o WIP médio relaciona-se com throughput e tempo de ciclo. Mais itens “em paralelo” sem aumentar throughput alonga o ciclo. Paralelizar três frentes no mesmo módulo não é velocidade — é fila disfarçada. O método Kanban trata limite de WIP como prática central precisamente por isso.
Prós
- Sponsor prioriza; TL corta gargalo — conversas diferentes.
- WIP explícito torna o custo do paralelismo visível.
- Funciona com planilha; ferramenta só acelera.
- Reduz a tentação de otimizar custo de ferramenta na call errada.
Contras
- Dois artefatos pedem dono e rotina.
- Estimativas ruins distorcem progresso — lixo na entrada.
- WIP limit cego demais pode subutilizar capacidade pontual.
- Sem ortogonalidade, “paralelo” só multiplica conflito.
Na prática
Toda sexta: uma página de progresso (o que mudou de status, o que fechou, sem custo de ferramentas internas) e uma página de ops (itens parados em review/QA, idade, o que mais demorou). Combine com um limite simples: no máximo N itens em implementação por time; item novo só entra quando um sai.
Paralelo só entre trabalhos ortogonais — serviços, donos e migrations diferentes. Se a quinzena anterior foi chat solto e a próxima usar contrato + floor de review + dois relatórios + WIP, compare de forma qualitativa: menos “não era isso”, menos PR parado, menos sexta sem merge. Ajuste os números depois de o sistema estabilizar.
Se quiser ver uma implementação open source desses padrões — que mantenho e uso no dia a dia — o repositório está em github.com/pereirawe/codex-flow.