Caçando fantasmas: como enxergar a contribuição real dos desenvolvedores

“Ghost engineers” — um em cada dez desenvolvedores quase não produz trabalho útil e apenas encena, de forma convincente, que está sempre ocupado. Os verdadeiros motivos dessa inatividade — trabalhos paralelos, burnout ou pura enrolação — podem permanecer escondidos da liderança por muito tempo. (Estudo de Stanford de 2024: thread original)

Desenvolvedores não gostam quando o assunto é o próprio desempenho. Depois de uma longa “era de ouro” da profissão, surgiu na indústria um tabu em torno de uma pergunta simples: o resultado da engenharia justifica o tempo e o dinheiro investidos? Mas os desenvolvedores fantasma também incomodam os próprios colegas — e quase sempre é a equipe, não a gestão, que percebe o problema primeiro.

Aqui na Rússia, “dedurar” alguém é malvisto há muito tempo. Por isso, muita gente pode saber que existe um problema, mas ninguém quer falar. Para que se meter na confusão dos outros? A verdade só aparece quando a paciência de todo mundo já acabou.

Mas talvez seja melhor deixar esses fantasmas em paz. Afinal, não é como se a empresa fosse sentir falta do dinheiro.

Só que há um porém…

Quando falo em baixo desempenho, não estou dizendo que João trabalha duro, sua a camisa e entrega 10% menos que Pedro. Estou falando de outra coisa: em toda daily, a equipe inteira precisa ouvir a história triste da vez — o outro time não colaborou, a tarefa estava mal explicada, os astros não se alinharam. Mas amanhã ela com certeza estará pronta. Juro de pés juntos.

O problema é que esse “amanhã” já foi ontem e anteontem — e, a essa altura, virou tradição.

As equipes percebem esse tipo de coisa rápido. Quem realmente carrega o trabalho começa, naturalmente, a se perguntar: para que se matar de trabalhar se basta contar histórias e não sofrer consequência nenhuma?

Mas perceber o problema não basta. Sem números e fatos em mãos, a conversa logo vira uma discussão: a equipe diz “ele entrega pouco”; o desenvolvedor responde “não me deixam trabalhar”. Em geral, ninguém começa a investigar até a paciência acabar e a equipe pedir à liderança que substitua a pessoa.

É aí que começa a longa novela: reunir os fatos, ouvir os dois lados, dar feedback e oferecer tempo para que a situação melhore. Na minha experiência, quase sempre termina com o fantasma seguindo para um novo — e muito sortudo — empregador.

O problema não é apenas uma pessoa produzir menos. A empresa paga duas vezes: primeiro pelo trabalho que nunca é feito; depois pelo tempo que colegas e gestores gastam conferindo, cobrindo as lacunas e tentando entender o motivo. No fim, não é mais um desenvolvedor que está abaixo do esperado. É a equipe inteira.

Será que um gestor pode perceber o problema mais cedo — enxergar a anomalia, pedir contexto e investigar antes que a equipe perca a paciência e a empresa perca tempo e dinheiro?

Com experiência suficiente, muitas vezes é possível reconhecer essas situações com antecedência por alguns padrões de comportamento característicos:

• Todo sucesso é mérito meu; todo fracasso é culpa sua.
• Desculpas para o fracasso de uma tarefa antes mesmo de o trabalho começar.
• Falta de competência compensada com conversa em excesso.
• Com o tempo, o gestor em particular passa a ser tratado como o “culpado”.
• Ao contrário de quem enfrenta uma dificuldade real, esse comportamento não melhora nem depois de um feedback direto.

Mas suspeitas precisam de rastros digitais.

Vamos analisar as ferramentas mais comuns para medir o desempenho em engenharia e ver se elas ajudam a encontrar fantasmas.

Antes de compará-las, preciso deixar claro o conflito de interesses: você está lendo o blog oficial da DevGhost, e eu sou o fundador do produto. Esta é a perspectiva do autor, não um estudo independente.

Para avaliar a engenharia de software em si — e não o negócio ou o produto como um todo —, uso uma tríade simples: velocidade, qualidade e volume. As métricas DORA falam de velocidade; testes e defeitos, de qualidade. O volume é mais difícil. Esse é o terreno menos explorado — e é onde os fantasmas que procuramos costumam se esconder.

DORA: velocidade e confiabilidade das entregas

