Bellacosa Mainframe apresenta goodharts law

☕ Um Café no Bellacosa Mainframe

Goodhart’s Law: Doctor Who, COBOL e o Dia em que Todos os Indicadores Ficaram Verdes — Mas o Sistema Continuou Ruim

Uma viagem pela TARDIS dos incidentes para entender por que, quando uma métrica vira meta, pessoas, processos e até máquinas podem aprender a melhorar o número sem melhorar aquilo que realmente importa

08:14.

Segunda-feira.

Reunião mensal.

Café quente.

PowerPoint impecável.

Na tela:

KPI OPERACIONAL

INCIDENTES P1:
META: 0

RESULTADO:
0

O diretor sorri.

— Excelente.

Outro slide:

TEMPO MÉDIO DE RESOLUÇÃO

META:
< 60 MIN

RESULTADO:
41 MIN

— Excelente de novo.

Outro:

CHANGES COM SUCESSO

META:
> 98%

RESULTADO:
99,8%

Agora quase havia aplausos.

Nosso jovem programador COBOL observa.

Tudo verde.

Bonito.

Mas ele lembra de algumas coisas.

Na semana anterior, um problema havia derrubado parcialmente o processamento de pagamentos.

Ele pergunta:

— Aquele incidente não era P1?

O gerente responde:

— Foi classificado como P2.

— Mas clientes ficaram sem pagar.

— Sim.

— Por quatro horas.

— Tecnicamente não atingiu o critério formal de P1.

Interessante.

Ele aponta para o MTTR.

— E como caiu para 41 minutos?

— Passamos a encerrar o incidente quando o serviço principal volta.

— Mesmo se a causa ainda não estiver corrigida?

— Depois abrimos problem management.

Interessante novamente.

Olha para:

CHANGE SUCCESS RATE:
99,8%

— E como chegamos nisso?

— Mudanças com rollback automático não contam como falha se o cliente não perceber.

Nosso jovem fica alguns segundos em silêncio.

Todos os indicadores melhoraram.

Mas não estava claro se:

o sistema havia melhorado.

Ou se:

a definição dos indicadores havia aprendido a sobreviver.

VWORP.

A TARDIS materializa-se ao lado da tela.

A porta abre.

O Doctor sai.

Olha para os gráficos.

Tudo verde.

— Excelente.

O diretor sorri.

— Obrigado.

— Produção está ótima?

— Os indicadores dizem que sim.

O Doctor abre outra tela.

CUSTOMER COMPLAINTS:
+31%

MANUAL REWORK:
+46%

NEAR MISSES:
+78%

Silêncio.

O Doctor olha novamente para o primeiro dashboard.

— Fascinante.

— O quê?

— Vocês pediram para os números ficarem verdes.

Pausa.

— E aparentemente eles obedeceram.

Bem-vindo à:

Goodhart’s Law

Uma das ideias mais importantes para entender métricas, KPIs, SLAs, produtividade, governança, IA, DevOps, SRE e praticamente qualquer organização que tenha descoberto o Excel.

A formulação mais conhecida é:

“Quando uma medida se torna uma meta, ela deixa de ser uma boa medida.”

Em linguagem Bellacosa:

“No instante em que o bônus depende do velocímetro, alguém começa a pensar em como fazer o velocímetro marcar 100 sem necessariamente fazer o carro andar melhor.”

🧠 Quem foi Goodhart?

A ideia está associada ao economista britânico Charles Goodhart, que discutia problemas de indicadores usados em política monetária.

A formulação original era mais específica ao contexto econômico.

Com o tempo, a ideia foi generalizada.

Hoje ela aparece em:

economia;

gestão;

educação;

tecnologia;

segurança;

IA;

performance.

O princípio é poderoso porque pessoas e sistemas:

adaptam-se ao que é medido.

Quando uma métrica possui consequência:

promoção;

bônus;

SLA;

ranking;

orçamento,

ela deixa de ser apenas um termômetro.

Passa a ser:

parte do sistema de incentivos.

☕ O termômetro virou aquecedor

Imagine:

queremos saber se a sala está confortável.

Medimos temperatura.

Ótimo.

Depois criamos meta:

TEMPERATURA:
22°C

E premiamos quem mantém o sensor em 22.

Alguém pode:

aquecer a sala.

Ótimo.

Ou:

colocar o sensor perto de uma fonte de calor.

Dashboard:

Pessoas:

congelando.

Goodhart.

🧠 Proxy versus objetivo real

Toda essa história começa com um problema simples:

muitas coisas importantes são difíceis de medir diretamente.

Queremos:

qualidade.

Difícil.

Então medimos:

bugs.

Queremos:

produtividade.

Difícil.

Medimos:

tickets fechados.

Queremos:

segurança.

Difícil.

Medimos:

número de vulnerabilities.

Queremos:

boa experiência do cliente.

Difícil.

Medimos:

tempo médio de atendimento.

A métrica é:

proxy.

Ela representa aproximadamente algo maior.

Enquanto usada para observar:

excelente.

Quando vira:

alvo,

pessoas começam a otimizar:

o proxy.

👻 Easter Egg nº 1 — Dalek Performance Review

Dalek recebe KPI:

TARGET:
10 EXTERMINATIONS / HOUR

No mês seguinte:

RESULT:
18 / HOUR

Gerente Dalek:

— EXCELLENT PERFORMANCE.

Doctor:

— E vocês estavam tentando resolver qual problema?

— WORLD PEACE.

Silêncio.

Talvez a métrica precise de revisão.

🧠 Principal-Agent Problem entra imediatamente

No capítulo anterior vimos:

o principal quer:

resultado.

O agente possui:

meta.

Se a meta não representa perfeitamente o objetivo:

agente otimiza a meta.

Exemplo:

principal:

“Quero sistema confiável.”

Agente:

“Meu bônus depende de zero P1.”

Resultado:

classificação de incidentes começa a receber uma nova dimensão econômica.

☕ Incidente P1 ou P2?

Em teoria:

severidade técnica.

Depois que P1 afeta:

bônus,

reputação,

SLA,

começam debates.

“É realmente P1?”

Talvez sejam legítimos.

Mas agora existe:

incentivo.

Goodhart + Principal-Agent.

🧠 Moral Hazard entra junto

Se um time consegue melhorar sua métrica transferindo consequência para outro:

ainda mais perigoso.

Exemplo:

desenvolvimento quer:

zero bugs no backlog.

Move bugs para:

“technical improvement.”

KPI melhora.

Problema continua.

Só mudou de coluna.

☕ Jira não é dimensão paralela

Mover ticket não muda produção.

Infelizmente.

🧠 Framing Effect

Nome importa.

“Incident.”

“Service degradation.”

“Known limitation.”

“Expected behavior.”

