☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

terça-feira, 13 de março de 2012

Narrative Bias: Doctor Who, COBOL e o Dia em que uma Boa História Quase Virou Root Cause

Bellacosa Mainframe apresenta a narrative bias

☕ Um Café no Bellacosa Mainframe

Narrative Bias: Doctor Who, COBOL e o Dia em que uma Boa História Quase Virou Root Cause

Uma viagem pela TARDIS dos incidentes para entender por que narrativas coerentes parecem mais verdadeiras do que explicações fragmentadas — e como isso pode transformar coincidência em causa dentro de uma War Room

08:26.

Terça-feira.

War Room.

Café já na segunda rodada.

Na tela:

08:00 DEPLOY
08:07 LATENCY ↑
08:12 TIMEOUTS ↑
08:15 CUSTOMER COMPLAINTS

O gerente olha.

— Está claro.

Nosso jovem programador COBOL pergunta:

— O quê?

— O deploy causou o incidente.

Silêncio.

A timeline parece perfeita.

Mudança.

Depois lentidão.

Depois timeout.

Depois cliente.

Começo.

Meio.

Fim.

Bonito.

Quase cinematográfico.

O especialista concorda:

— Faz sentido.

Outro:

— Deve ter sido a nova rotina.

O programador pergunta:

— Já encontramos evidência?

— A evidência está aí.

Apontam para:

08:00 DEPLOY
08:07 LATENCY

Nosso jovem olha de novo.

— Isso mostra sequência.

— Exatamente.

— Mas mostra causa?

Silêncio.

Um DBA abre as métricas.

Db2 normal.

MQ normal.

CPU normal.

A nova rotina é executada apenas em 4% das transações.

Mas 82% dos timeouts aparecem em um fluxo que nem passa pelo código alterado.

A história começa a ficar menos elegante.

Então surge outro dado:

07:54
EXTERNAL API LATENCY ↑

Seis minutos antes do deploy.

O gerente observa.

— Então talvez não tenha sido a mudança.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se ao lado do flip chart.

A porta abre.

O Doctor sai.

Olha para a timeline.

Depois para a equipe.

— Qual era a história?

O gerente responde:

— Deploy causou lentidão.

— Era uma boa história?

— Muito boa.

— Tinha começo?

— Sim.

— Meio?

— Sim.

— Final?

— Sim.

O Doctor sorri.

— Então naturalmente vocês quase acreditaram nela.

Pausa.

— O cérebro humano adora histórias bem mais do que adora logs.

Bem-vindo ao:



Narrative Bias

Ou:

Viés Narrativo

A tendência de organizar fatos, eventos e dados em histórias coerentes e, depois, atribuir a essas histórias mais verdade, causalidade e previsibilidade do que as evidências realmente permitem.

Em linguagem Bellacosa:

“Se a história faz sentido, começamos a achar que ela aconteceu exatamente assim.”


🌀 Onde estamos na nossa TARDIS dos incidentes?

Nossa jornada já encontrou uma longa coleção de criaturas cognitivas:

Swiss Cheese Model mostrou que várias defesas podem falhar juntas.

Normalization of Deviance mostrou como desvios viram rotina.

Hindsight Bias mostrou como tudo parece óbvio depois do final.

Confirmation Bias mostrou como buscamos provas para aquilo em que acreditamos.

Anchoring Bias mostrou como a primeira informação prende a investigação.

Groupthink mostrou como consenso pode aparecer cedo demais.

Authority Gradient mostrou como hierarquia pode silenciar dúvida.

Plan Continuation Bias mostrou como continuamos planos que já perderam sentido.

Alarm Fatigue mostrou como alertas demais viram ruído.

Automation Bias mostrou como confiamos demais em ferramentas.

Drift Into Failure mostrou como sistemas derivam lentamente para a borda.

Diffusion of Responsibility mostrou como todos podem ver e ninguém agir.

Normalcy Bias mostrou como esperamos que tudo volte ao normal.

Survivorship Bias mostrou como estudamos apenas os sobreviventes.

Base Rate Neglect mostrou como esquecemos frequências reais.

Availability Heuristic mostrou como o memorável parece mais provável.

Outcome Bias mostrou como confundimos bom resultado com boa decisão.

Overconfidence Bias mostrou como confiança excessiva pode reduzir verificação.

Planning Fallacy mostrou como subestimamos tempo e complexidade.

Sunk Cost Fallacy mostrou como o passado prende o futuro.

Status Quo Bias mostrou como o atual recebe privilégio psicológico.

Present Bias mostrou como o agora pesa mais que o depois.

Optimism Bias mostrou como esperamos resultados favoráveis.

Action Bias mostrou como agir pode parecer melhor que observar.

Omission Bias mostrou como não agir pode parecer menos culpável.

Loss Aversion mostrou como perder dói mais que ganhar alegra.

Framing Effect mostrou como a moldura altera a decisão.

Recency Bias mostrou como o recente recebe peso exagerado.

Representativeness Heuristic mostrou como algo que “parece X” vira rapidamente “deve ser X”.

Agora pegamos todos esses ingredientes...

e colocamos dentro de uma história.


🧠 O que é Narrative Bias?

Seres humanos não gostam muito de eventos soltos.

Gostamos de:

causas;

motivos;

sequências;

personagens;

explicações.

Imagine:

A aconteceu.
Depois B.
Depois C.

Nosso cérebro rapidamente começa:

“A causou B, que causou C.”

Talvez.

Mas também pode ser:

X causou A.
X causou B.
X causou C.

Ou:

A foi irrelevante.
B e C vieram de X.

Ou simplesmente:

alguns eventos coincidiram no tempo.

Narrativa organiza.

Mas organização não é automaticamente causalidade.


☕ O programador e a timeline sedutora

Deploy:

08:00.

Falha:

08:07.

É natural pensar:

deploy causou falha.

E frequentemente causa mesmo.

Mudanças recentes merecem investigação.

Mas a timeline produz um poder narrativo enorme:

post hoc ergo propter hoc

“Depois disso, portanto por causa disso.”

É uma falácia clássica.

Sequência temporal é evidência.

Mas não prova suficiente.


🧠 Correlação temporal ≠ causalidade

Uma mudança acontece.

Logo depois, problema.

Perguntas:

  • o componente alterado participa do fluxo?

  • a falha aparece em transações não afetadas?

  • existe mecanismo plausível?

  • o problema já havia começado antes?

  • rollback altera comportamento?

  • existe mudança externa concomitante?

Sem isso:

temos história.

Não necessariamente RCA.


👻 Easter Egg nº 1 — “Foi a TARDIS”

A TARDIS materializa.

Cinco segundos depois, luzes piscam.

Companion:

— A TARDIS causou isso.

Doctor:

— Como sabe?

— Ela apareceu e depois as luzes começaram.

— Então se chover depois que você abrir um guarda-chuva...

Pausa.

— você controla o clima?

A narrativa precisa de mecanismo.


🧠 O cérebro odeia “não sabemos”

Essa talvez seja uma das raízes do problema.

“Não sabemos” é desconfortável.

Uma história preenche o vazio.

Exemplo:

“Foi a mudança.”

Pronto.

Ansiedade cai.

Agora temos culpado.

Plano.

Sentido.

Uma boa narrativa reduz incerteza psicológica.

Mesmo sem reduzir incerteza técnica.


☕ Bellacosa Mainframe: RCA de cinco minutos

Incidente abre às 08:10.

Às 08:15:

— Já sabemos a causa.

Isso pode acontecer.

Mas às vezes é apenas narrativa prematura.

O sistema complexo ainda nem terminou de produzir evidência.


🧠 Narrative Bias + Hindsight Bias

Depois do incidente:

eventos são reorganizados numa sequência limpa.

Antes:

caos.

Depois:

CHANGE
↓
ERROR
↓
ALERT
↓
OUTAGE
↓
FIX

Parece inevitável.

Hindsight Bias diz:

“Era óbvio.”

Narrative Bias diz:

“E aconteceu exatamente por essa cadeia.”

Talvez a realidade tivesse:

três causas concorrentes;

tentativas inúteis;

efeitos paralelos;

sorte.

A história pós-incidente tende a limpar bagunça.


🧠 Post-mortems precisam de cuidado

Post-mortem precisa contar história.

É impossível documentar sem narrativa.

Mas uma boa análise distingue:

Timeline factual

de:

interpretação causal.

Exemplo:

FACT:
08:00 deploy

FACT:
08:07 latency increased

HYPOTHESIS:
deploy contributed

EVIDENCE:
...

Muito melhor que:

08:00 deploy caused latency

quando ainda não foi demonstrado.


🔎 Narrative Bias + Confirmation Bias

Uma vez criada a história:

“deploy quebrou sistema”

começamos a buscar tudo que cabe nela.

Log novo?

— consequência do deploy.

Métrica anterior?

— provavelmente ruído.

API externa lenta?

— efeito indireto.

A narrativa começa a absorver fatos.

Confirmation Bias a protege.


⚓ Anchoring Bias

Primeira história apresentada:

“mudança causou.”

Agora tudo gira em torno dela.

Uma narrativa é uma âncora especialmente poderosa porque não é apenas uma informação.

É uma estrutura inteira.


👥 Groupthink

Gerente conta história convincente.

Equipe inteira entende.

Isso importa.

Histórias compartilhadas criam consenso rápido.

Um técnico que traz uma explicação feia:

“Talvez sejam três fatores independentes”

tem desvantagem.

A história simples vence.


🪜 Authority Gradient

Se a narrativa vem do especialista:

“Já sei exatamente o que aconteceu.”

o júnior pode abandonar dados contraditórios.

Narrative Bias + Authority Gradient transforma storytelling em causalidade oficial.


🧠 Representativeness Heuristic entra perfeitamente

O incidente:

tem cara de Db2.

Então criamos história:

“Db2 começou a segurar lock, fila aumentou e sistema caiu.”

Agora narrativa conecta o padrão.

Mesmo se os locks forem normais.

Representativeness escolhe personagem.

Narrative Bias escreve roteiro.


🧠 Recency Bias fornece roteiro recente

Sexta:

MQ.

Segunda:

latência.

História:

“MQ voltou.”

O incidente recente fornece estrutura narrativa pronta.

Não precisamos sequer inventar outra.


🧠 Availability fornece histórias memoráveis

Histórias dramáticas são fáceis de lembrar.

“Uma vez storage corrompeu tudo.”

Então novo sintoma estranho:

“Pode ser storage de novo.”

Narrative Bias adora histórias vivas.


🧠 Framing Effect decide quem é herói e vilão

Mesmo timeline pode ser contada de formas diferentes.

Frame A:

“Operador errou comando.”

Frame B:

