Duas equipes podem reportar cycle time e medir intervalos diferentes, porque uma começa a contagem no primeiro commit enquanto a outra começa quando um pull request é aberto. Se esses limites não estiverem explícitos, comparar os números pouco diz a um líder sobre onde o trabalho fica mais lento.
Este guia explica como calcular 15 métricas de engenharia, quais decisões elas apoiam e onde sua interpretação pode falhar.
Métricas de engenharia para decisões de liderança em 2026
| # | Métrica de engenharia | O que mede | Uso principal |
|---|---|---|---|
| 1 | Frequência de deploy | Com que frequência uma aplicação ou serviço chega à produção | Examinar a cadência de releases e o tamanho dos lotes |
| 2 | Lead time de mudanças | Tempo decorrido do commit à execução bem-sucedida em produção | Encontrar atrasos depois que o código é commitado |
| 3 | Tempo de recuperação de deploy com falha | Tempo para se recuperar de uma falha causada por deploy | Avaliar a capacidade de recuperação para falhas relacionadas a mudanças |
| 4 | Taxa de falha de mudanças | Parcela dos deploys que exige remediação | Observar a instabilidade da entrega |
| 5 | Taxa de retrabalho de deploy | Parcela dos deploys que responde de forma não planejada a incidentes em produção | Quantificar o trabalho reativo de deploy |
| 6 | PR cycle time | Tempo decorrido em um intervalo de pull request definido explicitamente | Localizar atrasos no fluxo de uma mudança |
| 7 | Tempo até a primeira revisão | Tempo entre a abertura do PR e a primeira revisão humana | Examinar o início da revisão e a capacidade dos revisores |
| 8 | Tempo de feedback de build e testes | Tempo entre iniciar um build ou teste e receber um resultado utilizável | Priorizar ciclos de feedback lentos |
| 9 | Throughput | Itens concluídos de um tipo definido por período | Entender a taxa de entrega e apoiar previsões |
| 10 | Trabalho em progresso | Itens ativos em um fluxo ou etapa em determinado momento | Expor filas, sobrecarga e trabalho envelhecido |
| 11 | Alocação de engenharia | Parcela do esforço atribuída a categorias estáveis de trabalho | Comparar o investimento real com as prioridades |
| 12 | Acurácia do planejamento | Parcela do trabalho previsto para o Sprint que foi concluída sob uma regra estável de contagem | Calibrar previsões no Scrum e revelar trabalho não planejado |
| 13 | Conformidade com SLO e error budget | Se o comportamento do serviço relevante para o usuário atende ao objetivo | Equilibrar confiabilidade e decisões de release |
| 14 | Satisfação dos desenvolvedores | Respostas recorrentes de pesquisa sobre a experiência de trabalho dos desenvolvedores | Encontrar fricções que a telemetria do fluxo não observa |
| 15 | Impacto da entrega assistida por IA | Entrega, confiabilidade e custos de revisão para trabalho comparável assistido por IA | Avaliar se a IA melhora o sistema de entrega como um todo |
Defina a métrica antes de comparar o número
Antes de adicionar uma métrica de engenharia ao dashboard, registre os seis campos a seguir.
- Especifique os eventos inicial e final, estados ou respostas de pesquisa utilizados.
- Defina a população, incluindo serviços, equipes, tipos de trabalho ou respondentes.
- Declare a unidade contada, como deploys, itens de trabalho ou requisições.
- Registre a janela do relatório e a agregação, como taxa, mediana ou percentil.
- Nomeie a decisão que a métrica pode informar.
- Explique o que ela não consegue determinar sozinha.
Para medidas de tempo, preserve a distribuição porque uma média pode esconder trabalhos excepcionalmente lentos. O Google SRE explica essa limitação para latência, na qual janelas de medição e percentis afetam o que o número revela.
Coloque a definição junto ao gráfico para que outra pessoa consiga reproduzir o cálculo. Se os eventos, a população ou a regra de contagem mudarem, registre a mudança antes de comparar resultados entre períodos.
Métricas de performance da entrega de software
O modelo atual de entrega de software da DORA agrupa cinco métricas em throughput e instabilidade. Na evolução do conjunto antigo de quatro métricas, failed deployment recovery time substituiu a formulação mais ampla de MTTR e deployment rework rate tornou-se uma medida distinta.
A DORA recomenda aplicar essas medidas a uma única aplicação ou serviço, pois combinar serviços com caminhos de release e riscos operacionais diferentes pode esconder seu desempenho.
1. Frequência de deploy
Frequência de deploy conta os deploys em produção para uma aplicação ou serviço durante uma janela de relatório. Exclua releases em staging e documente como canários, rollbacks e execuções repetidas do pipeline afetam a contagem.
Use a métrica para examinar a cadência de releases e o tamanho dos lotes. Se a frequência cair, investigue aprovações de release, duração dos testes, filas de integração ou lotes maiores de entrega.
Deploys frequentes não estabelecem valor para o cliente, pois mudanças de configuração podem elevar a contagem sem melhorar o produto. Leia a frequência junto à estabilidade e a um resultado relevante de produto.
2. Lead time de mudanças
Lead time de mudanças mede o tempo entre o commit no controle de versão e a execução bem-sucedida da mudança em produção. Com dados suficientemente completos, reporte a mediana e um percentil superior para a aplicação, o tipo de trabalho e a janela definidos.
Use a métrica para investigar atrasos em integração, testes, aprovação e deploy. Uma cauda crescente pode revelar mudanças lentas mesmo quando a mediana permanece estável.
Como a contagem começa no commit, ela exclui descoberta, design, espera no backlog e parte da codificação. Para medir desde a solicitação do cliente, acrescente um lead time de item de trabalho com ponto inicial definido separadamente.
3. Tempo de recuperação de deploy com falha
O tempo de recuperação de deploy com falha mede o intervalo entre uma degradação causada por deploy que exige intervenção imediata e a restauração do serviço. Defina os eventos exatos de falha e restauração usados no cálculo.
Use o resultado para investigar detecção, responsabilidade, caminhos de rollback ou fix-forward e informações diagnósticas. Examine a cauda lenta porque recuperações difíceis podem carregar mais risco do que o incidente típico.
Mantenha a medida separada de um tempo médio geral para restaurar ou resolver, pois indisponibilidades de infraestrutura e falhas de terceiros podem exigir responsáveis e procedimentos de recuperação diferentes.
4. Taxa de falha de mudanças
A taxa de falha de mudanças é o número de deploys em produção que exigem intervenção imediata dividido pelo total de deploys em produção no mesmo escopo e janela. Defina remediação antes de calcular a taxa, incluindo se ela abrange rollback, fix-forward, hotfix, patch ou outra intervenção.
Se a entrega acelerar enquanto a taxa subir, examine estratégia de testes, tamanho dos lotes, controles de release e preparação para recuperação. Acompanhe também o impacto dos incidentes, pois uma taxa baixa ainda pode incluir falhas graves.
A taxa não conta todos os defeitos, pois bugs que não provocam remediação imediata podem ficar fora do numerador.
5. Taxa de retrabalho de deploy
A taxa de retrabalho de deploy é a parcela dos deploys que foram respostas não planejadas a incidentes em produção. Use a mesma população da frequência de deploy e documente como a organização atribui um deploy não planejado a um incidente.
Enquanto a taxa de falha conta deploys que exigem intervenção, a de retrabalho conta os deploys não planejados em resposta a incidentes. Se o retrabalho aumentar, investigue incidentes recorrentes, correções ineficazes e sua pressão sobre o trabalho planejado.
Refatorar uma branch ou revisar um pull request é retrabalho de código, por isso só entra nesse numerador se produzir um deploy em produção motivado por incidente.
Métricas de fluxo e feedback
Medidas de fluxo e feedback ajudam a localizar onde o trabalho espera. Kanban define taxa de entrega e WIP por meio de fronteiras explícitas do fluxo, enquanto a pesquisa de DevEx examina fricções causadas pelo feedback lento de ferramentas e pessoas.
6. PR cycle time
PR cycle time mede o tempo entre dois eventos escolhidos no fluxo de pull request. Subtraia o timestamp inicial do final e exiba essa fronteira junto ao resultado.
Para revisão, o intervalo pode ir da abertura do PR ao merge. Uma definição mais ampla do fluxo vai do primeiro commit ao deploy bem-sucedido em produção, dividida em codificação, pickup, revisão, merge e deploy. Como inclui trabalho fora do próprio PR, as duas definições produzem valores que não são diretamente comparáveis.
Investigue a etapa em que o atraso se acumula e verifique sinais de estabilidade e revisão para avaliar se um intervalo menor preservou a qualidade.
7. Tempo até a primeira revisão
O tempo até a primeira revisão mede o período entre a abertura de um pull request e a primeira ação humana substantiva de revisão. Exclua comentários automatizados de bots ou reporte-os separadamente, além de documentar se uma aprovação, solicitação de mudança ou comentário em linha conta como revisão.
Use a métrica para examinar a responsabilidade pela revisão, a cobertura entre fusos horários e a capacidade dos revisores. A pesquisa DORA de 2023 associou revisões rápidas a melhor performance de entrega e operações, sem estabelecer um limite universal.
Um início rápido não comprova uma revisão útil, por isso examine também o tempo de conclusão, as rodadas repetidas, os sinais de estabilidade e o feedback dos desenvolvedores.
8. Tempo de feedback de build e testes
O tempo de feedback de build e testes mede o intervalo entre iniciar uma execução e receber um resultado que permita agir. Separe feedback local e de CI, além da duração de build e testes quando os responsáveis ou as soluções forem diferentes.
O framework DevEx identifica os ciclos de feedback como uma das três dimensões centrais e recomenda combinar observações do fluxo com percepções dos desenvolvedores. Acompanhe execuções típicas e lentas, depois pergunte onde a espera interrompe o trabalho.
Uma suíte rápida ainda pode ter cobertura fraca ou resultados pouco confiáveis, enquanto uma suíte mais lenta pode pertencer a uma etapa posterior do pipeline. Priorize feedback antecipado onde ele ajuda os desenvolvedores sem enfraquecer as verificações.
9. Throughput
Throughput conta itens concluídos de um tipo definido por período. O guia do Kanban chama isso de taxa de entrega, com exemplos como funcionalidades por semana. Mantenha a unidade estável, pois pull requests, issues e funcionalidades para o cliente não são intercambiáveis.
Use o histórico do throughput para previsões, separando os tipos de trabalho quando seus caminhos de entrega forem diferentes. Se a contagem subir, verifique WIP, lead time, estabilidade e retrabalho para entender a mudança.
Itens menores podem elevar o throughput sem aumentar o volume ou a importância do trabalho entregue, por isso uma contagem maior, sozinha, não comprova produtividade superior.
10. Trabalho em progresso
Trabalho em progresso, ou WIP, conta os itens ativos em um fluxo ou etapa em determinado momento. Kanban distingue essa observação do limite de WIP, uma política que restringe quanto trabalho pode permanecer ativo.
O WIP ajuda a expor filas, pressão de multitarefa e trabalho que começou sem terminar. Divida-o por etapa e idade para que cinco itens recém-abertos não pareçam idênticos a cinco itens esperando há semanas.
WIP baixo também pode refletir pouco trabalho chegando, um bloqueio anterior ou uma política restritiva demais. Verifique throughput e lead time antes de decidir alterar um limite.
Métricas de investimento e planejamento
11. Alocação de engenharia
Alocação de engenharia divide o esforço em cada categoria de trabalho pelo esforço total classificado durante um período. Defina categorias relevantes localmente, como desenvolvimento de produto, confiabilidade, manutenção, dívida técnica e suporte.
Compare a alocação com as prioridades para orientar o planejamento. Se confiabilidade é uma prioridade, mas recebe pouca capacidade, investigue essa diferença mantendo categorias, cobertura da classificação e proxy de esforço consistentes entre períodos.
Uma pesquisa da Microsoft com 484 desenvolvedores em junho e julho de 2024 associou diferenças maiores entre a alocação da semana ideal e real a menor produtividade percebida e satisfação. Porém, usou autorrelatos de uma única empresa na Índia e nos Estados Unidos, com taxa de resposta de 8,06 por cento, e não estabeleceu causalidade.
A pesquisa não estabelece um mix ideal para todas as equipes. A interpretação também depende da cobertura da classificação, pois mentoria, colaboração e interrupções podem consumir capacidade sem se encaixar claramente em uma categoria.
12. Acurácia do planejamento
Para uma equipe Scrum, uma medida opcional de acurácia divide o trabalho previsto concluído pelo trabalho previsto para o Sprint, usando a mesma unidade nas duas partes. Documente como escopo adicionado, removido, dividido ou renegociado afeta o cálculo.
Use a tendência para calibrar previsões, examinando trabalho não planejado, mudanças de escopo, dependências e premissas de capacidade antes de atribuir trabalho pendente a estimativas ruins.
O Scrum Guide trata o trabalho selecionado como previsão, permite renegociar o escopo conforme o aprendizado e define o Sprint Goal como compromisso. Concluir 100 por cento do previsto, portanto, não deve se tornar uma meta universal de desempenho.
Para um fluxo Kanban contínuo sem previsão de Sprint, use throughput, WIP, idade dos itens e distribuições de lead time.
Métricas de confiabilidade e experiência dos desenvolvedores
13. Conformidade com SLO e error budget
A conformidade com SLO compara um indicador de nível de serviço, ou SLI, com seu objetivo de nível de serviço, ou SLO, durante uma janela definida. Para um SLI baseado em requisições, divida as requisições que atendem ao critério de sucesso ou latência pelo total elegível e compare essa proporção com a meta.
Para esse SLO baseado em requisições, o error budget é a parcela permitida de requisições que não atendem ao critério, calculada como um menos a meta. Use o consumo dessa margem para orientar decisões de release e confiabilidade, sem tratar confiabilidade absoluta como objetivo.
Verifique se o indicador reflete a experiência do usuário. A latência medida no servidor pode deixar de fora atrasos no navegador ou no cliente, por isso relatos dos usuários podem revelar uma lacuna que exige revisar o SLI.
14. Satisfação dos desenvolvedores
Acompanhe a satisfação dos desenvolvedores com perguntas recorrentes e específicas, mantendo escala, população e cadência estáveis. Pergunte sobre aspectos que a equipe pode melhorar, como feedback de build, documentação, carga cognitiva, concentração ou clareza dos objetivos.
SPACE e DevEx apoiam a leitura das percepções dos desenvolvedores junto aos dados do fluxo, pois cada fonte pode revelar fricções que a outra não observa.
A pesquisa de Storey e colegas descreve uma relação bidirecional entre satisfação e produtividade percebida, influenciada por fatores técnicos, sociais e contextuais. Isso não estabelece que uma causa a outra, portanto satisfação não deve substituir performance de entrega.
Interprete as mudanças com a equipe para escolher o trabalho seguinte e agregue as respostas em grupos grandes o bastante para proteger o anonimato. Um score de eNPS sozinho não explica o que deve mudar.
15. Impacto da entrega assistida por IA
O impacto da entrega assistida por IA compara resultados de trabalhos semelhantes, incluindo o esforço posterior de revisão, o retrabalho e os custos de confiabilidade. Uso e contagens de código gerado descrevem adoção, mas não estabelecem produtividade ou retorno sobre o investimento.
Defina a medição antes do rollout seguindo estas etapas.
- Nomeie uma classe de tarefas e uma hipótese, como reduzir o cycle time de trabalhos delimitados de manutenção.
- Capture uma baseline e registre repositório, equipe, mix de tarefas e condições do processo.
- Compare trabalhos semelhantes assistidos e não assistidos por IA quando a atribuição for confiável. Caso contrário, use uma comparação antes e depois da adoção cuidadosamente delimitada.
- Leia velocidade ou throughput junto a carga de revisão, retrabalho, falhas de mudanças, confiabilidade do serviço e feedback dos desenvolvedores.
A pesquisa DORA de 2025 reuniu quase 5.000 profissionais de tecnologia e mais de 100 horas de dados qualitativos. Ela associou maior adoção de IA a throughput de entrega e instabilidade mais altos, mas seus resultados agregados e correlacionais não comprovam causalidade para uma equipe específica.
Os resultados podem variar por tarefa, e uma escrita de código mais rápida pode deslocar a fila para revisão ou testes. Para examinar evidências e desenhos de avaliação, consulte a análise de IA e produtividade dos desenvolvedores.
Como escolher as primeiras métricas de engenharia
Escolha um resultado de entrega para a decisão atual, medidas do processo para investigá-lo e verificações dos custos para a qualidade ou a experiência dos desenvolvedores. Da mesma forma, o Google SRE recomenda um conjunto pequeno de indicadores representativos, sem prescrever um número fixo.
| Decisão da liderança | Resultado | Sinal diagnóstico | Verificação de qualidade ou contexto |
|---|---|---|---|
| Investigar mudanças em produção mais lentas | Lead time de mudanças | Etapas do PR cycle, feedback de build e testes | Taxa de falha de mudanças |
| Identificar se a revisão é a fila atual | PR cycle time | Tempo até a primeira revisão, WIP em revisão | Sinais de qualidade da revisão, feedback dos desenvolvedores |
| Avaliar se o trabalho ativo excede a capacidade | Throughput e lead time | WIP por etapa e idade | Mix de tipos de trabalho |
| Verificar se o investimento planejado chega ao trabalho pretendido | Alocação de engenharia | Parcela de trabalho não planejado | Satisfação dos desenvolvedores, prioridades do produto |
| Decidir se o serviço pode aceitar mais risco de release | Conformidade com SLO e consumo do error budget | Tempo de recuperação de deploy com falha | Impacto para usuários e gravidade dos incidentes |
| Avaliar se a IA melhora a entrega | Cycle time ou throughput comparável | Carga de revisão e retrabalho | Taxa de falha de mudanças, SLOs e satisfação dos desenvolvedores |
Defina um responsável, uma cadência de revisão e uma regra de ação para cada métrica. Uma equipe hipotética poderia investigar após a cauda superior crescer por três períodos, mas esse gatilho precisa fazer sentido em seu contexto.
Retire métricas quando deixarem de orientar uma decisão, pois uma migração ou um piloto de IA pode justificar acompanhamento temporário sem criar um KPI permanente.
Métricas de engenharia que não devem avaliar desenvolvedores individualmente
Não transforme commits, linhas de código, contagem de pull requests, story points, uso de IA ou as métricas deste guia em rankings individuais. Contagens de atividade omitem trabalhos como mentoria, coordenação e redução de risco, que o modelo multidimensional SPACE e a abordagem DevEx ajudam a considerar.
Mantenha métricas de entrega e fluxo no nível da equipe, serviço ou workflow para investigar restrições. Comparações individuais não sustentam uma avaliação quando deixam de considerar tipo de tarefa, complexidade, papel, colaboração e oportunidade.
Usar métricas como metas pessoais pode incentivar a divisão artificial do trabalho, a inflação da atividade ou a fuga de tarefas difíceis. Trate um número inesperado como motivo para investigar o trabalho e seu contexto.