Métricas de portfólio que sobrevivem a escrutínio

Uma métrica de portfólio sobrevive a escrutínio quando mede resultado, se entende fora de contexto e já está provada em algum lugar do projeto — nunca inventada pra soar melhor. Neste site, isso significou trocar contagem de atividade como "152 commits" e jargão como "100% tokens OKLCH" por números como 301 testes automatizados.

Cada card de projeto aqui tem uma faixa de "impact": 1 a 4 pares de número + rótulo, tipo 301 · testes automatizados. Fazia meses que essa faixa existia, mas nunca tinha revisado se os números ali diziam alguma coisa. Não diziam.

O que torna uma métrica de portfólio fraca?

Ela soa bem em voz alta mas não resiste a alguém perguntar "isso significa o quê, exatamente". Reli os cinco projetos com olho de quem nunca me conheceu, e a maioria das métricas caiu no teste do "e daí?" de um de três jeitos: media atividade, usava jargão ou dependia de um contexto que o card não tem.

• "152 commits em 4,5 meses" (SyncClass) — não prova nada. Cento e cinquenta commits pequenos valem menos que cinquenta bem cortados; é atividade, não resultado.
• "100% tokens em OKLCH" (Portfolio) — jargão interno. Recrutador não sabe o que é OKLCH e não devia precisar saber pra confiar no card.
• "33 ferramentas (de 13)" e "6 quizzes no ar (de 1)" — o "(de N)" tenta contar uma história de crescimento, mas fora do parágrafo que dá contexto, lido isolado no card, só confunde. Fica parecendo erro de digitação.

Por que nunca trocar uma métrica fraca por uma inventada?

Porque número inventado troca um problema por outro pior. A tentação óbvia, ao perceber que uma métrica é fraca, é trocar por outra que soa melhor. Se ela não existe em lugar nenhum do texto do projeto, isso é fabricação. A revisão tinha que ser auditoria, não sessão de copywriting.

O tipo ProjectImpact já carregava a regra que eu não seguia:

// Métricas curtas pro card estilo "Project Vault" — 1 a 4 pares, derivados
// dos results já existentes, nunca número inventado.
impact?: { value: string; label: string }[];

Cada candidata passou por uma pergunta só: essa métrica está provada em algum lugar do projeto, sim ou não.

Como mudaram as métricas de cada projeto?

Contagem de atividade e jargão saíram, e todo número que ficou é verificável no próprio projeto. Dois cards só perderam o "(de N)" confuso, um ganhou um número medido de verdade, e um ficou intocado de propósito, porque ainda não existia métrica melhor provada.

SyncClass: tirei "152 commits", mantive 301 testes · 14 tabelas RLS · 92/100 nota. Três métricas, todas verificáveis, nenhuma delas mede atividade.

Portfolio: essa é a única entrada da lista que é o próprio repositório onde estou escrevendo — dava pra medir de verdade em vez de descrever. Rodei a suíte e contei: 140 testes automatizados. Trocou o jargão OKLCH por um número que qualquer um entende sem precisar saber o que é espaço de cor.

QuickToolbox: "33 (de 13)" virou só 33 ferramentas — o card não é o lugar pra contar a história de reescrita, é o longDescription que já faz isso. Ganhou uma terceira métrica que já estava escrita no texto e não tinha virado card: 5 categorias.

Bom Cristão: mesmo problema do QuickToolbox, mesma correção — 6 quizzes no ar, sem o "(de 1)" batendo cabeça fora de contexto.

HER: aqui a auditoria deu em não fazer nada. A métrica de teste que eu queria colocar não existe escrita em lugar nenhum do texto do projeto, só a tecnologia (Vitest) citada. Sem número real medido, a faixa ficou como estava — 13 tabelas RLS · 0 erros de segurança — até eu ter o dado de verdade pra trocar.

Uma métrica só no card basta?

Basta, se for real. Métrica de portfólio não é decoração, é prova. Se ela não aparece em nenhum lugar do texto do projeto e eu não consigo medir na hora, ela não entra — nem que o card fique com uma métrica só. Um número real sozinho pesa mais que dois números vagos lado a lado.