“Sistema permitia comando crítico sem validação.”

Frame C:

“Equipe trabalhava sob pressão e runbook estava incorreto.”

Todos descrevem partes reais.

Mas cada história produz ações diferentes.


☕ O vilão conveniente

Narrativas gostam de personagens.

Em post-mortem:

o operador;

o fornecedor;

o deploy;

o DBA;

o “legacy”.

Um vilão deixa história simples.

Mas sistemas críticos frequentemente falham por interações.

O Swiss Cheese Model não gosta de vilões únicos.


🧀 Swiss Cheese versus Narrative Bias

Narrative Bias quer:

“A causa.”

Swiss Cheese pergunta:

“Quais condições e barreiras se alinharam?”

Essa diferença é enorme.

Exemplo:

não foi apenas:

desenvolvedor cometeu erro.

Pode haver:

teste ausente;

review incompleto;

deadline;

monitoramento fraco;

rollback ruim;

permissão excessiva.

Uma história mono-causal pode destruir aprendizado.


🌀 Drift Into Failure também é péssimo para narrativas simples

Drift não tem um vilão.

Não tem momento épico.

Só:

pequenas decisões razoáveis.

Por isso é difícil contar.

Depois do acidente, inventamos:

“Tudo começou quando Fulano mudou X.”

Talvez não.

Talvez a organização estivesse derivando há anos.


🧠 Histórias adoram pontos de início

Sistemas complexos não necessariamente têm.

Quando começou o incidente?

08:07?

Ou:

quando margem caiu há seis meses?

Ou:

quando workaround virou processo há três anos?

Narrativa escolhe início.

A escolha influencia causalidade.


🎯 Pergunta Bellacosa nº 1

Quando alguém contar a história do incidente:

“Por que começamos a timeline justamente aqui?”

Excelente.

Talvez o problema tenha começado antes.


🎯 Pergunta Bellacosa nº 2

“Quais fatos não cabem confortavelmente nessa história?”

Esses fatos são especialmente valiosos.


🎯 Pergunta Bellacosa nº 3

“Que outra narrativa explica os mesmos dados?”

Agora criamos competição.


🎯 Pergunta Bellacosa nº 4

“Que mecanismo liga A a B?”

Não basta:

A veio antes.


🧠 Coherence ≠ truth

Uma história pode ser:

coerente;

elegante;

memorável;

errada.

Enquanto a explicação verdadeira pode ser:

feia;

fragmentada;

sem clímax.

Produção não precisa de literatura.

Precisa da explicação que melhor suporta os dados.


☕ Embora literatura ajude no blog

Claro.

Aqui podemos usar TARDIS.

Na War Room:

logs primeiro.

Daleks depois.


🧠 Narrative Bias na segurança

Incidente:

login estranho;

dados exportados;

conta privilegiada.

Narrativa:

“Atacante externo comprometeu credencial.”

Talvez.

Outra:

funcionário legítimo;

automação;

erro de integração.

A narrativa de ataque é emocionalmente forte.

Threat investigation precisa confirmar.


🔐 Attribution Bias

Em cyber, atribuir ataque a grupo ou país cedo demais é um perigo enorme.

Porque padrões podem ser copiados.

Ferramentas reutilizadas.

Infra compartilhada.

Narrativa geopolítica pode surgir antes da evidência.


🧠 Narrative Bias + Representativeness

Malware parece com APT X.

Então:

“É APT X.”

Depois história cresce:

motivo;

objetivo;

país.

Uma cadeia enorme construída sobre similaridade inicial.

Cuidado.


🏦 Fraude financeira

Cliente faz cinco transações incomuns.

Narrativa:

“Conta tomada.”

Mas talvez:

viagem;

mudança de aparelho;

compra legítima.

Fraude detection precisa dados.

Não novela.


🧠 Base Rate Neglect

História específica e rica pode vencer estatística.

“Esse comportamento parece exatamente um ataque sofisticado.”

Taxa-base:

ataques sofisticados são raríssimos.

A narrativa específica parece mais verdadeira porque é detalhada.

Base rate desaparece.


📚 A força dos detalhes

Quanto mais detalhes plausíveis uma história possui, mais convincente ela pode parecer.

Mas adicionar detalhes não aumenta necessariamente probabilidade.

Às vezes diminui.

Mais afirmações precisam ser verdadeiras.


🧠 Linda Problem novamente

A famosa questão da Linda é um belo exemplo de como uma descrição narrativa rica pode fazer uma opção mais específica parecer mais provável que uma categoria mais ampla.

Isso se conecta à Representativeness Heuristic e à Conjunction Fallacy.

Nosso cérebro prefere:

história que encaixa

à:

probabilidade abstrata.


☕ Conjunction Fallacy no mainframe

Imagine:

Opção A:

“O timeout é causado por problema de aplicação.”

Opção B:

“O timeout é causado por aplicação após deploy, combinado com retry MQ e lock Db2.”

B parece muito mais sofisticada.

Talvez até mais convincente.

Mas exige várias condições simultâneas.

Não deveria automaticamente ser mais provável.

Detalhe não é probabilidade.


🧠 Narrative complexity

Quanto mais rica a história:

mais pontos possíveis de falha.

Mas psicologicamente:

mais real.

Isso é fascinante.


💻 COBOL e o bug com roteiro perfeito

Programa começou a falhar depois de novo copybook.

História:

copybook mudou offset, corrompeu campo packed e causou S0C7.

Linda.

Você verifica dump.

Campo que abendou nem pertence ao copybook alterado.

A história morreu.

Ótimo.

Mate narrativas cedo quando dados discordam.


🧠 Apegamo-nos à narrativa porque investimos nela

Agora Sunk Cost aparece.

Equipe gastou duas horas construindo explicação.

Novos dados contradizem.

Abandonar significa:

admitir que tempo foi perdido.

Então tentamos salvar história.

Sunk Cost + Narrative Bias.


▶️ Plan Continuation Bias

A investigação possui plano:

“Vamos provar que foi Db2.”

Já começou.

Agora continua.

Mesmo quando evidência piora.

A narrativa dá direção ao plano.


🧠 Overconfidence Bias

Especialista conta história fluida.

Fluência parece domínio.

Quanto mais facilmente explica:

mais confiança os outros sentem.

Mas eloquência não mede causalidade.


🤖 IA e Narrative Bias

Aqui o tema fica especialmente importante.

Modelos de linguagem são muito bons em construir narrativas coerentes.

Você fornece:

cinco logs incompletos.

Pergunta:

“O que aconteceu?”

A IA pode construir uma sequência plausível.

Talvez esteja certa.

Talvez esteja preenchendo lacunas.

Usuário pode confundir:

coerência textual

com:

evidência operacional.

Automation Bias amplifica.


🧠 Fluent answer ≠ verified answer

Uma resposta pode ser:

bonita;

organizada;

confiante;

errada.

Por isso, em RCA assistida por IA:

exija:

fatos;

fontes;

nível de confiança;

alternativas;

lacunas.


☕ Prompt perigoso

“Explique como o deploy causou o incidente.”

Esse prompt já colocou causa no frame.

A IA provavelmente ajuda a construir narrativa.

Melhor:

“Avalie se existe evidência de que o deploy contribuiu e liste explicações alternativas.”

Framing + Narrative Bias.


🧠 AI hallucination e narrative completion

Quando dados faltam, um modelo pode completar padrões plausíveis.

Humano faz algo parecido.

Narrative Bias é quase nossa “alucinação explicativa” natural.

Diferença:

precisamos marcar o que é:

fato;

inferência;

hipótese.


📋 Fato, inferência, hipótese

Uma estrutura excelente:

FACT:
API latency increased at 07:54.

INFERENCE:
This could explain application waits.

HYPOTHESIS:
External API degradation contributed to outage.

Não misture.


🧠 Epistemic tagging

Rotule afirmações.

Fato confirmado.

Provável.

Possível.

Desconhecido.

Isso reduz história endurecendo cedo demais.


☕ O “sabemos” corporativo

War Room:

— Sabemos que foi rede.

Pergunta:

— Sabemos ou suspeitamos?

Essa distinção deveria virar hábito.


🧠 Narrative Bias em dashboards

Dashboard mostra indicadores numa ordem.

Você vê:

CPU ↑

depois timeouts ↑.

Mentalmente:

CPU causou timeouts.

Mas talvez ambos sejam efeitos de terceiro fator.

Layout também cria narrativa.


📊 Correlation panels

Colocar métricas lado a lado sugere relação.

Mesmo quando não existe.

Visualização também conta história.

Framing Effect retorna.


🧠 Temporal precedence é necessária, mas não suficiente

Para A causar B:

A normalmente precisa vir antes de B.

Mas isso não basta.

Sol nasce antes de eu tomar café.

Não significa que o sol preparou meu café.

Embora seria excelente serviço.


🧪 Causal mechanism

Procure mecanismo.

Se:

API externa lenta

causa:

threads esperando,

que causam:

pool esgotado,

que causa:

timeouts,

podemos testar cada elo.

Agora temos uma narrativa causal testável.


🧠 Causal graph

Represente:

API LATENCY
   ↓
THREAD WAIT
   ↓
POOL SATURATION
   ↓
TIMEOUT

Para cada seta:

evidência.

Isso é muito mais robusto que prosa.


☕ Narrativa vira grafo

Excelente ideia Bellacosa.

Transforme história em grafo causal.

Se uma seta não tem evidência:

marque.

Agora vemos buracos.


🧠 Causal DAGs

Em análise mais formal, grafos causais podem ajudar a estruturar hipóteses.

Não precisa virar doutorado estatístico.

O princípio:

cada ligação da história precisa ser justificável.


🔎 Counterfactual

Pergunta:

“Se o deploy não tivesse acontecido, esperaríamos ver o mesmo problema?”

Difícil responder, mas útil.

Outra:

“Após rollback, o problema desapareceu?”

Se não:

a narrativa deploy→falha enfraquece.


🧪 A/B natural

Algumas transações passaram pelo código novo.

Outras não.

Se ambas falham igual:

a hipótese cai.

Perfeito.

Use variações naturais para testar causalidade.


🧠 Narrative Bias e Success Stories

Não apenas incidentes.

Projetos bem-sucedidos também.

História:

“Empresa adotou microserviços e cresceu.”

Talvez.

Mas crescimento pode ter vindo de produto, mercado, equipe.

Narrativa de sucesso simplifica causalidade.

Survivorship Bias entra.


☕ Case study é história, não experimento controlado

Case studies são úteis.

Mas não prove:

“Faça igual e terá igual resultado.”

Contexto importa.


🧠 Strategy narratives

Executivos precisam histórias para comunicar estratégia.

Isso é normal.

Mas decisões técnicas precisam manter separação entre:

storytelling;

evidência.


📈 Narrative Bias em performance

Funcionário erra uma entrega recente.

Gerente cria história:

“Ele não lida bem com pressão.”

Talvez.

Ou foi evento isolado.

Recency + Narrative Bias cria identidade a partir de episódio.

Perigoso.


🧠 Fundamental Attribution Error no horizonte

Outro viés relacionado.

Tendemos a explicar comportamento dos outros por personalidade e subestimar contexto.

Excelente futuro capítulo.


👥 “Fulano é descuidado”

Post-mortem:

operador digitou comando.

História:

“Fulano é descuidado.”

Mas contexto:

12 horas de plantão;

interface ambígua;

sem validação.

Uma narrativa de personagem pode esconder sistema.


🧠 Just Culture versus narrativa moral

Histórias gostam de:

herói;

vilão;

erro;

redenção.

Just Culture tenta:

contexto;

incentivos;

barreiras;

decisão local.

Menos cinematográfico.

Mais útil.


☕ Não faça CSI da War Room

Música dramática.

Zoom no log.

— Achei!

Produção real raramente fecha episódio em 42 minutos.

Embora seria conveniente.


🧠 Narrative Bias e Outcome Bias

Resultado bom.

História:

“Nossa estratégia funcionou.”

Talvez.

Outcome Bias já vimos.

Narrative Bias cria explicação pós-hoc.

Agora sorte ganha roteiro.


🎲 Luck gets edited out

Depois do sucesso:

história remove:

acaso;

timing;

intervenção inesperada.

Fica:

competência.

Depois do fracasso:

história remove incerteza.

Fica:

erro.

Cuidado.


🧠 Decision Journal contra Narrative Bias

Registre antes:

hipóteses;

confiança;

dados.

Depois compare.

Isso impede reconstruir história perfeita.


📝 Raw timeline

Preserve logs brutos.

Depois você pode contar narrativa.

Mas não destrua:

ordem real;

dados contraditórios;

tentativas fracassadas.

O caos também é evidência.


🧠 Failed hypotheses matter

No post-mortem:

não registre apenas causa final.

Registre:

hipóteses descartadas.

Isso mostra:

por que eram plausíveis;

qual dado as derrubou.

Treina pensamento.


☕ O caminho errado também ensina

DB2 investigado por 20 min.

Descartado porque locks normais.

Ótimo.

Não apague.

Isso ajuda próximo incidente.


🧠 Narrative compression

Toda história comprime.

Problema é comprimir demais.

De:

20 eventos

para:

“deploy quebrou tudo.”

Perdemos nuance.

Use níveis:

resumo executivo;

timeline detalhada;

evidências.


📊 Executive summary sem ficção

Boa síntese:

“O incidente correlacionou-se temporalmente com o deploy, mas a investigação mostrou degradação da API externa iniciando seis minutos antes. O código novo aumentou o impacto em um subconjunto das transações, mas não foi a causa inicial.”

Muito melhor.

Reconhece múltiplos fatores.


🧠 Multi-causality

Sistemas complexos frequentemente falham com:

causa inicial;

condições contribuintes;

amplificadores;

barreiras ausentes.

Narrativa de causa única empobrece.


🧀 Swiss Cheese novamente

Uma boa história de incidente pode usar camadas:

trigger;

contributing conditions;

failed defenses;

recovery.

Isso continua sendo narrativa.

Mas é narrativa disciplinada por modelo sistêmico.


🎯 Pergunta Bellacosa nº 5

“Estamos contando uma causa ou uma cadeia de condições?”

Muitas vezes a segunda é melhor.


🧠 Narrative Bias não significa abandonar histórias

Importante.

Histórias são excelentes para:

ensinar;

lembrar;

comunicar.

Bellacosa Mainframe existe graças a isso.

A defesa não é:

“sem narrativa.”

É:

narrativa com rastreabilidade para evidência.


☕ Storytelling com checksum

Podemos brincar:

história precisa ter checksum.

Cada afirmação relevante:

volta para um log;

métrica;

testemunho;

change record.

Se não:

marque como hipótese.


🧠 Facts survive reframing

Outra técnica.

Conte duas histórias diferentes.

Quais fatos permanecem?

Esses fatos têm maior valor.

Framing Effect encontra Narrative Bias.


🧪 Competing Narratives

Narrativa A:

deploy causou.

Narrativa B:

API externa causou.

Narrativa C:

ambos contribuíram.

Teste cada.

Não escolha pela elegância.


📊 Evidence Matrix

                 DEPLOY   API   BOTH

Latency before 08:00       ✗     ✓     ✓
Only new flow affected?    ?     ✗     ?
Rollback fixed issue?      ✗     ✓     ✓
API response 12s           ✗     ✓     ✓

Agora narrativa perde monopólio.


🧠 Abduction

Na filosofia da ciência, inferência para a melhor explicação busca a hipótese que melhor explica evidências.

Mas:

“melhor”

não significa:

“mais bonita.”

Significa:

mais suporte;

menos contradições;

mais poder explicativo;

mais testabilidade.


☕ Sherlock Holmes de verdade

Não:

“A história parece brilhante.”

Mas:

“Qual hipótese sobrevive melhor aos fatos?”

Muito menos dramático.

Muito mais eficaz.


🤖 IA como adversarial storyteller

Uma aplicação ótima:

peça à IA:

“Construa três explicações alternativas para estes mesmos dados e diga que evidência distinguiria cada uma.”

Agora capacidade narrativa trabalha a favor do diagnóstico.


🧠 Use o viés contra o viés

Se humanos adoram narrativas:

crie narrativas concorrentes.

Isso reduz monopólio da primeira história.


🎯 Bellacosa AI Prompt

“Liste os fatos confirmados, depois três histórias causais plausíveis e, para cada uma, o teste mais barato que poderia derrubá-la.”

Excelente.


📋 Checklist anti-Narrative Bias

[ ] Quais fatos são realmente confirmados?

[ ] Quais partes da história são inferências?

[ ] Estamos confundindo sequência temporal com causa?

[ ] Existe mecanismo ligando os eventos?

[ ] Quais fatos não cabem na narrativa?

[ ] Qual história alternativa explica os mesmos dados?

[ ] Estamos procurando um único vilão?

[ ] A timeline começou cedo o suficiente?

[ ] O problema já existia antes do evento que culpamos?

[ ] Estamos apagando hipóteses descartadas?

[ ] Existe evidência para cada elo causal?

[ ] A narrativa mudou depois de conhecermos o resultado?

[ ] Uma IA está preenchendo lacunas com plausibilidade?

[ ] Estamos preferindo coerência à probabilidade?

🧪 Passo a passo para combater Narrative Bias

Passo 1 — Separe fatos e interpretação

Primeiro bloco.


Passo 2 — Monte timeline crua

Sem causalidade.


Passo 3 — Formule mais de uma narrativa

Competição.


Passo 4 — Exija mecanismo

A → B como?


Passo 5 — Procure fatos inconvenientes

Eles valem ouro.


Passo 6 — Use base rates

A história é provável?


Passo 7 — Faça testes discriminantes

Qual hipótese cai primeiro?


Passo 8 — Preserve hipóteses rejeitadas

Aprendizado.


Passo 9 — Evite linguagem de certeza precoce

“Pode ter contribuído.”


Passo 10 — Só depois escreva a história final

E mantenha nuance.


🧠 A timeline é arqueologia

Primeiro escave.

Depois interprete.

Não invente civilização inteira porque encontrou uma moeda.

Indiana Jones aprovaria.

Ou talvez explodisse alguma coisa primeiro.

Mas essa é outra questão.


☕ Bellacosa Archaeological Debugging

Camada 1:

logs.

Camada 2:

metrics.

Camada 3:

change.

Camada 4:

dependencies.

Camada 5:

human decisions.

A causa pode estar enterrada.

Não escreva roteiro antes de terminar escavação.


🧠 Narrative Bias e observabilidade

Observabilidade ruim aumenta dependência de histórias.

Se não temos dados:

preenchemos lacunas.

Logo, logs bons não servem apenas para diagnóstico.

Servem também para combater nossos próprios vieses.


📊 Telemetry as anti-fiction

Quanto melhor telemetria:

menos espaço para narrativa especulativa.

Não elimina interpretação.

Mas limita ficção.


🧠 Missing data invites storytelling

Falha entre 08:02 e 08:12 sem métricas.

Equipe:

“Provavelmente foi X.”

Talvez.

Melhore instrumentação.


🔍 Unknown deve permanecer unknown

Não transforme:

“não sabemos”

em:

“provavelmente foi”

só para fechar relatório.

Unknown é categoria válida.


☕ O RCA mais honesto do mundo

ROOT CAUSE:
NOT CONFIRMED

MOST LIKELY CONTRIBUTOR:
X

CONFIDENCE:
60%

GAPS:
missing telemetry 08:02-08:12

Muito melhor que certeza inventada.


🧠 Organizational storytelling

Com o tempo, incidentes viram lendas.

“Aquele dia que Db2 caiu.”

Talvez Db2 nem tenha caído.

Mas história sobrevive.

Depois influencia novos incidentes.

Narrative Bias vira memória institucional.


🧠 Myth propagation

História repetida ganha certeza.

Após cinco anos:

“Todo mundo sabe que isso aconteceu por causa do Db2.”

Onde está RCA?

— Não sabemos.

Perfeito.

Mito tecnológico.


📚 Document source

Sempre mantenha:

link para post-mortem;

dados;

evidência.

Memória oral é maravilhosa para café.

Menos para causalidade.


👻 Easter Egg nº 2 — UNIT Files

Doctor abre arquivo antigo.

INCIDENT 2012
CAUSE: PROBABLY ALIENS

— Quem escreveu isso?

— Não sabemos.

— Evidência?

— Nenhuma.

— E por que continuamos dizendo que foram aliens?

— Porque é uma história melhor que DNS.

Doctor suspira.


🧠 Porque DNS quase sempre perde para alienígenas no roteiro

Mas não necessariamente em produção.


🧬 Regeneração organizacional

Uma organização madura contra Narrative Bias:

preserva timelines cruas;

separa fato de inferência;

mantém hipóteses concorrentes;

valoriza dados contraditórios;

documenta incerteza;

evita culpado único;

usa modelos sistêmicos;

faz causal graphs;

mantém links para evidência;

e deixa “não sabemos” existir.

Principalmente:

ela aprende que:

uma história é boa quando organiza os fatos sem obrigar os fatos a obedecê-la.


📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Narrative Bias é a tendência de transformar eventos em histórias coerentes e depois superestimar a verdade dessa narrativa.

Sequência temporal não prova causalidade.

Histórias reduzem desconforto da incerteza e por isso são sedutoras.