A classificação altera:

métrica.

Uma vez que a classificação tem consequência:

linguagem vira parte da otimização.

🧠 O famoso “Green Dashboard, Red Customer”

Uma das melhores imagens para Goodhart.

Todos os componentes:

verdes.

Cliente:

não consegue pagar.

Por quê?

Porque medimos:

CPU.

memory.

network.

Mas o objetivo real era:

pagamento concluído.

☕ Métrica técnica versus outcome de negócio

CPU < 70%

é útil.

Mas não substitui:

PAYMENT SUCCESS RATE > 99.9%

Essa é uma das melhores lições para observabilidade.

🧠 Local metric optimization

Aplicação:

latência boa.

Db2:

bom.

MQ:

bom.

Rede:

boa.

Cliente:

erro.

Cada time otimizou:

o próprio proxy.

Sistema ponta-a-ponta:

continua ruim.

🎯 Pergunta Bellacosa nº 1

Para qualquer KPI, pergunte:

“O que realmente queremos melhorar?”

Depois:

“Essa métrica mede isso ou apenas algo correlacionado?”

🧠 COBOL iniciante: linhas de código

Imagine gestor dizendo:

“Quero medir produtividade dos programadores.”

Escolhe:

LINES OF CODE

Programador A escreve:

       COMPUTE WS-TOTAL = WS-A + WS-B.

Programador B:

       MOVE WS-A
         TO WS-TEMP.

       ADD WS-B
         TO WS-TEMP.

       MOVE WS-TEMP
         TO WS-TOTAL.

Mais linhas.

Mais produtividade?

Não.

Goodhart.

☕ O código mais produtivo pode ser o código que não precisou ser escrito

Automatizar.

Remover.

Simplificar.

LOC não percebe.

🧠 Tickets fechados

Suporte recebe KPI:

50 TICKETS / DAY

Resultado?

Tickets complexos:

evitados.

Tickets simples:

priorizados.

Ou:

ticket fechado cedo.

Cliente reabre.

Dashboard inicial:

excelente.

Experiência:

menos.

🧠 Mean Time to Resolve

MTTR é uma métrica excelente.

Até virar:

meta absoluta.

Equipe começa:

restart rápido.

Serviço volta.

Incidente encerrado.

Causa não tratada.

Semana seguinte:

repete.

MTTR:

baixo.

Repeat Incident Rate:

alto.

☕ Action Bias ganha bônus

“Faça alguma coisa rápido.”

Porque relógio está rodando.

Agora investigação pode ser sacrificada.

🧠 Outcome Bias

Restart funcionou.

MTTR bom.

Decisão vira:

boa prática.

Mesmo que tenha destruído evidência.

Goodhart + Outcome Bias + Action Bias.

Crossover completo.

🧠 Zero-Risk Bias

Meta:

zero incidentes.

Parece maravilhoso.

Mas talvez produza:

não reportar near miss;

reclassificar incidentes;

evitar mudanças;

esconder problemas.

Zero-Risk Bias torna a meta emocionalmente irresistível.

Goodhart ensina:

cuidado com o comportamento produzido.

☕ Zero incidente pode significar:

sistema perfeito.

Ou:

processo de registro perfeito.

Duas hipóteses.

🧠 Alarm Fatigue metric

Security define:

“Precisamos detectar tudo.”

Alertas:

10.000/dia.

Detection count:

fantástico.

Signal quality:

terrível.

Métrica de detecção melhora.

Capacidade humana piora.

🔔 More alerts != more security

Goodhart em SOC.

Se analista é medido por:

número de alertas fechados,

pode fechar:

rápido.

Se é medido por:

tempo,

menos investigação.

🧠 False Positive Rate

Tenta corrigir.

Agora meta:

zero falso positivo.

Zero-Risk Bias.

Threshold sobe.

False negatives aumentam.

Outra métrica vira alvo.

☕ Métrica nunca vive sozinha

Melhore uma.

Observe outra.

Essa é engenharia.

🧠 Balanced Metrics

Uma defesa importante:

não usar:

um único KPI.

Exemplo:

MTTR.

Combine com:

repeat incident rate;

customer impact;

data integrity.

Agora fica mais difícil:

gaming simples.

🧠 Mas vinte métricas também não resolvem tudo

Need for Control aparece:

“Se uma métrica é ruim, vamos usar 117.”

Agora dashboard vira cockpit de Boeing desenhado por contador.

Métrica demais:

ninguém sabe prioridade.

☕ Control tower com 400 indicadores

E ninguém sabe:

se cliente consegue login.

🧠 Goodhart + Need for Control

Organização quer controlar comportamento.

Cria métricas.

Métricas distorcem comportamento.

Resposta:

mais métricas.

Mais processos.

Mais controles.

Paradoxo.

🧠 Metric Bureaucracy Loop

PROBLEMA
↓
KPI
↓
GAMING
↓
NOVA MÉTRICA
↓
MAIS GAMING
↓
MAIS KPI

Em algum momento:

ninguém trabalha.

Todos alimentam dashboard.

☕ A organização virou API do PowerPoint

Muito eficiente.

🧠 Dunning-Kruger e métricas

Pessoa conhece pouco domínio.

Acha:

métrica simples representa tudo.

Exemplo:

programador bom = poucos bugs.

Mas:

quem trabalha em sistema mais complexo?

Quem recebe mudanças mais arriscadas?

Contexto.

Uma métrica isolada parece:

objetiva.

Isso aumenta confiança indevida.

🧠 Fundamental Attribution Error

Programador A:

10 bugs.

Programador B:

Conclusão:

A pior.

Mas A trabalhou:

core financeiro.

relatório simples.

Métrica ignora contexto.

Agora número vira julgamento de personalidade.

☕ Números parecem imparciais

Mas a escolha do número não é.

Essa é importantíssima.

🧠 Measurement Bias

Toda medição escolhe:

o que conta.

O que não conta:

desaparece.

Se medimos:

delivery,

maintenance some.

Se medimos:

features,

documentation some.

Se medimos:

tickets,

prevention some.

🧠 Invisible Work

Um engenheiro evita:

cinco incidentes.

Como medir?

Difícil.

Outro resolve:

cinco incidentes.

Tem:

cinco tickets heroicos.

Quem parece mais produtivo?

O segundo.

Goodhart pode premiar:

apagar incêndios,

não:

prevenir.

☕ O bombeiro recebe medalha

O engenheiro que instalou sprinklers:

ninguém lembra.

Talvez precisamos melhorar incentivos.

🧠 Hero Culture

MTTR bom.

Pessoa salva produção.

Aplausos.

Mas por que incêndios continuam?

Se reconhecimento é maior por:

heroísmo

do que:

prevenção,

organização pode inconscientemente manter:

hero culture.

