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