Métricas que importam vs métricas que parecem importar

O problema

Métrica de engenharia costuma ser mal usada de dois jeitos.

O primeiro:

• quase ninguém mede nada
• toda decisão vira impressão
• gargalo só aparece quando já virou atraso ou incidente

O segundo:

• o time coleta um monte de número
• todo mundo olha dashboard bonito
• ninguém consegue dizer o que faria diferente por causa dele

Os dois cenários são ruins.

No primeiro, falta sinal.

No segundo, sobra ruído.

Modelo mental

Pensa assim:

métrica útil não existe para parecer objetiva. Ela existe para ajudar alguém a decidir melhor o próximo passo.

Essa pergunta filtra muita coisa:

• que decisão esse número ajuda a tomar?
• que comportamento ele deveria revelar?
• que gargalo ou risco ele ajuda a enxergar?

Se a resposta for vaga, a métrica provavelmente está mais perto de decoração do que de ferramenta.

Quebrando o problema

Métrica boa normalmente está ligada a fluxo, risco ou resultado

Em time de entrega, números mais úteis costumam apontar coisas como:

• tempo entre começar e terminar um trabalho
• onde o item fica parado
• quanto retrabalho está voltando
• frequência de falha em deploy
• volume de blocker recorrente

Esses sinais ajudam a localizar problema real.

Métrica vaidosa costuma parecer mais fácil do que útil

Exemplos clássicos:

• quantidade de story points queimados
• número de tickets fechados
• linhas de código
• volume bruto de PRs

Esses números até podem subir ou descer.

Mas, sozinhos, costumam responder pouco sobre:

• qualidade do fluxo
• saúde da entrega
• risco acumulado
• custo de mudança

O problema não é o número em si; é o uso

Até uma métrica razoável pode ficar ruim se virar:

• ranking individual
• cobrança moral
• proxy torto de produtividade

Quando o time sente que o número virou arma, ele começa a otimizar o score, não o sistema.

E aí a métrica para de revelar realidade.

Começa a deformar comportamento.

Poucas métricas boas costumam valer mais do que painel completo

Na prática, um conjunto pequeno costuma ser mais útil:

• lead time
• taxa de retrabalho
• falha ou rollback em produção
• blocker recorrente por tipo

Dependendo do time, isso já dá leitura suficiente para conversar melhor sobre fluxo.

O ponto não é decorar sigla.

É conseguir ligar o número a uma pergunta operacional real.

Exemplo simples

Imagine um time que reclama que está entregando pouco.

O dashboard atual mostra:

• story points por sprint
• tickets fechados por pessoa
• número de PRs abertas

Parece organizado.

Mas ainda não responde:

• o trabalho está entrando grande demais?
• estamos acumulando fila de revisão?
• tem blocker externo travando o fluxo?
• estamos fechando rápido e reabrindo depois?

Agora imagine outro recorte:

• lead time por tipo de trabalho
• quantos itens ficaram bloqueados por dependência externa
• quantos tickets voltaram por regra mal alinhada
• quantos deploys geraram rollback ou correção rápida

Esse segundo conjunto ajuda muito mais a melhorar o sistema de entrega.

Erros comuns

• Medir o que é fácil em vez do que é útil.
• Usar métrica de time para vigiar pessoa individualmente.
• Achar que volume bruto significa progresso real.
• Criar dashboard sem pergunta operacional por trás.
• Tratar qualquer número como verdade neutra e não como instrumento com efeito comportamental.

Como um senior pensa

Quem está mais maduro costuma perguntar:

• esse número ajuda a localizar gargalo ou só gera sensação de controle?
• ele está medindo fluxo ou só atividade?
• o time mudaria alguma decisão por causa dele?
• que comportamento ruim essa métrica pode incentivar?

Esse último ponto é importante.

Métrica boa não é só a que parece inteligente.

É a que melhora conversa e não estraga o sistema humano ao redor.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador costuma procurar:

• clareza sobre o que medir em times de engenharia
• capacidade de separar fluxo de vanity metrics
• noção de efeito colateral de indicador mal usado
• maturidade para conectar métrica a decisão

Uma resposta forte costuma soar assim:

Eu tento escolher poucas métricas que ajudem a entender fluxo, risco e qualidade da entrega. Em geral desconfio de número que vira proxy de produtividade individual, como story points queimados ou tickets por pessoa. Prefiro sinais que ajudem a localizar gargalo, como lead time, blocker recorrente, retrabalho e falha em produção. Se a métrica não muda decisão, ela provavelmente está ocupando espaço demais.

Métrica boa não existe para parecer gestão madura. Existe para melhorar leitura do sistema.