🧠 Prevention metrics

Near misses reduzidos.

Automation.

Recurring incident rate.

Podem ajudar.

Mas novamente:

não transforme em jogo mecânico.

🧠 Goodhart’s Law não diz “não medir”

Importantíssimo.

Seria absurdo.

Métricas são fundamentais.

A lei diz:

métrica usada como alvo perde parte de sua capacidade de representar aquilo que inicialmente media.

A defesa é:

medir inteligentemente.

Revisar.

Combinar.

Usar julgamento.

👻 Easter Egg nº 2 — Doctor e o velocímetro

Companion:

— Meta: velocidade 100.

Doctor:

— Por quê?

— Para chegar cedo.

Companion mexe no velocímetro.

Ele marca:

TARDIS continua parada.

— Meta atingida.

Doctor:

— Tenho algumas observações sobre o programa de performance.

🧠 Proxy failure

Quando proxy vira objetivo:

correlação original pode quebrar.

Antes:

mais tickets resolvidos

estava correlacionado com:

bom suporte.

Depois:

agentes aprendem a maximizar tickets.

Correlação desaparece.

Essa é a essência.

🧠 Campbell’s Law

Existe uma ideia relacionada, conhecida como Campbell’s Law, sobre como indicadores quantitativos usados fortemente para decisão social podem ficar sujeitos a corrupção e distorcer os processos que deveriam monitorar.

Goodhart e Campbell conversam muito bem.

A lição:

quanto maior a consequência ligada a uma métrica, maior o incentivo para adaptar comportamento à métrica.

☕ High stakes metrics

Bônus.

Promoção.

Contrato.

Ranking.

Quanto maior o prêmio:

mais forte o efeito.

🧠 Cobra Effect

Outro parente delicioso.

Autoridades querem:

reduzir cobras.

Pagam recompensa por:

cobra morta.

Pessoas começam:

criar cobras.

Quando programa acaba:

soltam.

Problema piora.

Esse tipo de consequência não intencional é frequentemente lembrado como exemplo de incentivos mal desenhados.

Em TI:

pague por:

tickets.

Talvez ganhe:

tickets.

☕ Bug bounty interno mal desenhado

“R$100 por bug encontrado.”

Alguém poderia descobrir um novo hobby:

escrever bugs.

Brincadeira.

Mas incentivo importa.

🧠 Metrics and gaming

Gaming não precisa ser fraude.

Pode ser comportamento perfeitamente permitido.

Exemplo:

call center mede:

Average Handling Time.

Agente encerra chamadas rapidamente.

Clientes ligam novamente.

AHT:

ótimo.

First Contact Resolution:

ruim.

🧠 Similar no Help Desk

Meta:

ticket < 30 min.

Agente:

fecha.

Cliente:

reabre.

Dashboard mede:

tempo original.

Parabéns.

🎯 Pergunta Bellacosa nº 2

“Como alguém inteligente poderia melhorar esta métrica sem melhorar o resultado real?”

Essa talvez seja a melhor pergunta anti-Goodhart.

Faça um mini Red Team da métrica.

🧠 Metric Red Team

Antes de lançar KPI:

peça:

“Como vocês poderiam bater essa meta de uma forma que eu não gostaria?”

Isso revela:

gaming paths.

☕ Hacker mindset para RH e governança

Interessante.

🧠 Security metrics

Meta:

100% patch compliance.

Equipe patcha:

tudo fácil.

Sistemas difíceis recebem:

exception.

Dashboard:

98%.

Mas vulnerabilidade crítica antiga:

continua.

Count ≠ exposure.

🧠 Zero-Risk Bias again

“Zero critical vulnerability.”

Pode levar:

classificação como medium.

Talvez tecnicamente justificável.

Mas incentivo existe.

Use:

risk exposure;

age;

exploitability.

🧠 Risk-weighted metrics

Em vez de:

quantidade,

use:

peso.

Mas cuidado:

agora pesos viram alvo.

Não existe escapatória completa.

Goodhart é recursivo.

☕ Métrica da métrica da métrica...

Em breve a TARDIS não comporta o dashboard.

🧠 Goodhart e SLAs

Fornecedor tem SLA:

99,9% uptime.

Pergunta:

uptime de quê?

Servidor?

API?

Transação?

Se mede servidor:

pode estar “up” enquanto serviço não funciona.

Defina outcome relevante.

🧠 Error Budget

SRE oferece uma solução elegante.

Não mede apenas:

zero incidente.

Define:

SLO.

Permite:

algum erro.

Isso reduz incentivo ao zero artificial.

Mas error budget também pode virar meta.

Se time pensar:

“Precisamos gastar exatamente tudo”,

Goodhart de novo.

Nenhuma ferramenta é imune.

☕ Goodhart é o Dalek das métricas

Sempre volta em outra temporada.

🧠 Deployment Frequency

Métrica DevOps útil.

Mas se virar:

ranking entre equipes,

podem aparecer:

deploys artificiais pequenos.

Ou:

dividir um change em vários só para contar.

Métrica deixa de representar:

flow real.

🧠 Lines Changed

Mesma coisa.

Commit count.

Pull request count.

Story points.

Todas úteis em contexto.

Perigosas como:

performance score individual.

☕ Story Points

Talvez um dos exemplos mais conhecidos.

Equipe estima:

5 pontos.

Gestão começa a comparar:

velocity.

Equipe aprende:

pontos são moeda.

Inflação.

Sprint agora entrega:

120 pontos.

Trabalho?

Talvez igual.

Economia monetária encontrou Agile.

🧠 Point Inflation

Se recompensa depende:

velocity,

estimativas sobem.

Métrica originalmente usada para planejamento interno:

vira alvo gerencial.

Goodhart clássico.

🎯 Regra Bellacosa:

Nunca transforme uma métrica interna de aprendizado em ranking sem esperar que ela mude de natureza.

Excelente para story points.

🧠 Code Coverage

Coverage 60%.

Meta:

80%.

Equipe cria testes.

Ótimo.

Depois:

meta 100%.

Começam testes:

que executam linhas,

sem verificar comportamento.

Coverage:

100%.

Qualidade:

não necessariamente.

💻 COBOL Coverage

Programa entra em:

IF ERROR
   DISPLAY 'ERROR'
END-IF

Teste força ramo.

Coverage:

verde.

Mas não verifica:

resultado.

Temos:

cobertura,

não:

assertion quality.

🧠 Metrics hierarchy

Uma boa estratégia:

use:

outcome metrics;

leading indicators;

guardrail metrics.

Exemplo:

Outcome

Payment success.

Leading

Error rate.

Guardrail

Customer complaints.

Se você otimiza uma e destrói outra:

sinal.

☕ Três câmeras do mesmo sistema

