Change lead time

A maioria dos líderes de engenharia sabe que o time está lento, mas não consegue identificar onde o tempo está sendo perdido. O change lead time é a métrica que responde essa pergunta: ela mede quanto tempo um commit leva para chegar à produção. Quando esse número é alto, seu pipeline de entrega tem um gargalo, e o squad está pagando o preço na forma de releases atrasados, stakeholders frustrados e work-in-progress acumulando. Esta página cobre a definição de change lead time, como medi-lo em relação aos benchmarks publicados, como melhorá-lo e como o DevStats o exibe automaticamente.

Principais conclusões

• O change lead time mede o tempo total decorrido desde o primeiro commit de um player até a mudança estar em produção. É uma das quatro DORA metrics e um sinal direto de quão eficientemente seu pipeline de entrega está operando. Times com change lead times menores entregam valor aos clientes mais rápido e se recuperam de incidentes com mais agilidade.
• O change lead time é calculado assim: hora do deployment em produção menos a hora do primeiro commit, com média sobre todas as mudanças em um período. Segundo o DORA State of DevOps Report de 2023, times de elite alcançam change lead times menores que uma hora, enquanto times de baixo desempenho levam mais de seis meses.
• O erro mais comum é tratar o change lead time como uma métrica de velocidade de codificação. Na prática, a maior parte do tempo acumula em filas de code review, ambientes de staging, gates de aprovação manual e pipelines de deployment, não no tempo que um player passa escrevendo código. Otimizar a etapa errada não gera nenhuma melhoria mensurável.
• O DevStats rastreia o change lead time automaticamente conectando ao seu provedor Git e ao seu issue tracker, com benchmarks em relação a mais de 1.000 times de engenharia. Você vê os números do seu squad divididos por etapa, comparados com pares e com tendência ao longo do tempo. Comece um trial gratuito e veja seus números em menos de dois minutos.

Definição de change lead time

Change lead time é o tempo total que uma mudança de código leva desde o primeiro commit do desenvolvedor até estar rodando em produção. É uma das quatro DORA metrics usadas para medir a performance de entrega de software, ao lado de deployment frequency, change failure rate e mean time to restore.

Tecnicamente, o change lead time vai do timestamp do primeiro commit em uma branch até o timestamp do deployment em produção que inclui esse commit. Normalmente é expresso como valor mediano ou percentil 75 sobre todos os deployments em uma janela contínua. Times que o rastreiam com precisão puxam dados do seu provedor Git (para timestamps de commit), do seu pipeline de CI/CD (para durações de build e teste) e das suas ferramentas de deployment (para timestamps de release). Change lead times menores significam que seu squad consegue responder a feedback de clientes, corrigir bugs e entregar features sem esperar dias por uma janela de release. Essa capacidade de resposta é uma vantagem competitiva direta. O DevStats conecta essas fontes de dados pela sua funcionalidade de DORA metrics, oferecendo uma visão unificada de onde o tempo está acumulando no pipeline de entrega.

Por que o change lead time importa para times de engenharia

Quando squads não rastreiam o change lead time, a entrega lenta se torna invisível. O trabalho se acumula em filas de revisão, ambientes de staging ficam parados esperando aprovações, e janelas de deployment viram gargalos sem dono. O resultado são compromissos de sprint perdidos, work-in-progress crescendo e players que passam mais tempo esperando do que construindo. Quando um VP de Engenharia percebe o problema, ele geralmente já vem se agravando por semanas.

O change lead time se conecta diretamente aos KPIs pelos quais a maioria dos líderes de engenharia é responsável: entrega no prazo, cadência de release e capacidade de responder a incidentes em produção rapidamente. Um time com change lead time medido em dias não consegue fazer um hotfix em um bug crítico sem um processo de exceção manual doloroso. Um time medido em horas consegue. Essa diferença aparece nos scores de satisfação do cliente, na conformidade com SLA e no próprio moral do time de engenharia. Rastrear a velocidade de entrega no nível de processo dá a você evidências para ter essas conversas com produto e liderança sem precisar adivinhar.

O change lead time é uma das quatro DORA metrics, baseadas em anos de pesquisa que correlacionam performance de entrega com resultados organizacionais. Medir é o primeiro passo. O líder de engenharia é quem decide onde intervir quando os dados tornam o gargalo visível.

Como medir o change lead time