DORA mostra com que rapidez e confiabilidade uma equipe leva mudanças à produção. O modelo usa cinco métricas: tempo do commit até a produção, frequência de deploy, percentual de deploys que causam falhas, tempo de recuperação e proporção de retrabalho não planejado.

É uma boa medida do processo de entrega, mas não da contribuição individual. Se uma pessoa faz o trabalho de três enquanto outra se esconde atrás do resultado geral da equipe, DORA não mostra isso.

Essas métricas também são KPIs maravilhosamente convenientes. Em uma empresa onde trabalhei, nós as espremíamos desde 2018 — pintando todos os dashboards de verde com sucesso e deixando todo mundo feliz. O modelo DORA atual.

Testes e defeitos: a qualidade do trabalho realizado

Os métodos estão bem estabelecidos e funcionam na prática. A qualidade é controlada por code review, testes e análise estática; as consequências são acompanhadas por defeitos e incidentes.

Mas esses sinais não dizem nada sobre volume. Uma correção minúscula e impecável deixará todos os indicadores verdes — e o fantasma continuará invisível.

Jira e story points: quantas tarefas foram concluídas

O Jira mostra tarefas concluídas e story points, mas as estimativas vêm da própria equipe. O mesmo trabalho pode ser estimado em três ou treze pontos, dividido em cinco tarefas ou concentrado em uma só.

Story points são úteis para planejamento, mas pouco confiáveis para medir contribuição individual. Quando os pontos viram a meta, as pessoas começam a otimizar os pontos.

Eles também dão KPIs muito convenientes. Dados são preenchidos e tarefas são movidas só para passar pelos quality gates. Um enorme volume de trabalho manual sem utilidade.

Commits e linhas de código: fatos sem contexto

O Git não depende das estimativas da equipe, então é tentador contar commits e linhas. Mas cinco commits podem representar uma pequena correção, enquanto um único squash commit pode representar uma semana inteira de trabalho.

Formatação, código gerado, cópia e movimentação de código inflam a contagem de linhas, enquanto uma correção difícil pode ter apenas dez linhas.

Swarmia, LinearB e Waydev: todo o sistema de engenharia em um só lugar

Swarmia, LinearB e Waydev reúnem Git, gerenciadores de tarefas e CI/CD. Os gestores conseguem ver métricas DORA, filas de revisão, tempo de entrega das mudanças e resultados de pesquisas.

Elas oferecem uma visão útil do sistema de engenharia — e muitas vezes mostram que o problema está no processo, não em uma pessoa. Mas medir o volume de trabalho de cada desenvolvedor em uma escala comparável não é a pergunta central que essas plataformas tentam responder. Swarmia, LinearB, Waydev.

GitClear: o que sobra depois do ruído do código

O GitClear distingue código adicionado, movido e copiado, exclui arquivos gerados e considera se o código novo foi reescrito ou excluído mais tarde.

Isso produz o Diff Delta — a unidade própria do GitClear para mudanças relevantes que permanecem na base de código. Código copiado ou logo descartado tem menos peso que uma mudança compacta que continua funcionando em produção. Como o Diff Delta funciona.

O Diff Delta não responde quanto trabalho foi necessário. Ele responde quanta mudança relevante restou depois do ruído e do retrabalho. O ponto forte do GitClear é medir a durabilidade e a qualidade do código, além de analisar o impacto da IA.

Agora estamos chegando mais perto. O serviço publica benchmarks, mas o Diff Delta continua sendo uma unidade própria: um número como 10.000 diz pouco sem a comparação adequada e sem entender a metodologia. Não há uma referência clara como “100% é o normal”. Benchmarks do Diff Delta.

BlueOptima: a mesma pergunta em escala corporativa

Conheço a BlueOptima de perto. Comecei a trabalhar com a plataforma em 2019. Foi essa experiência que me inspirou a criar meu próprio produto.

O algoritmo Coding Effort analisa cada mudança no código-fonte por meio de um conjunto de métricas estáticas, levando em conta tamanho, complexidade e relação com o restante do código. Depois, expressa o resultado em horas.

Isso permite comparar desenvolvedores de equipes e stacks tecnológicos diferentes, inclusive com um benchmark global. Para mim, foi a primeira tentativa convincente de responder não “quantas linhas este desenvolvedor escreveu?”, mas “quanto trabalho substancial essas mudanças representam?” Metodologia da BlueOptima, benchmark global.

