A maioria dos times de engenharia tem algum dashboard por aí. Normalmente ele está cheio de gráficos que acompanham desde a velocidade de tickets no Jira até o tempo de build no CI. O problema aparece quando você pergunta como esses números ajudam alguém a tomar uma decisão melhor. Na maior parte das vezes, ninguém sabe responder. Esse é o estado comum dos KPIs em desenvolvimento de software: muitos dados, pouco entendimento real.
Os dashboards acabam virando material de apresentação em reuniões, mas não entram no dia a dia de quem está construindo o sistema. Pior ainda, quando essas métricas viram metas isoladas, elas incentivam atalhos e otimizações locais que não melhoram, e às vezes até pioram, o funcionamento do sistema como um todo.
A desconexão começa quando medimos esforços de engenharia em vez de impacto. No momento em que uma métrica vira um alvo, ela deixa de servir como medida. Se o foco vira “número de PRs mergeados”, aparecem PRs pequenos e irrelevantes. Se vira “story points fechados”, as estimativas começam a inflar. No fim, essas métricas medem atividade, não valor. E isso cria atrito entre engenharia e o resto do negócio, porque elas não ajudam a responder a única pergunta que realmente importa: estamos construindo a coisa certa, de um jeito sustentável?
O Que Deveríamos Medir de Verdade
A obsessão por métricas puramente quantitativas de “produtividade” é um resquício de outra era do trabalho. Métricas como linhas de código ou commits por semana são fáceis de manipular e dizem quase nada sobre a qualidade, a manutenibilidade ou o impacto do trabalho que está sendo feito. Com a geração de código por IA se tornando comum, medir volume faz ainda menos sentido. Hoje, um desenvolvedor consegue produzir milhares de linhas em uma tarde. Isso não quer dizer que criou algum valor, muitas vezes, significa apenas que criou mais coisa para manter depois.
Para times de engenharia em 2026, não dá mais para olhar performance por um único ângulo. É preciso um conjunto de indicadores que mostre o sistema como ele realmente funciona: velocidade de entrega, qualidade do produto e o impacto disso sobre as pessoas que constroem o software. Boas métricas ajudam a identificar gargalos, fazer escolhas conscientes e melhorar o fluxo de trabalho sem esgotar o time. O objetivo não é cumprir uma meta isolada de features, mas criar um sistema capaz de entregar valor de forma previsível e consistente ao longo do tempo.
DORA Metrics em 2026: o que essas métricas ainda dizem
As métricas do DORA já existem há algum tempo, mas continuam relevantes porque medem dois resultados centrais de qualquer sistema de entrega: velocidade e estabilidade. Elas dizem o que está acontecendo, não como o time chega lá. Em 2026, o cuidado está na interpretação. Vivemos em um contexto em que CI/CD já faz parte da rotina e a geração de código com IA é comum, o que muda a forma como esses números precisam ser lidos.
Interpretando os KPIs
Olhar para essas métricas de forma isolada é o que coloca os times em apuros. Um time pode fazer deploy com frequência, mas se a cada dois deploys ocorre um incidente, essa velocidade tem um custo alto em estabilidade e confiança do usuário.
Frequência de Deploy: Velocidade Precisa de Estabilidade
Essa métrica mede com que frequência você consegue liberar código em produção com sucesso. Uma alta frequência geralmente indica um pipeline saudável e automatizado e lotes pequenos de mudança. Mas isso é só metade da história. Se você faz deploy dez vezes por dia, mas sua Change Failure Rate é de 20%, você só está enviando problemas mais rápido. A verdadeira pergunta que essa métrica ajuda a responder é: “Quão automatizado e confiável é o nosso caminho até a produção?” Uma baixa frequência de deploy costuma sinalizar etapas manuais, testes instáveis ou medo de quebrar coisas, todos problemas de nível sistêmico que precisam ser resolvidos.
Lead Time for Changes: tamanho dos lotes e custo de revisão
Esse é o tempo entre o primeiro commit de um desenvolvedor e esse código rodando em produção. É um indicador poderoso da eficiência de todo o ciclo de desenvolvimento. Um lead time longo raramente é um problema de “velocidade de codificação”. Quase sempre é um problema de espera. O código espera o CI terminar, espera por review, espera por um ambiente de QA ou espera por uma janela manual de release. Podemos pensar nesse tempo de espera como um “imposto de verificação”. Cada etapa adicionada para garantir qualidade antes do merge aumenta esse imposto. O ponto é encontrar o equilíbrio certo, automatizando o máximo possível da verificação para que o imposto não desacelere a entrega a ponto de travar. PRs pequenos são a forma mais fácil de reduzir esse imposto, porque são mais rápidos de revisar, testar e fazer merge.
Change Failure Rate: o que está quebrando depois do deploy
Essa métrica acompanha a porcentagem de deploys que causam uma falha em produção, exigindo hotfix, rollback ou patch. Uma taxa alta aponta problemas no processo de testes ou de review. Talvez sua suíte de testes esteja deixando passar categorias inteiras de problemas, ou os reviews estejam virando aprovações automáticas porque os PRs são grandes demais para analisar com cuidado. Com o aumento do uso de código gerado por IA, essa métrica ganha ainda mais peso. O código pode parecer correto à primeira vista, mas esconder bugs ou problemas de performance que análises estáticas não pegam. Isso torna testes de integração e end-to-end bem feitos algo essencial, não opcional.
Mean Time to Recovery (MTTR): resiliência do sistema
Quando uma falha acontece, quanto tempo leva para o serviço voltar ao normal? O MTTR mede a capacidade de recuperação do sistema e do time. Valores baixos normalmente indicam boa observabilidade, rollback automatizado e procedimentos operacionais claros. Times com MTTR baixo lidam melhor com incidentes porque sabem o que fazer e não precisam improvisar.
Essa métrica anda junto com a Change Failure Rate. Reduzir falhas é importante, mas eliminá-las por completo não é realista. Por isso, o equilíbrio está em investir tanto em prevenir problemas quanto em se recuperar rápido quando eles inevitavelmente acontecem.
Indicadores de qualidade do fluxo de desenvolvimento
O DORA oferece uma visão de alto nível dos resultados do sistema. Mas para entender o “porquê” desses resultados, é preciso olhar para o trabalho em si, à medida que ele passa pelo processo de desenvolvimento.
Tamanho de Pull Request
PRs pequenos são um dos sinais mais claros de um fluxo de trabalho saudável. PRs grandes são difíceis de revisar com profundidade, têm maior chance de conflitos de merge e são mais propensos a introduzir bugs. Acompanhar a distribuição do tamanho dos PRs (por exemplo, linhas de código alteradas) ajuda a perceber quando os lotes estão crescendo. Se o tamanho mediano dos seus PRs passa de 200-300 linhas de código, seu lead time tende a aumentar e a change failure rate costuma subir. É um sinal precoce de que o processo está começando a sair do controle.
Tempo até o Primeiro Review
Código que foi escrito, mas não revisado, não gera valor e corre o risco de ficar obsoleto. Essa métrica mede o tempo entre a abertura de um PR e o primeiro comentário de review realmente relevante. Um atraso longo aqui é um gargalo claro. Pode ser falta de clareza sobre quem deve revisar, sobrecarga dos revisores ou simplesmente PRs passando despercebido. É uma medida direta de colaboração e responsividade do time.
Taxa de Retrabalho
Retrabalho é código que é alterado ou removido pouco tempo depois de ser escrito, muitas vezes dentro do mesmo PR ou em um PR seguinte. Uma taxa de retrabalho alta (por exemplo, mais de 15-20% do código sofrendo churn) sinaliza desperdício. A causa geralmente está mais acima no fluxo: requisitos ambíguos, um design técnico mal pensado ou feedback que chegou tarde demais no processo. É uma métrica boa para tech leads, porque aponta atrito nas fases de planejamento e design, não apenas na fase de codificação.
Complexidade de Código e Carga Cognitiva
Isso é mais difícil de quantificar, mas crítico de acompanhar. Ferramentas conseguem medir complexidade ciclomática ou identificar código com baixa coesão, mas isso também diz respeito à developer experience. Quão difícil é para alguém novo entender uma parte específica do codebase? Quantos serviços você precisa tocar para entregar uma feature simples? Uma carga cognitiva alta desacelera o desenvolvimento e aumenta a chance de erros. Muitas vezes, isso é melhor medido por meio de feedback qualitativo, como perguntar aos desenvolvedores quais partes do sistema eles evitam trabalhar.
O Problema da Distorção: Quando Métricas Viram Metas
No momento em que uma métrica vira um alvo de avaliação de performance, ela deixa de ser uma boa medida. Isso é a Lei de Goodhart, e ela aparece o tempo todo no desenvolvimento de software.
Otimizar uma única métrica leva a comportamentos prejudiciais. Se você recompensa desenvolvedores por fechar mais story points, as estimativas tendem a inflar. Se recompensa por alta frequência de deploy, o incentivo vira enviar mudanças pequenas demais só para aumentar o número, gerando ruído operacional sem entregar valor real.
O impacto da IA em gargalos de review e na “inflação de commits”. Geradores de código com IA conseguem produzir grandes volumes de código rapidamente. Se os times são medidos por linhas de código ou frequência de commits, essas ferramentas criam uma ilusão de produtividade. Mas esse código ainda precisa ser revisado, testado e mantido por pessoas. Isso pode levar à “inflação de commits”, em que o volume de mudanças aumenta, mas o valor entregue não, enquanto o processo de review vira um gargalo permanente.
Para evitar essas distorções, métricas precisam ser analisadas em conjunto. Frequência de deploy, por exemplo, só faz sentido quando olhada junto com a Change Failure Rate, para garantir que velocidade não esteja vindo às custas da qualidade. Da mesma forma, throughput de PRs precisa ser combinado com tamanho de PR, para assegurar que o time está entregando mudanças relevantes, e não apenas aumentando números.
Como desenhar um sistema de métricas que faça sentido
Em vez de olhar para métricas isoladas, você pode adotar um conjunto de métricas que se complementam. A ideia não é otimizar um número específico, mas entender como o sistema se comporta como um todo e evitar que ganhos em uma área criem problemas em outra.
Métricas Dora + Taxa de Retrabalho
Uma evolução simples, mas muito boa, é adicionar a Taxa de Retrabalho às métricas DORA. Isso adiciona uma dimensão de qualidade e eficiência ao próprio fluxo de trabalho, não apenas ao resultado final. Ajuda a responder à pergunta: “Quanto do nosso esforço está indo para avançar versus corrigir erros recentes?”.
Métricas de fluxo
Métricas de fluxo vêm das práticas Lean e tratam o desenvolvimento de software como um sistema de entrega de valor. Elas são excelentes para diagnosticar gargalos.
- Flow Time: O tempo total desde o início do trabalho até a entrega (similar ao Lead Time).
- Flow Velocity: A quantidade de itens de trabalho concluídos por unidade de tempo (por exemplo, histórias por semana).
- Flow Efficiency: A proporção entre tempo de trabalho ativo e o tempo total de fluxo. Uma eficiência baixa (muitas vezes abaixo de 15%) mostra que a maior parte do tempo é gasta esperando.
- Flow Load: O número de itens de trabalho atualmente em andamento. Muito WIP desacelera tudo.
- Flow Distribution: A distribuição do trabalho por tipo (por exemplo, features, bugs, riscos, dívida). Isso ajuda a ver se você está gastando todo o tempo apagando incêndios em vez de construir novo valor.
Framework SPACE: Developer Experience importa
O framework SPACE parte da ideia de que não dá para entender produtividade sem considerar o bem-estar do desenvolvedor. Na prática, isso significa olhar para:
- Satisfação e bem-estar: Quão felizes e saudáveis estão os desenvolvedores?
- Performance: Quais são os resultados do trabalho? (Aqui entram as métricas DORA).
- Atividade: Quais ações estão sendo realizadas? (por exemplo, contagem de commits, PRs criados).
- Comunicação e colaboração: Quão bem a informação flui dentro e entre os times?
- Eficiência e fluxo: Quão facilmente o trabalho avança sem interrupções? (Aqui entram as métricas de fluxo).
Não é necessário acompanhar todas as métricas do SPACE. Selecionar poucas métricas de áreas diferentes já ajuda a enxergar melhor o que está acontecendo.
Adaptando métricas conforme a empresa cresce
As métricas certas dependem do tamanho e do estágio do time. O que funciona bem em uma startup tende a gerar problemas quando aplicado do mesmo jeito em uma empresa maior.
Foco em Startups: Velocidade e Sustentabilidade
Empresas em estágio inicial estão focadas em velocidade e em encontrar product-market fit. O Lead Time for Changes é cruicial. O risco é acumular decisões tomadas as pressas que cobram seu preço mais adiante e acabam desacelerando tudo. Parear Lead Time com Taxa de Retrabalho ajuda a garantir que a velocidade represente um progresso real, e não apenas movimento sem direção.
Desafios de Scale-ups: Distribuição
À medida que a organização cresce, médias se tornam menos úteis. Você precisa olhar distribuições. Seu lead time médio pode ser de dois dias, mas se o percentil 95 for de 20 dias, você tem um problema de previsibilidade. Aqui, métricas de fluxo se tornam críticas para identificar os gargalos sistêmicos que surgem conforme mais times e dependências são adicionados.
Realidade de Enterprises: Capacidade Acima de Velocidade
Em organizações grandes, o objetivo costuma ser construir capacidade organizacional. Você pode medir a adoção de uma nova plataforma de CI/CD ou a porcentagem de times que conseguem fazer deploy de forma independente. O foco sai da velocidade de um único time e vai para a resiliência e modularidade de toda a organização de engenharia.
No fim das contas, KPIs só são úteis quando ajudam a entender as relações de causa e efeito no seu processo de desenvolvimento. Eles são uma ferramenta para fazer melhores trade-offs e melhorar a previsibilidade da entrega, permitindo sustentar velocidade sem sacrificar a qualidade e a estabilidade das quais seus usuários dependem.