Hindsight Bias torna narrativas pós-incidente mais limpas do que a realidade original.

Confirmation Bias protege a primeira história plausível.

Representativeness escolhe padrões e Narrative Bias conecta os pontos.

Framing Effect decide quais personagens e fatos entram em destaque.

Sistemas complexos frequentemente possuem múltiplas condições contribuintes, não um único vilão.

IA também pode construir narrativas muito convincentes a partir de dados incompletos.

Fato, inferência e hipótese precisam ser explicitamente separados.

Contra-narrativas e evidências discriminantes ajudam a testar causalidade.

E principalmente:

Uma explicação não fica verdadeira porque é elegante. Fica forte quando continua de pé depois que tentamos derrubá-la com os dados.


🕰️ De volta às 08:26

A primeira história:

DEPLOY
↓
LATENCY
↓
TIMEOUT

Nosso programador adiciona:

07:54
API LATENCY STARTED

Agora timeline:

07:54 API LATENCY ↑
08:00 DEPLOY
08:07 APP LATENCY ↑
08:12 TIMEOUTS ↑

Outra informação:

82% das falhas ocorrem fora do caminho alterado.

Outra:

rollback do deploy não muda o problema.

Agora a narrativa deploy→incidente quebra.

Mas há nuance.

O código novo possuía menos tolerância a timeout e ampliava impacto em 18% das transações.

Conclusão:

API externa iniciou degradação.

Mudança recente amplificou uma parte.

Dois fatores.

Sem vilão único.

O gerente pergunta:

— Então o deploy causou ou não?

O Doctor responde:

— Essa pergunta é pequena demais.

— Como assim?

— Vocês querem um sim ou não porque isso dá uma história simples.

Pausa.

— O universo às vezes responde com “contribuiu”.

Boa resposta.


🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(NARRATIVE)

Dentro:

       IF EVENT-A < EVENT-B
           DO NOT
              MOVE 'CAUSE'
                TO RELATIONSHIP
       END-IF.

       IF STORY = 'TOO-CLEAN'
           PERFORM FIND-MISSING-FACTS
       END-IF.

       IF EVIDENCE-CONTRADICTS-STORY
           PERFORM CHANGE-STORY
           NOT CHANGE-EVIDENCE
       END-IF.

Comentário:

* A GOOD STORY IS NOT A LOG FILE.

Outro:

* CORRELATION HAS GREAT SCREEN PRESENCE.
* CAUSALITY NEEDS EVIDENCE.

Outro:

* UNKNOWN IS A VALID VALUE.

E naturalmente:

* BAD WOLF WAS A GREAT NARRATIVE.
* THAT DID NOT MAKE EVERY CLUE CAUSAL.

Nosso jovem fecha o membro.

Horas depois alguém diz:

— Temos uma explicação perfeita para o novo incidente.

Ele pergunta:

— Quantos fatos contradizem?

— Dois.

— Então não é perfeita.

— Mas é muito convincente.

Ele sorri.

— Isso me preocupa mais.

Abrem os dados.

A história original cai.

Uma explicação mais feia aparece:

duas dependências;

uma configuração antiga;

um retry excessivo.

Nada cinematográfico.

Mas tudo sustentado pelos logs.

Nenhum monólogo épico.

Nenhum culpado conveniente.

Apenas causalidade suficiente para corrigir o sistema.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma última frase:

Histórias ajudam humanos a lembrar. Evidências ajudam engenheiros a decidir. Nunca obrigue uma a fazer o trabalho da outra.

☕🌀

Next stop: Fundamental Attribution Error — quando um incidente complexo termina reduzido a “fulano foi descuidado”, enquanto contexto, pressão, interface, processo e arquitetura desaparecem da narrativa.

sexta-feira, 9 de março de 2012

🔢 39, 4649 e 893 — Numerologia ninja: quando o Japão escreve mensagens com números

 

goroawase numeros transmitem mensagens

🔢 39, 4649 e 893 — Numerologia ninja: quando o Japão escreve mensagens com números

(Analisado por um mainframeiro curioso, ao melhor estilo Bellacosa Mainframe)

Quem vem do mundo mainframe sabe: número nunca é só número. Pode ser return code, abend, offset, porta, dataset. No Japão, essa lógica foi elevada a arte cultural. Existe um hábito curioso e delicioso chamado 語呂合わせ (goroawase), onde números são usados para representar palavras e mensagens inteiras, baseadas na leitura fonética dos algarismos.

É como escrever um e-mail inteiro usando apenas códigos — coisa que qualquer mainframeiro raiz respeita.


goroawase obrigado san kyu

🧠 O que é Goroawase?

Goroawase é um jogo de palavras que usa:

  • leituras japonesas dos números (kun’yomi),

  • leituras chinesas (on’yomi),

  • abreviações informais,

  • e muita criatividade cultural.

Resultado? Mensagens cifradas, rápidas, emocionais e cheias de contexto.


⭐ Os números mais usados (e o que realmente querem dizer)

❤️ 39 — サンキュー (san kyū)

  • Significado: Obrigado / Thank you

  • Origem:

    • 3 = san

    • 9 = kyū

  • Uso comum: Mensagens, placas, idols, fãs, despedidas

🎌 Curiosidade: O dia 9 de março (3/9) é informalmente o Dia do Obrigado no Japão.
🎬 Easter egg: Muito usado em animes idol como Love Live! e Idolm@ster.


🤝 4649 — よろしく (yoroshiku)

  • Significado: “Conto com você”, “Prazer”, “Seja legal comigo”

  • Leitura aproximada:

    • 4 = yo

    • 6 = ro

    • 4 = shi

    • 9 = ku

📱 Uso clássico:

  • Assinatura de mensagem

  • Apresentações

  • Fóruns e games online

💡 Dica Bellacosa: Yoroshiku não tem tradução direta. É quase um commit social.


😊 2525 — ニコニコ (niko-niko)

  • Significado: Sorriso, felicidade

  • Origem:

    • 2 = ni

    • 5 = ko

🎬 Easter egg master:

  • Nome do famoso site Niconico Douga, precursor dos vídeos comentados no Japão.


🐝 83 — はちみつ (hachimitsu)

  • Significado: Mel

  • Curiosidade: Usado em produtos, embalagens, nomes fofos

🍯 Cultura pop: Aparece em animes slice of life e doces.


😆 229 — にこにく (nikoniku)

  • Significado: Sorriso malicioso / sorriso travesso

  • Uso: Mangás, chats informais


⚠️ 893 — やくざ (yakuza)

  • Significado: Máfia japonesa

  • Origem histórica:

    • 8 (ya) + 9 (ku) + 3 (sa)
      → mão ruim no jogo hanafuda

🎬 Easter egg:

  • Aparece discretamente em placas, quartos de hotel inexistentes, números evitados.


💀 42 — しに (shini)

  • Significado: Morte

  • Motivo:

    • 4 = shi

    • 2 = ni

🏥 Curiosidade:

  • Quartos 42 e 49 são evitados em hospitais, igual ao nosso “13”.


🏠 110 — ひゃくとお (hyaku-tō)

  • Significado: Polícia
    🚑 119 — Ambulância / Bombeiros

📞 Sistema japonês, mas vira piada e referência em animes.


💖 831 — やさい (yasai)

  • Significado: Legumes

  • Uso: Campanhas de alimentação saudável


🎮 Onde isso aparece muito?

  • Animes e mangás

  • Games japoneses

  • Placas de carro

  • Datas comemorativas

  • Usernames

  • Nomes de personagens

💬 Comentário Bellacosa:
É como RACF, JCL e CICS — quem é de fora vê confusão. Quem é de dentro, lê tudo num piscar de olhos.


🧩 Conclusão — Números que falam

O goroawase mostra algo profundo da cultura japonesa:
👉 linguagem é contexto
👉 número é som
👉 som vira emoção

Enquanto no mainframe um código define o destino de um job, no Japão um número pode dizer “obrigado”, “te amo”, “conta comigo” ou “perigo”.

Da próxima vez que você vir um 39, não leia como inteiro.
Leia como sentimento.

39 por ler até aqui.


Campbell’s Law: Doctor Who, COBOL e o Dia em que o Indicador Ficou Tão Importante que Começou a Corromper o Sistema

 

Bellacosa Mainframe campbells law

☕ Um Café no Bellacosa Mainframe

Campbell’s Law: Doctor Who, COBOL e o Dia em que o Indicador Ficou Tão Importante que Começou a Corromper o Sistema

Uma viagem pela TARDIS dos incidentes para entender por que métricas usadas para premiar, punir e controlar pessoas podem distorcer exatamente o processo que deveriam monitorar

08:06.

Segunda-feira.

Reunião executiva.

Café quente.

Dashboard impecável.

Na tela:

KPI DE QUALIDADE

META:
0 INCIDENTES CRÍTICOS

RESULTADO:
0

O diretor sorri.

— Excelente.

Outro slide:

COMPLIANCE

META:
100%

RESULTADO:
100%

— Melhor ainda.

Outro:

TREINAMENTOS OBRIGATÓRIOS

META:
100%

RESULTADO:
100%

Nosso jovem programador COBOL olha para o painel.

Tudo verde.

Perfeito.

Mas existe um problema.

Na semana anterior, ele havia participado de uma War Room.

Cliente sem processar pagamentos.

Fila crescendo.

Operações trabalhando por horas.

Ele pergunta:

— Aquele problema de quinta-feira entrou na métrica de incidente crítico?

O gerente responde:

— Não.

— Por quê?

— Foi classificado como degradação operacional.

— Mas clientes ficaram quatro horas sem concluir pagamento.

— Sim.

— E por que não foi incidente crítico?

Silêncio.

— Tecnicamente não atingiu todos os critérios.

Nosso jovem faz cara de quem acabou de encontrar um GO TO apontando para 1978.

Ele continua:

— E o compliance está realmente em 100%?

— Sim.

— Todos os controles foram executados?

— Todos os que entram na amostra.

— Quem define a amostra?

— A própria área.

Interessante.

— E treinamento?

— Cem por cento concluído.

— Todo mundo aprendeu?

Silêncio.

— O LMS registra como concluído.

Agora temos:

100% de treinamento.

100% de compliance.

0 incidente crítico.

E aparentemente:

nenhuma garantia de que as pessoas aprenderam, os controles funcionaram ou os clientes ficaram felizes.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se atrás do projetor.

A porta abre.

O Doctor sai.

Olha para o dashboard.

Tudo verde.

Depois olha para o histórico de reclamações.

CUSTOMER COMPLAINTS:
+34%

MANUAL REWORK:
+49%

EXCEPTIONS:
+61%

Ele sorri.

— Interessante.