No meu caso, ter acesso a esses recursos corporativos exigiu uma implantação bastante pesada: foi preciso instalar um agente dentro de um ambiente de rede fechado, o preço era alto e os resultados exigiam interpretação especializada.

Para uma empresa com milhares de desenvolvedores, isso pode se justificar. Para uma startup ou uma equipe pequena, provavelmente não. Essa lacuna mais tarde se tornou uma das razões para a existência da DevGhost.

A mesma régua, sem licitação

Quando criei a DevGhost, não queria construir mais uma plataforma tudo em um, abarrotada de todas as métricas de engenharia imagináveis.

Eu queria a mesma resposta que a BlueOptima oferecia — quanto trabalho substancial existe por trás das mudanças —, mas em um formato que o dono de uma startup ou uma equipe pequena pudesse usar sem licitação, implantação demorada ou um time de consultores.

A lógica é simples: a DevGhost analisa as próprias mudanças — o que foi adicionado, excluído e reestruturado e qual foi a dificuldade para criar e verificar o resultado. Formatação, movimentação de código, substituições automáticas em massa e código gerado são separados do trabalho substancial.

O resultado é uma estimativa de esforço expressa em horas equivalentes: quanto tempo um desenvolvedor pleno, que conhece a base de código e trabalha sem IA, levaria para escrever o mesmo código. Não é o tempo real diante do teclado, nem uma avaliação da qualidade ou do valor de negócio do código. É uma régua comum para comparar mudanças. Saiba mais sobre a metodologia da DevGhost.

O Ghost% compara essa estimativa com a produção esperada de um desenvolvedor pleno, levando em conta quanto do tempo da pessoa é realmente dedicado ao desenvolvimento. Um resultado de 100% significa que ela está dentro da norma. Um resultado menor é motivo para investigar; um maior merece ser estudado e talvez transformado em boa prática.

O benchmark pressupõe deliberadamente o trabalho sem IA. A DevGhost não tenta descobrir quem escreveu um trecho específico de código — uma pessoa, o Copilot ou um agente autônomo. Ela avalia as mudanças finais: quanto esforço um desenvolvedor pleno teria precisado para criá-las e verificá-las sem IA.

Isso significa que o efeito da IA não desaparece dentro da métrica. Ele se torna visível. Se, em determinado período, um desenvolvedor cria e verifica um trabalho que antes teria exigido duas ou três vezes mais esforço, o Ghost% mostra isso. Formatação, geração em massa e outras formas de ruído no código não deveriam produzir o mesmo efeito.

Quem avalia o avaliador?

A pergunta mais óbvia é: por que alguém deveria confiar em uma estimativa gerada por uma máquina? A resposta curta é que ninguém deveria confiar nela cegamente.

Avaliar a dificuldade de um trabalho é subjetivo por definição. Nós testamos isso pedindo a vários desenvolvedores experientes que estimassem as mesmas mudanças — e recebemos números bastante diferentes. Cada pessoa tem seu ritmo, sua experiência e sua própria noção do que é difícil.

A DevGhost também pode errar. Sua vantagem não é ter acesso a alguma verdade absoluta. A vantagem é que toda mudança é avaliada pela mesma régua — sem favoritismo, cansaço ou uma opinião prévia sobre seu autor.

Por isso, o Ghost% é um sinal, não um veredito. Um resultado baixo pode indicar uma contribuição fraca, mas também pode ser explicado por responsabilidades de liderança técnica, trabalho de arquitetura, mentoria, incidentes ou bloqueios.

O número mostra onde vale a pena fazer uma pergunta. O gestor ainda precisa encontrar a resposta — mas agora conta com uma segunda opinião independente, em vez de depender apenas da intuição.

“Eu já sei como cada pessoa da equipe trabalha”

Um cliente da DevGhost lidera a engenharia de uma empresa de IA em rápido crescimento. No início, ele era cético em relação à própria ideia de medir o desempenho em engenharia. Sua posição era simples: um bom líder de engenharia já sabe como cada pessoa está trabalhando, sem precisar de dashboard.

