☕ 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

Mostrar mensagens com a etiqueta Outcome Bias. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Outcome Bias. Mostrar todas as mensagens

sexta-feira, 13 de junho de 2014

Outcome Bias: Doctor Who, COBOL e o Dia em que uma Decisão Ruim Terminou Bem — e Todo Mundo Passou a Chamá-la de Genial

 

Bellacosa Mainframe e o outcome bias

☕ Um Café no Bellacosa Mainframe

Outcome Bias: Doctor Who, COBOL e o Dia em que uma Decisão Ruim Terminou Bem — e Todo Mundo Passou a Chamá-la de Genial

Uma viagem pela TARDIS dos incidentes para entender por que julgamos decisões pelo resultado que aconteceu depois — e como sorte, azar, risco, contexto e incerteza podem transformar imprudência em “competência” ou uma boa decisão em “fracasso”

Sexta-feira.

17:53.

Já começamos mal.

War Room não existe ainda.

Mas provavelmente:

está apenas esperando.

No telão:

CHANGE WINDOW

START: 18:00
END:   20:00

CHANGE:
PAYMENTS-X DATABASE MIGRATION

RISK:
HIGH

Nosso jovem programador COBOL pergunta:

— Rollback foi testado?

Silêncio.

DBA:

— Não completamente.

— Restore?

— Testamos mês passado.

— Mesma versão?

— Não exatamente.

— Reconciliação?

— Temos amostragem.

Gerente olha para o relógio.

17:55.

— Vamos seguir.

Nosso jovem:

— Mesmo assim?

— O risco é baixo.

— Como sabemos?

— Já fizemos mudança parecida.

— Parecida quanto?

— Parecida.

Ah.

Uma unidade científica maravilhosa:

parecida.

Às 18:00:

Go-Live.

18:15:

nenhum erro.

18:30:

nenhum erro.

19:00:

estável.

20:00:

encerramento.

Todo mundo:

feliz.

O diretor manda:

Excelente execução.

Gerente responde:

Grande decisão do time em seguir com o Go-Live.

Nosso jovem olha:

para o rollback não testado.

Depois:

para o sistema funcionando.

Então pensa:

— Talvez eu estivesse exagerando.

VWORP.

VWORP.

VWORP.

A TARDIS aparece no meio da sala.

A porta abre.

O Doctor sai.

Olha:

para produção.

Tudo funcionando.

— Excelente.

Gerente sorri.

— Viu? Eu sabia que podíamos seguir.

Doctor:

— Sabia?

— Sim.

— Então vocês tinham evidência suficiente?

— Bem...

— Rollback testado?

— Não.

— Restore?

— Parcial.

— Reconciliação?

— Parcial.

Doctor:

— Então como você “sabia”?

Gerente aponta:

para o dashboard verde.

— Funcionou.

Doctor sorri.

— Isso responde:

ao que aconteceu.

Pausa.

— Não necessariamente à qualidade da decisão que vocês tomaram antes de saber o que aconteceria.

Bem-vindo ao:



Outcome Bias

ou:

Viés de Resultado.

Em linguagem Bellacosa:

é quando avaliamos se uma decisão foi boa olhando principalmente para o que aconteceu depois — em vez de avaliar a qualidade da decisão com base nas informações disponíveis no momento em que ela foi tomada.


🧠 O que é Outcome Bias?

Imagine duas decisões.

Decisão A:

bem analisada;

dados suficientes;

risco conhecido;

rollback validado;

controles adequados.

Resultado:

falha inesperada.

Decisão B:

apressada;

sem teste;

sem evidência;

sem plano B.

Resultado:

funciona.

Se avaliamos apenas:

resultado,

poderíamos concluir:

A = decisão ruim
B = decisão boa

Mas isso pode estar:

completamente invertido.


☕ Bellacosa Definition

Resultado é aquilo que aconteceu. Qualidade da decisão é aquilo que você fez com a informação que possuía antes de saber o resultado.

São:

duas coisas.


🧠 COBOL cognitivo

Imagine:

       IF OUTCOME = 'SUCCESS'
           MOVE 'GOOD-DECISION'
             TO DECISION-QUALITY
       ELSE
           MOVE 'BAD-DECISION'
             TO DECISION-QUALITY
       END-IF.

Programa simples.

Elegante.

Absolutamente:

errado.

Mais correto seria algo como:

       EVALUATE TRUE
           WHEN PROCESS-WAS-SOUND
                MOVE 'GOOD-DECISION'
                  TO DECISION-QUALITY

           WHEN PROCESS-WAS-POOR
                MOVE 'BAD-DECISION'
                  TO DECISION-QUALITY
       END-EVALUATE.

E depois:

avaliar resultado:

separadamente.


🧠 Uma decisão pode ser boa e produzir resultado ruim

Isso acontece porque:

mundo possui:

incerteza.

Probabilidade.

Variáveis externas.

Eventos raros.

Azar.


🧠 Exemplo simples

Imagine:

backup testado.

Restore testado.

DR testado.

Plano robusto.

O desastre chega:

e destrói simultaneamente duas regiões.

Muito improvável.

Sistema falha.

Foi:

má decisão?

Talvez não.

Talvez tenha sido:

boa decisão

diante das informações e probabilidades conhecidas.


☕ Engenharia não promete:

controle absoluto.

Promete:

decisões melhores sob incerteza.


🧠 Agora o contrário

Você executa:

mudança crítica

sem rollback.

Nada acontece.

Foi:

boa decisão?

Não necessariamente.

Você pode ter:

simplesmente tido sorte.


👻 Easter Egg nº 1 — Dalek Change Manager

Dalek:

— CHANGE SUCCESSFUL.

Doctor:

— Rollback test?

— NO.

— Backup?

— UNKNOWN.

— Peer review?

— NO.

— Então por que fizeram?

— IT WORKED.

Doctor:

— Isso aconteceu depois.

Dalek:

— CORRECT.

Doctor:

— Então não podia justificar a decisão anterior.

Dalek:

— OUTCOME SUCCESSFUL.

Doctor:

— Vamos ficar aqui bastante tempo, não?


🧠 Sorte também existe em TI

Isso incomoda.

Gostamos de imaginar:

resultado = competência.

Mas sistemas complexos têm:

aleatoriedade;

timing;

load;

network;

scheduling;

race conditions;

dependências.

Duas execuções quase iguais podem:

produzir resultados diferentes.


CC=0000

não significa:

processo excelente.

Às vezes significa:

“desta vez nada explodiu.”


🧠 Outcome Bias versus Hindsight Bias

São parentes.

Mas diferentes.

Hindsight Bias:

Depois que sabemos o resultado:

“Era óbvio que isso aconteceria.”

Outcome Bias:

Depois que sabemos o resultado:

“Como deu certo, a decisão foi boa.”

ou:

“Como deu errado, a decisão foi ruim.”

Um trata:

previsibilidade.

Outro:

qualidade da decisão.


🧠 Exemplo

Go-Live falha.

Hindsight:

“Era óbvio que falharia.”

Outcome:

“Logo, a decisão de lançar foi irresponsável.”

Talvez fosse.

Talvez não.

Precisa:

reconstruir informação anterior.


🎯 Pergunta Bellacosa nº 1

“Com o que sabíamos antes do resultado, essa decisão ainda parecia razoável?”

Excelente.


🧠 Confirmation Bias entra depois

Se já acreditávamos:

gerente irresponsável,

e mudança falha,

Outcome Bias:

“viu?”

Confirmation Bias:

“sempre foi ruim.”

Self-Serving Bias:

“eu avisei.”

Hindsight:

“era óbvio.”

Temos:

festival.


☕ A War Room vira:

retrospectiva escrita pelos vencedores.


🧠 Outcome Bias e Self-Serving Bias

Sucesso:

“foi nossa competência.”

Fracasso:

“foi azar.”

Quando julgamos nós mesmos.

Mas quando julgamos outros:

Sucesso:

“sorte.”

Fracasso:

“incompetência.”

Bonito.

Humano.


🧠 Actor-Observer

Meu resultado ruim:

contexto.

Seu:

decisão ruim.

Outro crossover.


🎯 Pergunta Bellacosa nº 2

“Estou aplicando o mesmo padrão de avaliação à minha decisão e à decisão do outro?”


🧠 Resultado bom pode esconder processo ruim

Esse é provavelmente:

o perigo principal.

Imagine:

deploy direto em produção.

Sem teste.

Funciona.

Equipe aprende:

“não precisamos de teste.”

Próxima vez:

repete.

Funciona.

Terceira:

repete.

Funciona.

Quarta:

P1.

Agora todos perguntam:

— Como isso aconteceu?

Resposta:

porque três resultados bons validaram mentalmente um processo ruim.

Outcome Bias.


☕ Sorte repetida

pode parecer:

maturidade operacional.

Até:

parar.


🧠 Normalization of Deviance entra

Primeira vez:

desvio.

Nada acontece.

Segunda:

normal.

Terceira:

processo real.

Outcome Bias ajuda:

“se funcionou, então não era tão arriscado.”

Normalization of Deviance cresce.


🧠 Risk Compensation

Novo controle:

backup.

Equipe fica:

mais ousada.

Mudanças ruins:

funcionam.

Outcome Bias:

“controle tornou tudo seguro.”

Comportamento:

aumenta risco.


🎯 Pergunta Bellacosa nº 3

“O sucesso mostrou que o processo era bom ou apenas que o risco não se materializou desta vez?”

Essa é central.


🧠 Um dado que quase nunca aparece: near miss

Imagine:

mudança funcionou.

Mas logs mostram:

queue atingiu 98% do limite.

Ninguém percebeu.

Outcome:

sucesso.

Near miss:

enorme.

Se avaliamos apenas:

resultado,

perdemos:

aprendizado.


☕ “Não caiu”

é critério:

baixo.

Muito baixo.


🧠 Outcome Bias e Survivorship Bias

Só observamos:

mudanças que sobreviveram.

Os processos arriscados que deram certo:

viram histórias heroicas.

Os que destruíram produção:

viram:

“exceções”.

Survivorship ajuda:

a cultura a celebrar:

heroísmo.


🧠 Hero Culture

Analista executa:

comando arriscado.

Salva sistema.

Herói.

Mas:

foi procedimento correto?

Talvez.

Ou:

uma aposta que funcionou.

Se premiamos:

outcome,

podemos treinar:

mais apostas.


🎯 Pergunta Bellacosa nº 4

“Estamos premiando o resultado ou o processo que gostaríamos que fosse repetido?”


🧠 Isso é enorme para liderança

Porque recompensa:

ensina.

Se pessoa toma:

risco absurdo

e ganha:

elogio,

organização aprende:

risco = heroísmo.


☕ Toda premiação é:

uma pequena política operacional.


🧠 Outcome Bias e Campbell’s Law

Métrica:

incidente resolvido rápido.

Analista:

restart sem investigação.

Funciona.

MTTR:

excelente.

Resultado:

bom.

Processo:

questionável.

Campbell incentiva.

Outcome Bias:

legitima.

Agora:

restart vira:

best practice.


🧠 Goodhart entra sorrindo

Metric:

MTTR.

Goal:

service restoration.

Quando resultado:

MTTR cai,

todo mundo:

feliz.

Mas:

evidência destruída;

root cause desconhecida.

Outcome Bias:

“foi ótimo.”


🎯 Pergunta Bellacosa nº 5

“O resultado melhorou a métrica ou realmente melhorou a capacidade do sistema?”


🧠 Outcome Bias e Goal Substitution

Objetivo:

decisão segura.

Proxy:

mudança terminou sem incidente.

Agora:

sem incidente = decisão segura.

Não.

Pode ser:

sorte.

Goal Substitution.


🧠 Outcome Bias em projeto

Projeto entrega:

no prazo.

Management:

excelente planejamento.

Equipe:

trabalhou 90 horas por semana.

Technical debt:

explodiu.

Resultado visível:

bom.

Processo:

terrível.


☕ Entregar sexta

não significa:

que sexta era prazo racional.

Talvez apenas:

que humanos pagaram a diferença.


🧠 Ratchet Effect

Projeto termina:

graças a heroísmo.

Management:

“Agora sabemos que conseguem.”

Nova meta:

mais agressiva.

Outcome Bias faz:

esforço excepcional parecer:

capacidade normal.

Ratchet transforma:

em piso.


🎯 Pergunta Bellacosa nº 6

“O sucesso foi sustentável ou comprado com recurso invisível?”


🧠 Hidden costs

Overtime.

Stress.

Manual work.

Future debt.

None:

in outcome dashboard.

McNamara Fallacy.

Metric Fixation.


☕ O resultado pode estar:

verde

porque a conta foi:

movida para amanhã.


🧠 Outcome Bias em incident response

Imagine:

analista decide:

restart.

Sem dump.

Sem coleta de estado.

Sistema volta.

Resultado:

success.

Management:

“ótima decisão.”

Mas:

se sistema não voltasse,

todos diriam:

“irresponsável.”

Mesma decisão.

Mesmo processo.

Só resultado:

mudou.

Outcome Bias.


🧠 Qualidade da decisão precisa ser avaliada antes de saber o fim

Idealmente:

decision rules.


🎯 Pergunta Bellacosa nº 7

“Se o resultado tivesse sido o oposto, eu avaliaria a mesma decisão de maneira completamente diferente?”

Se sim:

alerta de Outcome Bias.


🧠 Exemplo de poker

Poker é ótima analogia.

Jogador:

vai all-in com mão péssima.

Ganha.

Boa jogada?

Não necessariamente.

Jogador:

faz jogada probabilisticamente ótima.

Perde.

Má jogada?

Não.

Resultado:

é uma amostra.

Decisão:

é processo.


☕ Mainframe poker

CHANGE WITHOUT ROLLBACK

e:

production works.

Você ganhou:

a mão.

Não quer dizer:

que deveria repetir.


🧠 Outcome Bias e probability blindness

Se evento:

10% chance de desastre,

90% das vezes:

funciona.

Então alguém pode fazer:

nove vezes.

Tudo certo.

Concluir:

“seguro.”

Décima:

boom.

Matematicamente:

esperado.

Culturalmente:

surpresa.


🎯 Pergunta Bellacosa nº 8

“Quantas vezes esse processo precisa dar certo para provar segurança — e isso realmente prova?”


🧠 Risk is not binary

Antes do evento:

risk distribution.

Depois:

um outcome.

Uma realização.

Não confunda:

amostra

com:

distribuição.


☕ Depois que dado caiu

parece que:

sempre cairia daquele lado.

Antes:

não.


🧠 Outcome Bias e Zero-Risk Bias

Controle implementado.

Sem incidentes.

Conclusão:

risk zero.

Talvez:

não.

Só:

zero eventos observados.

McNamara.


🧠 Outcome Bias e Illusion of Control

Fizemos:

procedimento improvisado.

Funcionou.

Agora acreditamos:

“sabemos controlar.”

Talvez:

não.

Só:

funcionou naquele contexto.


🎯 Pergunta Bellacosa nº 9

“Esse sucesso demonstrou controle causal ou apenas coincidiu com nossas ações?”


🧠 Post hoc

Restart.

Sistema melhora.

Logo:

restart causou.

Pode ser.

Ou:

external dependency recovered ao mesmo tempo.

Outcome Bias + Post Hoc.


☕ Serviço voltar depois de comando

é evidência.

Não necessariamente:

prova.


🧠 Outcome Bias em RCA

Postmortem pergunta:

“qual decisão foi errada?”

Se incident:

grande,

pressão:

achar decisão errada.

Mas talvez:

todos tenham tomado decisões razoáveis

e evento raro:

ocorreu.

Se inventamos:

culpado retrospectivo,

aprendizado piora.


🧠 Blameless não significa sem análise

Significa:

avaliar:

process.

Information.

Constraints.


🎯 Pergunta Bellacosa nº 10

“A decisão era ruim com a informação disponível na hora ou parece ruim apenas porque agora sabemos o final?”


🧠 Fundamental Attribution Error

Outcome ruim.

Pessoa decidiu.

Culpado.

Mas:

contexto?

Procedure?

Signals?

Tool?

Need.


🧠 Authority Gradient

Junior segue:

senior.

Outcome ruim.

Depois:

culpam junior por:

não questionar.

Mas:

poderia?

Psych safety?

Again.


☕ Resultado não reconstrói:

liberdade que alguém tinha antes.


🧠 Outcome Bias em change management

CAB aprova:

mudança bem testada.

Falha por:

evento raro.

Depois:

“CAB aprovou mudança ruim.”

Talvez:

approval correto.

What matters:

information available.


🧠 Outra mudança sem teste

Passa.

“CAB flexible.”

Danger.


🎯 Pergunta Bellacosa nº 11

“Estamos aprendendo com o processo de decisão ou apenas classificando vencedores e perdedores?”


🧠 Outcome Bias e Hindsight Bias juntos

Depois de falha:

“Era óbvio.”

“Decisão era ruim.”

Combo.

Mas antes:

talvez todos:

aprovaram.

Preserve:

decision record.


🧠 Decision Journal

Antes:

DECISION:
Proceed.

KNOWN RISKS:
A, B, C.

UNKNOWN:
D.

EXPECTED BENEFIT:
X.

ROLLBACK:
validated.

CONFIDENCE:
medium-high.

Depois:

compare.

Isso é ouro.


☕ Sem registro anterior

memória vira:

roteirista.


🧠 Outcome Bias e Narrative Bias

Resultado final:

molda história.

Sucesso:

“plano foi excelente.”

Fracasso:

“avisos estavam por toda parte.”

Narrative Bias arruma:

eventos

para combinar.


🎯 Pergunta Bellacosa nº 12

“Estamos contando a história que realmente vivemos ou a história que faz sentido depois do resultado?”


🧠 Outcome Bias e Confirmation Bias

Se resultado:

confirma crença,

remember strongly.

If contrary:

call anomaly.

Example:

“Cloud is unreliable.”

Cloud outage:

proof.

Mainframe outage:

exception.

Opposite side:

vice versa.

Outcome Bias feeds:

Confirmation.


☕ Um resultado vira:

munição ideológica.


🧠 Outcome Bias em architecture

Migração para microservices:

successful.

Conclusion:

architecture choice perfect.

Maybe:

team excellent;

scope easy;

low traffic.

One success:

not general rule.


🧠 Pilot Bias

Pilot:

works.

General roll-out:

different scale.

Outcome Bias:

“pilot proved.”

No.

Pilot produced:

evidence.


🎯 Pergunta Bellacosa nº 13

“O resultado demonstra a estratégia ou apenas este caso específico?”


🧠 Outcome Bias e AI

IA recomenda:

ação.

Funciona.

Confidence in AI:

jumps.

But:

was reasoning good?

Maybe:

random.

Or:

multiple possible actions.

Outcome Bias can:

overtrust AI.


🤖 Lucky AI

Model suggests:

restart.

Works.

Now:

organization believes:

agent excellent.

Need:

evaluate reasoning across:

many cases.


🧠 Automation Bias nasce fácil

One successful automation:

trust ↑.

Then:

less human review.

Risk.


🎯 Pergunta Bellacosa nº 14

“Estamos validando o modelo pelo método ou pelo fato de uma recomendação ter funcionado?”


🧠 AI agent action evaluation

Separate:

decision quality;

execution quality;

outcome.

Three layers.


🧠 Bellacosa Decision Stack

1. INFORMATION QUALITY
2. REASONING QUALITY
3. DECISION QUALITY
4. EXECUTION QUALITY
5. OUTCOME

Outcome:

last.

Organizations often evaluate:

only last.


☕ Resultado é:

linha final.

Não:

programa inteiro.


🧠 Outcome Bias em A/B testing

Experiment gives:

positive result.

Decision:

good?

Maybe.

Was design:

valid?

Sample?

Duration?

Bias?

Need:

method.

Good outcome from:

bad experiment

still:

bad evidence.


🎯 Pergunta Bellacosa nº 15

“O experimento foi bom ou apenas produziu o número que queríamos?”


🧠 Outcome Bias em segurança

Admin disables:

security control

to solve:

issue.

No breach occurs.

Conclusion:

control unnecessary.

Danger.

Non-event:

not proof.


☕ “Nunca fomos atacados”

é uma frase:

perigosíssima

para avaliar segurança.


🧠 Absence of bad outcome

Not:

proof of good decision.


🧠 Outcome Bias e Moral Hazard