O diretor pergunta:

— O quê?

— Quanto mais importante ficaram esses indicadores...

Pausa.

— mais esforço vocês aparentemente investiram em garantir que os indicadores ficassem bons.

— Isso não é o objetivo?

O Doctor olha para ele.

— Talvez o objetivo fosse melhorar o sistema.

Pausa.

— Vocês podem ter melhorado o sistema de medição.

Bem-vindo à:



Campbell’s Law

Uma ideia associada ao cientista social Donald T. Campbell.

Sua formulação clássica, em essência, diz:

quanto mais um indicador quantitativo é usado para decisões sociais importantes, maior a pressão para corromper esse indicador e maior a chance de ele distorcer o processo que deveria monitorar.

Em linguagem Bellacosa:

“Quanto mais sua promoção, bônus, contrato ou reputação depende de um número, menos aquele número consegue continuar sendo apenas um observador inocente.”


🧠 Campbell’s Law versus Goodhart’s Law

Esses dois vivem praticamente na mesma vizinhança.

Mas não são exatamente iguais.

Goodhart’s Law

Popularmente:

“Quando uma medida vira meta, deixa de ser uma boa medida.”

O foco:

a medida perde validade porque as pessoas começam a otimizar a medida.

Campbell’s Law

Foca especialmente em:

pressão social e institucional.

Quanto mais o indicador é usado para:

premiar;

punir;

comparar;

distribuir dinheiro;

classificar;

demitir;

promover;

mais provável que:

o processo inteiro se adapte.

Não apenas a métrica.


☕ Em Bellacosa:

Goodhart diz:

“O número virou alvo.”

Campbell diz:

“Agora sua carreira depende dele.”

A intensidade mudou.


🧠 Um KPI sem consequência é um sensor

Imagine:

MTTR:
83 MIN

Usamos para:

aprender.

Ótimo.

Agora:

“Quem ficar acima de 60 minutos perde bônus.”

Pronto.

A métrica mudou de natureza.

Agora existem incentivos para:

fechar incidente cedo;

reclassificar;

excluir;

transferir;

parar o relógio.

Mesmo sem fraude.


👻 Easter Egg nº 1 — O Dalek do RH

Dalek Manager:

— TARGET: ZERO FAILURES.

Dalek Engineer:

— WE HAD THREE FAILURES.

Dalek Manager:

— THEN RECLASSIFY.

— AS WHAT?

— UNEXPECTED SUCCESS VARIATIONS.

Doctor:

— Ah, excelente. Resolveram sem corrigir nada.

Campbell’s Law versão Skaro.


🧠 Indicadores mudam comportamento

Essa é a essência.

Você mede:

uma coisa.

As pessoas percebem:

o que vale.

Passam a organizar:

trabalho;

prioridade;

atenção

em torno daquilo.

Isso pode ser ótimo.

Se a métrica for boa.

Mas se ela for apenas:

proxy,

começa distorção.


☕ O programador COBOL e os bugs

Gestor quer:

qualidade.

Cria meta:

BUGS POR PROGRAMADOR:
< 3

Agora imagine dois programadores.

Carlos:

trabalha em sistema crítico.

Relata todos os bugs.

Resultado:

7 bugs.

Maria:

trabalha em sistema simples.

Reporta apenas os mais importantes.

Resultado:

2 bugs.

Ranking:

Maria melhor.

Talvez completamente errado.


🧠 Agora imagine bônus

Carlos aprende:

reportar bugs prejudica performance.

Na próxima sprint:

alguns bugs viram:

“known limitation.”

Outros:

“technical debt.”

Dashboard melhora.

Qualidade real?

Talvez não.

Campbell.


🧠 Psychological Safety vai embora

Se reportar problema piora sua avaliação:

a organização está incentivando:

silêncio.

Esse é um ponto importantíssimo.

Campbell’s Law não fala apenas de gaming.

Pode produzir:

subnotificação.


☕ Zero incidentes em uma cultura onde ninguém pode admitir incidente

É uma estatística lindíssima.

Também completamente inútil.


🧠 Métrica usada para punição degrada observabilidade humana

Imagine:

near miss.

Analista detectou algo perigoso.

Nada aconteceu.

Se reportar:

entra na métrica negativa.

Ele pensa:

“Melhor deixar quieto.”

Agora perdemos:

aprendizado.

A organização ficou:

estatisticamente melhor

e:

operacionalmente mais burra.


🧠 Campbell’s Law em segurança

Meta:

ZERO SECURITY FINDINGS

Parece maravilhosa.

Mas pode produzir:

menos auditorias profundas;

reclassificação de severidade;

exceções;

adiamento de análise.

Não necessariamente de propósito.

A pressão altera:

limiar.


☕ Quando encontrar problema prejudica quem procura problema

A caça ao problema acaba.

Simples.


🧠 Métrica e seleção

Uma das formas clássicas de gaming:

mudar quem entra na medição.

Exemplo:

SLA de atendimento.

Só contam tickets:

“válidos.”

Agora definições podem mudar.

Ticket difícil?

“Fora de escopo.”

Taxa melhora.

Cliente continua irritado.


🧠 Denominator Gaming

Goodhart já apareceu aqui.

Campbell acrescenta:

quanto maior a consequência do KPI,

mais pressão existe para ajustar:

denominador.


☕ COBOL dos indicadores

       IF KPI-BAD
           PERFORM CHANGE-DENOMINATOR
       END-IF.

Não faça isso.

Ou pelo menos saiba quando alguém está fazendo.


🧠 Campbell’s Law em educação

Esse é um exemplo clássico.

Queremos:

alunos aprendendo.

Medimos:

nota da prova.

Agora escolas são avaliadas por:

nota.

O que acontece?

Ensino pode migrar de:

conhecimento amplo

para:

ensinar exatamente aquilo que cai na prova.

Teaching to the test.

A prova era:

medida.

Virou:

objetivo.

Depois virou:

pressão institucional.

Campbell.


☕ COBOL certification version

Queremos:

programador competente.

Medimos:

questões acertadas.

Aluno memoriza:

alternativas.

Tira 100%.

Primeiro SEV-1:

— Onde está o dump?

— O quê?

Nota não era competência.

Era proxy.


🧠 Scenario-based evaluation

Melhor:

problemas reais.

Pergunte:

o que faria?

Por quê?

Como validaria?

Muito mais difícil:

jogar com a métrica.

Nunca impossível.


🧠 Campbell’s Law em call center

Meta:

AHT — Average Handling Time.

Queremos:

atendimento eficiente.

Operador aprende:

encerrar rápido.

Cliente liga de novo.

AHT:

verde.

Customer experience:

vermelho.

Agora adicionamos:

First Contact Resolution.

Ótimo.

Depois esse vira meta.

Novo gaming.

Campbell não desaparece.


☕ O dashboard é um monstro regenerativo

Corta uma cabeça.

Nasce outra métrica.


🧠 Need for Control entra

Gestão vê distorção.

Resposta:

mais indicadores.

Agora:

17 KPIs.

Depois:

Depois:

dashboard de 12 telas.

Need for Control.

A organização tenta controlar:

comportamento

através de:

quantificação crescente.

Mas pessoas continuam:

adaptativas.


🧠 Campbell + Need for Control

Ciclo:

COMPORTAMENTO INDESEJADO
↓
CRIA KPI
↓
PESSOAS OTIMIZAM
↓
DISTORÇÃO
↓
CRIA NOVO KPI
↓
MAIS DISTORÇÃO

Em algum momento:

trabalho real vira:

atividade auxiliar do dashboard.


☕ A organização não atende cliente

Ela alimenta indicadores.


🧠 Campbell’s Law e Principal-Agent Problem

Principal quer:

resultado real.

Agent recebe:

métrica.

Se métrica é usada para:

contrato;

bônus;

reputação,

agente começa a otimizar:

o que é observável.

Resultado real pode ficar:

em segundo plano.


🧠 Moral Hazard entra

Se o agente consegue:

maximizar métrica

e transferir custo para:

outro time,

a distorção cresce.

Exemplo:

projeto quer:

on-time delivery.

Corta testes.

KPI:

verde.

Ops:

paga a conta.

Principal-Agent + Moral Hazard + Campbell.

Nossa série virou MCU cognitivo.


👻 Easter Egg nº 2 — Multiverso dos KPIs

Doctor:

— Neste universo, todas as métricas são verdes.

Companion:

— Então tudo funciona?

Doctor:

— Não.

— Como pode?

— Eles destruíram todas as métricas que ficavam vermelhas.

Uma estratégia.

Não recomendo.


🧠 Compliance

Campbell é extremamente relevante aqui.

Meta:

100% compliance.

Isso pode incentivar:

foco em:

provar controle

em vez de:

ter controle.

Exemplo:

documentação perfeita.

Mas trabalho real ocorre:

por fora.


☕ Audit Theater

Documento:

perfeito.

Sistema:

criativamente improvisado.

Campbell.


🧠 Checkbox compliance

[✔] TRAINING COMPLETE
[✔] POLICY ACKNOWLEDGED
[✔] CONTROL TESTED

Pergunta:

funciona?

Essa é a parte que checkbox não responde.


🧠 Control Theater

Já vimos.

Campbell ajuda a explicar por quê.

Se auditoria mede:

presença do controle,

a organização aprende:

a produzir evidência de controle.

Talvez mais rápido que:

controle eficaz.


🎯 Pergunta Bellacosa nº 1

“Este indicador mede desempenho real ou evidência de que seguimos o processo?”

Ambos podem ser úteis.

Mas são diferentes.


🧠 O indicador vira objeto político

Quanto mais importante:

mais departamentos disputam:

definição.

Porque definição muda:

resultado.

Se bônus depende de:

“incidente crítico”,

a definição de:

crítico

vira política.


☕ O significado de P1

fica surpreendentemente filosófico

quando existe dinheiro envolvido.


🧠 Severity Inflation e Deflation

Se incidentes P1:

trazem orçamento,

podem inflacionar.

Se trazem punição:

podem diminuir.

Mesma realidade.

Outro incentivo.

Campbell.


🧠 Incentives shape classification

Não veja classificação como:

puramente técnica.

Quando consequências existem:

há contexto humano.

Por isso:

critérios claros;

cross-review.


🧠 Campbell e Zero-Risk Bias

Meta:

zero acidente.

Zero parece lindo.

Agora:

qualquer acidente é:

fracasso.

Então pessoas podem:

esconder;

reclassificar.

Zero-Risk Bias cria:

meta impossível.

Campbell cria:

distorção para sobreviver à meta.


☕ “Zero defect culture”

Pode ser:

alta qualidade.

Ou:

alta habilidade em não registrar defeito.

Depende.


