Portal de Notícias Jornal Aviação
Notícias

Como avaliar produtividade de dev sem contar linha de código?

Murilo Moura Alencar

A crescente demanda por métricas de engenharia leva Murilo Alencar a problematizar o uso de volume como indicador de produtividade. Linha de código, número de commits e pontos de história medem movimento, não valor entregue. Um time pode produzir muito e resolver pouco, situação comum quando a medida escolhida vira meta de desempenho. A facilidade da medida não garante relação alguma com o resultado.

Toda medida que se transforma em alvo perde a capacidade de medir, efeito descrito há décadas por economistas e visível em qualquer painel de engenharia. Desenvolvedor avaliado por commit aprende a fragmentar commit, e o indicador sobe sem que o produto melhore. O problema não está em medir, e sim em medir o que é fácil de contar. Indicador mal escolhido ensina o time a otimizar o indicador.

Por que a métrica de volume engana?

O trabalho de engenharia concentra valor na decisão, não na digitação. Uma semana gasta para remover duzentas linhas e simplificar um fluxo entrega mais do que uma semana de código novo empilhado sobre a mesma complexidade, comparação que Murilo Moura Alencar, Tech, People & Game Strategist, descreve ao tratar de medidas de produtividade. Código removido raramente aparece como entrega em relatório de equipe. Simplificação é ganho invisível para quem mede volume.

As tarefas de maior impacto costumam ser as menos visíveis em relatório de acompanhamento. Investigar falha intermitente, negociar escopo com produto e revisar decisão de arquitetura não geram artefato contável, ainda que determinem o ritmo dos meses seguintes de desenvolvimento. Conversa difícil com produto pode evitar seis semanas de retrabalho. Nenhum painel registra a semana que não foi perdida.

O que vale observar no fluxo de entrega?

Indicadores de fluxo descrevem o sistema de trabalho, e não a pessoa. Tempo entre início e entrega, frequência de implantação, taxa de falha em produção e tempo de recuperação mostram onde o processo trava, com leitura comparável ao longo dos meses e entre equipes diferentes. Medida de fluxo aponta gargalo de processo, não culpado individual. Leitura em série temporal informa mais que foto de um mês.

O valor dessas medidas aparece na tendência, nunca no número isolado de um mês. Fila longa antes da revisão de código, por exemplo, indica gargalo de capacidade de revisão, e não falta de empenho de quem escreve a funcionalidade, como esclarece Murilo Alencar, co-founder de uma empresa de games. Contratar mais gente para escrever não resolve fila de revisão.

Avaliação individual e efeito de time

Métrica individual de produtividade corrói a colaboração que pretendia estimular. Quem ajuda o colega, revisa com cuidado e documenta decisão aparece pior no painel do que quem produz sozinho, o que ensina a equipe a evitar exatamente o comportamento mais útil ao conjunto. Ranking interno costuma reduzir a troca de conhecimento entre pares. O custo aparece depois, em dependência concentrada em poucas pessoas.

Em sentido oposto, avaliação que considera contribuição ao resultado coletivo exige conversa, contexto e registro qualitativo ao longo do ciclo, segundo analisa Murilo Moura Alencar. Gestão de pessoas em tecnologia se sustenta em observação próxima, porque desempenho de engenharia raramente cabe em um único eixo numérico comparável entre funções distintas. Contexto de cada entrega muda o que conta como bom resultado. Avaliar sem esse detalhe produz injustiça com aparência de objetividade.

Conversa de desempenho sustentada por evidência

A avaliação ganha consistência quando reúne exemplos concretos, retorno de pares e efeito do trabalho no produto, no panorama traçado por Murilo Alencar. Um caso específico de decisão técnica bem conduzida informa mais do que média de pontos, porque mostra critério aplicado em situação real e sob restrição conhecida. Evidência concreta também torna a devolutiva acionável para quem recebe. Nota isolada não informa o que repetir nem o que corrigir.

O conjunto desses elementos indica que avaliar engenharia é tarefa de leitura, não de contagem. Medir fluxo ajuda a corrigir processo, enquanto julgar uma pessoa exige evidência de que painel nenhum entrega sozinho. O dado orienta a pergunta, enquanto a decisão continua sendo humana. Processo se corrige com número, e pessoa se avalia com contexto. Nos próximos conteúdos sobre gestão de tecnologia, você vai encontrar critérios práticos para estruturar esse acompanhamento.