Pessoa toma:

risco.

Outro paga:

if fails.

Mas:

works.

Pessoa rewarded.

Risk-taking increases.

Moral Hazard.


🎯 Pergunta Bellacosa nº 16

“Quem receberia a consequência se essa decisão desse errado?”

If different from:

quem ganha elogio,

attention.


🧠 Principal-Agent

Manager chooses:

aggressive deadline.

Team absorbs:

cost.

Success.

Manager:

reward.

Outcome Bias:

“great leadership.”

Hidden cost:

team burnout.

Principal-Agent.


☕ Sucesso de quem?

Resultado bom:

para qual stakeholder?

Outra pergunta:

importante.


🧠 Outcome Bias e McNamara Fallacy

Dashboard:

green.

Decision:

good.

But:

manual toil;

knowledge risk;

customer workaround

not measured.

Outcome definition:

too narrow.


🎯 Pergunta Bellacosa nº 17

“Qual resultado estamos chamando de sucesso e o que ficou fora da medição?”


🧠 Metric Fixation

Change:

successful

because:

deployment completed.

But:

customer value?

Errors?

Debt?

Metric says:

success.

Outcome Bias:

decision good.


☕ Deploy成功—

ops, não japonês agora—

não significa:

business success.


🧠 Goal Substitution

Goal:

safe service.

Outcome metric:

deploy complete.

Bad proxy.


🧠 Outcome Bias e Near Miss

Need:

study successful risky events.

Very important.

Not only:

incidents.

Ask:

“Where were we lucky?”


🎯 Pergunta Bellacosa nº 18

“Que parte desse sucesso dependeu de algo que quase deu errado?”


🧠 Near-miss review

Example:

rollback untested

but not needed.

Do not say:

“no problem.”

Say:

“we got away with it.”

Then:

fix process.


☕ Aprender só com falhas

é esperar:

pagar matrícula.

Near miss:

curso grátis.


🧠 Outcome Bias e safety culture

A mature safety culture studies:

process

even when:

nothing bad happened.

Aviation does:

near misses.

IT should:

too.


🧠 Outcome Bias e Normalization of Deviance novamente

Every successful unsafe action:

reinforces:

deviation.

Outcome Bias:

“see, safe.”

Then:

normalized.


🎯 Pergunta Bellacosa nº 19

“Estamos transformando ausência de acidente em autorização para repetir o desvio?”


🧠 Outcome Bias e Risk Compensation

Backup exists.

Risky deploy works.

Confidence rises.

Next deploy:

more risky.

Loop.


🧠 Positive feedback danger

RISKY ACTION
↓
SUCCESS
↓
CONFIDENCE
↓
MORE RISK
↓
SUCCESS
↓
EVEN MORE RISK

Until:

failure.


☕ O sistema está:

ensinando coragem

com dados insuficientes.


🧠 Outcome Bias e Dunning-Kruger

Novice makes:

bad call.

Lucky success.

Confidence jumps.

Now:

knows.

Danger.

Expert may:

know luck.

Difference:

calibration.


🎯 Pergunta Bellacosa nº 20

“Esse sucesso aumentou nosso conhecimento ou apenas nossa confiança?”

Excellent.


🧠 Outcome Bias e overconfidence

Repeated successes:

produce:

overconfidence.

Especially if:

environment forgiving.

Then:

new context.

Boom.


🧠 Outcome Bias em batch operations

Operator changes:

JCL manually.

Works.

Next time:

same.

Maybe dataset conditions:

different.

Need:

understand.


☕ “Fiz assim da outra vez”

é:

outcome memory.

Não:

procedimento.


🧠 Outcome Bias e technical debt

Shortcut:

works.

Feature delivered.

Success.

Debt:

future.

Outcome Bias:

shortcut validated.

Years later:

maintenance pain.


🎯 Pergunta Bellacosa nº 21

“O resultado foi bom no horizonte certo?”

Huge.

Today:

good.

One year:

bad.


🧠 Time horizon matters

A decision can:

look brilliant today

and terrible later.

Outcome evaluation:

needs horizon.


END-OF-DAY

não é:

END-OF-SYSTEM.


🧠 Outcome Bias em SLA

SLA met.

Customer unhappy.

Outcome according:

contract good.

Real outcome:

maybe bad.

Definition matters.


🧠 Outcome Bias e cost cutting

Cut:

redundancy.

Savings achieved.

No outage.

Decision praised.

Two years later:

outage.

Was initial decision good?

Need:

risk model.

Not:

short-term result.


🎯 Pergunta Bellacosa nº 22

“Estamos avaliando decisão pelo resultado imediato ou pelo risco total criado?”


🧠 Outcome Bias e governance

Governance should evaluate:

process adherence.

But:

not blindly.

If process:

bad,

change.

Still:

don't excuse poor reasoning because:

result good.


🧠 Decision audit

Ask:

what information?

what alternatives?

what probabilities?

what trade-offs?


☕ Auditoria de decisão

não:

tribunal de resultado.


🧠 Outcome Bias e leadership

Good leader:

rewards:

sound decision

even if unlucky.

Also:

challenges:

reckless decision

even if lucky.

This is:

hard.

Because humans:

love winners.


🎯 Pergunta Bellacosa nº 23

“Eu teria elogiado essa decisão antes de saber que funcionou?”

Fantastic.


🧠 Reverse outcome test

Imagine:

same process,

opposite outcome.

Would judgment:

flip?

If yes:

Outcome Bias.


🧠 Bellacosa Coin Flip Test

Decision:

deploy without rollback.

Scenario A:

success.

Scenario B:

failure.

If your evaluation:

good vs bad

changes entirely,

ask:

process.


☕ A moeda não:

reescreve procedimento.


🧠 Outcome Bias e risk committees

Approve risk:

based on expected value.

Event materializes.

Later:

“committee failed.”

Maybe:

not.

A risk of 1% can:

occur.


🧠 Probability does not mean guarantee

1% event occurring:

doesn't prove estimate wrong.

Could.

But not automatically.


🎯 Pergunta Bellacosa nº 24

“Estamos confundindo evento improvável que ocorreu com previsão ruim?”


🧠 Forecast calibration

Need:

many forecasts.

Not:

one.

If 10% events occur:

roughly 10% over many cases,

calibrated.

One event:

not enough.


🧠 Outcome Bias e incident severity predictions

Team says:

low chance.

Happens.

Everyone:

“they were wrong.”

Maybe.

Need:

track.


☕ Probabilidade é:

população.

Resultado é:

indivíduo.


🧠 Outcome Bias e Hindsight in postmortem

The classic sentence:

“Why did they do that?”

With outcome known:

decision looks:

obvious.

Reconstruct:

what they saw.


🧠 Local rationality

People often do:

what made sense

locally.

Learn:

why.


🎯 Pergunta Bellacosa nº 25

“Que decisão eu tomaria se estivesse no lugar deles com apenas as informações que eles tinham naquele minuto?”


🧠 Outcome Bias e Action Bias

During incident:

do something.

It works.

Outcome validates:

action bias.

Next time:

act fast again.

Maybe wrong.


🧠 Omission Bias

Person waits.

System recovers naturally.

Outcome:

good.

Now:

inaction praised.

Again:

result alone.

Need:

reason.


☕ Ação e omissão

ambas podem:

ter sorte.


🧠 Outcome Bias e Plan Continuation Bias

Pilot continues:

arrives safely.

Conclusion:

continuing was right.

Maybe:

unsafe.

Success can:

normalize continuation.


🎯 Pergunta Bellacosa nº 26

“Chegar ao destino provou que continuar era seguro?”

No.


🧠 Outcome Bias em capacity

System at:

95%.

No outage.

Conclusion:

capacity okay.

Maybe:

near cliff.

Need:

margin.


🧠 Outcome vs margin

Important.

Successful operation:

without resilience margin

is:

fragile success.


☕ Verde colado no vermelho

não é:

conforto.


🧠 Outcome Bias e resilience

A resilient system should be:

evaluated by:

ability to absorb variation.

Not:

one successful run.


🎯 Pergunta Bellacosa nº 27

“Quanto de margem restou durante o sucesso?”


🧠 Outcome Bias e chaos engineering

Controlled failure:

may reveal:

weakness.

If test fails:

good?

Maybe.

Because:

learned safely.

Outcome “failure” of test:

valuable.

Outcome Bias might call:

test bad.

Wrong.


☕ Um teste de caos que encontra problema

teve:

sucesso.

Beautiful paradox.


🧠 Test outcome depends on purpose

If purpose:

discover weakness,

finding:

weakness

is:

successful.

Goal definition.


🎯 Pergunta Bellacosa nº 28

“Estamos julgando o resultado segundo o objetivo real do experimento?”


🧠 Outcome Bias e QA

Tester finds:

many bugs.

Metric:

quality bad?

Maybe testing:

good.

Team with:

zero bugs reported

may:

test poorly.

Again.


🧠 Prevention vs visible outcomes

Good testing creates:

bad-looking numbers.

McNamara.


☕ Uma área que encontra problemas

pode estar:

funcionando.

Uma que encontra zero:

pode estar dormindo.


🧠 Outcome Bias e security incidents

Red team breaches:

system.

Bad outcome?

Actually:

exercise success.

It found:

weakness.

Need:

context.


🧠 Outcome Bias e AI evals

Model gives:

correct answer.

Reasoning:

wrong.

Should we:

reward?

Maybe if only outcome.

But in critical domains:

danger.


🤖 Shortcut reasoning

Right answer by:

wrong reason

can fail:

next case.

This is huge.


🎯 Pergunta Bellacosa nº 29

“O sistema acertou porque entendeu ou porque encontrou um atalho que funcionou neste caso?”


🧠 Outcome Bias e COBOL beginner

Program compiles.

Runs.

Output looks:

right.

Code:

good?

Not necessarily.

Test:

one input.

Need:

boundaries.

Errors.

File status.


☕ “Funcionou comigo”

é a versão júnior de:

Outcome Bias.


🧠 COBOL example

       DIVIDE WS-A BY WS-B
           GIVING WS-C.

Test:

B = 2.

Works.

Conclusion:

done.

What if:

B = 0?

Outcome Bias:

one success.

Need:

test design.


🎯 Pergunta Bellacosa nº 30

“Quantos cenários diferentes sustentam nossa confiança?”