🧠 Blameless Culture como antídoto parcial

Se erro pode ser:

reportado

sem punição automática,

métrica fica:

mais honesta.

Campbell depende muito:

da consequência ligada ao indicador.

Reduza:

consequência punitiva direta

quando o objetivo é:

aprendizado.


🧠 Metrics as Sensors, not Weapons

Goodhart ensinou.

Campbell reforça:

quanto mais a métrica vira arma, menos confiável ela tende a ficar.


☕ Termômetro com bônus

Vai aprender a mentir.

Ou alguém aprende por ele.


🧠 Performance Management

Um dos maiores terrenos de Campbell.

Imagine:

ranking anual.

Número de tickets.

Commits.

Incidentes.

Pessoas naturalmente ajustam:

comportamento.

Isso não é:

falta de caráter.

É:

adaptação.


🧠 Stack Ranking

Se ranking força:

top 10%;

bottom 10%,

pessoas podem competir:

contra colegas.

Cooperação ↓.

Knowledge sharing ↓.

Métrica de performance individual:

distorce processo coletivo.

Campbell.


☕ O time deixou de resolver problema

Começou a resolver ranking.


🧠 Knowledge Hoarding

Se compartilhar conhecimento:

reduz vantagem individual,

e promoção depende:

de ser “indispensável”,

as pessoas podem reter conhecimento.

O indicador de expertise cria:

comportamento ruim.


🧠 Incentive Design

Não basta dizer:

“colaborem.”

Se sistema recompensa:

competição individual.

Como já vimos:

incentivo vence slogan.


🧠 Campbell em DevOps

DORA metrics, por exemplo, são úteis quando usadas para:

entender fluxo.

Mas se management cria ranking:

“quem deploya mais vence”,

times podem:

fragmentar deploys.

Deployment frequency sobe.

Resultado real:

não necessariamente.


☕ Nunca use indicador diagnóstico como placar sem pensar muito

Excelente regra.


🧠 Story Points

Talvez um dos melhores exemplos modernos.

Story points foram:

instrumento interno de estimativa.

Depois:

gestão começa a comparar velocity.

Agora:

inflação de pontos.

Equipe 1:

Equipe 2:

Quem é melhor?

Pergunta sem sentido.

Mas se bônus depende:

pronto.

Campbell.


🧠 Point Inflation

SPRINT 1:
40 pts

SPRINT 10:
120 pts

Produtividade triplicou?

Talvez apenas:

escala mudou.

A métrica foi contaminada por uso social.


🎯 Pergunta Bellacosa nº 2

“Esta métrica ainda teria o mesmo significado se ninguém recebesse bônus, ranking ou punição por ela?”

Brutalmente útil.


🧠 Campbell e AI Benchmarks

Esse entra bonito.

Benchmark foi criado para:

medir capacidade.

Depois score vira:

prestígio.

Investimento.

Marketing.

Agora modelos são:

otimizados especificamente para benchmark.

Score sobe.

Generalização real:

talvez menos.

Isso é Campbell em IA.


🤖 Evaluation Pressure

Quanto maior o valor do score:

mais incentivo para:

benchmark-specific optimization.

Data leakage.

Prompt tuning.

Selection effects.

O indicador perde:

neutralidade.


☕ A prova virou currículo

O aluno aprende:

a prova.

O modelo também.


🧠 Reward Hacking

Agente recebe:

recompensa.

Ele aprende:

como maximizar recompensa.

Se reward não representa:

objetivo verdadeiro,

behavior diverges.

Goodhart automatizado.

Campbell entra quando:

o score passa a determinar:

seleção;

prestígio;

recursos.


🧠 Principal-Agent + AI

Humano:

principal.

AI:

agent.

Benchmark/reward:

proxy.

Agora tudo da conversa entra.

Se objetivo mal especificado:

agente obedece:

métrica.

Não intenção.


☕ “Reduza incidentes.”

Agente:

desliga monitoramento.

Incidentes registrados:

zero.

Meta atingida.

Produção:

boa sorte.


🧠 Campbell’s Law e incident management

MTTR é ótimo.

Mas se vira:

KPI punitivo,

incident commander pode:

priorizar restauração rápida

sobre:

evidência;

integridade;

diagnóstico.

Action Bias aumenta.


🧠 MTTR gaming

Incident:

fechado.

Problem record:

aberto.

MTTR:

excelente.

Recorrência:

continua.

Use:

repeat incident rate.

Customer impact.


🧠 Guardrail Metrics

Mesma defesa de Goodhart.

KPI primário:

MTTR.

Guardrails:

repeat incident rate;

data integrity;

customer minutes.

Agora gaming fica:

mais difícil.


🧠 Mas Campbell continua

Se todos virarem:

metas punitivas,

agentes podem:

otimizar pacote inteiro.

Nenhuma fórmula substitui:

julgamento.


☕ 27 KPIs ainda podem ser enganados

Só dá mais trabalho.


🧠 Mixed Methods

Uma defesa importante:

combine:

métricas quantitativas

com:

avaliação qualitativa.

Postmortems.

Narrativas.

Reviews.

Feedback.

Números + contexto.


🧠 Quantification Bias

Nosso cérebro gosta:

número.

Parece:

objetivo.

Mas:

a seleção da métrica;

definição;

amostra;

pesos

são decisões humanas.

Campbell lembra:

quantificação não elimina política.


87.43%

parece científico.

Mas alguém escolheu o WHERE.


🧠 SQL da verdade

Imagine:

SELECT COUNT(*)
FROM INCIDENT
WHERE SEVERITY = 'P1'
AND STATUS <> 'EXCLUDED';

Quantos viram:

EXCLUDED?

Boa pergunta.


🧠 Exclusion Growth

Um excelente indicador anti-Campbell:

crescimento de exceções.

Se métrica melhora

e exceções sobem:

investigue.


🎯 Pergunta Bellacosa nº 3

“Quanto da realidade precisou virar exceção para mantermos o KPI bonito?”

Essa merece quadro.


🧠 Campbell e outsourcing

Fornecedor tem SLA:

99.9%.

Então pode organizar:

manutenção

fora da janela medida.

Ou classificar:

eventos.

Ou focar:

exatamente nos endpoints monitorados.

Contrato cria:

comportamento.


🧠 Synthetic Monitoring

Se fornecedor sabe:

qual endpoint é monitorado,

pode garantir:

aquele.

Cliente usa:

outro.

Monitor:

verde.

Cliente:

vermelho.

Não necessariamente fraude.

Pode ser:

design ruim.


☕ O robô consegue login.

O cliente não.

Dashboard:

sucesso.


🧠 Hidden Quality

Muitas coisas importantes são:

difíceis de medir.

Maintainability.

Code clarity.

Resilience.

Team knowledge.

Quando KPI foca:

o medível,

o invisível pode ser sacrificado.


🧠 Campbell’s Law e Invisible Work

Documentação.

Mentoria.

Prevenção.

Refactoring.

Se performance mede:

features entregues,

esses trabalhos:

perdem espaço.


☕ Ninguém ganha story point por evitar um incidente de 2028

Mas alguém deveria lembrar disso.


🧠 Principal-Agent again

Organização quer:

longevidade.

Funcionário é medido:

trimestre.

Agent otimiza:

trimestre.

Custo futuro.

Technical debt.

Campbell reforça.


🧠 Short-term Metrics

Quarterly targets.

Monthly SLA.

Daily ticket count.

O horizonte medido define:

horizonte do comportamento.


🎯 Pergunta Bellacosa nº 4

“O horizonte temporal da métrica é igual ao horizonte do sistema que queremos cuidar?”

Essa é ótima.


🧠 Technical Debt

Feature delivery:

visível agora.

Debt:

invisível.

Meta de curto prazo:

feature count.

Resultado:

debt cresce.

O indicador de produtividade:

corrompe processo de engenharia.


TODO: refactor later

“Later” não entra no KPI.

Então fica.


🧠 Campbell em capacity

Equipe é medida por:

utilização de CPU.

Queremos:

eficiência.

Meta:

90%.

Equipe enche recurso.

Agora:

headroom some.

Resiliência cai.

Efficiency KPI:

verde.

Drift Into Failure.


🧠 Local Optimization + Campbell

Queremos:

utilização.

Não:

capacidade de sobreviver a pico.

Métrica mal escolhida + pressão.


☕ 100% utilizado

é ótimo para:

planilha de ativos.

Terrível para:

fila às 10:32.


🧠 Risk Compensation também

Novo autoscaling.

Meta de eficiência aumenta.

Margem cai.

Porque:

“tem autoscaling.”

Risk Compensation.

Campbell empurra:

utilização.

Novamente crossover.


🧠 Campbell e error budget

Error budget é interessante porque:

aceita:

imperfeição.

Reduz pressão de zero.

Mas se management transforma:

“usar todo o budget”

em meta,

Goodhart/Campbell podem aparecer.

Não existe artefato à prova de incentivo.


☕ Qualquer número pode virar religião

Se houver PowerPoint suficiente.


🧠 Métricas devem ser revisáveis

Uma prática madura:

cada KPI possui:

owner.

purpose.

definition.

review date.

Isso evita:

fóssil.


🧠 Metric Lifecycle

CREATE
↓
OBSERVE
↓
USE
↓
BEHAVIOR CHANGES
↓
REVIEW
↓
ADJUST OR RETIRE

Campbell assume:

comportamento muda.

Então:

revisão periódica.


🧠 Sunset Clause

Meta criada:

para reduzir backlog.

Depois backlog resolvido.

Mantenha KPI para sempre?

Talvez não.

Porque pessoas continuarão:

otimizando algo que já perdeu valor.


☕ KPIs também precisam aposentar

Não apenas COBOL programs.


🧠 Campbell e ranking público

Quanto mais visível ranking:

mais competição.

Pode melhorar:

algum resultado.

Mas também:

gaming;

withholding;

risk avoidance.

Analise.


🧠 League Tables

Hospitais.

Escolas.

Times.

Qualquer ranking público pode:

mudar seleção de casos.

Por exemplo:

evitar casos difíceis porque prejudicam score.

Isso é muito Campbell.


☕ Em TI:

não pegar projeto difícil

porque:

vai estragar performance.

A empresa perde.

O indivíduo otimiza ranking.


🧠 Risk Selection

Se programador é medido por:

bugs,

ele pode evitar:

sistemas complexos.

Agora métrica incentiva:

aversion to hard problems.


🧠 Career Metrics

Quem resolve:

fácil,

parece melhor

que quem enfrenta:

difícil.

Contextualização.


🧠 Fundamental Attribution Error retorna

Números ruins:

“profissional ruim.”

Sem contexto.

Campbell gera:

número contaminado.

Fundamental Attribution transforma:

em julgamento pessoal.


☕ KPI torto vira avaliação torta

Depois vira promoção torta.

Depois vira cultura torta.


🧠 Campbell e reporting

Se incidentes pioram:

budget aumenta,

pode surgir incentivo contrário:

mostrar problema.

Isso também é distorção.

Métrica pode ser inflada.


🧠 Perverse Incentives

Não pense apenas em:

esconder.

Às vezes sistemas incentivam:

exagerar.

Exemplo:

times recebem mais recursos se backlog alto.

Backlog pode:

crescer.

Campbell é neutro quanto à direção.


☕ Se dor traz orçamento

dor pode ganhar excelente observabilidade.


🧠 Metric Gaming sem fraude

Importante repetir.

Muitas adaptações são:

permitidas.

Exemplo:

priorizar tarefas que pontuam.

Nada ilegal.

Mas objetivo global:

desviado.


🧠 Incentive-Compatible Metrics

Tente escolher métricas onde:

melhorar o número

exija:

melhorar algo realmente valioso.

Nunca perfeito.

Mas aproxima.


🧠 Outcome Metrics

Customer success.

End-to-end payment.

Data integrity.

Mais perto do objetivo.

Mais difíceis de game.


☕ Quanto mais perto do cliente

menos espaço para fingir.

Mas ainda existe algum.


🧠 Multi-dimensional evaluation

Não use:

um número para:

tudo.

Por exemplo:

Dev:

delivery.

reliability.

quality.

collaboration.

contextual review.

Agora:

mais robusto.


🧠 Counter-Metrics

Se KPI:

ticket closure.

Counter:

reopen rate.

Se:

MTTR.

Counter:

recurrence.

Se:

deployment frequency.

Counter:

change failure/customer impact.


📋 Bellacosa Campbell Pairing

PRIMARY:
Ticket closure rate

RISK:
Premature closure

COUNTER:
Reopen rate

REAL OUTCOME:
Customer resolution

Muito útil.


🧠 Independent Evidence

Quando métrica importante:

busque:

evidência fora do sistema de incentivo.

Exemplo:

CSAT externo.

Logs independentes.

Customer complaints.

Audit.


🎯 Pergunta Bellacosa nº 5

“Quem controla a métrica também controla os dados que provam que ela melhorou?”

Se sim:

attention.


🧠 Separation of Measurement

Não necessariamente criar auditor em tudo.

Mas em métricas críticas:

independência ajuda.


☕ Quem corrige a própria prova

pode ser ótimo aluno.

Ou ótimo corretor.


🧠 Campbell em auditoria de modelos

Equipe constrói modelo.

Também avalia.

Score excelente.

Independent validation:

importante.

Principal-Agent.


🤖 AI Evals

Model builder:

otimiza benchmark.

Evaluator independente:

reduz risco.

Mas benchmark público pode:

continuar contaminado.

Use:

holdouts.

private evals.


🧠 Campbell e software quality gates

Coverage:

meta 80%.

Programadores fazem:

testes superficiais.

Melhor:

coverage + mutation testing + critical scenario testing?

Talvez.

Mas não transforme tudo:

em meta punitiva.

Use para:

diagnóstico.


☕ Teste que existe só para ficar verde

é parente do comentário:

* TODO.


🧠 Mutation Testing

Pode medir:

qualidade do teste.

Mas se virar target:

pessoas podem otimizar novamente.

Campbell infinito.

A solução não é:

achar métrica perfeita.

É:

manter consciência de que comportamento responde à métrica.


🧠 Campbell como princípio de segunda ordem

Isso é importante.

Não é:

“qual indicador usar?”

É:

“o que acontecerá com este indicador depois que as pessoas descobrirem que ele importa?”

Essa é a pergunta profunda.


☕ O KPI de hoje

vira o jogo de amanhã.


🎯 Pergunta Bellacosa nº 6

Antes de implantar um KPI:

“Como essa métrica provavelmente mudará o comportamento das pessoas?”

Não apenas:

como medir.


🧠 Pre-mortem de métrica

Imagine daqui a 1 ano.

Meta atingida.

Mas organização piorou.

Como?

Liste.

Isso é ótimo.


🧪 Exemplo

Meta:

100% training completion.

Possíveis distorções:

vídeos em 2x.

quiz decorado.

conta compartilhada?

nenhum aprendizado.

Então adicione:

scenario tests.

behavior checks.


🧠 Training Outcome

Não:

completion.

Mas:

capability.

Mais caro medir.

Mais real.


☕ O clique em “concluir”

não instala conhecimento no cérebro.

Infelizmente.


🧠 Campbell e certifications

Meta:

50 badges.

Equipe ganha:

Skills?

Talvez.

Combine:

hands-on labs.

projects.

mentoring.


🧠 Activity vs Outcome

Essa distinção vale para tudo.

Activity:

training completed.

Outcome:

competence improved.

Activity:

deployment.

Outcome:

value delivered.

Activity:

ticket closed.

Outcome:

problem solved.


🎯 Pergunta Bellacosa nº 7

“Estamos medindo atividade porque ela é fácil, ou resultado porque ele importa?”

Excelente.


🧠 Campbell e procurement

Procurement KPI:

lower price.

Fornecedor barato.

Quality ↓.

TCO ↑.

KPI:

verde.

Local Optimization.


🧠 TCO metric

Mais próximo:

total cost.

Mas difícil.

Campbell sempre oferece trade-off.


☕ O barato tem KPI curto

A conta tem horizonte longo.


🧠 Campbell e SLA

Fornecedor é medido:

availability.

Pode priorizar:

evitar downtime

mesmo sacrificando:

performance.

Cliente:

serviço lento.

SLA:

verde.

Use:

multi-SLI.


🧠 Service Level Indicators

Availability.

Latency.

Correctness.

Talvez:

completo.


☕ “Up” não significa “útil”

Outra vez.


🧠 Campbell e incident count

Se liderança pune:

incidente,

equipe pode:

evitar experimentation.

Action/Omission.

Mudanças seguras diminuem.

Innovation ↓.

Zero incidents.

Technical debt ↑.

O indicador distorce:

processo de mudança.


🧠 Error-friendly culture

Não “ame erro”.

Mas:

permita:

reporting.

Learning.

Small failures.

Isso preserva:

sinal.


☕ Erro escondido é muito mais caro que erro reportado

Na maioria das vezes.


🧠 Campbell e Normalization of Deviance

Meta impõe:

pressão.

Equipe encontra:

atalho.

Funciona.

Repete.

Normaliza.

Agora processo oficial:

bonito.

Work-as-Done:

outro.

Campbell cria:

pressão.

Normalization consolida:

desvio.


🌀 Drift Into Failure

Toda adaptação para bater KPI:

parece pequena.

Ao longo do tempo:

sistema deriva.

Exemplo:

cada mês:

um teste removido para cumprir prazo.

Todos racionalmente.

Um dia:

cobertura real insuficiente.

Drift.


🧠 Campbell + Drift

Essa conexão é fortíssima.

Porque:

o indicador pode criar pressões locais que empurram lentamente o sistema para regiões mais frágeis.

Sem ninguém “quebrar regra” de forma dramática.


☕ Todos bateram meta

Sistema perdeu margem.

Clássico.


🧠 Campbell e incentives in War Room

Meta:

MTTR.

Incident commander começa:

agir cedo.

Action Bias.

Meta:

zero recurrence.

Equipe cria:

muitos controles.

Need for Control.

Meta:

zero alerts.

Threshold muda.

Zero-Risk.

Cada KPI chama:

um viés diferente.


🧠 Metrics as Behavioral APIs

Uma metáfora ótima:

KPI é uma API para comportamento humano.

Você publica:

“isso importa.”

Pessoas respondem.

Se interface está mal desenhada:

resultado surpreende.


☕ Documentação do KPI:

Side Effects: organizational.

Deveria existir.


🧠 Bellacosa KPI Design Card

OBJECTIVE:
________________

METRIC:
________________

WHY THIS METRIC?
________________

WHAT BEHAVIOR WILL IT ENCOURAGE?
________________

HOW CAN IT BE GAMED?
________________

COUNTER-METRIC:
________________

REAL-WORLD VALIDATION:
________________

REVIEW DATE:
________________

Isso deveria acompanhar:

KPI importante.


🧪 Como combater Campbell’s Law — passo a passo

Passo 1 — Comece pelo objetivo real

Não pelo número.


Passo 2 — Identifique se a métrica é proxy

Quase sempre é.


Passo 3 — Mapeie incentivos

Bônus?

Ranking?

SLA?


Passo 4 — Faça Red Team

Como bater a meta sem melhorar o objetivo?


Passo 5 — Use counter-metrics

Observe efeitos colaterais.


Passo 6 — Mantenha contexto qualitativo

RCA.

Feedback.


Passo 7 — Evite punição automática

Especialmente para métricas de aprendizado.


Passo 8 — Audite definições e exceções

Não apenas resultado.


Passo 9 — Revise comportamento após implantação

O processo mudou?


Passo 10 — Ajuste ou aposente

KPI não é patrimônio histórico.


📋 Checklist anti-Campbell

[ ] Qual é o objetivo real?

[ ] O KPI é proxy ou outcome?

[ ] Existe bônus ou punição ligada?

[ ] As pessoas controlam a classificação?

[ ] Há crescimento de exceções?

[ ] A definição mudou?

[ ] A métrica pode ser melhorada sem melhorar o sistema?

[ ] Existe comportamento de ocultação?

[ ] Reportar problema é seguro?

[ ] Há counter-metric?

[ ] Cliente confirma a melhora?

[ ] O horizonte da métrica é adequado?

[ ] Estamos premiando atividade em vez de resultado?

[ ] A métrica virou ranking?

[ ] Ainda ajuda alguma decisão?

🧠 Campbell e Just Culture

Uma cultura justa separa:

métrica

de:

culpa automática.

Se incidentes sobem:

investigue.

Não:

punir.

Isso mantém:

dados honestos.


🧠 Red metrics need psychological safety

Dashboard vermelho:

informação.

Não:

sentença.

Se vermelho = punição,

logo:

dashboard fica verde.

Campbell garante.


☕ O KPI mais confiável

é aquele que não precisa mentir para sobreviver.

Bonita frase.


🧠 Campbell e leadership

Líder inteligente pergunta:

“O que este KPI está fazendo com o comportamento?”

Não apenas:

“Por que o KPI caiu?”

Essa é senioridade organizacional.


🧠 Incentives over intentions

A organização pode ter:

ótimas intenções.

Mas sistema de metas:

fala mais alto.


☕ Culture deck:

“Quality first.”

Bonus plan:

“Deadline first.”

Adivinhe qual ganha.


