Simyl
simylflow
Início do Curso
Módulo 3: Fluxo de Valor e Fluxo
Lição 3 de 5
12 min

Lead Time vs. Cycle Time

Medindo o que os clientes sentem vs. o que os trabalhadores experimentam.

1Definições que Importam

Esses termos são frequentemente confundidos, mas são crucialmente diferentes:

Lead Time: O tempo total decorrido desde quando um cliente faz uma solicitação até quando recebe o valor. Isso é o que o cliente experimenta. Inclui toda a espera, todo o processamento, tudo.

Cycle Time: O tempo que o trabalho passa sendo ativamente trabalhado. Isso é o que os trabalhadores experimentam durante sua parte do fluxo.

Exemplo: Um cliente solicita uma funcionalidade na segunda-feira. Ela é priorizada e puxada para desenvolvimento na quarta-feira. Um desenvolvedor trabalha nela por 2 dias. Ela fica em revisão de PR por 3 dias. O teste leva 1 dia. Ela é implantada na sexta-feira da semana seguinte.

  • Lead Time: 12 dias (segunda-feira até sexta-feira da semana 2)
  • Cycle Time (Desenvolvimento): 2 dias
  • Cycle Time (Revisão): Algumas horas
  • Cycle Time (Teste): 1 dia

Observe: o trabalho ativo foi talvez 4 dias no total. O lead time foi de 12 dias. Oito dias foram de espera.

A Métrica que Você Provavelmente Acompanha Está Errada

A maioria das equipes acompanha cycle time ou velocity—o que os trabalhadores produzem. Mas os clientes não se importam com sua velocity. Eles se importam com lead time—quanto tempo esperam. Otimize para o que os clientes sentem, não para o que parece bom internamente.

2De Onde Vem a Diferença

A diferença entre lead time e cycle time é o tempo de espera. E o tempo de espera normalmente domina.

Tempo de fila: Trabalho parado em backlogs, esperando para ser priorizado, esperando alguém pegá-lo.

Atrasos de handoff: Trabalho concluído em uma etapa, esperando a próxima etapa ter capacidade.

Atrasos de lote: Trabalho que está finalizado mas esperando ser implantado com outro trabalho.

Dependências externas: Esperando outras equipes, fornecedores ou aprovações.

Atrasos de calendário: Trabalho que está pronto mas "só implantamos às terças-feiras."

Na maioria das organizações de software, o tempo de espera é 80-95% do lead time. Isso significa que apenas 5-20% do tempo, o trabalho está realmente sendo trabalhado.

A implicação: melhorar a velocidade com que você trabalha tem impacto mínimo. Se você trabalha duas vezes mais rápido mas as esperas permanecem as mesmas, o lead time mal muda. A alavancagem está nas esperas.

2 Horas de Trabalho, 2 Semanas de Lead Time

Uma correção de bug simples: 2 horas de tempo do desenvolvedor. Mas: 3 dias esperando atribuição, 2 dias esperando revisão de PR, 1 dia esperando QA, 3 dias esperando a implantação semanal, 2 dias monitorando em produção. Lead time: 11 dias.

Mesmo Trabalho, Sistema Diferente

Mesma correção de bug, equipe diferente: PR revisado em horas (PRs pequenos, prioridade da equipe na revisão). Sem fila de QA (desenvolvedores testam seu próprio código). Implantação contínua (sem janelas de implantação). Lead time: 3 horas.

3Touch Time e Wait Time

Outra divisão útil:

Touch Time: Tempo em que o trabalho está sendo ativamente progredido por um humano. Mãos no teclado. Cérebro engajado neste problema.

Wait Time: Todo o tempo entre eles. Em filas. Esperando revisão. Esperando implantação. Esperando informação.

Processing Time: Touch time mais tempo de máquina (builds, testes, implantações). Isso é cycle time.

Quando você entende essa divisão, pode direcionar melhorias corretamente:

  • Touch time longo mas alto valor agregado? Provavelmente não é desperdício—isso é trabalho qualificado.
  • Touch time longo mas baixo valor agregado? Desperdício potencial—automatize ou elimine.
  • Wait time longo? Quase certamente desperdício—reduza lotes, limite WIP, elimine filas.

A maioria das equipes tenta tornar o touch time mais rápido (melhores ferramentas, mais desenvolvedores) quando o problema é o wait time (muito WIP, lotes, filas). É como tentar fazer carros andarem mais rápido quando estão presos no trânsito.

Se você tem um problema de lead time, provavelmente tem um problema de wait time. Se você tem um problema de wait time, provavelmente tem um problema de WIP. Reduzir WIP é geralmente o caminho mais rápido para lead times mais curtos.

Principais Conclusões
  • Lead time é o que os clientes experimentam; cycle time é tempo de trabalho
  • A diferença entre eles é wait time—geralmente 80-95% do lead time
  • Melhorar a velocidade do trabalho tem impacto mínimo no lead time
  • Wait time é geralmente o maior ponto de alavancagem para melhoria
  • Acompanhe lead time como sua métrica principal—é o que os clientes sentem