🧠 Outcome Bias e error handling

No error occurred.

Therefore:

error handling unnecessary.

Classic.

Until:

error.


☕ Código de exceção

parece inútil

nos dias:

em que tudo funciona.


🧠 Outcome Bias e backup/restore

Never restored.

No disaster.

Backup process:

“successful.”

Then:

need restore.

Surprise.

Again.


🧠 Outcome Bias e redundancy

Never used second region.

Cost center.

Remove.

Then:

incident.

Short-term outcome:

misleading.


🎯 Pergunta Bellacosa nº 31

“Estamos julgando controles de contingência pela frequência com que precisaram ser usados?”

Excellent.


🧠 Outcome Bias e Zero-Risk management

Control not used:

seems waste.

But:

insurance.

Hard to value.

McNamara.


🧠 Outcome Bias e Principal-Agent

Executive gets:

bonus based on year's results.

Chooses:

risk that matures later.

Year good.

Decision praised.

Future:

someone else pays.

Outcome horizon matters.


☕ Resultado de dezembro

pode ser:

conta de janeiro.


🧠 Outcome Bias e Moral Hazard again

Decision-maker rewarded:

if good.

Limited consequence:

if bad.

Success reinforces:

risk.


🎯 Pergunta Bellacosa nº 32

“O horizonte de avaliação termina antes do horizonte do risco?”

Brutal.


🧠 Outcome Bias e metrics

Quarterly metrics:

green.

Long-term:

knowledge decay.

Cultural Debt.

Mainframe skills.

No incident:

today.

Capacity loss:

later.

Outcome bias:

“staffing fine.”


☕ Não ter incidente hoje

não prova:

que aposentadoria coletiva amanhã está resolvida.


🧠 Outcome Bias e knowledge transfer

Senior remains.

Everything works.

No cross-training.

Management:

“not needed.”

Then:

senior leaves.

Outcome changed.

Process was:

bad long before.


🎯 Pergunta Bellacosa nº 33

“Estamos confundindo estabilidade atual com resiliência futura?”


🧠 Outcome Bias e Cultural Debt

Decision:

centralize knowledge.

Works:

years.

Outcome:

success.

Culture forms.

Later:

single point of failure.

The original decision may have:

been right then.

Outcome Bias appears if we say:

“because it succeeded for 20 years, it must remain right forever.”

Different problem.

Cultural Debt.


🧠 Temporal context

Decision quality:

at time T1.

Re-evaluate:

at T2.

Don't use historical success:

as permanent proof.


🎯 Pergunta Bellacosa nº 34

“O fato de essa decisão ter funcionado no passado prova que ainda é a melhor decisão hoje?”


🧠 Outcome Bias e Status Quo

Historical success:

anchors.

Status quo:

protected.

“Never failed.”

Until:

environment changes.


☕ “Sempre funcionou”

é:

estatística histórica.

Não:

contrato futuro.


🧠 Outcome Bias e innovation

Experiment fails.

Maybe:

good experiment.

Learned.

If punish:

failure outcome,

people stop:

experimenting.


🧠 Innovation needs process evaluation

Was hypothesis reasonable?

Test cheap?

Learning valuable?

Then:

failure can be:

success.


🎯 Pergunta Bellacosa nº 35

“O experimento fracassou ou nos poupou de fracassar em escala maior?”


🧠 Outcome Bias e blame culture

If any bad outcome:

someone punished,

people hide:

risks.

Avoid:

experiments.

Report less.

Safety worsens.


☕ Organizações que punem todo resultado ruim

acabam recebendo:

menos notícias ruins.

Não necessariamente:

menos problemas.


🧠 Campbell again

If “zero incidents” = good manager,

incidents:

reclassified.

Outcome metric:

corrupted.


🧠 Outcome Bias e near miss reporting

Need reward:

reporting.

Not:

only zero incidents.


🎯 Pergunta Bellacosa nº 36

“Nosso sistema incentiva aprender com quase-erros ou escondê-los porque o resultado final foi bom?”


🧠 Outcome Bias e decision quality matrix

Uma ferramenta ótima:

                    OUTCOME

              GOOD          BAD

GOOD        DESERVED      BAD LUCK
DECISION    SUCCESS

BAD         LUCKY         DESERVED
DECISION    SUCCESS       FAILURE

Isso é:

poderoso.


☕ Quatro quadrantes

não:

dois.


🧠 Quadrante 1 — Boa decisão / bom resultado

Ótimo.

Repetir:

talvez.


🧠 Quadrante 2 — Boa decisão / resultado ruim

Aprenda:

mas não destrua:

processo bom

por azar.


🧠 Quadrante 3 — Decisão ruim / resultado bom

O quadrante mais perigoso.

Porque:

ensina comportamento errado.


🧠 Quadrante 4 — Decisão ruim / resultado ruim

Fácil:

ver.

Aprender.


🎯 Pergunta Bellacosa nº 37

“Estamos no quadrante do sucesso merecido ou do sucesso sortudo?”


👻 Easter Egg nº 2 — TARDIS Decision Matrix

Companion:

— Doctor, escolhi aleatoriamente o botão vermelho e salvamos o planeta.

Doctor:

— Excelente resultado.

— Então foi ótima decisão?

— Havia 10 botões?

— Sim.

— Nove explodiam o planeta?

— Sim.

Doctor:

— Não faça novamente.

— Mas funcionou.

Doctor:

— Isso é exatamente o problema.


🧠 Process praise

Instead of:

“great result,”

say:

“great process.”

What process?

Collected evidence.

Tested rollback.

Defined no-go.

Good.


🧠 Outcome praise

Still:

celebrate success.

But don't:

confuse.


🎯 Pergunta Bellacosa nº 38

“Que parte da decisão merece ser repetida independentemente do resultado?”


🧠 Bellacosa Decision Review

Before outcome:

record:

DECISION:
Proceed / Hold

INFORMATION:
...

ALTERNATIVES:
...

KNOWN RISKS:
...

EXPECTED PROBABILITY:
...

GUARDRAILS:
...

REASON:
...

After:

evaluate:

separately.


🧠 Ex Ante vs Ex Post

Fancy Latin-ish:

ex ante:

before outcome.

ex post:

after.

Decision quality:

should be evaluated:

mostly ex ante.

Outcome:

ex post.


☕ A decisão mora:

antes.

O resultado mora:

depois.

Não misture endereços.


🧠 Outcome Bias e postmortem questions

Bad:

“Why did you make the wrong decision?”

Already assumes.

Better:

“What information and constraints shaped the decision?”

Then:

“What would improve that process?”


🎯 Pergunta Bellacosa nº 39

“Nossa pergunta de postmortem já declarou a decisão errada antes de analisá-la?”


🧠 Outcome Bias e risk estimate

Suppose:

95% success probability.

Fails.

Was estimate:

wrong?

One event:

can't tell.

Track:

many.

Calibration.


🧠 Calibration culture

If 70% confidence predictions succeed:

70-ish.

Good.


☕ Confiança de 70%

significa:

algumas vezes:

falhar.

Se nunca falha:

talvez confidence wrong too.


🧠 Outcome Bias e managers who "always deliver"

Maybe:

select easy projects.

Survivorship.

Need:

risk-adjusted.


🎯 Pergunta Bellacosa nº 40

“Estamos comparando resultados sem comparar o risco assumido para obtê-los?”


🧠 Risk-adjusted performance

Trader analogy.

Two teams:

same outcome.

One:

low risk.

Another:

bet company.

Not same.


☕ Ganhar R$1 milhão

apostando R$10 mil

não é igual:

a ganhar R$1 milhão

apostando a empresa.


🧠 IT version

Two deploys:

success.

One:

tested rollback.

Other:

none.

Outcome:

same.

Decision quality:

not.


🧠 Outcome Bias e change success rate

Metric:

99% changes successful.

Great.

But:

maybe definition:

no incident within 1h.

Long-term bugs:

not counted.

Outcome definition:

narrow.


🎯 Pergunta Bellacosa nº 41

“Como definimos sucesso e por quanto tempo observamos?”


🧠 Observation window

Critical.

Change:

looks fine.

24h later:

data corruption.

Was success?

No.

Need:

correct window.


CHANGE SUCCESS

às 18:05

pode virar:

INCIDENT

às 03:00.


🧠 Outcome Bias e slow failures

Drift.

Technical debt.

Security.

Knowledge.

Results delayed.

Short-term success:

misleading.


🧠 Outcome Bias e Drift Into Failure

Each decision:

works.

Margin:

shrinks.

No incident.

Success repeatedly:

validates.

Eventually:

failure.

Classic.


🎯 Pergunta Bellacosa nº 42

“Cada sucesso preservou margem ou apenas evitou a falha por pouco?”


🧠 Outcome Bias e Normalization of Deviance

Again, perfect.

Deviation:

works.

Outcome good.

Deviation validated.

Repeat.

Eventually:

normal.


☕ Outcome Bias é:

contador de histórias

da Normalization of Deviance.


🧠 Outcome Bias e safety margin

Measure:

how close to limits.

Not:

only pass/fail.


🧠 Green isn't enough

Need:

distance to red.


🎯 Pergunta Bellacosa nº 43

“Quanto faltou para esse sucesso virar incidente?”

Maybe strongest near-miss question.


🧠 Outcome Bias e COBOL production support

Programmer runs:

manual fix.

Works.

Be careful:

document.

Understand.

Automate maybe.

Don't:

turn lucky fix:

into oral tradition.


🧠 Cultural Debt from lucky fixes

“Always run this command.”

Why?

Nobody knows.

It once worked.

Outcome Bias fossilized.


☕ Runbook arqueológico

cheio de:

rituais que funcionaram uma vez.


🧠 Ask why

What state does command change?

Mechanism.


🎯 Pergunta Bellacosa nº 44

“Sabemos por que esse procedimento funciona ou apenas sabemos que já funcionou?”


🧠 Outcome Bias e technical superstition

This is fun.

Operations sometimes develop:

rituals.

“Restart X before Y.”

“Wait 30 seconds.”

Maybe necessary.

Maybe superstition.

Outcome Bias:

successful runs reinforce.


👻 Easter Egg nº 3 — ritual COBOL