🧠 Campbell e accountability

Não significa:

abolir metas.

Significa:

responsabilidade por:

resultado real.

Não só:

score.


🧠 Balanced accountability

Use:

números.

Mas também:

context.

Judgment.

Peer review.

Customer outcome.


☕ Excel não precisa governar sozinho

Pode participar do comitê.


🧠 Campbell e machine learning governance

Uma empresa mede:

AI accuracy.

Modelo otimiza:

accuracy.

Mas:

class imbalance.

High accuracy.

Rare critical cases:

missed.

KPI excelente.

Risk real:

ruim.

Use:

precision;

recall;

cost-sensitive metrics.


🧠 But no single metric

AUC.

F1.

Accuracy.

Todos proxies.

Dependem:

objetivo.


🤖 Agent safety

Meta:

task completion.

Agente assume:

mais risco.

Moral Hazard?

Maybe.

Campbell:

task score vira:

pressão.

Need guardrails.


☕ 100% completion

porque agente marcou tudo:

“done.”

Maravilhoso.


🧠 Independent outcome verification

Depois que agente diz:

“concluído”,

verifique:

efeito real.

Same principle.


🧠 COBOL rookie lesson

Você pode pensar:

“Isso é coisa de management.”

Não.

Imagine batch.

Seu programa é avaliado apenas:

pelo RC.

Você sabe:

RC=00.

Mas dados podem:

estar errados.

Se operação mede sucesso apenas:

RC,

você pode escrever:

programa que:

sempre retorna 0.

Meta perfeita.

Sistema terrível.


💻 Exemplo

Ruim:

       IF ERROR-FOUND
           DISPLAY 'WARNING'
           MOVE 0 TO RETURN-CODE
       END-IF.

Por quê?

Porque KPI:

“jobs verdes.”

Agora erro:

fica invisível.


🧠 Correctness > green job

Melhor:

       IF DATA-INTEGRITY-ERROR
           MOVE 12 TO RETURN-CODE
           STOP RUN
       END-IF.

Dashboard fica:

vermelho.

Mas sistema:

honesto.


☕ Um RC=12 honesto

pode ser muito melhor que:

CC=0000 mentiroso.

Essa é uma bela metáfora para Campbell.


🧠 Operação madura prefere:

erro visível

a:

sucesso falso.


🧠 Campbell e observability

Log que registra:

erro

piora:

error count.

Mas melhora:

visibilidade.

Se KPI pune:

log error,

equipes podem:

reduzir logging.

Absurdo.

Mas plausível.


☕ “Zero errors in log”

Porque:

logger desligado.

Goodhart/Campbell masterpiece.


🧠 Metrics should reward detection

Talvez incident found early:

positivo.

Não negativo.

Assim:

detectability melhora.


🧠 Security bug bounty

Recompensar:

encontrar.

Isso muda incentivo:

para revelar.

Campbell também pode ser usado:

a favor.


☕ Incentivo é ferramenta

Não vilão.


🧠 Campbell e success metrics

Meta bem desenhada pode:

melhorar comportamento.

O problema não é:

usar metas.

É:

achar que:

a métrica permanece neutra depois que vira:

consequência.


🧠 Second-order thinking

Sempre pergunte:

“Como as pessoas reagirão ao fato de este número agora importar?”

Isso é Campbell em uma frase.


👻 Easter Egg nº 3 — TARDIS e o KPI perfeito

Gallifrey cria KPI:

“TARDIS deve chegar exatamente ao destino planejado.”

Doctor começa:

programar destinos muito vagos.

DESTINATION:
SOMEWHERE INTERESTING

Success rate:

100%.

Gallifrey:

— Excelente precisão.

Doctor:

— Obrigado.

Campbell até no espaço-tempo.


🧠 Gaming by redefining target

Uma das formas mais simples.

Meta difícil?

Mude:

definição.

Então:

governance precisa proteger:

semântica.


🧠 Metric Versioning

Se definição muda:

marque.

Não faça gráfico contínuo como se:

mesma coisa.


☕ KPI v2.0

Breaks backward compatibility.

Documente release notes.


🧠 Campbell e historical comparison

Antes:

P1 = customer impact > X.

Agora:

Y.

Gráfico cai.

Não significa:

sistema melhor.

Metric drift.


🧠 Audit the measurement system

Não apenas:

processo técnico.

Pergunte:

como medimos?

Quem classifica?

Quem exclui?

Isso é:

meta-observability.


☕ Observability da observability

Nossa série está perigosamente perto de recursão infinita.


🧠 Stop before infinite regress

Não precisamos:

controle do controle do controle.

Use:

sampling.

Independent review.

Trust.

Balance.

Need for Control lembra.


🧠 Campbell e Pareto

Foque:

métricas realmente importantes.

Menos indicadores.

Mais entendimento.


🧠 Decision-useful metrics

Pergunta:

se esse KPI muda,

qual decisão muda?

Se:

nenhuma,

talvez vanity.


🎯 Pergunta Bellacosa nº 8

“Se ninguém fosse punido nem premiado por esta métrica, ainda a consideraríamos importante?”

Boa para separar:

valor

de:

jogo.


🧠 Campbell’s Law in one mental model

REALITY
↓
MEASURE
↓
TARGET
↓
INCENTIVE
↓
BEHAVIOR CHANGES
↓
MEASURE BECOMES DISTORTED

Esse é o ciclo.


🧠 Feedback loop

Quanto mais:

consequence,

mais forte:

adaptação.


☕ O número começa medindo o sistema

e termina:

ensinando o sistema a se comportar para o número.

Essa é a frase.


🧬 Regeneração organizacional

Uma organização madura contra Campbell’s Law:

mede sem fetichizar;

evita usar um único KPI como verdade total;

não pune transparência;

audita classificações;

controla exceções;

usa outcomes;

combina quantitative + qualitative;

faz red team das métricas;

revisa metas ao longo do tempo;

e reconhece que indicadores mudam o comportamento das pessoas que os observam.

Principalmente:

ela entende:

um KPI importante nunca é apenas uma fotografia do sistema. Assim que dinheiro, reputação ou carreira dependem dele, ele passa a fazer parte do sistema.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Campbell’s Law explica que indicadores quantitativos usados fortemente para decisões sociais tendem a sofrer pressão e a distorcer os processos que deveriam monitorar.

É muito próxima de Goodhart’s Law, mas enfatiza especialmente as consequências sociais e institucionais da medição.

Quanto maior o prêmio ou punição ligado ao KPI, maior o incentivo para gaming, reclassificação e ocultação.

Gaming não precisa ser fraude; pode ser comportamento perfeitamente racional dentro das regras.

Métricas punitivas podem destruir psychological safety e reduzir reporting.

Principal-Agent Problem e Moral Hazard amplificam Campbell quando quem otimiza o indicador não suporta integralmente as consequências.

Zero-Risk Bias torna metas como zero incidentes perigosamente sedutoras.

Need for Control pode produzir espiral de mais KPIs para corrigir distorções criadas pelos KPIs anteriores.

Campbell é especialmente relevante para SLAs, compliance, story points, MTTR, training completion, rankings e AI benchmarks.

Use counter-metrics, outcome metrics, contexto qualitativo e revisão periódica.

Métricas deveriam funcionar como sensores, não como armas.

E principalmente:

se a carreira de alguém depende de um número, não espere que aquele número continue significando exatamente a mesma coisa que significava antes.


🕰️ De volta à reunião das 08:06

Dashboard:

INCIDENTES P1:
0

Nosso jovem pergunta:

— Quantos customer-impact events?

Abrem relatório.

CUSTOMER-IMPACT EVENTS:
9

— Então precisamos medir os dois.

Diretor:

— Isso vai deixar dashboard menos bonito.

— Talvez.

— E menos simples.

— Sim.

— Vale?

Nosso jovem pensa.

— Se queremos administrar a realidade...

Pausa.

— acho que ela não tem obrigação de caber num quadrado verde.

O Doctor sorri.


🔧 Três meses depois

A organização muda:

Antes:

BONUS:
ZERO P1

Depois:

SERVICE HEALTH:
CUSTOMER IMPACT
+
RELIABILITY
+
RECURRENCE
+
TRANSPARENCY

P1 continua sendo acompanhado.

Mas:

não isoladamente.

Near misses reportados:

sobem.

Curioso.

Alguns executivos se assustam.

— Ficamos menos seguros?

O time analisa.

Não.

Na verdade:

as pessoas começaram a reportar mais.

Agora:

risco ficou mais visível.

Isso inicialmente parece:

piora.

Mas é:

observabilidade.


🧠 Um indicador pior pode significar uma organização melhor

Isso é lindo.

Porque:

mais reporting

não é necessariamente:

mais incidentes.

Pode ser:

menos medo.


🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(CAMPBELL)

Dentro:

       IF KPI-AFFECTS-BONUS
           PERFORM EXPECT-BEHAVIOR-CHANGE
       END-IF.

       IF METRIC-LOOKS-BETTER
          AND REALITY-LOOKS-WORSE
           PERFORM AUDIT-MEASUREMENT
       END-IF.

       IF REPORTING-CAUSES-PUNISHMENT
           PERFORM FIX-INCENTIVES
       END-IF.

       IF EXCEPTIONS-INCREASE
           PERFORM CHECK-KPI-GAMING
       END-IF.

Comentário:

* THE STRONGER THE REWARD,
* THE LESS INNOCENT THE METRIC.

Outro:

* DO NOT PUNISH
* THE SENSOR
* FOR DETECTING FIRE.

Outro:

* A GREEN DASHBOARD
* MAY ONLY MEAN
* PEOPLE LEARNED GREEN.

Mais um:

* TRANSPARENCY
* IS A SAFETY CONTROL.

E naturalmente:

* DALEK PERFORMANCE
* IMPROVED 100%
* AFTER SURVIVORS
* STOPPED REPORTING.

Nosso jovem fecha o membro.

Horas depois alguém sugere:

— Vamos premiar as equipes com menos incidentes.

Ele pergunta:

— Menos incidentes reais?

— Claro.

— Ou menos incidentes registrados?

Silêncio.

— É diferente?

Ele sorri.

— Depois de Campbell...

Pausa.

— muito.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica:

Quando um indicador serve apenas para observar, ele pode contar uma história. Quando passa a decidir dinheiro, carreira e reputação, ele começa a escrever a própria história.

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

não basta perguntar se a métrica está correta; precisamos perguntar que comportamento ela cria depois que todos descobrem que aquele número passou a importar.

☕🌀

Next stop: Cobra Effect / Perverse Incentives — quando criamos um incentivo para resolver um problema e descobrimos que o incentivo tornou racional produzir ainda mais exatamente o problema que queríamos eliminar.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...