 |
| Bellacosa Mainframe e o availabitity heuristic |
☕ Um Café no Bellacosa Mainframe
Availability Heuristic: Doctor Who, COBOL e o Dia em que o Último Incidente Virou a Explicação para Tudo
Uma viagem pela TARDIS dos incidentes para entender por que aquilo que lembramos com facilidade parece acontecer com mais frequência do que realmente acontece
08:03.
Segunda-feira.
Café quente.
War Room vazia.
Produção aparentemente tranquila.
Até que surge:
WARNING
PAYMENT RESPONSE TIME
ABOVE BASELINE
O operador olha.
— Ih.
O programador COBOL iniciante pergunta:
— O quê?
— Está parecendo aquele incidente de sexta.
Silêncio.
Sexta-feira havia sido memorável.
Fila MQ crescendo.
Timeouts.
Clientes reclamando.
Gerente ligando.
Diretor entrando na War Room.
Quatro horas de incidente.
Muito café.
Pouca dignidade.
Então o operador olha novamente para o warning.
— É MQ de novo.
Nosso jovem pergunta:
— Já verificou?
— Não precisa. Está com a mesma cara.
08:07.
DBA entra.
— O que temos?
— MQ.
— De novo?
— De novo.
08:09.
Gerente:
— Já acionaram middleware?
— Sim.
08:12.
Quatro pessoas estão investigando MQ.
Ninguém percebe que:
MQ QUEUE DEPTH: NORMAL
Mas existe:
DB2 LOCK WAIT: +640%
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado da máquina de café.
A porta abre.
O Doctor sai.
Olha para a War Room.
Depois para os gráficos.
Depois para a equipe.
— Por que todos estão olhando MQ?
O operador responde:
— Porque sexta-feira foi MQ.
O Doctor ergue uma sobrancelha.
— E hoje é sexta-feira?
— Segunda.
— Então por que sexta-feira está dirigindo a investigação?
Silêncio.
O Doctor sorri.
— Ah.
Pausa.
— Vocês não estão investigando o incidente de hoje.
Aponta para a cabeça do operador.
— Estão investigando a memória do último.
Bem-vindo ao:
Availability Heuristic
Ou:
Heurística da Disponibilidade
A tendência de estimar a frequência, probabilidade ou importância de um evento com base na facilidade com que exemplos desse evento vêm à nossa mente.
🌀 Recapitulando a nossa TARDIS dos incidentes
Nossa coleção já está ficando respeitável.
Conhecemos:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios viram rotina.
Hindsight Bias — depois do incidente tudo parece óbvio.
Confirmation Bias — buscamos evidências que confirmem nossas crenças.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — o grupo converge cedo demais.
Authority Gradient — hierarquia silencia sinais importantes.
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 — estudamos quem sobreviveu e esquecemos os ausentes.
Base Rate Neglect — ignoramos a frequência real dos eventos.
Agora encontramos um parceiro natural do Base Rate Neglect:
Availability Heuristic
Porque muitas vezes não usamos a taxa real.
Usamos:
“o que lembro mais facilmente.”
🧠 O que é uma heurística?
Primeiro, uma palavra importante.
Heurística é um atalho mental.
Nosso cérebro precisa tomar milhares de decisões.
Não calcula tudo estatisticamente.
Não abre planilha.
Não roda regressão.
Não faz Bayes conscientemente antes de escolher se atravessa a rua.
Ele usa atalhos.
Isso é útil.
Muito útil.
Sem heurísticas, viveríamos paralisados.
O problema começa quando:
atalho vira substituto da realidade.
🧠 A pergunta real e a pergunta substituta
Imagine a pergunta difícil:
“Qual é a probabilidade real de o problema ser MQ?”
Isso exige:
dados;
histórico;
telemetria;
base rates;
evidências.
Nosso cérebro pode substituí-la por uma pergunta mais fácil:
“Consigo lembrar rapidamente de um problema de MQ?”
Sim.
Sexta-feira.
Foi traumático.
Pronto.
MQ parece muito provável.
Esse mecanismo é Availability Heuristic.
🔥 Eventos dramáticos ficam disponíveis
Memória não armazena tudo igualmente.
Eventos:
recentes;
emocionais;
dramáticos;
visuais;
dolorosos;
incomuns
ficam mais acessíveis.
Então parecem mais frequentes.
Exemplo clássico fora da TI:
pessoas podem superestimar riscos de eventos muito noticiados e subestimar riscos cotidianos menos dramáticos.
Nosso cérebro mede:
facilidade de lembrança
como se fosse:
frequência estatística.
Mas não é.
☕ Bellacosa Mainframe: o trauma da sexta-feira
Sexta:
incidente MQ.
Quatro horas.
Segunda:
lentidão.
Automaticamente:
MQ.
Por quê?
Porque o incidente anterior está fresco.
Isso é chamado também de efeito de recency dentro desse contexto.
Eventos recentes ficam cognitivamente disponíveis.
🧠 Recência não é frequência
Essa frase vale ouro:
O que aconteceu recentemente não é necessariamente o que acontece frequentemente.
Histórico real:
Últimos 100 incidentes de lentidão
DB2: 38
Aplicação: 27
MQ: 12
Rede: 11
Storage: 7
Outros: 5
MQ aconteceu sexta.
Mas taxa histórica:
12%.
Ainda relevante.
Não dominante.
🌀 Base Rate Neglect + Availability Heuristic
Aqui os dois monstros se abraçam.
Base Rate Neglect:
esqueço que MQ ocorre em 12%.
Availability:
lembro muito bem do MQ de sexta.
Resultado:
“É quase certeza que é MQ.”
Perceba.
Nada técnico mudou.
A memória alterou a probabilidade percebida.
👻 Easter Egg nº 1 — Daleks de novo
O Doctor encontra uma porta destruída.
Companion:
— Dalek.
Doctor:
— Por quê?
— Porque vimos Daleks ontem.
— Isso é evidência?
— Não.
— Então é o quê?
— Trauma?
— Exatamente.
Pausa.
— E também uma heurística.
🚨 Incidente recente domina a mente
Depois de um grande incidente de segurança, toda anomalia pode parecer ataque.
Depois de uma falha de storage:
tudo parece storage.
Depois de um problema de certificado:
qualquer erro TLS vira:
certificado novamente.
Isso é compreensível.
Mas precisa ser controlado.
🔐 Segurança cibernética e headlines mentais
Imagine que ransomware esteja nas notícias.
Toda organização conversa sobre ransomware.
Surge lentidão.
Alguém diz:
— Estamos sendo atacados?
Talvez.
Mas existem dezenas de causas mais comuns.
Notícias tornam determinado evento cognitivamente disponível.
Não necessariamente estatisticamente provável naquele ambiente.
🧠 O noticiário vira dashboard mental
Se você assiste cinco reportagens sobre falha X, seu cérebro começa a pensar:
X acontece muito.
Mas talvez X apenas seja notícia boa.
Eventos banais e frequentes não viram manchete.
Isso conecta Availability Heuristic com Survivorship Bias e seleção de dados.
📺 Newsworthiness Bias
Eventos dramáticos recebem cobertura.
Eventos comuns não.
Logo:
memória pública fica enviesada.
Na TI:
post-mortems épicos são lembrados.
Pequenos incidentes repetitivos são esquecidos.
Mas os pequenos talvez causem mais impacto acumulado.
💻 COBOL e o último S0C7
Imagine que ontem houve:
ABEND S0C7
CAUSE: INVALID PACKED DECIMAL
Hoje novo S0C7.
Programador:
— Dado inválido de novo.
Provável?
Talvez.
Mas pode ser:
copybook inconsistente;
overlay;
REDEFINES mal usado;
índice errado;
campo truncado.
O fato de ontem ter sido dado inválido não prova hoje.
🧠 Experiência ajuda e atrapalha
Veteranos possuem memória rica.
Isso é fantástico.
Reconhecem padrões rapidamente.
Mas memórias fortes também podem puxar demais.
Uma situação pode “parecer” com outra.
Esse reconhecimento é valioso.
Mas precisa ser tratado como:
hipótese baseada em padrão, não sentença.
🧩 Recognition-Primed Decision
Profissionais experientes frequentemente tomam boas decisões porque reconhecem padrões familiares.
Isso é útil.
Mas existe um risco:
o padrão mais disponível pode não ser o mais adequado.
Pergunta madura:
“Isso realmente corresponde ao caso anterior ou apenas me lembra dele?”
🔍 Compare assinaturas
Em vez de:
“parece MQ”
compare sinais.
Incidente anterior:
MQ queue depth ↑
Consumer rate ↓
Timeouts ↑
DB2 normal
Hoje:
MQ normal
DB2 lock wait ↑
Timeouts ↑
Apenas um sintoma comum:
timeouts.
Não é o mesmo incidente.
Dados quebram o encanto da memória.
⚓ Availability + Anchoring Bias
Alguém lembra de sexta:
“MQ.”
Essa memória vira primeira hipótese.
Agora Anchoring Bias entra.
A investigação passa a girar em torno de MQ.
🔎 Confirmation Bias chega depois
Equipe começa a procurar:
retries;
timeouts;
mensagens MQ.
Encontra qualquer detalhe compatível.
— Viu?
Agora memória virou teoria.
Teoria virou filtro.
👥 Groupthink amplifica
Um veterano diz:
— Está igual sexta-feira.
Outros lembram.
— Verdade.
Agora o grupo inteiro revive o incidente.
Consenso substitui comparação objetiva.
🪜 Authority Gradient
Especialista sênior:
— Aposto em MQ.
Júnior vê lock wait alto.
Mas pensa:
“Ele acabou de resolver um incidente de MQ sexta.”
Silêncio.
Memória + autoridade.
Combinação forte.
🤖 Automation Bias pode também criar disponibilidade
Ferramenta exibe “Top incident causes”.
Último grande caso aparece destacado.
Equipe começa a lembrar desse tipo com maior facilidade.
Dashboards e interfaces influenciam quais eventos ficam mentalmente disponíveis.
🚨 Alarm Fatigue também pode distorcer memória
Milhares de alertas banais são esquecidos.
O único alerta que virou incidente fica na memória.
Depois concluímos:
esse tipo de alerta é sempre grave.
Mas talvez existam 2.000 ocorrências benignas que esquecemos.
Memória seleciona impacto.
🧠 Peak-End Rule
Existe uma ideia relacionada:
experiências são muitas vezes lembradas fortemente pelo pico emocional e pelo final.
Incidente traumático termina com madrugada heroica.
Essa narrativa fica.
As semanas normais desaparecem.
Availability Heuristic ganha material.
🦸 Heroísmo vira memória dominante
Equipe se lembra:
“Naquele incidente Carlos restartou CICS e resolveu.”
Depois, em novo incidente:
— Reinicia CICS.
Por quê?
Porque lembramos da solução heroica.
Mas talvez restart seja irrelevante ou até prejudicial.
Não transforme soluções memoráveis em rituais.
🧙 Cargo cult de incidentes
Caso anterior:
limpamos cache.
Funcionou.
Novo problema:
limpa cache.
Outro:
limpa cache.
Virou encantamento.
Availability Heuristic + correlação histórica mal entendida.
O famoso:
“Have you tried turning it off and on again?”
Às vezes funciona.
Isso não faz dele RCA.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Está igual ao incidente da semana passada.”
Pergunte:
“Quais sinais específicos são realmente iguais?”
Muito poderosa.
🎯 Pergunta Bellacosa nº 2
Outra:
“Esse caso é frequente ou apenas fácil de lembrar?”
Essa é a essência.
🎯 Pergunta Bellacosa nº 3
Outra:
“Quantas vezes esse sintoma ocorreu sem virar aquele problema?”
Você recupera o denominador.
🎯 Pergunta Bellacosa nº 4
E:
“O histórico completo confirma a nossa memória?”
Se não:
dados vencem nostalgia operacional.
🧪 Como combater Availability Heuristic
Passo 1 — Use histórico estruturado
Não confie só em lembrança.
Passo 2 — Compare taxas
Quantas vezes realmente aconteceu?
Passo 3 — Liste hipóteses alternativas
Antes de mergulhar no caso memorável.
Passo 4 — Compare assinatura técnica
Sintomas realmente coincidem?
Passo 5 — Separe recência de frequência
Recente não significa comum.
Passo 6 — Separe dramaticidade de probabilidade
Grave não significa provável.
Passo 7 — Registre incidentes pequenos
Senão memória fica dominada pelos épicos.
Passo 8 — Use base rates
Nosso capítulo anterior volta aqui.
Passo 9 — Faça revisão fria depois
Com emoção menor, compare percepção e dados.
Passo 10 — Pergunte pela evidência contrária
O que mostra que este incidente não é igual ao último?
📊 Incident Taxonomy
Uma base de incidentes ajuda muito.
Exemplo:
SYMPTOM: RESPONSE TIME
CAUSES:
DB2 lock 38%
Application 27%
MQ 12%
Network 11%
Storage 7%
Other 5%
Agora memória vira suplemento.
Não fonte única.
🧠 Taxonomia evita histórias soltas
Sem classificação:
“lembro de um incidente.”
Com classificação:
“temos 243 incidentes semelhantes.”
Muda completamente.
💾 O mainframe adora histórico
E aqui o mainframeiro tem vantagem.
SMF.
Logs.
Scheduler history.
DB2 stats.
CICS stats.
MQ metrics.
Temos uma mina de dados.
Use.
Não dependa da frase:
“Tenho impressão que...”
Impressão é hipótese.
SMF é testemunha.
😄 Easter Egg nº 2 — SMF não tem nostalgia
O operador:
— Tenho certeza que CPU sempre fica assim.
SMF:
NO, IT DOESN'T.
Talvez o melhor psicólogo do mainframe seja o histórico de métricas.
📈 Frequência versus intensidade
Outra nuance.
Um tipo de incidente pode ser raro, mas muito grave.
Availability faz parecer frequente porque foi traumático.
Isso não significa ignorá-lo.
Você precisa separar:
probabilidade
de:
impacto.
O evento pode merecer forte controle mesmo sendo raro.
Mas não precisa ser diagnosticado toda segunda-feira.
🧠 Risco = probabilidade + impacto
Em termos conceituais:
evento raro e catastrófico:
controle.
evento comum e leve:
gestão.
Mas diagnóstico deve respeitar evidência atual.
Não medo histórico.
🔐 Segurança depois de ataque
Após um ataque real, organizações podem entrar em hiperalerta.
Isso é compreensível.
Mas podem gastar meses perseguindo falsos indícios do mesmo ataque e negligenciar vetores mais prováveis.
O incidente recente vira filtro.
🏦 Fraude recente
Banco sofre fraude por engenharia social.
Semana seguinte:
qualquer transação suspeita parece engenharia social.
Mas ataques mudam.
Criminosos também aprendem.
A memória do último método não deve impedir olhar para o próximo.
🌀 Drift Into Failure e memórias antigas
Availability Heuristic pode funcionar ao contrário também.
Talvez a equipe lembre facilmente de incidentes antigos típicos.
Mas sistema mudou.
Novos tipos de falha apareceram.
O repertório mental continua preso no passado.
Drift arquitetural cria incidentes novos.
Memória oferece causas velhas.
🧠 “Fighting the Last War”
Existe uma expressão famosa:
lutar a guerra anterior.
Organizações se preparam para aquilo que acabou de acontecer.
Fortalecem a barreira anterior.
Mas próximo incidente pode vir por outro caminho.
Depois do desastre:
criam 20 controles para exatamente aquele caso.
Isso pode ser Availability Heuristic organizacional.
🧀 Swiss Cheese e o remendo hiper-específico
Incidente:
data 00000000.
Correção:
bloquear 00000000.
Próximo:
99999999.
Lição real deveria ser:
validar data.
Se memória do caso específico domina, corrigimos o sintoma histórico, não a classe de falha.
🔁 Pattern versus instance
Essa distinção é crucial.
Instance:
sexta-feira foi MQ consumer.
Pattern:
dependência downstream sem backpressure adequado.
Aprender pattern protege melhor que memorizar instance.
🧠 Hindsight Bias ajuda a consolidar memória
Depois do incidente:
criamos narrativa limpa.
Ela fica fácil de lembrar.
“Foi MQ.”
Mas realidade talvez tenha sido:
capacity;
consumer;
retries;
configuração;
mudança;
timeouts.
Narrativa simplificada aumenta disponibilidade mental.
Por isso post-mortem deve preservar complexidade suficiente.
📚 Histórias são excelentes — com dados
Bellacosa Mainframe ama histórias.
E isso é ótimo.
Histórias ensinam.
Mas precisamos evitar que uma boa história vire estatística.
A regra:
Use histórias para lembrar padrões. Use dados para estimar frequência.
👨💻 Dica para COBOL iniciante
Veterano diz:
— Esse S0C7 é sempre dado.
Responda:
“Provável. Vou começar por dados e confirmar no dump.”
Perfeito.
Você usa experiência.
Sem entregar sua independência.
🧠 A palavra “sempre” merece breakpoint
Quando ouvir:
sempre;
nunca;
toda vez;
é igual ao último;
geralmente é X;
pare e pergunte:
“temos histórico?”
Essas palavras podem esconder heurísticas.
🔬 Counterexamples
Procure casos que contradigam memória.
“Lembra de quando esse mesmo sintoma era Db2?”
Isso reduz certeza.
Não para confundir.
Para ampliar espaço de hipóteses.
🧠 Debiasing por frequência natural
Em vez de porcentagens abstratas:
“12% dos casos são MQ.”
diga:
“de cada 100 casos parecidos, aproximadamente 12 foram MQ.”
Frequências naturais são cognitivamente mais intuitivas.
📊 War Room Board
Você pode ter:
SYMPTOM:
Timeout
HISTORICAL BASE:
DB2 38%
App 27%
MQ 12%
Network 11%
CURRENT EVIDENCE:
MQ normal
DB2 wait high
Agora a sala fica menos dependente de memórias fortes.
🧠 Availability Heuristic na gestão
Executivo lê notícia:
empresa perdeu milhões por ataque de ransomware.
Dia seguinte:
— Precisamos investir tudo em ransomware.
Pode ser importante.
Mas quais são os maiores riscos da empresa?
Talvez:
fraude interna;
configuração;
indisponibilidade;
backup;
terceiros.
Eventos recentes podem deslocar orçamento desproporcionalmente.
💰 Risk Budget e memória
Organizações podem gastar baseado em medo recente.
Maturidade:
usar cenário + frequência + impacto.
Não apenas headline.
📺 “Todo mundo está falando”
Isso não é taxa base.
É disponibilidade social.
Se tema está popular:
parece importante.
Talvez seja.
Mas:
popularidade ≠ probabilidade.
No mundo da IA isso acontece constantemente.
🤖 IA e Availability Heuristic
Um modelo pode também refletir padrões frequentes nos dados de treinamento ou contexto fornecido.
Mas o usuário pode alimentar apenas incidentes recentes.
Então IA responde enviesada pela amostra contextual.
Exemplo:
últimos cinco casos fornecidos são MQ.
Pergunta:
“Qual provável causa?”
IA:
MQ.
Talvez não porque seja globalmente provável.
Mas porque foi o contexto mais disponível.
Interessante, não?
🧠 Context Window também cria disponibilidade
Para humanos:
memória recente.
Para modelos:
contexto recente.
Isso é uma analogia útil.
O que está mais “perto” ganha influência.
Por isso datasets e contexto precisam ser representativos.
🔍 RAG e amostra enviesada
Sistema de IA recupera documentos.
Se busca retorna apenas incidentes de MQ:
resposta provavelmente enfatiza MQ.
O problema pode estar na recuperação.
Automation Bias pode fazer humano aceitar.
Availability Heuristic agora foi terceirizada para retrieval.
🧠 Ferramenta de RCA precisa de diversidade
Um sistema de RCA automático deveria buscar:
casos similares;
mas também alternativas.
Caso contrário:
“similaridade” pode virar prisão.
🎯 Pergunta Bellacosa nº 5
Para IA:
“Você está sugerindo isso porque é realmente mais provável ou porque os exemplos recuperados são desse tipo?”
Excelente pergunta para 2026.
🛡️ Como construir processos melhores
Uma boa triagem pode usar:
sintomas atuais;
base rates;
incidentes similares;
sinais discriminantes;
hipóteses alternativas.
Não apenas:
“qual caso lembro?”
🧠 Similaridade não é identidade
Dois incidentes podem compartilhar:
timeout.
Mas um:
MQ.
Outro:
Db2.
O sintoma superficial pode ser igual.
A assinatura profunda não.
Use múltiplas dimensões.
📋 Checklist anti-Availability Heuristic
Antes de concluir:
[ ] Estou lembrando de um caso recente?
[ ] Esse caso foi especialmente dramático?
[ ] Estou confundindo facilidade de lembrar com frequência?
[ ] Qual é a taxa histórica real?
[ ] Quais outros casos existem?
[ ] Os sinais realmente correspondem?
[ ] O que é diferente desta vez?
[ ] Estou lutando o incidente anterior?
[ ] Minha equipe inteira está presa à mesma memória?
[ ] A ferramenta está recuperando exemplos representativos?
[ ] Existe evidência atual mais forte que a lembrança?
[ ] Estou usando histórias como estatística?
Se a resposta para a última for sim:
volte aos dados.
🧬 Regeneração organizacional
Uma organização madura aprende a:
preservar histórico;
classificar incidentes;
usar base rates;
comparar assinaturas;
registrar casos pequenos;
evitar supercorreção após eventos dramáticos;
revisar controles com calma;
e distinguir:
“isso me lembra X”
de:
“as evidências apontam para X.”
Essa pequena diferença muda tudo.
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Availability Heuristic é a tendência de estimar probabilidade com base na facilidade com que exemplos vêm à memória.
Eventos recentes e dramáticos parecem mais frequentes do que realmente são.
Recência não é frequência.
Uma memória forte pode virar âncora.
Confirmation Bias pode transformar essa memória em narrativa dominante.
Groupthink pode transformar a narrativa em consenso.
Base rates corrigem nossa percepção.
Histórico estruturado é melhor que lembrança seletiva.
Casos similares precisam ser comparados por assinatura, não apenas por sensação.
Aprenda o padrão do incidente, não apenas sua última versão.
E principalmente:
O incidente que você lembra melhor não é necessariamente o incidente que acontece mais.
🕰️ De volta às 08:03
A TARDIS retorna.
Primeiro warning.
PAYMENT RESPONSE TIME
ABOVE BASELINE
Operador:
— MQ de novo.
Nosso programador responde:
— Pode ser. Vamos comparar.
Abre o caso de sexta.
SEXTA
MQ QUEUE: +900%
DB2 WAIT: NORMAL
Hoje:
SEGUNDA
MQ QUEUE: NORMAL
DB2 LOCK WAIT: +640%
Ele aponta.
— Não está igual.
O operador fica quieto.
DBA é acionado.
Descobrem uma transação longa segurando locks.
09:02.
Problema corrigido.
Sem quatro horas de investigação errada.
O gerente pergunta:
— Como vocês descobriram tão rápido?
O programador responde:
— Paramos de tentar repetir sexta-feira.
O Doctor sorri.
— Excelente.
— Então experiência é ruim?
— Não.
— Mas quase nos enganou.
— Experiência é mapa.
Pausa.
— Só não confunda o mapa antigo com o planeta novo.
VWORP.
VWORP.
VWORP.
🥚 Easter Egg final
No dia seguinte surge:
BELLACOSA.BIAS(AVAILABLE)
Dentro:
IF MEMORY = 'VIVID'
PERFORM CHECK-FREQUENCY
END-IF.
IF INCIDENT = 'RECENT'
MOVE 'HYPOTHESIS'
TO CONCLUSION-STATUS
END-IF.
IF CURRENT-DATA
NOT = PAST-SIGNATURE
PERFORM LET-GO-OF-PAST
END-IF.
Comentário:
* EASY TO REMEMBER
* IS NOT THE SAME AS
* LIKELY TO HAPPEN.
Outro:
* DON'T FIGHT LAST FRIDAY.
E naturalmente:
* BAD WOLF WAS VERY MEMORABLE.
Nosso programador fecha o membro.
Mais tarde o telefone toca.
— Temos timeout.
Ele respira.
Pensa imediatamente:
“Db2.”
Porque foi o incidente desta manhã.
Sorri.
O cérebro já começou de novo.
Ele abre o histórico.
— Quais sinais temos?
O operador responde.
A investigação começa.
Não do caso mais memorável.
Do caso que existe agora.
Em algum lugar:
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma frase:
Memória é uma excelente biblioteca de hipóteses. É uma péssima tabela de frequências.
☕🌀
Next stop: Outcome Bias — quando uma decisão ruim dá certo e vira “excelente decisão”, enquanto a mesma decisão dá errado e alguém procura um culpado.
Sem comentários:
Enviar um comentário