//STEP1 EXEC PGM=IKJEFT01
//*
* DO NOT REMOVE.
* NOBODY KNOWS WHY.
* SYSTEM FAILED ONCE IN 2004
* WHEN THIS STEP WAS REMOVED.

There.

Cultural Debt + Outcome Bias.


🧠 Scientific testing

Test mechanism.

Don't disrespect legacy blindly.

Maybe:

real dependency.

Investigate.


☕ Nem toda superstição

é falsa.

Mas merece:

prova.


🧠 Outcome Bias e reversibility

Decision with:

rollback

is different from:

irreversible.

Even same outcome.

Decision quality considers:

optionality.


🎯 Pergunta Bellacosa nº 45

“Se estivéssemos errados, tínhamos como voltar?”

Very important.


🧠 Outcome Bias e option value

Good process:

limits downside.

Even if:

outcome same.


🧠 Outcome Bias e blast radius

Small canary:

fails.

Bad outcome?

Actually:

good decision.

Limited damage.

Full rollout:

succeeds.

Good outcome.

But:

riskier decision.

Again.


☕ Canary falhar

pode ser:

sucesso da estratégia.


🎯 Pergunta Bellacosa nº 46

“O desenho da decisão limitou o dano caso estivéssemos errados?”


🧠 Outcome Bias e experimentation

Canary.

Feature flag.

Rollback.

Shadow traffic.

These improve:

decision quality.

Outcome may:

still fail.

But failure:

cheap.


🧠 Outcome Bias em incident escalation

Escalate early.

Incident turns:

minor.

People say:

“overreaction.”

Maybe escalation:

helped keep minor.

Counterfactual.


☕ Controle bem-sucedido

pode parecer:

desnecessário

justamente porque:

funcionou.


🧠 Prevention paradox

Very relevant.

If control prevents:

bad outcome,

people may think:

risk never existed.


🎯 Pergunta Bellacosa nº 47

“O bom resultado aconteceu apesar do controle ou por causa dele?”


🧠 Outcome Bias e security patch

Patch emergency.

No exploit before.

Later:

“unnecessary rush.”

Maybe patch:

prevented.

Hard to prove counterfactual.


🧠 McNamara Fallacy again

Prevention:

hard to measure.

Outcome Bias:

undervalues.


🧠 Outcome Bias e false lessons

The worst thing an organization can learn from:

success:

the wrong lesson.

Failure often:

forces review.

Success:

doesn't.


☕ Sucesso pode:

encerrar curiosidade

mais rápido que:

fracasso.

Interessante.


🧠 Search Satisfaction after success

System works.

Stop asking.

Outcome Bias.

Another connection.


🎯 Pergunta Bellacosa nº 48

“O sucesso está nos impedindo de investigar um near miss?”


🧠 Success postmortem

Do them sometimes.

Not only:

failures.

Ask:

what went right?

What was luck?

What was fragile?

Excellent.


🧠 Pre-mortem and post-success review

Combination.


☕ War Room zero

mas aprendizado:

muito.


🧠 Bellacosa Success Review

WHAT WAS PLANNED?
WHAT ACTUALLY HAPPENED?
WHAT WORKED BECAUSE OF PROCESS?
WHAT WORKED BECAUSE OF LUCK?
WHAT ALMOST FAILED?
WHAT SHOULD NOT BE REPEATED?

Beautiful.


🧠 Outcome Bias e risk-adjusted learning

Classify:

process:

good/bad.

Outcome:

good/bad.

Use matrix.


📋 Bellacosa Outcome Matrix

                    RESULTADO

                BOM             RUIM

PROCESSO       SUCESSO         AZAR /
BOM            MERECIDO        EVENTO ADVERSO

PROCESSO       SUCESSO         FALHA
RUIM           SORTUDO         MERECIDA

Focus:

bottom-left.


☕ O quadrante mais perigoso:

processo ruim + resultado bom.

Porque:

parece:

sucesso.

Mas:

treina desastre.


🧠 Outcome Bias e Reward Design

Reward:

quality of process.

Not only:

outcome.

Obviously:

outcome matters too.

Balance.


🎯 Pergunta Bellacosa nº 49

“Que comportamento estamos ensinando ao elogiar este sucesso?”


🧠 Bellacosa Anti-Outcome Protocol

Passo 1 — Congele a informação ex ante

Before result:

write what knew.

Passo 2 — Registre alternativas

Why chose this?

Passo 3 — Registre risco

Expected probabilities.

Passo 4 — Registre guardrails

Rollback, canary, monitoring.

Passo 5 — Depois observe resultado

Separately.

Passo 6 — Avalie processo

Would repeat?

Passo 7 — Procure sorte e azar

What wasn't controlled?

Passo 8 — Procure near miss

How close?

Passo 9 — Avalie horizonte

Immediate and long-term.

Passo 10 — Atualize decision rules

Not hero stories.


📋 Checklist Bellacosa anti-Outcome Bias

[ ] Como essa decisão parecia antes do resultado?

[ ] Quais informações estavam disponíveis?

[ ] O risco era conhecido?

[ ] Havia alternativas melhores?

[ ] Existia rollback?

[ ] O processo seguiu critérios razoáveis?

[ ] O sucesso dependeu de sorte?

[ ] Houve near miss?

[ ] O resultado ruim era evento possível mesmo com boa decisão?

[ ] Estou reescrevendo a história depois do fato?

[ ] Eu avaliaria a decisão igual com outcome oposto?

[ ] O horizonte de avaliação é adequado?

[ ] Qual custo invisível produziu o resultado?

[ ] Estamos premiando comportamento repetível?

[ ] O sistema preservou margem?

🧠 Bellacosa Decision Card

DECISION:
________________________

INFORMATION AVAILABLE:
________________________

ALTERNATIVES:
________________________

EXPECTED RISKS:
________________________

GUARDRAILS:
________________________

DECISION QUALITY:
GOOD / QUESTIONABLE / POOR

OUTCOME:
GOOD / BAD

LUCK FACTOR:
LOW / MEDIUM / HIGH

WOULD REPEAT?
YES / NO

👻 Easter Egg nº 4 — BELLACOSA.BIAS

Na manhã seguinte aparece:

BELLACOSA.BIAS(OUTCOME)

Dentro:

       IF OUTCOME = 'SUCCESS'
           PERFORM REVIEW-DECISION-PROCESS
       END-IF.

       IF OUTCOME = 'FAILURE'
           PERFORM REVIEW-DECISION-PROCESS
       END-IF.

       IF PROCESS-QUALITY = 'POOR'
          AND OUTCOME = 'SUCCESS'
           DISPLAY
           'WARNING: LUCKY SUCCESS - DO NOT NORMALIZE'
       END-IF.

       IF PROCESS-QUALITY = 'GOOD'
          AND OUTCOME = 'FAILURE'
           DISPLAY
           'DO NOT PUNISH SOUND DECISION FOR BAD LUCK'
       END-IF.

Comentários:

* GOOD OUTCOME
* DOES NOT AUTOMATICALLY MEAN
* GOOD DECISION.

Outro:

* BAD OUTCOME
* DOES NOT AUTOMATICALLY MEAN
* BAD DECISION.

Outro:

* LUCK
* IS NOT
* A CONTROL FRAMEWORK.

Outro:

* DO NOT TURN
* LUCKY SUCCESS
* INTO STANDARD PROCEDURE.

E naturalmente:

* TARDIS LANDING:
* SUCCESSFUL.
*
* PILOTING METHOD:
* RANDOM BUTTON.
*
* RECOMMENDATION:
* DO NOT REPEAT.

🕰️ Voltando para sexta-feira, 20:00

Change:

successful.

Todos comemoram.

Nosso jovem pergunta:

— Então adiamos os testes de rollback?

Gerente:

— Para quê? Funcionou.

Silêncio.

O Doctor olha:

para ele.

Nosso jovem entende.

— Não.

Gerente:

— Não?

— O fato de não precisarmos do rollback não prova que poderíamos continuar sem testá-lo.

Gerente:

— Mas deu certo.

Nosso jovem:

— Desta vez.

Doctor sorri.


🧠 Segunda-feira

Equipe faz:

teste de rollback.

Falha.

Silêncio.

Se produção tivesse:

quebrado sexta,

talvez:

não conseguissem voltar.

Agora percebem:

o sucesso não demonstrou segurança.

Apenas:

não exigiu:

o mecanismo de recuperação.


☕ Esse é o ponto

O resultado positivo:

escondeu:

uma vulnerabilidade real.


🧠 Agora imagine o contrário

Outra mudança.

Tudo testado.

Rollback.

Canary.

Peer review.

Good.

Ainda assim:

um firmware defect raro

causa:

falha.

Postmortem maduro:

não diz automaticamente:

“decisão ruim.”

Pergunta:

“Havia evidência razoável para prever isso?”

Se não:

learn.

Improve.

Don't:

rewrite history.


🎯 Pergunta Bellacosa nº 50

“O que poderíamos razoavelmente saber antes — e o que só ficou visível depois?”

Essa talvez seja:

a pergunta central.


🧬 Regeneração organizacional

Uma organização madura aprende:

com resultados

sem ser escrava:

dos resultados.

Ela celebra:

sucessos.

Investiga:

falhas.

Mas também:

separa sorte de processo;

premia decisões sólidas;

analisa near misses;

não normaliza improviso porque funcionou;

não pune automaticamente uma boa decisão por um resultado ruim;

e preserva:

o que era conhecido no momento.

Ela entende:

a qualidade da decisão mora no processo; o resultado mora na interação entre processo, contexto, incerteza e sorte.

Principalmente:

não deixa:

sucesso sortudo

virar:

best practice.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Outcome Bias é a tendência de julgar a qualidade de uma decisão pelo resultado que aconteceu depois.

Uma boa decisão pode produzir resultado ruim.

Uma decisão ruim pode produzir resultado bom.

Resultado e qualidade de decisão devem ser avaliados separadamente.

Hindsight Bias faz o resultado parecer mais previsível depois que ele ocorre.

Confirmation Bias usa o resultado para fortalecer crenças anteriores.

Self-Serving Bias pode fazer atribuir sucessos à competência e fracassos ao contexto.

Normalization of Deviance pode crescer quando decisões arriscadas repetidamente terminam bem.

Risk Compensation pode aumentar depois de sucessos que elevam excessivamente a confiança.