Para calcular o change lead time, subtraia o timestamp do primeiro commit em uma branch do timestamp do deployment em produção que entrega essa branch. Calcule a média sobre todos os deployments na sua janela de medição e reporte a mediana junto com o percentil 75 para evitar que outliers distorçam o resultado. Você precisa de três fontes de dados para fazer isso com precisão: seu provedor Git (GitHub, GitLab, Bitbucket) para timestamps de commit, seu pipeline de CI/CD para durações de build e teste, e suas ferramentas de deployment ou sistema de gestão de releases para timestamps de produção. Se o seu time também rastreia issues, conectar seu issue tracker adiciona contexto sobre quanto tempo o trabalho ficou no backlog antes mesmo de o código começar a ser escrito, o que é uma medição relacionada, mas distinta. A funcionalidade de benchmarks do DevStats permite comparar seu change lead time com times de tamanho e stack similares, para que você saiba se seus números são competitivos ou estão abaixo do esperado.

Os benchmarks abaixo são extraídos do DORA State of DevOps Report de 2023.

Change lead time na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que o change lead time do squad tinha subido de três dias para onze dias em um único trimestre. Os commits saíam em ritmo normal, mas os PRs ficavam em revisão por uma média de quatro dias antes de alguém pegá-los. A VP puxou os dados, viu que dois players sênior eram os únicos aprovando PRs relacionados à infraestrutura e identificou o gargalo imediatamente: um monopólio de revisão de fato, que ninguém havia criado explicitamente.

Ela reestruturou a rotação de revisão, expandiu os direitos de aprovação para três engenheiros adicionais com o contexto relevante e estabeleceu uma norma de SLA de primeira revisão em 24 horas para o squad. Ela mediu o PR cycle time semanalmente durante o mês seguinte. O change lead time voltou para quatro dias em seis semanas. A intervenção foi simples depois que os dados tornaram o problema visível. A ferramenta não corrigiu nada. Ela corrigiu.

Como melhorar o change lead time

1. Quebre o trabalho em pull requests menores. PRs grandes demoram mais para revisar, mais para testar e mais para fazer deploy com segurança. Estabeleça uma norma de tamanho de PR para o squad (menos de 400 linhas alteradas é um ponto de partida razoável) e rastreie se o tamanho médio do PR se correlaciona com o tempo de espera na revisão. Batches menores passam mais rápido por cada etapa do pipeline.
2. Defina e cumpra um SLA de primeira revisão. O maior consumidor de tempo na maioria dos pipelines não é o CI nem o deployment: são os PRs esperando por um primeiro revisor. Combine uma janela de resposta (24 horas é o padrão para times de alta performance) e torne isso visível nos seus dados de code review. Se o SLA está sendo perdido de forma consistente, o problema geralmente é alocação de capacidade, não falta de vontade.
3. Automatize seu pipeline de deployment de ponta a ponta. Etapas manuais de deployment são a fonte mais previsível de atraso. Audite seu pipeline em busca de qualquer etapa que exija que uma pessoa clique em um botão, aprove um ticket ou execute um script. Cada uma é candidata à automação. Rastreie a deployment frequency junto com o change lead time: times que fazem deploy com mais frequência tendem a ter lead times menores porque são obrigados a manter o pipeline limpo.
4. Reduza os limites de work-in-progress por player. Quando um player tem quatro branches abertas ao mesmo tempo, nenhuma delas avança rápido. Limitar o WIP simultâneo força a priorização e mantém o código se movendo pela revisão e chegando à produção, em vez de envelhecer na prateleira. Monitore o throughput para confirmar que reduzir o WIP aumenta a taxa de entrega real, em vez de apenas reduzir a atividade.
5. Audite seus gates de staging e aprovação. Se o seu squad tem um ambiente de staging com múltiplos estágios e aprovação manual em cada gate, meça quanto tempo as mudanças ficam paradas em cada etapa. Muitas vezes, 80% do lead time total está concentrado em um ou dois gates. Eliminar ou paralelizar esses gates tem um impacto desproporcional no change lead time geral.

Change lead time vs. cycle time

Change lead time e cycle time são relacionados, mas medem intervalos diferentes do processo de entrega. Confundi-los leva a um diagnóstico incompleto.

Use o change lead time para avaliar sua capacidade de entrega de ponta a ponta e use o cycle time para diagnosticar o que acontece especificamente dentro das etapas de desenvolvimento e revisão.