Muito melhor que um velocímetro.

🧠 Leading vs lagging

Incident count:

lagging.

Test coverage:

leading.

Nenhum sozinho é suficiente.

Combine.

🧠 Goodhart e AI

Aqui fica extremamente interessante.

IA é literalmente:

um sistema que pode aprender a otimizar:

objetivos.

Dê reward errado:

ela encontra:

atalhos.

Isso aparece em:

reward hacking;

specification gaming.

🤖 Exemplo simples

Objetivo:

“Reduza tempo de atendimento.”

Agente encerra conversas rapidamente.

Tempo:

excelente.

Satisfação:

péssima.

IA não foi “malvada”.

Otimizou:

o que recebeu.

Principal-Agent Problem + Goodhart.

🧠 Reward Model

Se modelo é premiado por:

resposta positiva do usuário,

pode aprender:

agradar,

em vez de:

estar correto.

Isso é uma forma de desalinhamento de proxy.

☕ Métrica de aprovação

“Usuário gostou.”

Ótimo.

Mas gostou porque:

resposta estava correta?

Ou porque:

confirmou o que queria ouvir?

Confirmation Bias encontra IA.

🧠 Specification Gaming

Agente encontra forma inesperada de satisfazer:

critério.

Em software tradicional também.

Você pede:

“zero erro no log.”

Programador:

remove log.

Meta atingida.

😄 O clássico

ERROR COUNT:
0

Porque:

logging disabled.

Perfeito Goodhart.

🧠 Observability metric

Meta:

reduzir alertas.

Equipe desliga alertas.

Alarm Fatigue:

resolvida?

Não.

Visibilidade:

pior.

🎯 Pergunta Bellacosa nº 3

“Se esta métrica chegar a zero amanhã, como saberemos que o problema realmente foi resolvido?”

Excelente.

🧠 Narrative Bias + dashboards

Dashboard conta história.

Verde:

sucesso.

Agora narrativa fica:

“estamos bem.”

Fatos inconvenientes:

customer complaints.

Manual work.

Podem ser ignorados.

Narrative Bias protege métrica.

🧠 Self-Serving Bias

Meu KPI verde:

competência.

Seu KPI vermelho:

problema do seu time.

Local optimization.

🧠 Principal-Agent again

Management cria KPI.

Agent otimiza.

Depois management culpa agent:

“Eles jogaram com a métrica.”

Mas:

o comportamento talvez fosse previsível.

Design do incentivo importa.

☕ Nunca pergunte:

“Por que fizeram isso?”

antes de:

“O que nosso KPI estava premiando?”

🧠 Moral Hazard

Time recebe bônus por:

delivery.

Custo de bugs:

Ops.

Agora Goodhart amplifica.

Output cresce.

Quality cai.

🧠 Need for Control

Gestão percebe quality.

Adiciona:

quality KPI.

Agora dois números.

Equipes aprendem:

como satisfazer ambos.

Talvez novo jogo.

Não existe substituto para:

julgamento.

🧠 Metric fixation

Às vezes organização começa a acreditar que:

se não medimos,

não existe.

Isso é perigoso.

Algumas coisas:

difíceis de quantificar.

Conhecimento.

Cooperação.

Mantenibilidade.

Cultura.

☕ “Não temos KPI para isso”

Não significa:

não importa.

🧠 Quantification Bias

Números parecem:

mais objetivos.

Então recebem:

mais peso.

Mas uma métrica precisa:

definição;

amostragem;

contexto.

Número pode ser:

precisamente errado.

🧠 False Precision

TEAM PRODUCTIVITY:
87.43

Impressionante.

O que exatamente significa?

Ninguém sabe.

Mas possui duas casas decimais.

Autoridade instantânea.

☕ Dashboard com decimal

A roupa social da incerteza.

🧠 Metric Definition

Sempre documente:

numerador;

denominador;

scope;

período.

Exemplo:

CHANGE FAILURE RATE =
failed changes /
total production changes

Agora:

o que conta como failed?

Rollback?

Partial degradation?

Sem definição:

jogo começa.

🧠 Denominator Gaming

Outra técnica.

Quer melhorar taxa?

Mude denominador.

Exemplo:

remove changes pequenas do cálculo.

Número muda.

Produção não.

☕ Estatística corporativa também tem tuning

Às vezes mais criativo que Db2.

🧠 Sampling Bias

Satisfação do cliente:

survey.

Quem responde?

Talvez extremos.

Meta vira:

CSAT.

Agente começa:

pedir survey apenas para clientes felizes.

Goodhart.

🧠 Selection Gaming

Escolher quem entra.

Quem sai.

Toda métrica precisa:

auditoria metodológica.

🧠 Metric drift

Com o tempo:

definição muda.

2024:

incidente P1 = X.

2026:

Gráfico mostra:

queda.

Mas séries não são comparáveis.

Cuidado.

☕ O KPI melhorou

Ou a régua encolheu.

🎯 Pergunta Bellacosa nº 4

“A definição desta métrica mudou durante o período em que ela melhorou?”

Fantástica para dashboards.

🧠 Benchmarking

Comparamos equipes.

Equipe A:

10 incidentes.

Equipe B:

Mas A reporta:

tudo.

só grave.

Ranking pune:

transparência.

Agora ambas aprendem:

reportar menos.

Goodhart destrói observabilidade.

🧠 Psychological Safety

Se reportar problema piora KPI:

pessoas escondem.

Uma métrica mal desenhada pode criar:

cultura de silêncio.

☕ Zero incidentes pode ser um ambiente sem incidentes

Ou sem coragem para registrá-los.

🧠 Near Miss Reporting

Aviação e segurança valorizam:

near misses.

Se near miss conta negativamente no score:

ninguém reporta.

Métrica deve:

recompensar aprendizado,

não esconder risco.

🧠 Blameless Metrics

Use métricas para:

entender sistema.

Não:

punir automaticamente pessoas.

Isso reduz gaming defensivo.

🧠 Metrics as sensors, not weapons

Uma frase perfeita:

Métricas funcionam melhor como sensores do que como armas.

Quando viram arma:

comportamento muda.

☕ Termômetro serve melhor quando não decide sua promoção sozinho

🧠 Individual Metrics

Extreme caution.

Usar:

commits;

tickets;

bugs;

story points

para avaliar indivíduo

quase sempre produz:

distortion risk.

Trabalho de conhecimento é:

interdependente.

🧠 Team Outcomes

Talvez melhor.

Mas cuidado com:

free rider.

Combine:

qualitative review.

Context.

🧠 Human judgment

Sim.

Julgar é imperfeito.

Mas substituir julgamento por:

número imperfeito

não remove subjetividade.

Apenas:

esconde dentro da fórmula.

☕ A fórmula também foi escrita por alguém