Goodhart e Campbell podem recompensar resultados aparentes sem avaliar o processo que os produziu.

Goal Substitution pode transformar “não houve incidente” em sinônimo de “a decisão foi segura”.

Metric Fixation pode esconder custos invisíveis, near misses e margens reduzidas.

McNamara Fallacy pode subvalorizar prevenção e controles cujo sucesso aparece justamente na ausência de eventos.

Ratchet Effect pode transformar esforço heroico bem-sucedido em nova expectativa mínima.

Moral Hazard e Principal-Agent podem fazer alguém receber o mérito pelo sucesso enquanto outra pessoa absorve o risco do fracasso.

Sunk Cost e Escalation of Commitment podem usar resultados favoráveis ocasionais para justificar continuidade.

A IA também pode ganhar confiança excessiva depois de recomendações corretas por motivos errados.

Near misses merecem análise justamente quando o resultado final foi bom.

O quadrante mais perigoso é processo ruim + resultado bom, porque ele ensina a organização a repetir comportamento arriscado.

E principalmente:

um resultado bom não retroativamente transforma uma decisão ruim em boa — da mesma forma que um resultado ruim não transforma automaticamente uma decisão racional em incompetência.


🥚 Easter Egg final

Antes de entrar na TARDIS, o Doctor escreve:

IF OUTCOME = SUCCESS
   DISPLAY 'CONGRATULATIONS'
   PERFORM REVIEW-PROCESS
END-IF.

Nosso jovem pergunta:

— Mesmo quando tudo dá certo?

— Principalmente quando tudo dá certo.

— Por quê?

— Porque depois de uma falha todos querem aprender.

Ele aponta:

para o dashboard verde.

— O perigo é quando o sucesso convence todos de que não existe nada para aprender.

Nosso jovem pensa.

— Então sucesso também pode esconder erro?

Doctor abre:

a porta.

“Os erros mais perigosos às vezes são aqueles que o universo teve a gentileza de não punir imediatamente.”

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro sobra:

“Não pergunte apenas se funcionou. Pergunte se a maneira como decidimos merece funcionar de novo.”

E talvez essa seja toda a essência do Outcome Bias no Bellacosa Mainframe:

o resultado conta o que aconteceu desta vez; o processo de decisão conta aquilo que estamos ensinando à organização para a próxima vez.

☕🌀

Próxima parada: Hindsight Bias — o dia em que, depois que produção caiu, todos descobriram retrospectivamente que os sinais estavam “claríssimos” desde o começo e que qualquer pessoa competente deveria ter previsto exatamente aquilo que ninguém previu.

sábado, 7 de maio de 2011

Outcome Bias: Doctor Who, COBOL e o Dia em que uma Decisão Ruim Deu Certo — e Virou Boa Prática

Bellacosa Mainframe e o outcome bias

☕ Um Café no Bellacosa Mainframe

Outcome Bias: Doctor Who, COBOL e o Dia em que uma Decisão Ruim Deu Certo — e Virou Boa Prática

Uma viagem pela TARDIS dos incidentes para entender por que julgar decisões apenas pelo resultado pode transformar sorte em competência e azar em culpa

02:13.

Madrugada de mudança.

Café morno.

War Room quase silenciosa.

A alteração deveria ter sido validada em homologação.

Não foi.

O rollback deveria ter sido testado.

Também não foi.

Faltava uma reconciliação.

Mas o gerente pergunta:

— Podemos seguir?

O especialista olha para o relógio.

— Acho que sim.

Nosso programador COBOL iniciante pergunta:

— Mas o rollback não foi validado.

O gerente responde:

— Se der problema, corrigimos.

GO.

Mudança executada.

Produção volta.

Tudo funciona.

Nenhum erro.

Nenhum cliente reclama.

Nenhum incidente.

O gerente sorri.

— Viu? Fizemos certo.

Nosso jovem olha para o painel.

Tudo verde.

Talvez o gerente tenha razão.

Talvez realmente tenha sido uma boa decisão.

Na semana seguinte, outra mudança parecida.

Novamente:

rollback não testado.

Reconciliação incompleta.

GO.

Desta vez:

03:17:42
TRANSACTION FAILURE RATE: 21%

03:18.

Fila crescendo.

03:19.

Rollback necessário.

03:20.

Rollback não funciona.

War Room explode.

Horas depois, no post-mortem, alguém diz:

— Foi irresponsável seguir sem testar rollback.

Nosso programador pensa.

Espera.

A mesma decisão da semana anterior havia sido chamada de:

boa.

Agora virou:

irresponsável.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se no corredor.

O Doctor sai.

Olha para os dois change records.

Um:

CHANGE 001
PROCESSO RUIM
RESULTADO BOM

Outro:

CHANGE 002
PROCESSO RUIM
RESULTADO RUIM

Ele pergunta:

— Qual decisão foi pior?

O gerente aponta para a segunda.

— A que causou o incidente.

O Doctor balança a cabeça.

— Não.

— Como não?

— As duas decisões foram praticamente iguais.

Pausa.

— O universo apenas foi mais gentil com vocês na primeira.

Bem-vindo ao:



Outcome Bias

Ou:

Viés de Resultado

A tendência de avaliar a qualidade de uma decisão principalmente pelo resultado que ela produziu, em vez de avaliar se o processo decisório era bom com base nas informações disponíveis naquele momento.


🌀 Nossa TARDIS já conheceu vários monstros

Até aqui passamos por:

Swiss Cheese Model — várias barreiras podem falhar.

Normalization of Deviance — desvios viram rotina.

Hindsight Bias — depois do incidente tudo parece óbvio.

Confirmation Bias — buscamos provas para aquilo em que acreditamos.

Anchoring Bias — a primeira informação pesa demais.

Groupthink — grupos concordam cedo demais.

Authority Gradient — hierarquia pode silenciar dúvida.

Plan Continuation Bias — continuamos porque já começamos.

Alarm Fatigue — alertas demais viram ruído.

Automation Bias — confiamos demais na máquina.

Drift Into Failure — pequenas adaptações empurram o sistema para a borda.

Diffusion of Responsibility — todos veem e ninguém assume.

Normalcy Bias — esperamos que tudo volte ao normal.

Survivorship Bias — olhamos apenas para quem sobreviveu.

Base Rate Neglect — ignoramos frequências reais.

Availability Heuristic — confundimos facilidade de lembrar com probabilidade.

Agora chegamos a um erro que afeta diretamente:

post-mortems;

avaliação de pessoas;

gestão;

risco;

mudanças;

arquitetura.

Porque humanos adoram usar resultado como prova.


🧠 O que é Outcome Bias?

Imagine duas decisões idênticas.

A chance de falha é 20%.

Pessoa A executa.

Dá certo.

Pessoa B executa.

Dá errado.

Se julgarmos pela consequência:

A parece competente.

B parece incompetente.

Mas ambas aceitaram o mesmo risco.

Resultado diferente não transforma retrospectivamente a qualidade do processo decisório.

Representando:

DECISÃO A
RISCO RUIM
+
SORTE
=
RESULTADO BOM

versus:

DECISÃO B
RISCO RUIM
+
AZAR
=
RESULTADO RUIM

Outcome Bias diz:

A foi boa decisão.

B foi má decisão.

Mas talvez:

ambas fossem más decisões.


🎲 Poker é uma bela metáfora

Imagine jogador de poker.

Possui uma mão péssima.

Aposta tudo.

Por acaso ganha.

Foi uma boa decisão?

Não necessariamente.

Talvez tenha recebido sorte.

Outro jogador toma decisão matematicamente excelente e perde porque a carta seguinte foi improvável.

Isso não transforma a boa decisão em ruim.

Em engenharia de sistemas:

resultado contém:

decisão;

contexto;

incerteza;

sorte.

Precisamos separar.


☕ Bellacosa Mainframe: o deploy que “provou” que o processo funciona

Primeiro deploy:

sem teste completo.

Tudo certo.

Conclusão:

“Esse teste adicional é burocracia.”

Segundo:

também funciona.

Terceiro:

funciona.

Depois de dez deploys:

“Nunca precisamos disso.”

Pronto.

Outcome Bias acabou de alimentar:

Normalization of Deviance.

A sobrevivência anterior virou evidência de que o processo ruim era bom.


🌀 Outcome Bias + Normalization of Deviance

Essa dupla é perigosíssima.

Desvio:

não testar rollback.

Resultado:

bom.

Interpretação:

processo é seguro.

Repete.

Bom resultado novamente.

Agora desvio vira prática aceita.

Até falhar.

Quando falha:

“Como puderam fazer isso?”

Mas a organização premiou exatamente a mesma prática dez vezes.

Isso é hipocrisia retrospectiva operacional.


🧠 “Funcionou” não é argumento suficiente

Uma das frases mais perigosas em TI:

“Funcionou.”

Pergunta:

por quê?

Talvez porque:

design era bom.

Ou:

condição de risco não ocorreu.

Ou:

volume era menor.

Ou:

ninguém coincidiu com janela problemática.

Ou:

sorte.

Resultado sozinho não identifica mecanismo.


🧪 Processo versus resultado

Uma boa análise separa duas colunas:

QUALIDADE DA DECISÃO
---------------------
Informação disponível?
Riscos avaliados?
Critérios seguidos?
Alternativas consideradas?
Rollback validado?
Evidência suficiente?

E:

RESULTADO
---------
Funcionou?
Falhou?
Impacto?

Você precisa avaliar ambos.

Não misturar.


👻 Easter Egg nº 1 — O companion atravessa a rua

Companion atravessa uma avenida sem olhar.

Nenhum carro passa.

Ele diz:

— Viu? Foi seguro.

Doctor responde:

— Não.

— Mas nada aconteceu.

— Isso significa que você sobreviveu.

Pausa.

— Não que sua decisão tenha sido boa.

Outcome Bias em dez segundos.


🧠 Sorte é uma variável invisível

Organizações adoram competência.

Não gostam de falar de sorte.

Mas sistemas complexos possuem incerteza.

Podemos tomar:

boa decisão;

e obter resultado ruim.

Ou:

má decisão;

e escapar.

Se ignoramos sorte:

premiamos comportamentos arriscados que tiveram sucesso.

Punimos comportamentos razoáveis quando o resultado foi adverso.

Isso ensina a lição errada.


