Medindo o que os clientes sentem vs. o que os trabalhadores experimentam.
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.
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.
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.
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.
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.
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:
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.