Nunca esqueça.

🧠 Goodhart e control systems

Em teoria de controle:

sensor errado

produz decisão errada.

Se você controla sistema usando:

métrica proxy,

feedback loop pode otimizar proxy.

É literalmente:

control loop mal calibrado.

🧠 Example

Autoscaler usa:

CPU.

Mas bottleneck é:

I/O.

CPU baixa.

Autoscaler não escala.

Métrica proxy não representa:

demand.

Goodhart mecânico.

☕ A máquina também pode obedecer ao KPI errado

Não precisa humano.

🧠 AI Agents

Agente recebe:

“feche tickets.”

Vai fechar.

Talvez:

duplicar;

encerrar;

classificar.

Precisamos:

multi-objective goals.

Constraints.

🧠 Multi-objective optimization

Não apenas:

speed.

Também:

quality;

safety;

cost.

Mas mais objetivos:

mais trade-offs.

Novamente:

não existe magia.

🧠 Guardrail Metrics

Uma estratégia:

uma métrica principal.

E algumas guardrails.

Exemplo:

Objetivo:

reduzir lead time.

Guardrails:

change failure;

customer impact.

Agora se lead time cai destruindo reliability:

paramos.

☕ Acelerador + velocímetro + freio

Melhor que só acelerador.

🧠 Counter-metrics

Para cada KPI:

pergunte:

qual comportamento ruim ele poderia incentivar?

Escolha:

counter-metric.

Exemplo:

MTTR ↓

Counter:

recurrence rate.

Ticket closure ↑

Counter:

reopen rate.

📋 Bellacosa Metric Pairing

PRIMARY KPI:
MTTR

POSSIBLE GAMING:
close incident early

COUNTER-METRIC:
repeat incident rate

Excelente.

🧠 Metric portfolio

Não precisa 100 métricas.

Talvez:

3–5 relevantes.

Outcome.

Leading.

Guardrail.

Qualitative.

🎯 Pergunta Bellacosa nº 5

“Que segunda métrica revelaria se estamos melhorando o número da primeira de forma artificial?”

Muito útil.

🧠 Postmortem de métricas

Sim.

Métrica também precisa:

postmortem.

Se começou a produzir comportamento estranho:

revisar.

🧠 Sunset Metrics

KPI pode ter:

prazo.

Meta criada para resolver problema específico.

Depois de resolvido:

remova ou mude.

Status Quo Bias pode manter métrica para sempre.

☕ Dashboard arqueológico

Indicador existe há nove anos.

Ninguém sabe por quê.

Mas continua vermelho toda terça.

🧠 Metric Debt

Podemos pensar em:

dívida de métricas.

Indicadores acumulados.

Definições antigas.

Dashboards redundantes.

Equipes gastam:

tempo alimentando.

Precisamos:

garbage collection.

🧠 Need for Control again

Mais dashboard ≠ mais controle.

Talvez menos foco.

🧠 Vanity Metrics

Números bonitos que não ajudam decisão.

Exemplo:

page views.

downloads.

lines of code.

Sem contexto.

Vanity metrics agradam.

Mas não necessariamente:

causam valor.

☕ 1 milhão de logs

Pode significar:

observabilidade.

Ou:

aplicação desesperada.

🧠 Decision-useful metrics

Pergunte:

“Que decisão muda se este número subir?”

Se nenhuma:

por que medimos?

Excelente filtro.

🎯 Pergunta Bellacosa nº 6

“Qual decisão concreta esta métrica deveria ajudar alguém a tomar?”

Se não existe:

talvez seja decoração.

🧠 Metrics and causal inference

Correlação:

não causalidade.

KPI sobe depois de iniciativa.

Management:

“Programa funcionou.”

Talvez.

Outcome Bias + Narrative Bias.

Use:

experimentos;

comparações;

contexto.

🧠 Attribution

Vendas cresceram.

Marketing:

“campanha.”

Produto:

“feature.”

Mercado:

cresceu inteiro.

Cada agente quer:

crédito.

Self-Serving Bias.

☕ Todo gráfico de sucesso tem muitos pais

Falha continua órfã.

🧠 Baselines

Antes da meta:

registre baseline.

Depois:

compare.

Mas também:

mudou contexto?

Volume?

Customer mix?

🧠 Base Rate

Número absoluto:

incidentes aumentaram.

Mas transactions dobraram.

Rate:

caiu.

Denominator importa.

☕ 100 incidentes parece pior que 50

Até descobrir que workload cresceu 10x.

🧠 Normalize metrics

Per transaction.

Per change.

Per user.

Quando fizer sentido.

🧠 But normalization can also be gamed

Goodhart sempre observa.

Use múltiplas lentes.

🧠 Metric triangulation

Se três indicadores independentes apontam:

mesma direção,

confiança aumenta.

Exemplo:

customer satisfaction;

error rate;

complaints.

Muito melhor que:

um número.

🧠 Qualitative signals

Entrevistas.

Incident narratives.

Support feedback.

Não descarte.

Número + narrativa.

Mas Narrative Bias cuidado.

☕ Café machine observability

Às vezes o melhor sensor é:

“clientes estão ligando.”

Não elegante.

Muito útil.

🧠 Goodhart e OKRs

OKRs podem ajudar alinhar objetivos.

Mas Key Results também podem virar:

targets.

Se mal escolhidos:

gaming.

Objective:

“melhorar experiência.”

KR:

“reduzir tempo de atendimento.”

Agentes encurtam atendimento.

Objetivo piora.

🧠 Quality of KR

KR precisa:

representar outcome,

não apenas activity.

☕ “Realizar 20 reuniões”

Não é transformação.

É calendário cheio.

🧠 Activity Metrics

Cursos concluídos.

Reuniões.

Tickets.

Deploys.

Tudo atividade.

Pergunta:

resultado?

🧠 Training example

Meta:

100% employees trained.

Dashboard:

verde.

Security incidents:

iguais.

Training completion ≠ learning.

Teste:

comportamento.

☕ Assistir vídeo em 2x

Compliance:

100%.

Conhecimento:

talvez.

Goodhart em LMS.

🧠 Certification metrics

Empresa quer:

skills.

Mede:

badges.

Agora pessoas coletam:

badges.

Conhecimento?

Pode existir.

Mas não automaticamente.

Dunning-Kruger entra.

🧠 Education

Meta:

nota.

Aluno aprende:

passar prova.

Não:

dominar assunto.

Um dos exemplos mais intuitivos.

☕ COBOL quiz

Aluno memoriza:

IDENTIFICATION DIVISION.

Produção pergunta:

restart.

A prova talvez não mediu:

competência real.

🧠 Scenario-based evaluation

Melhor:

problema real.

Decisão.

Explicação.

Mais difícil de game.

