# Sua avaliação de desempenho é um teste de memória
> Pontuamos 740 pull requests por gravidade, multiplicamos cada um pelo quanto nosso roadmap se importava com o componente que ele tocava, e publicamos o ranking. Duas pessoas acabaram sendo 58% da produção. Aqui está a fórmula, e aqui está onde ela ainda está errada.
- Source: https://jays.fyi/pt/blog/avaliacao-desempenho-teste-memoria
- Author: Jay Derinbogaz
- Published: 2026-08-08
- Language: pt
- Tags: engineering-management, performance-reviews, ai, gitrank
- Reading time: 21 min
- Machine translated: yes — original: https://jays.fyi/blog/your-performance-review-is-a-memory-test
---
Pergunte a qualquer gerente de engenharia quem é o melhor engenheiro da equipe. Veja a rapidez com que a resposta vem. Não há hesitação, nem ressalva, nem "deixa eu verificar algo primeiro". Eles sabem. Sempre souberam.
Agora peça para mostrarem o trabalho.
Você vai ouvir uma história. Uma boa história, geralmente, sobre um incidente que alguém resolveu às 2 da manhã, ou uma refatoração que desbloqueou um trimestre, ou a pessoa que sempre responde no canal. O que você não vai ouvir é um número, ou uma comparação, ou qualquer relato dos quatro engenheiros cujo trabalho o gerente não presenciou. A confiança nunca foi baseada em medição. Foi baseada em lembrança, e lembrança é função de proximidade.
Aqui está a tese, e tudo depois disso é evidência para ela. O desempenho em engenharia é julgado pela memória, a memória recompensa visibilidade em vez de valor, e aquilo que você realmente quer que as pessoas construam está escrito em um roadmap que nunca é conectado com aquilo pelo qual você as avalia. Esses dois documentos, o roadmap e a avaliação de desempenho, não têm nada a ver um com o outro em quase todas as empresas que vi, incluindo a minha até recentemente.
Então nós os conectamos. Cada pull request mergeado é lido por um modelo, recebe uma severidade e é multiplicado pelo quanto nosso roadmap se importa com o componente que ele tocou. O resultado é um ranking mensal, e ele alimenta as decisões de bônus.
Vou mostrar o nosso, incluindo as partes em que é constrangedor e as partes em que está errado.
O ranking de 30 dias do nosso repositório da plataforma, agosto de 2026. Sete desenvolvedores, 10.415 pontos entre eles.
## A sabedoria convencional diz que isso não pode ser medido, e a sabedoria convencional é um dar de ombros
A posição padrão sobre medir a produção individual em engenharia é que você não deve, porque qualquer proxy é uma armadilha. Linhas de código recompensam inchaço. Contagem de commits recompensa divisão. Story points são uma negociação, não uma medição. Até os bons frameworks são deliberadamente no nível de time: DORA mede quatro coisas sobre um pipeline de entrega e não diz nada sobre pessoas, o que é uma escolha de design que seus autores explicitam.
Tudo isso está correto, e nada disso é uma resposta. Recusar-se a medir não produz uma empresa onde ninguém é classificado. Produz uma empresa onde todo mundo é classificado de qualquer forma, por um mecanismo sem trilha de auditoria. A classificação ainda acontece na hora da compensação. Só que acontece em uma sala, de memória, ponderada por quem a pessoa na sala passou mais tempo.
Chame isso de **prêmio do engenheiro barulhento**: a diferença entre quão bem você é avaliado e quão bem você se saiu, explicada inteiramente pela sua distância de quem escreve sua avaliação. Não é um defeito de caráter dos gerentes. É o resultado previsível de pedir a um ser humano que compare as contribuições técnicas de quinze pessoas ao longo de um ano usando apenas o que ele por acaso notou.
O prêmio era inevitável até cerca de dois anos atrás, porque a matéria-prima para uma resposta melhor era uma pilha de diffs que ninguém tinha tempo de ler. Essa restrição acabou. Um modelo pode ler todos os diffs do seu repositório todo mês por menos do que o custo de uma hora da reunião onde você atualmente chuta.
Lê-los é a parte fácil. Decidir quanto vale a leitura é o problema inteiro, e isso não é uma questão técnica.
## A fórmula inteira cabe em uma linha
Aqui está ela, por completo, do caminho de pontuação no [GitRank](https://gitrank.dev):
```
final_score = is_eligible ? severity_base_points × component_multiplier : 0
```
Isso não é uma simplificação para o blog. Essa é a linha. Não há regressão oculta, nem ponderação aprendida, nem termo de reputação, nem ajuste por tempo de casa. Severidade vezes importância, ou zero.
A metade da severidade é uma escada fixa. Quatro níveis, quatro valores de pontos, definidos uma vez e visíveis para todos que estão sendo pontuados:
Pontos base por severidade. Um modelo atribui o rótulo; os valores dos pontos são nossos.
Uma correção crítica vale vinte correções de baixa prioridade. Essa proporção é uma declaração de política, e a escrevemos em vez de deixá-la na cabeça de alguém.
A metade da importância é a parte que realmente importa, e é a razão pela qual acho que essa abordagem se generaliza. Cada componente no repositório carrega um multiplicador, e o multiplicador é definido pelo que o produto precisa neste trimestre:
Vinte componentes, quatro níveis de importância. Crítico é 2,0x, Alto é 1,5x, Normal é 1,0x, Baixo é 0,5x.
Chat está em 2,0x porque chat é no que estamos apostando o produto. Autenticação está em 1,0x porque funciona e gostaríamos que continuasse funcionando quietamente. Funcionalidades de colaboração e destaque de documentos estão em 2,0x pela mesma razão que chat. Nenhum desses números são julgamentos técnicos. Eles são o roadmap, redigitado em um campo que paga.
Este é o movimento. Não o modelo, não o ranking, não a gamificação. O movimento é que o documento de estratégia e a entrada para compensação se tornaram o mesmo documento. Se o roadmap mudar em outubro, os multiplicadores mudam em outubro, e o incentivo muda em outubro, em vez de no próximo ciclo de avaliação anual daqui a catorze meses.
Vou explicar isto, porque é a parte que as pessoas ignoram. O problema difícil numa organização de engenharia em crescimento nunca foi que as pessoas são preguiçosas. É que quarenta pessoas inteligentes, cada uma a otimizar localmente e honestamente, vão produzir coletivamente um quarto de trabalho que não se soma ao que a empresa disse que queria. A gestão intermédia existe em grande parte para resolver isso, transportando a estratégia em conversa, uma secretária de cada vez, perdendo fidelidade a cada salto. Uma tabela de multiplicadores faz o mesmo trabalho de encaminhamento num único salto e não se cansa, não tem favoritos e não se esquece do que lhe disseste em janeiro.
## Uma correção crítica no chat vale quarenta commits de polimento na API
Junte as duas metades e a disparidade é severa.
Um P0 no chat vale 100 base vezes 2,0, ou seja, **200 pontos**. Um P3 na API vale 5 base vezes 1,0, ou seja, 5 pontos. O pull request individual mais valioso que podes fundir aqui vale quarenta dos menos valiosos. Não quarenta por cento a mais. Quarenta vezes.
Esse número é deliberadamente violento, e faz o que incentivos suaves nunca conseguem fazer. Ninguém reorganiza a sua semana por uma diferença de 15%. As pessoas reorganizam a sua semana por uma diferença de 40x.
Vê o que acontece a uma semana real sob esses pesos. Aqui está a distribuição de severidade ao longo de cinco semanas, com a semana de 13 de julho expandida:
Semana de 13 de julho de 2026: 1 P0, 50 P1, 111 P2, 26 P3. 188 pull requests fundidos.
188 pull requests. P2 é 59% deles, que é o aspeto de uma semana normal de engenharia em todo o lado: maioritariamente correções de tamanho médio com uma solução alternativa disponível.
Agora pondera. Esses 111 P2s valem 2.220 pontos a 1x. Os 50 P1s valem 2.500. **Menos de metade dos pull requests carregam mais de metade do valor da semana**, e o único P0 vale tanto como vinte dos P3s que uma contagem bruta de commits teria tratado como trabalho idêntico.
Esse é o argumento inteiro para a ponderação, numa semana de dados reais. Conta pull requests e concluis que a semana foi sobre P2s. Pondera-os e descobres que a semana foi sobre cinquenta peças específicas de trabalho, e podes nomear quem as fez.
## Duas pessoas foram 58% do output, e eu não teria adivinhado a ordem
De volta ao leaderboard, porque foi aqui que parei de confiar na minha própria intuição.
Sete developers, 10.415 pontos na janela de 30 dias. O developer no topo detém 3.530 deles, que é **33,9% de tudo o que a equipa produziu em valor**. Os dois primeiros detêm 57,7% entre eles.
Quero ter cuidado com o que isso significa e não significa. Não significa que os outros cinco estão com baixo desempenho, e se leres dessa forma aprendeste a lição errada deste post. Concentração como essa geralmente significa que os dois primeiros estão a trabalhar nos componentes de maior multiplicador, que é exatamente o que o sistema foi desenhado para recompensar e exatamente o que lhes pedimos para fazer. O número é uma descrição de onde o valor está a aterrar, não um veredito sobre cinco pessoas.
Mas olha para a ordenação, porque quebrou a minha previsão. Aqui está quem possui o quê:
Contribuidor principal por componente. Uma pessoa é a especialista principal em ambas as áreas mais movimentadas.
Mulualem-E é o especialista principal no chat, o nosso componente de 2,0x, com 71 dos seus 230 pull requests. Ele é também o especialista principal nos agents, o nosso componente de 1,5x, com 86 de 148, ou 58% dessa área. Se me tivesses descrito isso e perguntado quem está no topo do leaderboard, eu teria dito ele sem hesitar. Ele é segundo.
O primeiro lugar vai para tugberkayartextcortex, com 31 pull requests P1 contra os 12 de Mulualem-E. A mistura de severidade venceu a posse de componente. Possuir a área mais importante do produto não é o mesmo que aterrar repetidamente trabalho de alto impacto nela, e até publicarmos isto eu não teria conseguido dizer qual dessas duas coisas a nossa compensação estava realmente a recompensar. Estava a recompensar aquela que eu por acaso tinha notado.
Esse é o prémio do engenheiro barulhento, apanhado em flagrante, na minha própria empresa. A minha intuição tinha as duas pessoas certas e a ordem errada, e a ordem errada é o que um bónus é.
## A pessoa que escreveu mais código está em último lugar
Agora a descoberta que me deixou desconfortável, que é aquela com que quero que realmente reflitas.
karthikmudunuri é o especialista principal no presentation maker, com 51 dos 58 pull requests desse componente. Isso é 88% de uma área de produto inteira. Volume não é o seu problema. Ele está em último no leaderboard, com 300 pontos.
Há uma combinação que dá exatamente esse número: quatro pull requests P1 num componente de 1,5x, e mais nada a pontuar. 4 × 50 × 1,5 = 300. O seu badge diz 4 P1, o que encaixa. Não consigo provar que essa é a decomposição real a partir deste dashboard, e quero assinalar a imprecisão honestamente, porque o leaderboard cobre 30 dias enquanto os gráficos de componente cobrem de 6 de julho a 3 de agosto, pelo que as duas janelas são próximas mas não idênticas.
Se a decomposição estiver correta, cerca de 47 pull requests mesclados produziram zero pontos. Existem apenas duas explicações. Ou eram realmente polimentos de baixa severidade, caso em que a pontuação está correta e a conversa útil é sobre se devemos ter uma pessoa gastando um mês com 88% de concentração em um componente que não marcamos como importante. Ou eram trabalho real que o portão de elegibilidade zerou, caso em que a pontuação está errada e a ferramenta deve uma explicação a ele.
A pontuação é tudo ou nada na elegibilidade. Falhe em um critério habilitado, e o conjunto padrão é vinculação de issue, implementação de correção, qualidade da descrição do PR, testes onde o modelo julga que testes são necessários, e um teto de 3.000 linhas, e a pontuação é zero independentemente da severidade. Uma correção genuinamente crítica com uma descrição ruim pontua o mesmo que nada.
Não sei qual explicação está correta, e aqui está minha reclamação real: o dashboard deveria ser capaz de me dizer, por pull request, e hoje ele me faz fazer engenharia reversa a partir de um total. Essa é uma lacuna real em nosso produto e está sendo corrigida. É também o modo de falha exato que as pessoas temem sobre sistemas de pontuação, então não vou fingir que descobri isso em uma revisão de design. Descobri enquanto escrevia este post.
## Onde os bugs estão é uma decisão de produto, não de engenharia
A outra coisa que decorre de pontuar cada pull request é que você para de discutir sobre qualidade a partir de anedotas.
Os dez componentes mais movimentados, 6 de julho a 3 de agosto de 2026. 740 pull requests, 230 deles correções de bugs.
740 pull requests nos dez componentes mais movimentados. 230 deles, **31%, eram correções de bugs em vez de trabalho novo**. Só o Chat tem 230 pull requests, outros 31%, que é como um multiplicador de 2,0x deve parecer quando está funcionando.
Depois há o presentation maker: 58 pull requests, 23 deles bugs. Isso é uma taxa de bugs de 40% em um componente com quatro contribuidores, contra 25% no chat com sete. E payments tem 44 pull requests com 20 bugs, uma taxa de 45%, no componente que lida com dinheiro.
Bugs críticos por componente. Chat e agents estão empatados com 57 cada.
Chat e agents estão empatados com 57 bugs cada, mas chat produziu esses ao longo de 230 pull requests e agents ao longo de 148. Mesma contagem de bugs, 55% mais trabalho por trás de um deles. Isso é um sinal sobre agents que nenhuma retrospectiva jamais iria revelar, porque nenhuma pessoa isolada na equipe mesclou o suficiente de ambos para perceber.
Correções de bugs versus desenvolvimento de funcionalidades ao longo das mesmas cinco semanas.
A linha de bugs e a linha de funcionalidades sobem juntas ao longo da janela em vez de se compensarem, que é o formato que você quer e não o formato que eu esperava. Estou lendo esse gráfico como descritivo, não como uma afirmação de que melhoramos algo. Ele cobre cinco semanas e a tendência está dentro do ruído que você obteria de um único grande projeto sendo entregue.
## Aqui está onde nossa própria ferramenta está atualmente errada
Se eu mostrasse apenas as partes que funcionam, você estaria certo em desconsiderar tudo. Então:
**A aba de prompt não faz o que diz no caminho de produção.** Existe uma tela de administração que permite personalizar o prompt de avaliação. Ela controla o executor de avaliação em lote. O caminho de webhook e cron que pontua pull requests em produção usa um prompt hardcoded no código-fonte. Se você editar esse template esperando que ele mude suas pontuações ao vivo hoje, não vai mudar, e nada na interface informa isso.
**A coluna do leaderboard do dashboard rotulada como "PRs" não é uma contagem de pull requests.** É a pontuação de autoria. Você pode ver na captura de tela acima: a linha superior mostra 3530 em PRs e 3530 em Score. A página de leaderboard independente acerta isso, com colunas separadas para pull requests e autoria, então é um rótulo errado na única tela que todo mundo realmente abre, o que é quase o pior lugar para ter um.
**Nosso README publica os valores de pontos errados.** Ele diz que P2 é 25 pontos e P3 é 10. O banco de dados semeia 20 e 5, e a captura de tela de configuração acima confirma 20 e 5. A documentação e o software discordam sobre a pontuação, e o software vence.
**A trilha de revisão está quase morta.** Revisar o código de outras pessoas ganha pontos em uma escada de velocidade separada, revisões mais rápidas pontuando mais alto. Em todo esse leaderboard, exatamente uma pessoa tem algum ponto de revisão: 90 de 10.415 no total, ou **0,86% de tudo que foi pontuado**. Seja o que for que pensamos estar incentivando sobre revisão de código, não estamos. A razão mais provável é que a sincronização de revisão só começou a coletar recentemente, mas não confirmei isso, e até que eu confirme, a leitura honesta é que a funcionalidade não está sendo entregue.
**Nosso próprio FAQ alega aproximadamente 90% de precisão de classificação e não consigo comprovar.** Não há conjunto de avaliação no repositório, nenhum script de benchmark e nenhum corpus adjudicado por trás desse número. É uma alegação que eu não aceitaria de um fornecedor, e está em nossa própria página de marketing. Vai ser removida.
## Um placar é manipulado, e o nosso quase não tem defesas
Eu fui procurar no nosso código de pontuação por medidas anti-manipulação. Aqui está a lista completa do que existe.
Pull requests com mais de 3.000 linhas alteradas são inelegíveis, o que impede a forma mais grosseira de inflação. Auto-revisões pontuam zero e são excluídas de toda consulta ao leaderboard. Revisões de contas com `[bot]` no login são ignoradas. O modelo é questionado se o código realmente faz o que a descrição alega, que é o mais próximo de um detector de nonsense. Administradores podem sobrescrever qualquer pontuação, e a sobrescrita exige uma razão escrita de pelo menos dez caracteres.
Aqui está o que não existe. Nenhum limite de pontos semanal ou mensal por pessoa. Nenhum retorno decrescente em trabalho repetido no mesmo componente. Nenhuma decadência temporal de qualquer tipo, e a janela de 30 dias no leaderboard é um intervalo de data padrão que qualquer um pode ampliar, não um limite. Nenhuma detecção de duplicatas ou reversões, então corrigir algo que você quebrou na semana passada pontua como corrigir algo que outra pessoa quebrou. Nenhuma detecção de conluio entre revisores. E o filtro de bot se aplica a revisores, mas não a autores de pull requests, então um pull request mesclado criado por um bot pontua como um humano, o que em 2026 não é uma hipótese.
Qualquer pessoa determinada a explorar este sistema pode fazê-lo. Divida o trabalho em mais pull requests, cada um com um link de issue e uma descrição limpa, direcionados ao componente 2.0x. Essa é a exploração, e quero nomeá-la precisamente por causa do que parece: parece pequenas mudanças bem documentadas e bem testadas na parte mais importante do produto. A maneira mais eficaz de enganar nosso placar é fazer o que queremos. Isso não é um acidente, é o objetivo do design, e é a única defesa contra a lei de Goodhart que realmente funcionou. Torne o proxy caro de falsificar de qualquer forma que não seja a coisa real.
Não é uma defesa completa. A severidade é atribuída por um modelo que lê um diff, e um modelo pode ser convencido a chamar um bug médio de alto por uma descrição de pull request suficientemente dramática. Não medimos com que frequência isso acontece. Ninguém mediu. Se você está avaliando qualquer ferramenta nesta categoria, incluindo a nossa, essa é a pergunta a fazer, e "aproximadamente 90%" não é uma resposta.
## Não vou lhe dar o número de aumento, porque não tenho um
Aqui está a afirmação que gostaria de fazer. Desde que começamos a publicar este leaderboard mensalmente, o trabalho visivelmente se deslocou para os componentes que marcamos como importantes, porque os engenheiros querem a pontuação.
Aqui está por que não estou apresentando isso como um número. Ativamos isso no meio do fluxo, sem uma linha de base limpa, sem repositório de controle e sem uma definição pré-registrada do que "deslocado" significaria. Os multiplicadores mudaram durante o período. O mesmo aconteceu com o headcount e o roadmap. Qualquer porcentagem que eu publicasse seria um número que escolhi depois de ver os dados, o que não é uma medição, é uma decoração.
O que posso lhe dizer é qualitativo e estou rotulando como tal. Os argumentos mudaram. As pessoas pararam de me perguntar se seu trabalho era apreciado e começaram a perguntar por que um componente era classificado como 1.0x. Esse é um argumento muito melhor para se ter, e é a única coisa pela qual eu teria pago por si só.
Se eu algum dia tiver um antes-e-depois real, publicarei a metodologia primeiro e o número depois. Se eu publicar ao contrário, não acredite em mim.
## Aponte para o roadmap, depois entregue a régua às pessoas
Quero terminar acima do produto, porque o produto é a coisa menos interessante aqui.
O verdadeiro trabalho do organograma nunca foi autoridade. Era roteamento. Ele carregava a resposta para "o que importa neste trimestre" para fora das pessoas que decidiram, e carregava a resposta para "quem fez o quê" de volta para dentro, e fazia ambos mal, lentamente e com enorme distorção em cada salto. Tudo que você não gosta na política corporativa é um artefato de compressão desse roteamento. Os gerentes não eram a causa disso. Eles eram o único hardware disponível.
Eles não são mais o único hardware disponível. Um modelo que lê cada diff mais uma tabela de multiplicadores faz o roteamento externo em um salto e o roteamento interno em uma consulta. O que resta para os humanos é a parte que sempre foi realmente o trabalho e nunca teve tempo: decidir quais devem ser os multiplicadores e sentar com as pessoas cujas pontuações essas decisões moveram.
A política não desaparece. Não deixe ninguém lhe vender isso. Ela se move. Ela se move de "meu gerente se lembra do meu trimestre" para "por que meu componente é classificado como 1.0x quando o roadmap diz que é central", e essa segunda briga é uma briga sobre a estratégia real da empresa, conduzida em público, em uma tabela que qualquer um pode ler. Prefiro ter essa briga todo mês do que a atual, que é conduzida uma vez por ano, em particular, por alguém reconstruindo onze meses de memória.
Alguém vai administrar isso mal. Alguém vai colocar um placar na parede sem explicações de elegibilidade e sem rastro de sobrescrita e demitir o décimo inferior, e será um desastre, e será culpado no modelo em vez da pessoa que escolheu os multiplicadores. Essa é a parte que é paga, e não será paga por quem configurou.
Então me meça com o mesmo instrumento. Se você executar algo assim, publique três coisas junto com o leaderboard: a tabela de multiplicadores, para que as pessoas possam argumentar com a estratégia em vez da pontuação. O detalhamento por pull request, para que qualquer um que pontuou zero possa ver qual portão se fechou para eles e recorrer. E o log de sobrescritas, porque o número que um humano alterou é o único número que vale a pena auditar.
Atualmente publicamos o primeiro. Fazemos o terceiro mal: uma sobrescrita escreve sua razão na linha de avaliação, e limpar a sobrescrita deleta a razão junto, então o que temos é uma nota que pode ser revogada em vez de um log. E não publicamos o segundo bem o suficiente, o que só descobri porque um desenvolvedor com 88% de um componente acabou em último no meu próprio leaderboard e não consegui explicar a ele por quê.
*O GitRank está em [gitrank.dev](https://gitrank.dev) e é licenciado sob CC BY-NC 4.0.
A pontuação no caminho de produção é executada no Claude Haiku 4.5 com temperatura 0,3. Todos
os números acima são do
nosso próprio repositório da plataforma entre 6 de julho e 3 de agosto de 2026, com tamanho de amostra de uma
empresa e sete desenvolvedores, o que é uma descrição nossa e não um benchmark de nada.*
