Lead Time for Changes (Lead Time de Mudança): O Que É e Como Calcular

O que mede

Lead time de mudança é o tempo entre um código ser commitado (ou mergeado) e esse mesmo código rodando em produção. É uma medida direta de quão rápido uma correção ou feature chega de verdade num usuário — não quão rápido alguém escreve o código, mas quanto tempo o resto do pipeline (revisão, teste, deploy) leva depois que o código já está pronto.

Por que importa

Lead time é a métrica que transforma "estamos trabalhando nisso" numa promessa de verdade. Um bug reportado ou um pedido de cliente não parece resolvido quando alguém começa a escrever código pra ele — parece resolvido quando o conserto está no ar. Um time com lead time medido em dias consegue dizer com credibilidade "isso vai ser corrigido essa semana"; um time com lead time medido em meses só consegue dizer "está na fila", porque é genuinamente tudo que sabem. Encurtar o lead time é um dos poucos investimentos de engenharia que aparece direto como uma resposta melhor pra "quando isso vai sair".

Também é um diagnóstico, não só um resultado. Um lead time longo raramente é um gargalo grande só — geralmente são vários pequenos empilhados: código parado sem revisão, uma suíte de teste que leva horas, um processo de deploy que precisa de alguém acompanhando na mão. Medir o número regularmente é o que revela qual desses é de fato o maior pra resolver primeiro, em vez de chutar.

Como calcular

Pra cada mudança, meça o tempo entre o commit (ou merge na main) e o deploy que primeiro incluiu ela em produção, e então olhe a distribuição entre mudanças ao longo de um período — mediana importa mais que média aqui, já que algumas mudanças incomumente lentas podem distorcer o número. Um único "lead time" que na verdade é uma média de tamanhos de mudança muito diferentes (uma correção de uma linha vs. uma feature de várias semanas) costuma ser menos útil do que olhar a mediana e a dispersão juntas.

Um exemplo rápido: 10 pull requests são mergeados numa semana, com lead times (commit até produção) de 2h, 3h, 4h, 5h, 6h, 8h, 10h, 12h, 20h e 96h — um PR que ficou esperando por uma janela de release atrasada. A mediana é 7h, que é o que uma mudança típica de fato passa. A média, 16,6h, é puxada quase toda por esse valor fora da curva — reportar só a média aqui faria uma semana rápida parecer lenta.

Performance elite vs. típica

Times de elite tipicamente colocam uma mudança em produção em menos de um dia. Times no meio costumam levar entre um dia e uma semana, às vezes até um mês. Times de performance mais baixa podem levar um mês ou mais. Como na frequência de deploy, trate isso como uma noção geral de escala, não um placar rígido — as faixas exatas mudaram um pouco entre diferentes anos do State of DevOps Report.

Uma armadilha comum

Começar a contagem no merge em vez do primeiro commit faz o lead time parecer melhor sem o pipeline de fato ficar mais rápido — só para de contar o tempo que uma mudança passou em revisão, que é muitas vezes onde o atraso de verdade mora. Nenhum dos dois pontos de partida está errado, mas vale a pena deixar explícito qual um time está usando antes de comparar o número ao longo do tempo ou entre times.

Como o moasy.tech calcula isso

O moasy.tech recalcula o lead time de mudança automaticamente a partir do que já sincroniza do GitHub, GitHub Actions, ArgoCD, Vercel e Azure Pipelines — somente leitura, sem caça manual de timestamp. Qual evento inicia a contagem (um commit, um merge, a abertura de um PR) é configurável por time, com um padrão da empresa como fallback, então dois times com fluxos de trabalho diferentes podem cada um medir o mesmo conceito corretamente, em vez de forçar uma única definição nos dois.

Veja as outras 3 métricas DORA no guia completo, ou a implementação inteira na página de DORA Metrics.

Perguntas sobre lead time de mudança