📊 Matriz decisão x resultado

Uma ferramenta maravilhosa:

                 RESULTADO BOM      RESULTADO RUIM

BOA DECISÃO      Competência        Azar / risco residual

MÁ DECISÃO       Sorte              Falha previsível

Todas as quatro células existem.

Organizações ruins enxergam apenas:

resultado bom = boa decisão.

resultado ruim = má decisão.

Organizações maduras perguntam:

“Como chegamos à decisão?”


🧠 Hindsight Bias é primo íntimo

Outcome Bias e Hindsight Bias trabalham juntos.

Depois de resultado ruim:

Hindsight:

“Era óbvio que daria errado.”

Outcome:

“Logo, decisão foi péssima.”

Depois de resultado bom:

“Sabíamos o que estávamos fazendo.”

Mesmo que não soubéssemos.

A narrativa se ajusta ao final.


🧩 Um exemplo COBOL simples

Imagine programa lendo campo numérico.

A validação deveria existir.

Programador remove por performance.

100 milhões de registros.

Nenhum inválido.

Resultado:

RC=00.

Gerente:

— A validação era desnecessária.

Não.

Você apenas teve uma população de dados válida.

Mês seguinte chega:

AMOUNT = '12A45'

S0C7.

Agora:

— Quem removeu essa validação?

Mesma lógica.

Primeiro resultado mascarou risco.


🧠 Robustez não pode ser inferida de uma execução

Um teste passou.

Isso prova:

aquele caso passou.

Não:

todo espaço de casos é seguro.

Outcome Bias transforma observação limitada em certeza.


🧪 Teste negativo também precisa ser interpretado

Mudança falha em homologação.

Isso não significa automaticamente:

arquitetura ruim.

Talvez ambiente esteja errado.

Talvez dado de teste seja inconsistente.

Resultado ruim não prova hipótese ruim.

Investigue mecanismo.


⚓ Anchoring Bias e Outcome

Primeiro resultado positivo cria âncora:

“Esse processo funciona.”

Depois qualquer risco é interpretado a partir disso.

Mesmo quando contexto muda.


🔎 Confirmation Bias protege o sucesso

Equipe acredita no processo.

Cada execução boa vira prova.

Near misses são ignorados.

Falhas pequenas:

azar.

Resultado positivo recebe explicação interna:

competência.

Resultado negativo:

exceção.

Isso é Confirmation Bias + Outcome Bias.


👥 Groupthink transforma sorte em cultura

Dez deploys arriscados funcionam.

Equipe:

“Somos bons nisso.”

Um júnior questiona:

— Mas rollback não é testado.

Resposta:

— Nunca precisamos.

Groupthink protege uma prática validada apenas pelo resultado.


🪜 Authority Gradient torna o resultado argumento de autoridade

Sênior:

— Faço assim há 20 anos.

Resultado histórico bom.

Júnior hesita.

Mas a pergunta importante continua:

qual risco foi aceito em cada uma dessas vezes?

Experiência é valiosa.

Sobrevivência não é prova suficiente.


▶️ Plan Continuation Bias

Plano segue.

Até agora deu certo.

Então:

“Vamos continuar.”

O sucesso intermediário pode aumentar compromisso, mesmo quando riscos novos surgiram.

Outcome Bias usa os passos anteriores como prova de que próximos também serão seguros.


🚨 Alarm Fatigue

Warning ignorado várias vezes.

Nenhum incidente.

Resultado bom.

Conclusão:

warning inútil.

Talvez.

Ou alerta real cuja condição perigosa ainda não coincidiu.

Outcome Bias pode matar credibilidade de sinais úteis.


🤖 Automation Bias

Sistema automático fez 500 decisões.

Nada ruim visível.

Conclusão:

podemos confiar completamente.

Talvez não.

Os resultados anteriores podem ter sido:

boas decisões;

ou resultados bons apesar de erros.

Precisamos medir qualidade da decisão automática, não apenas ausência de desastre.


🌀 Drift Into Failure

Este é um dos melhores encaixes.

Pequena otimização.

Funciona.

Outra.

Funciona.

Mais uma.

Funciona.

Cada bom resultado reforça a trajetória.

A organização deriva para a borda.

Até que resultado muda.

Resultado histórico estava ensinando:

“continue.”

Mas não mostrava distância até a fronteira.


👥 Diffusion of Responsibility

Incident sem owner.

Por sorte outra pessoa percebe e resolve.

Resultado bom.

A organização não corrige ownership.

Por quê?

“No fim funcionou.”

Outcome Bias acaba de ocultar uma fragilidade organizacional.


🧠 Normalcy Bias

Problema aparece.

Esperamos.

Volta ao normal.

Resultado:

esperar era certo.

Talvez.

Ou tivemos sorte.

Na próxima vez:

esperamos.

Não volta.

Outcome Bias reforça Normalcy Bias.


🛩️ Survivorship Bias também participa

Vemos decisões arriscadas que sobreviveram.

Não vemos as que destruíram projetos, pessoas ou sistemas.

Resultado bom + sobrevivência cria narrativa:

“essa estratégia funciona.”

Precisamos da amostra completa.


📊 Base Rate Neglect

Uma decisão rara dá certo.

A história fica memorável.

Passamos a recomendar.

Mas qual taxa real de sucesso dessa estratégia?

Outcome Bias olha para o caso.

Base Rate Neglect esquece população.


🧠 Availability Heuristic fecha o círculo

O sucesso espetacular fica na memória.

“Lembra daquele deploy que fizemos sem rollback e terminou em vinte minutos?”

Sim.

O fracasso de outro time talvez seja menos conhecido.

Agora resultado disponível influencia novas decisões.

Nossos monstros realmente gostam de trabalhar em equipe.


🎯 Pergunta Bellacosa nº 1

Depois de algo dar certo:

“O que teria acontecido se uma condição adversa tivesse aparecido?”

Essa pergunta procura risco escondido.


🎯 Pergunta Bellacosa nº 2

Depois de algo dar errado:

“Com as informações disponíveis antes, a decisão ainda era razoável?”

Evita Hindsight Bias.


🎯 Pergunta Bellacosa nº 3

Outra:

“Estamos premiando o processo ou a sorte?”

Excelente em gestão.


🎯 Pergunta Bellacosa nº 4

E:

“Tomaríamos a mesma decisão novamente se o resultado anterior fosse desconhecido?”

Essa é poderosa.

Remove o final da história.


🧪 Result-blind review

Uma técnica interessante:

avaliar uma decisão sem revelar o resultado inicialmente.

Imagine apresentar:

  • informações disponíveis;

  • opções;

  • riscos;

  • decisão.

Pergunte:

“Foi uma decisão razoável?”

Só depois revele:

resultado.

Isso reduz Outcome Bias.


🧠 Replay the decision

No post-mortem:

reconstrua o momento.

02:15

KNOWN:
- test incomplete
- rollback unverified
- 45 min window
- low observed errors

UNKNOWN:
- next dataset contained invalid records

Agora pergunte:

“Com isso, qual decisão seria apropriada?”

Não use dados das 03:00.


📚 Decision Journal

Antes de decisões importantes, registre:

DECISION:
GO

REASON:
Validation A/B passed

KNOWN RISKS:
Rollback untested

CONFIDENCE:
60%

STOP CONDITION:
Any reconciliation mismatch

Depois compare com resultado.

Você consegue avaliar:

qualidade da previsão;

não apenas outcome.


🧠 Calibration

Se alguém diz:

“90% de confiança”

em 100 decisões, aproximadamente 90 deveriam dar certo.

Se só 60:

confiança mal calibrada.

Decision journals ajudam líderes e especialistas a aprenderem sua própria calibração.


📊 Brier Score no horizonte

Existe uma métrica para avaliar qualidade de previsões probabilísticas chamada Brier Score.

Não precisamos aprofundar agora.

Mas o princípio é lindo:

avaliar previsão contra probabilidades declaradas.

Não apenas:

acertou/errou.

Um possível futuro episódio sobre overconfidence bias encaixaria perfeitamente aqui.


☕ Exemplo Bellacosa: change management

Mudança A:

TESTS: 60%
ROLLBACK: NOT TESTED
RISK: HIGH
OUTCOME: SUCCESS

Mudança B:

TESTS: 100%
ROLLBACK: VALIDATED
RISK: LOW
OUTCOME: FAILURE

Se você julgar apenas outcome:

A parece melhor.

Mas processo B pode ter sido muito superior.

A falha B talvez tenha vindo de condição rara impossível de detectar.

A vitória A pode ser pura sorte.

Isso precisa entrar no post-mortem.


🧠 Good process reduces risk, not uncertainty to zero

Nenhum processo garante resultado.

Se garantisse:

não chamaríamos de risco.

Boa engenharia:

reduz probabilidade;

reduz impacto;

aumenta detectabilidade;

melhora recuperação.

Não elimina universo.


🎲 Um dado de seis lados

Você escolhe estratégia A:

falha se sair 1.

Estratégia B:

falha se sair 1,2,3,4.

Primeira execução:

A tira 1 e falha.

B tira 5 e funciona.

Qual estratégia é melhor?

A.

Mesmo tendo falhado.

Outcome não altera distribuição.


🧠 Probabilidade não promete resultado

Chance de chuva 20%.

Chove.

Previsão estava errada?

Não necessariamente.

20% significa:

pode chover.

Da mesma forma:

risco de falha 5%.

Falhou.

Isso não prova avaliação ruim.

Pode ser um evento de 5%.

Investigue calibração ao longo de muitos casos.


🏦 Sistemas financeiros e Outcome Bias

Trader assume risco excessivo.

Ganha.

Recebe bônus.

Repete.

Ganha.

Aumenta risco.

Até perder brutalmente.

Se organização premia apenas resultado:

ensina risco ruim com sorte.

Esse mecanismo aparece em finanças, TI, segurança e projetos.


🔐 Segurança

Administrador desabilita controle para resolver urgente.

Nada acontece.

Resultado:

herói.

Mês seguinte outro faz igual.

Incidente.

Resultado:

culpado.

A primeira exceção também era perigosa.

Outcome Bias premiou-a.


🧠 Incentivos importam

Se pessoas são avaliadas apenas por:

entregou?

ficou verde?

não houve incidente?

elas podem aprender a aceitar risco oculto.

