 |
| 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.
VWORP.
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.
B:
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:
Y.
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.
B:
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.
VWORP.
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.