Analisamos o histórico de um repositório que ele conhecia bem. Já havia preocupações com três desenvolvedores: as tarefas avançavam devagar, mas eles trabalhavam em um serviço separado, o que dificultava a comparação com o restante da equipe. A DevGhost mostrou resultados consistentemente baixos para os três ao longo de aproximadamente seis meses.

Mais tarde, quando os desenvolvedores começaram a sair, descobriu-se que, durante todo aquele período, eles também vinham criando produtos próprios. A DevGhost não tinha como saber o motivo. Apenas trouxe à tona algo que a contagem de commits, os pull requests e as conversas diárias no Slack não tinham mostrado: o volume de trabalho deles estava bem abaixo do esperado.

Mas a análise não virou uma lista de demissões. Para outros dois desenvolvedores, um resultado baixo permitiu dar feedback específico, investigar as causas e melhorar o desempenho. Ambos continuaram na equipe.

Os desenvolvedores que ele considerava fortes também apareceram exatamente onde esperava. E agora ele conseguia ver não apenas quem entregava acima do esperado, mas com que consistência.

Um caso isolado, é claro, não prova que o método seja preciso. O que surpreendeu o cliente foi como o quadro geral coincidia com aquilo que antes só era conhecido pela intuição — e que, em alguns casos, só ficou óbvio em retrospecto.

E se um desenvolvedor entregar o resultado de três?

Caçar fantasmas é a parte que mais chama atenção nesta história. Mas o topo do gráfico talvez seja ainda mais útil.

Se um desenvolvedor entrega de forma consistente várias vezes a média, vale descobrir exatamente como ele consegue.

Hoje, a pergunta já não é se um desenvolvedor usa IA — para muita gente, ela se tornou uma parte normal do trabalho. A pergunta é com que eficiência ele transforma agentes em capacidade adicional de entrega.

Uma pessoa se limita ao autocomplete. Outra sabe oferecer o contexto certo aos agentes, definir regras claras, conduzir várias tarefas em paralelo e revisar o resultado com cuidado. Por isso, o mesmo acesso à IA pode gerar ganhos de produtividade radicalmente diferentes.

Um Ghost% alto ajuda a identificar os desenvolvedores que já estão obtendo bons resultados dessa parceria entre pessoa e agente — e a entender quais práticas o restante da equipe poderia adotar.

Se o resultado alto for sustentado pela qualidade do trabalho e pela avaliação do gestor, esse desenvolvedor deve ser valorizado, retido e considerado para uma promoção. Suas práticas devem ser estudadas e disseminadas pela equipe.

Não transforme a régua em uma arma

Toda métrica tem o mesmo destino: mais cedo ou mais tarde, alguém tenta transformá-la em KPI. O Ghost% não serve para isso.

Transforme o Ghost% em KPI da equipe e as pessoas começarão a adaptar o trabalho à métrica. Publique um ranking e a confiança desaparecerá. Transforme a pontuação em um botão de demissão e os erros serão inevitáveis.

Eu estabeleceria quatro regras:

• Não tire conclusões com base em uma única medição ou em um período curto.
• Considere o papel da pessoa, a parcela do tempo dedicada ao desenvolvimento e o trabalho que acontece fora do código.
• Mostre o resultado ao desenvolvedor e dê a ele a oportunidade de explicar o contexto.
• Não use o Ghost% como único fundamento para uma decisão de pessoal.

Se um resultado baixo persistir, o gestor deve primeiro investigar os motivos. Talvez a pessoa esteja realmente tendo dificuldades para entregar. Ou talvez esteja trabalhando em arquitetura, resolvendo incidentes de outras pessoas ou bloqueada pelos processos da equipe.

Se o problema for confirmado, deve haver um plano concreto de melhoria e uma nova avaliação após um período combinado.

Rejeitar métricas não elimina a avaliação das pessoas. Apenas deixa no lugar a intuição, as histórias contadas nas dailies e as preferências pessoais do gestor.

Velocidade, qualidade e volume exigem ferramentas diferentes. DORA mostra como as mudanças chegam à produção. Testes e defeitos mostram a qualidade. A DevGhost acrescenta uma estimativa do trabalho por trás das mudanças no código.

Nenhuma dessas métricas deve tomar decisões pelo gestor.

O valor de um número não está em dar um veredito. Está em fazer uma conversa difícil começar mais cedo — e com base em fatos.

Como você avalia o volume de trabalho dos desenvolvedores e onde traça a linha entre transparência útil e vigilância?