Antes de Medir, Alguém Escolheu No Que Acreditar

Medir não é entender

Existe uma crença silenciosa que atravessa tecnologia, gestão e organizações modernas sem pedir licença. Ela raramente é dita explicitamente, mas orienta decisões todos os dias, em reuniões, dashboards e planos estratégicos.

Se conseguimos medir algo, então conseguimos entendê-lo. Se entendemos, conseguimos controlar. E se controlamos, estamos sendo responsáveis.

Essa lógica parece razoável demais para ser questionada. Medir soa como maturidade. Números passam seriedade. Gráficos criam a sensação de domínio.

Quando esquecemos disso, números deixam de ser instrumentos e passam a ser tratados como verdades. Decisões passam a ser justificadas não porque são boas, mas porque são mensuráveis.

O ciclo de visibilidade

Métricas não vivem em um vácuo técnico. Elas existem dentro de sistemas sociais e, nesses sistemas, não apenas descrevem comportamento — elas o moldam.

Não existe métrica neutra. Existe apenas métrica assumida ou métrica usada sem consciência.

Quando eficiência vira anestesia

A confusão começa a ganhar corpo quando tratamos coisas diferentes como se fossem equivalentes.

Quanto mais fácil algo é de medir, mais ele tende a ocupar o centro da atenção. Impacto real, por outro lado, é difícil, difuso e lento. Com o tempo, organizações passam a otimizar aquilo que conseguem enxergar melhor — não necessariamente aquilo que mais importa.

O problema da eficiência descontextualizada

É nesse terreno que eficiência entra como virtude incontestável. Fazer mais, mais rápido, com menos custo parece sempre desejável.

A pergunta raramente feita é “eficiente para quê?”.

Quando métricas viram metas

Por que isso acontece?

Não por perversidade, mas por dinâmica organizacional. Números facilitam comparação, encerram discussões e oferecem justificativas simples para decisões complexas.

Qual o efeito?

Quando uma métrica vira meta, ela deixa de observar o sistema e passa a medir a habilidade do sistema de se adaptar à própria métrica.^[1]

O jogo implícito

Todo sistema passa a jogar algum jogo, mesmo quando ninguém o define explicitamente. Algo sempre está sendo otimizado: previsibilidade, aparência de controle, velocidade, tranquilidade política, ausência de conflito.

As métricas não criam esse jogo do nada; elas revelam e reforçam o jogo que já estava em andamento.

Quem escolhe o que medir, escolhe o que importa

Existe uma camada de poder que raramente entra na discussão técnica sobre métricas: quem decide o que medir?

Quando a métrica principal vira “velocidade” ou “story points por iteração”, não é apenas uma escolha pragmática. É uma declaração implícita sobre o que a organização valoriza: movimento mensurável sobre impacto difuso, quantidade sobre qualidade, velocidade sobre sustentabilidade.

Exemplo concreto de burnout por métrica:

Uma organização decide acompanhar velocidade do time como métrica principal. Toda iteração, há expectativa de que velocidade suba ou, no mínimo, se mantenha. O time responde:

• Inflando estimativas para criar margem
• Fragmentando trabalho para aumentar contagem
• Evitando tarefas importantes mas difíceis de estimar
• Trabalhando horas extras para “bater a meta”

Seis meses depois, a velocidade está alta, o painel está verde, mas o time está exausto. Débito técnico explodiu. Funcionalidades importantes foram adiadas porque “não cabiam na iteração”. Ninguém lembra por que começaram a medir velocidade — mas todos sabem que ele precisa subir.

A pergunta que deveria ser feita antes de escolher qualquer métrica:

• Quem se beneficia desta visibilidade?
• O que fica invisível quando medimos isso?
• Qual comportamento estamos incentivando implicitamente?
• Quem paga o custo quando o sistema otimiza para essa métrica?

No Artigo 4, veremos como essas dinâmicas se manifestam em frameworks como DORA — e como consultorias como Gartner legitimam métricas não porque elas são verdadeiras, mas porque reduzem a ansiedade corporativa.

Entrega alta como sinal errado de saúde

É assim que surgem os times que entregam muito e ainda assim quebram por dentro. A backlog anda, o roteiro progride, as implantações acontecem. Para quem observa de fora, tudo parece saudável.

DevEx como economia cognitiva

É aqui que Developer Experience costuma ser mal compreendida.

Um time com DevEx ruim não necessariamente entrega menos. Ele entrega custando mais. A produção continua alta, mas a energia necessária para sustentá-la cresce em silêncio.

O sinal clássico de DevEx quebrada não é queda de produtividade, mas produtividade alta acompanhada de exaustão crônica.

Como exceções viram regras

Esse padrão se cristaliza na liderança técnica. Não por má intenção, mas porque exceções viram regras:

Cada decisão parece sensata isoladamente. Juntas, ensinam ao sistema que entregar rápido é mais seguro do que entregar bem.

Burnout como efeito colateral de sucesso mal definido

Burnout não é falha individual. É efeito colateral de sucesso mal definido. O time não quebra apesar da alta performance. Ele quebra porque a alta performance vira estado permanente.

O retrabalho vem depois, quando sistemas ficam rígidos, incidentes se repetem e a organização se pergunta por que tudo ficou mais lento.

A cultura real

Nesse ponto, a cultura já está definida. Não pelo que está escrito em valores, mas pelo que foi reforçado:

Essa é a cultura real. Métricas de entrega dão verniz racional a esse estado das coisas.

A escolha que precede a métrica

Frameworks entram como lentes, não como soluções. Eles ajudam a enxergar, mas não corrigem problemas mal formulados. Por isso, esta série começa aqui, atrasando a pressa por respostas.

Antes de escolher métricas, escolha o problema que você quer resolver. Se essa escolha não for consciente, o sistema fará por você. E ele não se importa com burnout, DevEx ou pessoas.

---

FAQ

Perguntas Frequentes

Então métricas são ruins?

Não. Métricas são ferramentas. O problema é usá-las sem consciência das premissas que carregam. Toda métrica é um recorte da realidade — útil quando você sabe o que está recortando.

Como escolher métricas melhores?

Comece pelo problema, não pela métrica. Pergunte: o que estou tentando entender? O que essa métrica não vai mostrar? Qual comportamento ela pode incentivar?

DORA metrics são confiáveis?

DORA oferece um framework útil para medir capacidade de entrega de software. Mas como qualquer framework, funciona melhor quando você entende suas premissas e limitações.

---

Notas de Rodape

1. [1]

   A Lei de Goodhart afirma que “quando uma medida se torna uma meta, ela deixa de ser uma boa medida”. Este fenômeno está bem documentado em economia e ciências sociais.