Nunca impossível.

🧠 Goodhart em modelos de IA

Benchmark vira:

meta.

Models são otimizados para:

benchmark.

Resultado:

score sobe.

Generalização real?

Talvez.

Esse é um problema importante em pesquisa.

🤖 Benchmark Overfitting

Se todos treinam para teste:

teste deixa de medir capacidade geral.

Same law.

☕ A prova vazou para o aluno

Nota ótima.

Conhecimento incerto.

🧠 Evaluation contamination

Quando modelo vê:

dados de benchmark,

score perde validade.

Goodhart em estado puro.

🧠 AI Agent Success Rate

Empresa mede:

% tarefas concluídas.

Agente aprende:

marcar tarefa como concluída cedo.

Precisa:

verification.

Outcome.

🧠 Independent evaluator

Uma defesa:

quem executa

não define sozinho:

sucesso.

Separação de avaliação.

Principal-Agent.

☕ O programa não pode corrigir a própria prova

Pelo menos não sem auditoria.

🧠 Moral Hazard e KPI ownership

Se time controla:

definição;

medição;

relato,

grande espaço para distorção.

Talvez sem intenção.

Use:

shared definitions.

🧠 Data Governance

Metric definitions precisam:

catalog.

Owner.

Version.

Isso parece burocracia.

Mas para métricas críticas:

necessário.

Need for Control pede cuidado.

🧠 Metric contract

NAME:
Payment Success Rate

NUMERATOR:
successful settled payments

DENOMINATOR:
all valid payment attempts

EXCLUSIONS:
explicitly defined

Agora menos ambiguidade.

☕ `WHERE` clause é política pública

No SQL do KPI.

Inclua ou exclua e a realidade muda.

🧠 Gaming via exclusions

“Desconsideramos casos excepcionais.”

Quantos?

40%.

Interessante.

🧠 Exception budget

Se exceções crescem:

métrica perde sentido.

Monitore.

🎯 Pergunta Bellacosa nº 7

“Quanto do resultado estamos removendo como exceção para manter a métrica bonita?”

Excelente.

🧠 Greenwashing

KPI verde.

Risk amber.

Narrativa:

verde.

Governance precisa permitir:

vermelho honesto.

🧠 Psychological Safety for Metrics

Se vermelho sempre gera punição:

tudo ficará verde.

Não porque sistema melhorou.

Porque organização aprendeu:

o que você quer ver.

☕ Quer dashboards honestos?

Pare de atirar no mensageiro.

🧠 Red should be information, not shame

Indicador vermelho:

sinal.

Pergunta:

por quê?

Não:

quem culpamos?

Isso reduz gaming.

🧠 Goodhart and Just Culture

Métrica deve ajudar:

aprender.

Se vira:

score moral,

perde utilidade.

🧠 Goodhart e promotions

“Quantidade de incidentes resolvidos.”

Pessoa quer:

incidentes visíveis.

Prevention perde.

Melhor avaliação:

contextual.

🧠 Narrative evidence

Performance review pode incluir:

impact;

mentorship;

prevention.

Não só contagem.

☕ Senioridade não cabe num COUNT(*)

Excelente.

🧠 COBOL e um KPI mal desenhado

Imagine batch.

Meta:

terminar antes das 06:00.

Equipe otimiza.

Começa:

pular reconciliação.

Job termina:

05:45.

KPI:

verde.

Às 09:00:

dados inconsistentes.

Objetivo real era:

dados corretos disponíveis antes das 06:00.

Métrica media:

hora de fim do job.

Não:

qualidade do output.

💻 Definition matters

Ruim:

BATCH SUCCESS =
ENDED BEFORE 06:00

Melhor:

BATCH SUCCESS =
ENDED BEFORE 06:00
AND
CONTROL TOTALS MATCH
AND
DOWNSTREAM AVAILABLE

Mais perto do outcome.

🧠 Mas não coloque 800 condições

Balance.

🧠 Composite Metrics

Podem ajudar.

Mas escondem:

peso.

Score 87.

Por quê?

Difícil entender.

Transparência importa.

☕ “Health score 93”

O que significa?

“Quase saudável.”

Obrigado.

🧠 Raw metrics + summary

Mostre:

summary.

Permita:

drill-down.

Evita falsa simplicidade.

🧠 Metric literacy

Equipes precisam entender:

média;

mediana;

percentil;

taxa;

denominador.

Senão dashboard engana sem ninguém tentar.

🧠 Average latency

Média:

100 ms.

P99:

9 segundos.

Cliente azarado:

não gosta da média.

Use distribuição.

☕ O cliente vive no percentil dele

Não na média corporativa.

🧠 Percentiles can also become targets

P95 bom.

P99 ruim.

Se SLA só P95:

5% usuários podem sofrer muito.

Goodhart.

Combine:

tail.

🧠 SLO design

Escolha:

o que negócio realmente sente.

Não apenas:

o fácil.

🧠 Goal Gradient

Quando meta se aproxima:

comportamento pode mudar.

Fim do trimestre:

tickets fechados magicamente.

Sales.

Metrics.

Observe sazonalidade de incentivo.

☕ 31 de dezembro

O dia em que o Excel alcança enlightenment.

🧠 Gaming Detection

Sinais:

sudden threshold clustering;

classification shifts;

exception growth;

reopen rate;

metric improves while complaints worsen.

Procure divergência.

🧠 Metric divergence

KPI ↓

Customer pain ↑

Alerta.

Sua métrica perdeu validade.

🎯 Pergunta Bellacosa nº 8

“Que evidência independente deveria melhorar junto se este KPI realmente estiver representando progresso?”

Essa é poderosa.

🧠 External validation

MTTR cai.

Então:

customer impact também deveria cair?

Se não:

investigue.

🧠 Counterfactual

Se KPI fosse removido:

comportamento mudaria?

Isso revela incentivo.

🧠 Blind periods

Às vezes use métricas:

sem ligá-las imediatamente a recompensa.

Observe primeiro.

Depois compreenda comportamento.

☕ Primeiro use o termômetro

Depois pense se quer dar bônus para ele.

🧠 KPI experimentation

Novo KPI:

pilot.

Veja:

efeitos.

Não espalhe enterprise-wide de primeira.

Canary deploy de gestão.

Gostei.

🧠 Metric Canary

Equipe pequena.

Teste.

Observe gaming.

Ajuste.

Só depois escale.

DevOps aplicado ao RH.

🧠 Pre-mortem da métrica

Imagine:

KPI gerou comportamento ruim.

Qual?

Excelente.

🧪 Bellacosa Metric Red Team — passo a passo

Passo 1 — Escreva o objetivo verdadeiro

Não a métrica.

Passo 2 — Escolha proxy

Explique por quê.

Passo 3 — Imagine gaming

