Os KPIs de Engenharia que Realmente Importam
Uma vez estive numa reunião do conselho de administração onde um VP of Engineering mostrou um dashboard com doze métricas. Linhas de código por desenvolvedor. Contagem de PRs por sprint. Story points concluídos. Tudo estava a verde. O conselho acenou com a cabeça.
Dois meses depois, o produto ainda não conseguia integrar um cliente sem um workaround manual, os deploys falhavam uma semana sim outra não, e dois engenheiros sénior tinham começado a fazer entrevistas noutros lugares.
O dashboard media atividade. Ninguém media se a organização de engenharia era saudável, produtiva ou a melhorar. Esta é a armadilha — as equipas escolhem métricas fáceis de recolher em vez de métricas que lhes digam algo útil.
As Métricas que Realmente Te Dizem Algo
Métricas DORA: A Tua Linha de Base de Entrega
Já escrevi sobre as métricas DORA em detalhe anteriormente, por isso não vou repetir o argumento completo aqui. Mas as quatro métricas DORA — Frequência de Deploy, Lead Time para Mudanças, Mean Time to Restore e Change Failure Rate — são o mais próximo que temos de uma medida cientificamente validada do desempenho de entrega de software.
Continuam a ser o alicerce. Se não as estás a acompanhar, começa por aí antes de adicionar qualquer outra coisa. Dizem-te se a tua equipa consegue entregar de forma fiável e recuperar rapidamente, que é a linha de base para tudo o resto.
Cycle Time: da Ideia à Produção
O cycle time vai mais longe do que o lead time do DORA. Mede o percurso completo desde "decidimos construir isto" até "está em produção e os utilizadores estão a usá-lo". Isto captura as decisões de produto, as transferências de design, os esclarecimentos de especificações — todos os gargalos não-código que as equipas de engenharia herdam.
Quando o cycle time é alto mas o lead time DORA é baixo, o problema não está na execução de engenharia. Está em tudo o que vem antes: especificações pouco claras, aprovações lentas, gargalos de design, ou demasiadas coisas em progresso ao mesmo tempo. O cycle time revela o atrito organizacional, não apenas o atrito do pipeline.
Acompanha-o marcando o tempo quando um ticket passa de "pronto para desenvolvimento" para "deployado". A maioria das ferramentas de gestão de projetos consegue mostrar isto com configuração mínima.
Incidentes com Impacto nos Clientes
Nem todos os incidentes são iguais. Um job em background que falha mas tenta novamente com sucesso não é o mesmo que o checkout em baixo durante 40 minutos numa sexta-feira à tarde. O que importa é a frequência e gravidade dos incidentes que os utilizadores realmente sentem.
Acompanha duas coisas:
- Frequência de incidentes — quantos incidentes com impacto nos clientes por mês?
- Distribuição de gravidade — são SEV-1 (críticos para o negócio) ou SEV-3 (degradação menor)?
Uma equipa com dois SEV-3 por mês está numa posição fundamentalmente diferente de uma equipa com dois SEV-1 por mês, mesmo que o número seja idêntico. Agregar sem gravidade não tem significado.
A tendência importa mais do que o número absoluto. Os incidentes estão a diminuir ao longo do tempo? A gravidade está a baixar? Isso diz-te se os teus investimentos em fiabilidade estão a funcionar.
Tempo-até-Primeiro-Valor para Novas Contratações
Esta está subvalorizada e quase ninguém a acompanha: quanto tempo demora um novo engenheiro a entregar algo significativo para produção?
Não "quanto tempo até fazerem merge de uma correção de typo". Quanto tempo até entregarem um trabalho real — uma funcionalidade, um bug fix com impacto no negócio, uma melhoria de infraestrutura significativa.
Se os novos engenheiros demoram seis semanas a entregar a sua primeira contribuição real, tens um problema de onboarding, um problema de complexidade da codebase, ou ambos. As equipas de elite fazem as novas contratações entregarem na primeira semana. Não porque cortam caminho, mas porque investiram em documentação, developer experience e ownership clara.
Esta métrica também te diz algo sobre a qualidade das contratações. Se um engenheiro demora três meses a tornar-se produtivo independentemente da seniority, o problema é provavelmente o teu ambiente, não a pessoa.
Satisfação e Envolvimento da Engenharia
Eu sei — parece soft. Mas a retenção em engenharia é uma das rubricas de custo mais caras que não acompanhas, e quando alguém apresenta a demissão, o dano está feito. Substituir um engenheiro sénior custa seis meses de salário e doze meses de contexto.
Faz uma pesquisa de pulso trimestral. Cinco a sete perguntas: Acreditas no que estamos a construir? Tens as ferramentas para fazer o teu melhor trabalho? Sentes que estás a crescer? Recomendarias esta equipa a um amigo? Acompanha as tendências. Uma tendência descendente ao longo de dois trimestres é um alarme de incêndio.
As Métricas Perigosas
Algumas métricas não são apenas inúteis — danificam ativamente as equipas quando o liderança lhes presta atenção.
Linhas de código. Um desenvolvedor que elimina 500 linhas de código morto e simplifica um módulo fez um trabalho mais valioso do que um que escreveu 500 linhas de novo código para resolver um problema que poderia ter sido evitado. Medir linhas de código incentiva o bloat.
Contagem de commits. Fácil de manipular, trivialmente inflado, e não te diz nada sobre a qualidade ou impacto do trabalho. Um desenvolvedor a trabalhar num problema arquitetural difícil pode ter três commits numa semana. Um desenvolvedor a produzir boilerplate pode ter trinta. Os três commits valem provavelmente mais.
Métricas de desempenho individual. Classificar os desenvolvedores por contagem de PRs ou tickets fechados cria competição que destrói a colaboração. As melhores culturas são orientadas para a equipa. A classificação individual empurra as pessoas para o comportamento de herói e para longe das code reviews, do mentoring e de ajudar os colegas a desbloquear-se.
Horas registadas. Mede presença, não produtividade. Os engenheiros sénior fazem frequentemente o seu trabalho mais impactante nas menos horas. Se estás a medir horas, estás a gerir uma linha de montagem.
Apresentar Métricas à Liderança Sem Serem Manipuladas
O conselho quer saber três coisas: A equipa é eficaz? Está a melhorar? Onde estão os riscos?
Aqui está a estrutura que uso:
Desempenho de entrega — métricas DORA, com tendência trimestral. Mostra a direção, não apenas o número. "A nossa frequência de deploy passou de semanal para diária este trimestre, e a taxa de falha de mudanças desceu de 22% para 11%." Essa é uma história que o conselho pode acompanhar.
Qualidade e fiabilidade — incidentes com impacto nos clientes com tendência mensal, com repartição por gravidade. Se os incidentes aumentam, explica porquê (nova área de funcionalidades, desafios de escala) e o que estás a fazer sobre isso.
Saúde da equipa — tempo-até-primeiro-valor para contratações recentes, mais tendências de envolvimento. Estes são indicadores avançados. Uma equipa saudável com onboarding sólido e alto envolvimento vai entregar. Uma equipa esgotada com uma pipeline de onboarding quebrada é um risco, mesmo que o output atual pareça bom.
Uma coisa a ter em atenção: apresenta métricas ao nível da equipa, nunca métricas individuais. No momento em que um membro do conselho vê uma lista classificada de desempenho dos desenvolvedores, vai pedir-te para gerir por essa lista. E então a métrica torna-se o objetivo, o objetivo é manipulado, e perdeste o sinal.
Mantém o dashboard em cinco ou seis métricas. Se precisas de doze métricas para explicar como vai a engenharia, não percebes como vai a engenharia.
A Métrica por Trás da Métrica
Cada métrica é um proxy. As métricas DORA são um proxy para a capacidade de entrega. As contagens de incidentes são um proxy para a fiabilidade. Os scores de envolvimento são um proxy para o risco de retenção. Nenhuma captura o quadro completo sozinha.
A verdadeira habilidade na liderança de engenharia é saber em quais proxies confiar, quando investigar mais, e quando um número te está a dizer o que queres ouvir em vez do que está realmente a acontecer.
Na Conectia, quando integramos engenheiros sénior numa equipa, muitas vezes tornam-se o catalisador para uma melhor medição — não porque instalam dashboards, mas porque trazem o hábito de perguntar "como sabemos que isto está a funcionar?". Viram equipas suficientes para saber quais sinais importam e quais são ruído. Essa é uma mentalidade que não consegues obter de uma métrica.
Queres engenheiros que tragam o julgamento para saber o que medir e o que ignorar? Fala com um CTO — os nossos engenheiros sénior LATAM trabalharam em equipas suficientes para saber quais KPIs realmente movem a agulha.