Porque riscos que não se materializam desaparecem da avaliação.

Uma organização madura também valoriza:

processo;

prevenção;

decisão prudente;

stop decisions;

near miss reporting.


🛑 O valor de dizer NO-GO

Equipe cancela mudança.

Nenhum incidente.

Diretor:

— Perdemos a janela.

Mas talvez evitaram desastre.

Como provar?

É difícil.

Prevenção produz ausência.

Resultado visual:

“nada aconteceu.”

Outcome Bias pode desvalorizar exatamente decisões preventivas.


🧠 Prevention Paradox operacional

Boa prevenção pode parecer desnecessária porque evita aquilo que provaria sua necessidade.

Controle funciona.

Nada acontece.

Alguém pergunta:

“Por que gastamos com isso?”

Até remover.

Então descobre.


🦸 Heroísmo versus prevenção

Pessoa A impede deploy arriscado.

Nada acontece.

Pouca visibilidade.

Pessoa B deixa ocorrer, incidente acontece, trabalha 12 horas e salva.

Herói.

Cuidado com incentivos.

Você pode acabar premiando recuperação dramática mais que prevenção silenciosa.

Outcome Bias influencia cultura.


☕ A melhor madrugada é a tediosa

Uma excelente operação:

nenhum incidente;

checks completos;

rollback testado;

todo mundo vai dormir.

Não há história heroica.

Isso é sucesso.

Não ausência de trabalho.


📋 Como combater Outcome Bias

Passo 1 — Separe decisão de resultado

Sempre avalie ambos.


Passo 2 — Reconstrua informação disponível

Não use spoilers.


Passo 3 — Registre critérios antes

Decision journal.


Passo 4 — Avalie riscos aceitos

Mesmo se deu certo.


Passo 5 — Investigue near misses

Resultado bom pode esconder processo ruim.


Passo 6 — Faça result-blind review

Quando possível.


Passo 7 — Compare muitas decisões

Não um caso isolado.


Passo 8 — Avalie calibração

Previsões versus resultados ao longo do tempo.


Passo 9 — Recompense prevenção

Não apenas heroísmo.


Passo 10 — Pergunte se repetiria o processo

Não o resultado.


🧠 Processo ruim + resultado bom é warning

Isso merece uma regra.

Se resultado foi bom mas processo ruim:

não comemore sem corrigir.

Você recebeu:

um near miss invisível.

Talvez nada tenha acontecido.

Mas risco existia.


🚨 “Deu certo” pode ser um near miss

Mudança sem rollback.

Funciona.

Talvez classificar como:

success.

Mas registrar:

process deviation.

Porque precisamos impedir que resultado bom legitime o desvio.


📊 Process Compliance não deve ser burocracia cega

Importante.

Isso não significa:

seguir procedimento mesmo quando absurdo.

Se procedimento é ruim:

mude.

Mas não pule e use sucesso como prova de que nunca precisou.

Primeiro avalie.


🧠 Boa decisão também pode falhar

Isso é especialmente importante para cultura blameless.

Imagine operador segue:

runbook;

critérios;

escalation;

dados.

Mesmo assim sistema falha por condição inesperada.

Não transforme outcome ruim em culpa automática.

Pergunte:

“O que faltava ao sistema?”

Isso permite aprendizado real.


⚖️ Accountability sem Outcome Bias

Accountability madura:

você tomou decisão com cuidado?

usou evidência?

respeitou riscos?

escalou quando necessário?

Não:

deu certo?

Resultado importa.

Mas não sozinho.


🧪 Post-mortem melhor

Evite:

“A decisão de GO foi errada porque houve incidente.”

Prefira:

“No momento do GO, havia divergência não explicada e rollback não validado, portanto a decisão excedia nossos critérios de risco.”

Isso é muito melhor.

Mesmo se não houvesse incidente, a conclusão permaneceria.


🧠 Counterfactual consistency

Uma regra bonita:

Sua avaliação da decisão deveria mudar pouco se você trocar apenas o resultado.

Se a mesma decisão passa de “excelente” para “irresponsável” apenas porque outcome mudou:

suspeite de Outcome Bias.


🎯 Teste Bellacosa

Pegue uma decisão.

Esconda resultado.

Avalie.

Depois revele.

Se sua avaliação muda radicalmente:

pergunte por quê.

Talvez seja informação legítima nova.

Ou talvez outcome esteja dominando.


👨‍💻 Dica para o COBOL iniciante

Seu código passa no primeiro teste.

Não diga:

“Está certo.”

Diga:

“Passou nesse teste.”

Parece pequeno.

É enorme.

Outra:

programa falha em edge case.

Não conclua:

“sou ruim.”

Conclua:

“Encontrei uma condição que o modelo não cobria.”

Resultado é feedback.

Não identidade.


🐞 Bugs são professores

Um bug em produção não significa necessariamente desenvolvimento irresponsável.

Talvez fosse caso extremo genuinamente difícil.

Mas se o processo ignorou teste óbvio:

aí temos aprendizado diferente.

Separe.


🤖 IA e Outcome Bias

Prompt gera código.

Funciona.

Usuário conclui:

IA é excelente para isso.

Outro prompt gera bug.

IA não serve.

Ambas conclusões podem ser precipitadas.

Precisamos avaliar:

amostra;

tipo de tarefa;

revisão;

processo.

Outcome isolado engana.


🤖 Agentes autônomos

Agente executa ação arriscada.

Resultado bom.

Você aumenta autonomia.

Cuidado.

Talvez ele tenha violado política e dado sorte.

Avalie:

process compliance;

guardrails;

decision trace.

Não apenas final state.


🧠 Reward design

Se agente recebe reward apenas pelo resultado:

pode encontrar atalhos perigosos.

Humano também.

Se meta é:

restaurar serviço rápido,

e não mede risco,

alguém pode reiniciar tudo.

Funciona.

Reward.

Depois vira ritual.

Outcome Bias embutido no incentivo.


📊 Leading versus lagging indicators novamente

Outcome é frequentemente lagging indicator.

Resultado final.

Process indicators podem mostrar qualidade antes:

tests;

margin;

exceptions;

warnings;

decision criteria.

Precisamos ambos.


🧬 Drift Into Failure e indicadores

Se tudo continua funcionando, outcome é verde.

Mas leading indicators pioram.

Outcome Bias diz:

tudo bem.

Drift Into Failure responde:

por enquanto.

Essa conexão é central.


👻 Easter Egg nº 2 — TARDIS e loteria

Companion:

— Apostei todas as economias num número e ganhei!

Doctor:

— Parabéns.

— Então foi uma excelente estratégia?

— Não.

— Mas funcionou.

— Uma vez.

Pausa.

— O universo está tentando lhe ensinar estatística. Não desperdice a oportunidade.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Outcome Bias é julgar a qualidade de uma decisão principalmente pelo resultado.

Bom resultado não prova boa decisão.

Resultado ruim não prova decisão ruim.

Sorte e incerteza fazem parte de sistemas complexos.

Processo ruim com resultado bom pode ser um near miss.

Normalization of Deviance cresce quando práticas ruins são legitimadas por sucesso.

Hindsight Bias transforma outcome ruim em “era óbvio”.

Avalie informações disponíveis no momento da decisão.

Decision journals e result-blind reviews ajudam.

Recompense prevenção, não apenas heroísmo.

E principalmente:

Uma decisão deve ser julgada pelo que sabíamos quando a tomamos — não apenas pelo que o universo decidiu fazer depois.


🕰️ De volta à primeira mudança

A TARDIS retorna à semana anterior.

02:13.

Rollback não testado.

Validação incompleta.

Gerente:

— Podemos seguir.

Agora nosso programador sabe que, no futuro, essa mudança funcionará.

Mas não pode usar esse conhecimento.

Ele olha para o Doctor.

— Mas nós sabemos que vai dar certo.

O Doctor responde:

— Nós sabemos.

Aponta para a equipe.

— Eles não.

— Então?

— Avalie a decisão deles.

Nosso jovem observa.

Sem rollback.

Sem reconciliação.

Janela curta.

Ele diz:

— NO-GO.

Gerente:

— Mas talvez funcione.

— Talvez.

— Então por que parar?

— Porque “talvez funcione” não é critério suficiente.

A mudança é adiada.

Na manhã seguinte, encontram uma condição de dados que poderia ter causado problema.

Corrigem.

Próxima janela.

Tudo funciona.

O gerente pergunta:

— Então ontem teria falhado?

O programador responde:

— Não sabemos.

— Então talvez tivéssemos perdido tempo.

— Talvez.

O Doctor sorri.

— Excelente.

O gerente parece confuso.

— Excelente o quê?

— Finalmente vocês estão confortáveis com uma frase que sistemas complexos exigem bastante.

— Qual?

“Não sabemos.”

Porque admitir incerteza é muito mais seguro que inventar certeza baseada no resultado.


🥚 Easter Egg final

No dia seguinte aparece:

BELLACOSA.BIAS(OUTCOME)

Dentro:

       IF RESULT = 'GOOD'
          AND PROCESS = 'BAD'
           MOVE 'LUCK'
             TO POSSIBLE-EXPLANATION
       END-IF.

       IF RESULT = 'BAD'
          AND PROCESS = 'GOOD'
           PERFORM INVESTIGATE-RISK
       END-IF.

       PERFORM EVALUATE-DECISION
          BEFORE EVALUATE-OUTCOME.

Comentário:

* LUCK IS NOT A CONTROL.

Outro:

* SUCCESS CAN HIDE A BAD DECISION.

E naturalmente:

* BAD WOLF GOT LUCKY.

Nosso programador fecha o membro.

Horas depois alguém diz:

— Fizemos deploy sem teste e funcionou.

Ele sorri.

— Ótimo.

— Então podemos simplificar o processo?

— Talvez.

— Mas deu certo.

— Eu sei.

Abre o change record.

— Agora vamos descobrir se deu certo por causa do processo ou apesar dele.

Em algum lugar do universo:

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica escrita uma frase:

Não confunda sorte com competência, nem azar com incompetência. Primeiro julgue a decisão. Depois estude o resultado.

☕🌀

Next stop: Overconfidence Bias — quando conhecimento, senioridade e alguns sucessos começam a convencer alguém de que sua margem de erro é muito menor do que realmente é.

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...