Pular para o conteúdo

Mapeamento de fluxo de valor

Avançado14 min de leituracultura
Antes disto:

Quando o lead time está alto, o instinto é otimizar o que se enxerga: acelerar o build, comprar runner maior, cobrar revisão mais rápida. Quase sempre é o alvo errado. O mapeamento de fluxo de valor existe para mostrar onde o tempo realmente vai — e a resposta costuma ser espera, não trabalho.

Escolha uma mudança concreta e recente (não a hipotética), e reconstrua o caminho dela da ideia até estar em produção, com o time em uma sala por duas horas.

Para cada etapa, registre três números:

  • PT (tempo de processo): quanto tempo alguém trabalhou nisso.
  • LT (tempo decorrido): quanto tempo passou até a etapa terminar.
  • %C&A (completo e correto): quanto do que chega já vem em condições de seguir, sem retrabalho.
Ideia priorizada ─ PT 2h LT 12 dias %C&A 70% (espera na fila do backlog)
Refinamento ─ PT 3h LT 4 dias %C&A 80%
Desenvolvimento ─ PT 3d LT 5 dias %C&A 90%
Revisão de código ─ PT 40min LT 2 dias %C&A 85% ← espera
CI ─ PT 22min LT 22min %C&A 95%
Aprovação de CAB ─ PT 15min LT 6 dias %C&A 100% ← espera
Deploy ─ PT 20min LT 20min %C&A 90%
────────────────────────────────────────────────────
Total: PT ≈ 3,5 dias | LT ≈ 29 dias | eficiência de fluxo ≈ 12%

A eficiência de fluxo (PT ÷ LT) é o número que muda a conversa. Entre 5% e 15% é o comum — ou seja, a mudança passa 85% a 95% do tempo esperando, não sendo trabalhada. Otimizar os 22 minutos de CI num fluxo desses não muda nada.

  • Fila de priorização antes de alguém começar.
  • PR aberto esperando revisão.
  • Espera por ambiente de teste compartilhado.
  • Aprovação de comitê ou janela de deploy.
  • Dependência de outro time (um endpoint, uma permissão, um dado).
  • Retrabalho por requisito incompleto (o %C&A baixo lá no começo).

Repare que quase nada disso se resolve com ferramenta. Resolve-se com política e com desenho de time — o que liga esta página diretamente a Team Topologies.

O gargalo é a etapa que limita a vazão do sistema inteiro. Melhorar qualquer etapa que não seja ela não aumenta a entrega — só acumula trabalho parado na frente do gargalo.

Como identificar: procure onde o trabalho se acumula (a fila mais longa), onde o LT é desproporcional ao PT, e onde o %C&A é mais baixo (retrabalho consome capacidade duas vezes).

E cuidado com a armadilha da ocupação: manter todo mundo 100% ocupado aumenta o tempo de espera. Sistema sem folga forma fila — é o mesmo comportamento não linear de um servidor saturado, aplicado a pessoas.

Ataque o gargalo com a intervenção mais barata que funciona:

Gargalo Intervenção típica
Revisão de código PRs menores, revisão como primeira tarefa do dia, mais donos por área
Ambiente compartilhado Ambiente efêmero por PR
Aprovação de comitê Substituir por controle automatizado no pipeline e revisão por pares
Dependência de outro time Autoatendimento pela plataforma, ou mover a responsabilidade
Retrabalho por requisito ruim Critério de pronto antes de entrar na fila
Deploy manual Automatizar e reduzir o lote

Sobre o comitê de mudanças: a pesquisa DORA é direta ao mostrar que aprovação externa de mudança correlaciona com pior desempenho de entrega e de estabilidade. O caminho que atende auditoria e melhora o fluxo é substituir aprovação humana genérica por controle automatizado com evidência — testes, política como código, revisão por pares registrada, deploy rastreável.

Mude uma coisa por vez e meça de novo. Alterar cinco etapas juntas impede saber o que funcionou.

Resolvido o gargalo, ele se move — sempre. O que era espera de revisão vira espera de ambiente. Por isso o mapeamento é um exercício recorrente (a cada trimestre, ou depois de uma mudança grande), e não um documento.

Guarde os mapas anteriores: a série histórica de eficiência de fluxo é uma das evidências mais convincentes que um time pode levar para a liderança — muito mais que a sensação de que “está melhor”.

Próximo passo: você fechou a trilha de Cultura. Se o gargalo é atrito de plataforma, continue em Quando construir uma plataforma.