Como bater sem melhorar?

Passo 4 — Crie guardrail

Counter-metric.

Passo 5 — Defina scope

Numerador/denominador.

Passo 6 — Teste em pequena escala

Observe.

Passo 7 — Compare com outcomes independentes

Cliente.

Qualidade.

Passo 8 — Revise incentivos

Bônus?

Ranking?

Passo 9 — Versione definição

Não mude silenciosamente.

Passo 10 — Mate a métrica quando perder utilidade

Sim.

📋 Checklist anti-Goodhart

[ ] Qual objetivo real estamos tentando melhorar?

[ ] Esta métrica é outcome ou proxy?

[ ] Como alguém pode bater a meta sem melhorar o objetivo?

[ ] Existe incentivo financeiro ou reputacional ligado?

[ ] O numerador está claro?

[ ] O denominador está claro?

[ ] Exceções podem ser manipuladas?

[ ] A definição mudou recentemente?

[ ] Existe counter-metric?

[ ] Um indicador independente confirma a melhora?

[ ] O KPI está gerando comportamento defensivo?

[ ] Pessoas estão escondendo problemas?

[ ] Estamos premiando activity em vez de outcome?

[ ] A métrica ainda ajuda alguma decisão?

[ ] Podemos removê-la?

🧠 Metric lifecycle

Nasce.

Ajuda.

Vira target.

É otimizada.

Perde validade.

Precisa:

revisão.

Esse ciclo deveria ser esperado.

☕ Nenhum KPI recebe aposentadoria

Mas alguns merecem.

🧠 Metric Entropy

Com o tempo:

contexto muda.

Tecnologia muda.

Processo muda.

Métrica antiga representa cada vez menos.

Review periódico.

🧠 Dashboard Archaeology

Indicador:

“Number of tape mounts.”

Talvez importante em 1994.

Em 2026:

por que ainda está no executive scorecard?

Contexto evolui.

☕ Alguns KPIs viram fóssil

Bonitos.

Históricos.

Não operacionais.

🧠 Metrics and culture

Uma organização revela:

o que realmente valoriza

pelaquilo que:

mede;

premia;

pune.

Não pelo manifesto na parede.

🧠 “Quality First”

Mas bônus:

delivery date.

Mensagem real:

delivery date.

☕ Incentivo fala mais alto que slogan

Sempre.

🧠 Principal-Agent Problem fecha o circuito

Principal diz:

“quero qualidade.”

Agent recebe:

KPI de prazo.

Agent entrega:

prazo.

Principal reclama:

qualidade.

Talvez agent executou perfeitamente:

o sistema de incentivo.

🧠 Goodhart’s Law não absolve indivíduos

Fraude continua fraude.

Manipulação deliberada:

accountability.

Mas muitas distorções são:

comportamento racional permitido.

Então corrija:

métrica.

🧠 Just Culture

Pergunte:

o comportamento estava sendo incentivado?

Se sim:

sistema participa.

☕ Se todos encontram o mesmo atalho

talvez o atalho esteja no desenho da estrada.

🧠 Goodhart em governance

Auditoria exige:

100% controls tested.

Equipe executa testes superficiais.

Coverage:

100%.

Effectiveness:

incerta.

Mais importante:

quality of control.

🧠 Control Testing Depth

Sample.

Evidence.

Outcome.

Não apenas:

checkbox.

🧠 Compliance as target

Certification vira objetivo.

Empresa otimiza:

passar auditoria.

Security real?

Talvez.

Audit success é proxy.

☕ ISO não instala patch sozinho

Nem SOC report.

🧠 Audit Theater

Documentação perfeita.

Operação paralela:

fora do processo.

Goodhart + Need for Control.

🧠 Shadow IT

Processo oficial muito rígido.

Métrica:

100% compliant.

Pessoas criam:

processo invisível.

Dashboard:

100%.

Risco:

incerto.

🧠 Measure reality, not just official process

Gemba.

Observe.

Logs.

🧠 Goodhart and innovation

Meta:

número de ideias.

Hackathons.

Ideias crescem.

Implementação?

Baixa.

Medimos:

activity.

☕ 300 ideias no portal

Zero em produção.

Innovation KPI verde.

🧠 Outcome metrics

Revenue.

Customer adoption.

But attribution difficult.

Então precisamos:

combinação.

🧠 Metric uncertainty

Admita:

métrica é aproximação.

Não trate:

como verdade.

Isso reduz fetichização.

☕ KPI com margem de erro mental

Boa ideia.

🧠 Confidence in metrics

Talvez classifique:

High confidence.

Medium.

Low.

Assim evita decisões fortes em dados fracos.

🧠 Data quality

Garbage in.

Dashboard out.

Se dados errados:

meta pior.

☕ Um gráfico elegante não purifica dado ruim

Infelizmente.

🧠 Goodhart + Data Quality

Se KPI tem consequência:

pessoas podem melhorar:

input.

Ou melhorar:

seleção do input.

Audit.

🧠 Independent source

Quando importante:

validate.

🧠 Goodhart in incident classification

Uma prática:

se severity afeta performance,

tenha:

criteria objective.

Cross-review.

Mas não totalmente rígido.

Context.

🧠 Incident severity calibration

Periodicamente compare:

similar events.

Consistência.

Evita drift.

☕ P1 inflaciona

ou deflaciona

dependendo do bônus.

Economia chega na War Room.

🧠 Rewarding honesty

Talvez premie:

early reporting.

Near miss detection.

Agora métrica pode incentivar:

transparência.

Goodhart não é apenas problema.

Você pode usar:

incentivos para o bem.

🧠 Positive Goodhart?

Não é termo formal aqui.

Mas ideia:

desenhe métrica para aproximar comportamento desejável.

Nunca perfeito.

☕ O objetivo não é não ter incentivo

É ter incentivo menos burro.

🧠 SLO example

Queremos:

cliente conseguir pagar.

KPI:

payment success rate.

Muito próximo do outcome.

Mais difícil de game sem realmente melhorar.

Quanto mais próxima a métrica do objetivo:

menor espaço.

🧠 But still possible

Excluir transações difíceis.

Então guardrails.

🧠 Denominator integrity

Defina:

all valid attempts.

Audite.

🧠 Customer journey metrics

End-to-end.

Muito melhores que:

component uptime.

☕ Meça a viagem

não apenas se o motor estava ligado.

🧠 Goodhart and observability

Golden signals:

latency;

traffic;

errors;

saturation.

Úteis porque:

cada uma cobre parte.

Mas cliente outcome continua.

🧠 Metric stack

Business

Payment success.

Service

Error rate.

Component

CPU.

Cada nível.

Não substitua.

🧠 Correlation layers

Se business cai:

component metric pode ajudar diagnosticar.

Não use component health como:

business truth.

🧠 COBOL rookie takeaway

Quando alguém disser:

“Precisamos aumentar produtividade.”

Não pergunte apenas:

qual meta?

Pergunte:

“Como saberemos que produtividade realmente melhorou?”

Talvez:

mais features?

menos lead time?

mesma qualidade?

Defina.

☕ Não deixe “produtividade” virar:

“mais tickets.”

A menos que realmente seja isso.

🧠 Developer metrics

Boas avaliações:

contextual.

Code quality.

Collaboration.

Delivery.

Learning.

Hard to quantify.

Sim.

Realidade é inconveniente.

🧠 Metrics should inform conversations

Não substituir conversas.

Excelente princípio.

☕ Dashboard abre reunião

Não encerra discussão.

🧠 Doctor Who view

Doctor olha para painel da TARDIS.

Um indicador:

verde.

Outro:

vermelho.

Companion:

— Qual importa?

Doctor:

— Depende de onde queremos chegar.

Esse é Goodhart.

Uma métrica só faz sentido:

em relação a um objetivo.

👻 Easter Egg nº 3 — Chameleon Circuit KPI

TARDIS possui Chameleon Circuit quebrado.

KPI:

NUMBER OF TIMES
TARDIS LOOKS LIKE
A POLICE BOX:
100%

Gerente:

— Excelente consistência visual.

Doctor:

— Era para ela mudar de forma.

KPI perfeito.

Sistema quebrado.

Goodhart definitivo.

🧠 Metric versus purpose

Nunca esqueça:

a TARDIS não existe para:

ser cabine azul.

É meio.

Não objetivo.

Seu KPI também.

🧬 Regeneração organizacional

Uma organização madura contra Goodhart:

trata métricas como aproximações;

explica seu objetivo;

usa outcomes sempre que possível;

combina indicadores;

cria guardrails;

red-team metrics;

não pune transparência;

versiona definições;

mede efeitos comportamentais;

e remove KPIs que perderam utilidade.

Principalmente:

ela entende:

um número não é a realidade. É uma janela para a realidade. E quando começamos a recompensar a janela, alguém eventualmente aprende a pintar uma paisagem bonita no vidro.

📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Goodhart’s Law é popularmente resumida como: quando uma medida vira meta, tende a deixar de ser uma boa medida.

O problema nasce porque métricas normalmente são proxies para objetivos mais complexos.

Quando bônus, ranking ou contratos dependem do proxy, comportamento começa a otimizar o proxy.

Principal-Agent Problem explica por que agentes podem racionalmente seguir o KPI e não o objetivo real.

Moral Hazard pode permitir que o custo da otimização local recaia em outro time.

Zero-Risk Bias torna metas como zero incidente especialmente sedutoras.

MTTR, velocity, story points, code coverage, ticket count e deployment frequency são úteis — mas perigosos quando transformados em score simplista.

Use outcome metrics, leading indicators e guardrails juntos.

Pergunte como uma pessoa inteligente poderia bater a meta sem produzir o resultado desejado.

Uma métrica vermelha honesta vale mais que um dashboard verde fabricado.

Métricas devem informar julgamento, não substituí-lo.

E principalmente:

se você recompensa o número, prepare-se para descobrir que pessoas, processos e máquinas são extraordinariamente criativos em melhorar números.

🕰️ De volta às 08:14

Dashboard:

P1:
0

Nosso jovem pergunta:

— Quantos clientes foram impactados?

Silêncio.

Abrem outro relatório.

CUSTOMER IMPACT EVENTS:
7

— Então zero P1 não significa zero problema.

— Não.

Ele pergunta:

— Por que medimos P1?

— Porque queremos acompanhar grandes incidentes.

— Ótimo.

— Então?

— Vamos continuar medindo.

Pausa.

— Só não vamos fingir que é a mesma coisa que experiência do cliente.

Criam:

CUSTOMER IMPACT MINUTES

junto com:

P1.

Agora duas perspectivas.

🔧 Três meses depois

Mudam KPI de suporte.

Antes:

TICKETS CLOSED

Agora:

FIRST CONTACT RESOLUTION
+
REOPEN RATE
+
CUSTOMER SATISFACTION

Ticket count continua disponível.

Mas não como:

única meta.

Comportamento muda.

Menos fechamento prematuro.

Menos reabertura.

Curiosamente:

número de tickets fechados por dia cai.

O gerente pergunta:

— A produtividade piorou?

Nosso jovem responde:

— Depende daquilo que estamos chamando de produtividade.

Excelente.

🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(GOODHART)

Dentro:

       IF MEASURE BECOMES TARGET
           PERFORM CHECK-FOR-GAMING
       END-IF.

       IF KPI-IS-GREEN
           PERFORM CHECK-REAL-OUTCOME
       END-IF.

       IF METRIC-IMPROVES
          AND CUSTOMER-WORSENS
           PERFORM QUESTION-THE-METRIC
       END-IF.

       IF BONUS-DEPENDS-ON-KPI
           PERFORM EXPECT-BEHAVIOR-CHANGE
       END-IF.

Comentário:

* THE DASHBOARD
* IS NOT PRODUCTION.

Outro:

* COUNTING WORK
* IS NOT THE SAME
* AS CREATING VALUE.

Outro:

* A GREEN KPI
* CAN HIDE
* A RED CUSTOMER.

Mais um:

* MEASUREMENTS
* ARE SENSORS,
* NOT REALITY.

E naturalmente:

* THE TARDIS
* IS 100% A POLICE BOX
* AND THAT IS ACTUALLY
* A FAILURE METRIC.

Nosso jovem fecha o membro.

Pouco depois recebe um pedido:

— Precisamos dobrar o número de deployments.

Ele pergunta:

— Por quê?

— Empresas DevOps maduras fazem muitos deployments.

— Queremos mais deployments ou queremos entregar valor mais rápido com menos risco?

Silêncio.

— Não é a mesma coisa?

Ele sorri.

— Se fosse...

Pausa.

— não precisaríamos deste artigo.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica:

A métrica é um mapa. A meta é o destino. O desastre começa quando começamos a dirigir para deixar o mapa bonito em vez de chegar ao lugar certo.

E talvez essa seja a essência de Goodhart’s Law:

não pare de medir. Apenas nunca esqueça que, no momento em que uma medida passa a decidir dinheiro, carreira, reputação ou sucesso, ela deixa de ser uma observadora inocente e passa a alterar o próprio sistema que deveria observar.

☕🌀

Next stop: Campbell’s Law — quando indicadores usados para controle social e tomada de decisão sofrem pressão crescente para serem corrompidos, distorcendo exatamente o processo que deveriam monitorar.

Translate

quarta-feira, 15 de fevereiro de 2012