 |
| Bellacosa Mainframe e o survivorship bias |
☕ Um Café no Bellacosa Mainframe
Survivorship Bias: Doctor Who, COBOL e o Dia em que Estudamos Apenas Quem Sobreviveu
Uma viagem pela TARDIS dos incidentes para entender por que olhar apenas para casos de sucesso pode esconder exatamente as falhas que mais precisamos conhecer
08:12.
Sala de reunião.
Projetor ligado.
Café na mesa.
Uma apresentação começa.
No primeiro slide:
“Como nossas equipes de maior sucesso trabalham.”
No segundo:
“Padrões encontrados nos projetos que entregaram no prazo.”
No terceiro:
“Boas práticas das aplicações que sobreviveram 20 anos em produção.”
Nosso programador COBOL iniciante observa.
Parece excelente.
Lições práticas.
Experiência real.
História.
Até que ele faz uma pergunta:
— E os projetos que fracassaram?
Silêncio.
O gerente responde:
— Esses não estão na amostra.
O jovem olha novamente para os slides.
— Então estamos aprendendo só com quem deu certo?
— Sim.
— Mas como sabemos que as características que eles possuem foram a causa do sucesso?
Outro silêncio.
VWORP.
VWORP.
VWORP.
A TARDIS aparece ao lado do projetor.
A porta abre.
O Doctor sai.
Olha para a apresentação.
Depois para o programador.
Depois para o gerente.
— Quantos projetos começaram?
— Cinquenta.
— Quantos aparecem no relatório?
— Doze.
O Doctor faz aquela expressão preocupada.
— E os outros trinta e oito?
— Falharam, foram cancelados ou desapareceram.
— Ah.
Pausa.
— Então talvez estejam justamente com a informação mais interessante.
Bem-vindo ao:
Survivorship Bias
Ou:
Viés de Sobrevivência
A tendência de concentrar nossa atenção nos casos que sobreviveram a algum processo de seleção e esquecer os casos que desapareceram, falharam, foram descartados ou nunca chegaram ao final.
🌀 A TARDIS já encontrou muitos monstros
Até aqui estudamos:
Swiss Cheese Model — várias barreiras imperfeitas podem falhar juntas.
Normalization of Deviance — desvios repetidos viram rotina.
Hindsight Bias — depois do incidente tudo parece óbvio.
Confirmation Bias — buscamos evidências que apoiem nossas crenças.
Anchoring Bias — a primeira explicação pesa demais.
Groupthink — grupos convergem rápido demais.
Authority Gradient — hierarquia pode silenciar informação importante.
Plan Continuation Bias — continuamos um plano porque já investimos nele.
Alarm Fatigue — alertas demais viram ruído.
Automation Bias — confiamos demais em sistemas automáticos.
Drift Into Failure — pequenas adaptações empurram sistemas lentamente para a borda.
Diffusion of Responsibility — todo mundo vê e ninguém assume.
Normalcy Bias — sinais anormais aparecem, mas esperamos que tudo volte ao normal.
Agora nossa TARDIS precisa fazer uma coisa diferente:
procurar quem não está mais na fotografia.
✈️ A história clássica dos aviões
Survivorship Bias ficou famoso por um exemplo associado à Segunda Guerra Mundial.
Analistas estudavam aviões que retornavam de missões e observavam onde havia mais marcas de tiros.
A ideia intuitiva seria:
reforçar as áreas mais atingidas.
Mas Abraham Wald percebeu algo importante.
Esses eram os aviões que conseguiram voltar.
As áreas perfuradas nos aviões sobreviventes eram justamente lugares onde o avião podia ser atingido e ainda retornar.
As regiões que deveriam receber maior atenção eram aquelas onde havia poucos impactos nos aviões sobreviventes.
Por quê?
Porque aviões atingidos nessas áreas provavelmente não voltavam para ser observados.
Essa história é uma das melhores ilustrações do Survivorship Bias.
A informação crucial estava nos ausentes.
💥 Bellacosa Mainframe: os jobs que “sempre funcionaram”
Imagine uma equipe analisando programas COBOL antigos.
Eles selecionam dez aplicações com 25 anos de produção.
Descobrem:
muita lógica procedural;
poucos testes automatizados;
documentação incompleta;
manutenção manual;
arquitetura monolítica.
Conclusão:
“Aplicações COBOL sobrevivem bem mesmo sem testes modernos.”
Cuidado.
Talvez essas dez aplicações tenham sobrevivido apesar dessas características.
E onde estão as outras cinquenta aplicações semelhantes que foram:
reescritas;
descontinuadas;
substituídas;
abandonadas;
ou quebraram de forma irrecuperável?
Se você não olha para elas, pode transformar acaso em receita.
🧠 Sobrevivente não é sinônimo de modelo
Esse é um ponto essencial.
Se alguém sobreviveu a uma prática arriscada, isso não significa que a prática seja segura.
Exemplo:
“Faço deploy direto há dez anos e nunca deu problema.”
Ótimo.
Isso prova:
você sobreviveu por dez anos.
Não prova:
deploy direto é seguro.
Talvez outros tenham feito a mesma coisa e falhado.
Você não os vê porque saíram da amostra.
☕ “Sempre fiz assim”
Essa frase já apareceu em Normalization of Deviance.
Agora ela ganha outro significado.
“Sempre fizemos assim e estamos aqui.”
Isso parece forte.
Mas é um argumento baseado apenas nos sobreviventes.
Talvez os que fizeram diferente também estejam aqui.
Talvez os que fizeram igual e quebraram não estejam.
O simples fato de você existir hoje distorce a amostra.
👻 Easter Egg nº 1 — O companion que não voltou
Imagine o Doctor dizendo:
— Todos os companions que voltaram disseram que o planeta era seguro.
O novo companion pergunta:
— E os que não voltaram?
Silêncio.
O Doctor olha para a TARDIS.
— Excelente pergunta.
Em segurança, sempre pergunte pelos ausentes.
📊 Dados sobreviventes são dados filtrados
Esse ponto é muito importante.
Imagine uma tabela:
PROJETOS CONCLUÍDOS COM SUCESSO
A
B
C
D
E
Você estuda.
Descobre que todos usavam metodologia X.
Conclui:
metodologia X causa sucesso.
Mas talvez houvesse:
PROJETOS QUE USARAM X
A → sucesso
B → sucesso
C → sucesso
D → sucesso
E → sucesso
F → falhou
G → falhou
H → cancelado
I → cancelado
J → fracasso
Agora a história muda.
A metodologia X não possui mais 100% de sucesso.
Você só estava olhando para uma amostra censurada.
🧠 Selection Bias
Survivorship Bias é um tipo de viés de seleção.
A amostra observada não representa toda a população porque algum processo eliminou casos.
Isso acontece muito em tecnologia.
Você observa:
empresas que cresceram;
sistemas que continuam rodando;
profissionais que ficaram na carreira;
projetos que chegaram à produção.
Mas não vê:
os que falharam cedo.
💻 “COBOL está há 60 anos funcionando”
É verdade que COBOL possui uma extraordinária história de longevidade.
Mas tome cuidado com a interpretação.
Você pode observar aplicações COBOL robustas que sobreviveram décadas.
Isso pode refletir:
qualidade;
estabilidade;
investimento;
criticidade;
manutenção;
processos maduros.
Mas também existe seleção.
Aplicações COBOL ruins podem ter sido substituídas há décadas.
Logo, o conjunto atual é formado parcialmente pelos sobreviventes mais úteis e resilientes.
Isso não diminui o valor do COBOL.
Apenas melhora nossa análise.
🏛️ Sistemas legados são sobreviventes selecionados
Quando alguém olha para um mainframe antigo e diz:
“Se ainda está rodando, deve ser bom.”
Talvez.
Ou talvez seja:
caro de substituir;
crítico;
bem mantido;
fortemente acoplado;
ou simplesmente sobrevivente de um processo histórico.
Precisamos investigar.
🧠 Lindy Effect e Survivorship Bias não são iguais
Existe uma ideia chamada Lindy Effect: para certas coisas não perecíveis, sobreviver por muito tempo pode sugerir maior probabilidade de continuar existindo.
Isso é diferente de dizer:
“Se sobreviveu, tudo em sua arquitetura é correto.”
Um sistema antigo pode ter valor comprovado.
Mas ainda possuir fragilidades.
Não use longevidade como imunidade.
🧀 Swiss Cheese + Survivorship Bias
Aqui surge uma conexão interessante.
Se estudamos apenas incidentes evitados ou sistemas sobreviventes, talvez observemos apenas barreiras que funcionaram.
Mas e os casos onde:
barreiras falharam;
incidentes destruíram sistemas;
empresas desapareceram?
Eles podem não estar disponíveis para estudo interno.
A amostra fica otimista.
🚨 Near Misses e sobrevivência
Near miss é, por definição, um evento em que o sistema sobreviveu.
Isso é valioso.
Mas não conclua:
“a defesa final sempre funciona.”
Talvez tenha funcionado daquela vez.
Investigue quantas vezes falhou.
📚 Post-mortems publicados também sofrem seleção
Empresas maduras publicam incident reports.
Excelente.
Mas quais empresas você consegue estudar?
As que:
existem;
documentam;
publicam.
E as organizações que falharam profundamente e desapareceram?
Talvez tenham informações preciosas que nunca foram publicadas.
Então até nossa literatura de incidentes pode sofrer Survivorship Bias.
🧠 “Best Practices” precisam de cuidado
Muitos textos dizem:
“Estudamos 100 empresas de sucesso e descobrimos que todas fazem X.”
Survivorship Bias pergunta:
Quantas empresas fracassadas também faziam X?
Sem grupo comparativo, talvez X seja irrelevante.
Exemplo:
todas empresas bem-sucedidas possuem reuniões.
As fracassadas também.
Reuniões não explicam sucesso.
💰 Empreendedorismo é cheio desse viés
Empresário bilionário:
“Abandonei a faculdade e deu certo.”
Talvez.
Mas quantos abandonaram e não ficaram bilionários?
Os que fracassaram não recebem palestras TED.
Esse é Survivorship Bias.
👨💻 Carreira técnica também
Veterano:
“Nunca precisei aprender Git e cheguei até aqui.”
Interessante.
Mas quantos profissionais com mesma estratégia perderam oportunidades?
Você não sabe.
A trajetória de quem permaneceu visível não representa todos os caminhos.
🌀 Drift Into Failure + Survivorship Bias
Essa combinação é perigosa.
Sistema opera perto do limite durante anos.
Nada acontece.
Conclusão:
margem baixa é suficiente.
Mas você está usando o sobrevivente como prova.
Talvez outro sistema semelhante tenha falhado.
A ausência de desastre local não é evidência universal.
🧠 Normalization of Deviance reforça
Desvio.
Nada acontece.
Repete.
Sistema sobrevive.
Survivorship Bias:
“Viu? É seguro.”
Normalization of Deviance:
“Então vira normal.”
Essa dupla pode aumentar risco rapidamente.
🔔 Alarm Fatigue
Um operador diz:
“Ignoramos esse alerta há cinco anos e nunca aconteceu nada.”
Você está ouvindo:
normalização do desvio;
survivorship bias.
Talvez o sistema simplesmente tenha sobrevivido cinco anos.
🤖 Automation Bias
Ferramenta automatizada tomou mil decisões.
999 aparentemente corretas.
Uma errada ainda não causou desastre.
Equipe conclui:
automação é confiável.
Mas talvez você só esteja observando resultados que sobreviveram.
Além disso, falhas não detectadas podem não estar nos dados.
🧠 Silent Failures
Esse ponto é fantástico.
Nem toda falha gera incidente visível.
Talvez uma automação esteja errando 0,5% das transações, mas o problema seja corrigido manualmente pelos usuários.
O dashboard registra:
sucesso.
Você está olhando apenas para o que permaneceu visível.
Falhas silenciosas também saem da amostra.
👥 Diffusion of Responsibility
Incident reports normalmente registram incidentes reconhecidos.
E os problemas que ninguém assumiu e desapareceram silenciosamente?
Talvez voltaram depois.
Se não foram registrados, não entram no aprendizado.
Survivorship Bias também pode acontecer dentro do histórico operacional.
🧠 Historical Logging Bias
Se logs guardam apenas:
erros severos,
você não consegue estudar:
warnings;
near misses;
correções manuais.
Seu passado parece mais limpo do que realmente foi.
Preservação de dados influencia aprendizado.
☕ Bellacosa Mainframe: o batch perfeito
Imagine:
JOB ABC123
RUNS: 10.000
ABENDS: 0
Fantástico.
Mas alguém pergunta:
Quantas vezes houve intervenção manual?
Resposta:
1.800.
A história muda.
O job não era autonomamente perfeito.
Pessoas salvaram 1.800 execuções.
Se você olha só para ABENDs, sofre Survivorship Bias operacional.
🦸 Heroísmo oculta falhas
No Drift Into Failure vimos isso.
Carlos corrige manualmente.
Nada cai.
Então sistema parece resiliente.
Mas o sobrevivente é:
sistema + Carlos.
Não sistema sozinho.
Se você esquecer Carlos na análise, aprenderá a lição errada.
🧠 Counterfactual Thinking
Uma técnica poderosa:
pergunte:
“O que teria acontecido sem essa intervenção?”
Se resposta:
incidente,
então registre como near miss.
Não como execução normal.
📊 Denominador importa
Esse talvez seja o coração matemático do Survivorship Bias.
Não pergunte apenas:
quantos sucessos?
Pergunte:
sucessos de quantas tentativas?
Exemplo:
10 sucessos
Parece bom.
Agora:
10 sucessos / 10 tentativas
Excelente.
Ou:
10 sucessos / 1000 tentativas
Péssimo.
Sem denominador, não sabemos quase nada.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Todos os casos que conheço deram certo.”
Pergunte:
“Quantos casos deram errado e deixaram de ser visíveis?”
🎯 Pergunta Bellacosa nº 2
Quando alguém mostrar:
“Top 10 projetos de sucesso”
Pergunte:
“Qual era a população original?”
🎯 Pergunta Bellacosa nº 3
Quando alguém disser:
“Esse sistema nunca caiu.”
Pergunte:
“Quantas intervenções impediram que caísse?”
🎯 Pergunta Bellacosa nº 4
E:
“O que estamos incapazes de observar porque não sobreviveu até entrar no relatório?”
Essa é a pergunta central.
🧪 Como combater Survivorship Bias
Passo 1 — Procure os casos ausentes
Projetos cancelados.
Incidentes silenciosos.
Clientes perdidos.
Aplicações desativadas.
Mudanças rollbackadas.
Passo 2 — Defina o denominador
Não apenas sucessos.
Total de tentativas.
Passo 3 — Compare sobreviventes e não sobreviventes
O que existia em ambos?
O que realmente diferencia?
Passo 4 — Preserve near misses
Eles mostram caminhos que quase falharam.
Passo 5 — Registre intervenções manuais
Não deixe heroísmo virar execução “normal”.
Passo 6 — Estude rollbacks
Rollback bem-sucedido não é simplesmente “nada aconteceu”.
Talvez tenha evitado incidente.
Passo 7 — Analise projetos mortos
Post-mortem não deveria existir só para incidentes.
Projetos cancelados também ensinam.
Passo 8 — Estude sistemas aposentados
Por que saíram?
Custo?
Fragilidade?
Escalabilidade?
Manutenção?
Esses dados ajudam.
Passo 9 — Cuidado com histórias inspiradoras
História individual não é distribuição estatística.
Passo 10 — Procure dados negativos
Não apenas:
o que funcionou?
Mas:
o que não funcionou?
E onde não há dados?
🏦 Bancos e Survivorship Bias
Imagine revisar controles antifraude.
Você estuda:
fraudes detectadas.
Mas e as fraudes não detectadas?
Você não conhece.
Isso é um problema clássico.
Os dados disponíveis são parcialmente selecionados pelo próprio sistema de detecção.
O invisível continua invisível.
🔐 Segurança cibernética
SOC analisa ataques bloqueados.
Ótimo.
Mas e ataques que passaram sem detecção?
A ausência deles no SIEM não significa ausência real.
Mais uma vez:
o dataset possui sobreviventes.
🧠 Detection Bias
Seu sistema de detecção define o que consegue estudar.
Se ferramenta detecta melhor malware A que malware B, histórico mostrará mais A.
Você pode concluir:
A é mais comum.
Talvez apenas seja mais visível.
🧬 Observabilidade afeta epistemologia
Frase sofisticada.
Tradução Bellacosa:
Você aprende sobre aquilo que consegue enxergar.
Se sensores são enviesados, conhecimento também será.
Isso conecta Survivorship Bias com Automation Bias.
💾 COBOL e testes
Imagine testes unitários cobrindo cenários conhecidos.
Todos passam.
Ótimo.
Mas testes fracassados anteriores podem ter sido corrigidos e removidos.
Histórico atual mostra apenas suíte saudável.
Não esqueça bugs passados.
Eles revelam fronteiras do sistema.
🐞 Bug database é memória dos não sobreviventes
Um bug corrigido é um comportamento que não sobreviveu à seleção.
Isso é valioso.
Mantenha histórico.
Não apague tudo porque:
“já corrigimos.”
A correção ensina.
📚 Documente por que algo foi removido
Comentário:
* VALIDATION ADDED AFTER INC-2024-017
Excelente.
Isso preserva memória do caminho que falhou.
Caso contrário, futura equipe vê código “redundante” e remove.
Normalization of Deviance e Survivorship Bias se cumprimentam.
🕰️ Hindsight Bias + Survivorship Bias
Depois de um sucesso:
“Era óbvio que daria certo.”
Depois de fracasso:
“Era óbvio que daria errado.”
Mas se você estuda apenas sucessos, pode reconstruir uma narrativa falsa de inevitabilidade.
Isso é:
Hindsight + Survivorship.
Dupla perigosa.
👥 Groupthink em histórias de sucesso
Uma empresa bem-sucedida cria cultura:
“Nosso método funciona.”
Todos repetem.
Casos ruins são atribuídos a execução.
Casos bons ao método.
Confirmation Bias entra.
Survivorship Bias escolhe amostra.
Groupthink protege narrativa.
Perfeito.
🧠 Cargo cult
Talvez você já tenha visto:
empresa A teve sucesso usando prática X.
Empresa B copia X.
Sem entender contexto.
Isso é quase um cargo cult tecnológico.
Exemplo:
Spotify usou modelo organizacional X.
Então todas empresas copiam.
Mas você vê o Spotify que sobreviveu.
Não todas as empresas que tentaram modelos similares e falharam.
Práticas precisam ser avaliadas no contexto.
🤖 IA e benchmark survivorship
Imagine avaliar agentes de IA apenas nas tarefas que completaram.
Você conclui:
95% accuracy.
Mas e tarefas abandonadas?
Timeout?
Escaladas para humano?
Filtradas antes?
Se não entram no denominador, métrica engana.
📊 Success Rate precisa incluir falhas silenciosas
Métrica:
COMPLETED TASKS: 950
SUCCESS: 900
Você precisa saber:
Total recebido?
1000?
1200?
Quantos foram descartados?
Sem denominador completo:
não sabemos.
🧠 Censoring
Em estatística existe o conceito de censura de dados.
Algumas observações não são vistas completamente.
Isso aparece muito em sobrevivência.
Em sistemas:
tarefas que desaparecem antes de completar podem ser justamente as mais importantes.
🛰️ Space Missions
Imagine estudar apenas missões espaciais que chegaram ao destino.
Você aprende características dos sobreviventes.
Mas os lançamentos que falharam contêm informações fundamentais sobre risco.
Engenharia aprende muito com destroços.
Talvez mais do que com sucesso.
💥 Acidentes são dados caros
Incidentes custam.
Quando acontecem, desperdiçar aprendizado é quase ofensivo.
Não basta corrigir.
Preserve:
timeline;
condições;
sinais;
decisões;
barreiras;
falhas.
Os não sobreviventes pagaram a mensalidade da aula.
Estude.
🧠 Safety-I + Safety-II
Perspectivas modernas de segurança valorizam estudar:
o que dá errado;
e o que dá certo.
Survivorship Bias lembra:
não podemos estudar apenas um lado.
Precisamos observar:
sucessos;
falhas;
near misses;
adaptações.
A distribuição completa.
☕ Exemplo completo Bellacosa
Você quer descobrir melhor forma de deploy.
Analisa 20 deploys bem-sucedidos.
Todos tiveram:
aprovação manual.
Conclui:
aprovação manual causa sucesso.
Mas histórico completo:
TOTAL: 100 deploys
80 sucesso
20 falha
Dos 80:
60 tinham aprovação manual.
Dos 20 falhos:
18 também tinham aprovação manual.
Agora aprovação manual não parece tão protetora.
Talvez outro fator seja mais importante.
📐 Compare taxas
Pergunta correta:
P(success | control)
versus
P(success | no control)
Não apenas:
quantos sucessos tinham controle?
Essa mudança de pergunta é gigantesca.
🧠 Base Rate Neglect aparece no horizonte
Outro viés relacionado:
Base Rate Neglect.
Ignorar taxas-base.
Talvez seja outro ótimo capítulo futuro.
Porque a probabilidade de um evento depende também da frequência original.
Survivorship Bias e base rates andam perto.
👨💻 Dica para o programador COBOL iniciante
Quando veterano disser:
“Esse padrão é ótimo. Todos os programas antigos usam.”
Pergunte:
“Os programas antigos que não usam desapareceram ou nunca existiram?”
E também:
“Existiam programas ruins com esse mesmo padrão?”
Você não está desrespeitando experiência.
Está tentando entender seleção.
🧠 Experience Bias
Experiência é valiosa.
Mas a experiência de uma pessoa é uma amostra.
Ela lembra:
projetos onde trabalhou;
empresas onde ficou;
tecnologias que sobreviveram.
Pode não ver aquilo que desapareceu.
Por isso história, dados e casos negativos complementam experiência.
🏛️ Arqueologia do fracasso
Uma prática maravilhosa:
não estude apenas sistemas vivos.
Estude:
cemitérios de aplicações.
Projetos aposentados.
Arquiteturas removidas.
Ferramentas abandonadas.
Pergunte:
“Por que isso morreu?”
Isso é arqueologia tecnológica.
E talvez seja uma das melhores escolas de engenharia.
👻 Easter Egg nº 2 — O cemitério de TARDIS
Imagine um planeta cheio de TARDIS quebradas.
O companion diz:
— Mas a nossa sempre funcionou.
Doctor olha ao redor.
— Exatamente.
— Não entendi.
— Nós estamos dentro da que sobreviveu.
Silêncio.
Perfeito.
🧪 Failure Database
Crie um repositório de:
falhas;
near misses;
rollbacks;
bugs críticos;
mudanças canceladas;
projetos descontinuados.
Não como vergonha.
Como ativo de conhecimento.
🔍 Perguntas para projetos mortos
Por que cancelou?
Qual hipótese estava errada?
Qual sinal apareceu primeiro?
Quando poderíamos ter parado?
Qual dependência foi subestimada?
Qual custo cresceu?
Isso conecta Plan Continuation Bias.
🧠 Survivorship Bias e Plan Continuation
Projetos que continuaram até dar certo são celebrados.
Histórias:
“Quase desistimos, mas persistimos!”
Inspirador.
Mas onde estão os projetos que persistiram e queimaram milhões?
Não recebem filme.
Logo podemos supervalorizar persistência.
Isso é perigosíssimo.
Às vezes persistir é coragem.
Às vezes é Plan Continuation Bias.
Você precisa da população completa.
💸 “Nunca desista” é péssima política de risco
Melhor:
“Não desista apenas por desconforto; não continue apenas por orgulho.”
Dados.
Critérios.
Contexto.
🧠 Authority Gradient + Survivorship Bias
Líder veterano:
“Eu sempre fiz assim e deu certo.”
Essa frase possui força hierárquica.
Júnior pode não perguntar:
“Quantas vezes outros fizeram e falharam?”
Authority Gradient protege uma narrativa enviesada.
📈 Métricas de sucesso precisam incluir churn
Produto:
1 milhão de usuários ativos.
Impressionante.
Mas quantos saíram?
Se só olha quem ficou:
Survivorship Bias.
Em sistemas internos:
quantas transações concluídas?
Mas quantas abandonadas?
Sempre procure o desaparecido.
🧠 Missingness is Data
A ausência pode ser informação.
Exemplo:
clientes que não reclamaram.
Talvez estejam satisfeitos.
Ou desistiram.
Você não sabe.
Silêncio não é necessariamente sucesso.
Essa ideia conecta com Diffusion of Responsibility e Groupthink.
🚪 Pessoas que saíram da empresa
Pesquisa de cultura apenas com funcionários atuais pode mostrar:
todo mundo gosta.
E quem odiava saiu.
Survivorship Bias.
Exit interviews também importam.
👥 Incidentes e turnover
Equipe veterana diz:
processo funciona.
Mas cinco pessoas saíram porque burnout era insustentável.
Processo sobreviveu.
Pessoas não.
Métrica técnica verde.
Sistema sociotécnico vermelho.
🧠 Safety inclui pessoas
Drift Into Failure nos ensinou isso.
Não avalie apenas uptime.
Avalie:
carga;
burnout;
heroísmo;
turnover.
Caso contrário, pessoas que permanecem tornam-se amostra enviesada.
🧬 Regeneração organizacional
Como uma organização se regenera contra Survivorship Bias?
Ela pergunta:
quem está faltando na amostra?
quais falhas não registramos?
quais projetos morreram?
quais pessoas saíram?
quais rollbacks evitamos contar?
quais transações abandonaram?
quais clientes desistiram?
quais sistemas foram substituídos?
Depois amplia o dataset.
Compara.
Aprende.
O segredo é:
não estudar apenas aquilo que chegou vivo até o relatório.
📋 Checklist anti-Survivorship Bias
Antes de concluir:
[ ] Qual é a população completa?
[ ] Estamos olhando apenas sucessos?
[ ] Onde estão os casos que falharam?
[ ] Existe denominador?
[ ] Near misses estão incluídos?
[ ] Rollbacks estão incluídos?
[ ] Intervenções manuais estão registradas?
[ ] Casos silenciosos podem estar faltando?
[ ] Nosso sistema de detecção filtra a amostra?
[ ] Pessoas ou projetos desapareceram antes da medição?
[ ] A característica observada aparece também nos fracassos?
[ ] Estamos transformando história inspiradora em regra geral?
Se você não sabe quem está ausente...
a conclusão deveria ficar mais humilde.
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Survivorship Bias acontece quando estudamos os casos que sobreviveram e esquecemos os que desapareceram.
Sobrevivência não prova que uma prática seja segura.
Histórias de sucesso sem denominador enganam.
Pergunte sempre quantas tentativas existiram.
Sistemas legados são uma amostra selecionada pelo tempo.
Near misses e rollbacks precisam entrar na análise.
Intervenção manual pode esconder fragilidade.
Falhas silenciosas podem não entrar nos dados.
Best practices baseadas apenas em vencedores merecem desconfiança.
Ausência de caso não significa ausência de evento.
E principalmente:
Às vezes a informação mais importante não está nas máquinas que voltaram para casa — está nos lugares onde as máquinas que não voltaram foram atingidas.
🕰️ De volta à apresentação das 08:12
O Doctor pega o controle remoto.
Slide:
“12 projetos de sucesso.”
Ele pergunta:
— Quantos começaram?
— Cinquenta.
Novo slide.
Criam uma tabela:
50 PROJETOS
12 sucesso
14 cancelados
9 atrasados
8 abandonados
7 substituídos
Agora estudam todos.
Descobrem algo curioso.
A característica que aparecia nos 12 projetos vencedores...
também aparecia em quase todos os projetos fracassados.
Logo:
não explicava sucesso.
Mas outra característica aparecia com muito mais frequência nos casos bem-sucedidos:
feedback precoce.
Ainda não prova causalidade.
Mas agora temos uma hipótese melhor.
Nosso programador sorri.
— Então estávamos estudando a coisa errada?
O Doctor responde:
— Não exatamente.
— Como não?
— Vocês estavam estudando dados reais.
Pausa.
— Só esqueceram que realidade também inclui aquilo que desapareceu.
🥚 Easter Egg final
Depois da reunião, nosso programador encontra:
BELLACOSA.BIAS(SURVIVE)
Dentro:
IF SAMPLE = SURVIVORS-ONLY
PERFORM FIND-MISSING
END-IF.
IF SUCCESS-COUNT > 0
PERFORM CHECK-DENOMINATOR
END-IF.
IF SOMEONE-SAYS
'IT-WORKED-FOR-ME'
PERFORM ASK-WHO-FAILED
END-IF.
Comentário:
* THE ABSENT CASES STILL COUNT.
Outro:
* A SUCCESS STORY IS NOT A DISTRIBUTION.
E, naturalmente:
* BAD WOLF DID NOT MAKE IT INTO THE SAMPLE.
Nosso programador fecha o membro.
Mais tarde, alguém diz:
— Nunca vi esse erro acontecer.
Ele quase responde:
“Então não acontece.”
Mas para.
Pergunta:
— Ou será que quando acontece ele não chega até nós?
Silêncio.
O operador olha.
O DBA pensa.
Talvez exista uma fila de registros rejeitados que ninguém acompanha.
Eles abrem.
Existem centenas.
Nenhum incidente.
Nenhum chamado.
Nenhum cliente reclamou.
Os registros simplesmente não chegaram ao fluxo normal.
Os dados ausentes acabaram de aparecer.
O Doctor, em algum ponto do espaço-tempo, provavelmente sorri.
Porque nosso programador aprendeu uma habilidade nova:
olhar para a fotografia e perguntar quem deveria estar nela, mas não está.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro fica escrito:
Não pergunte apenas por que os vencedores venceram. Pergunte também por que os outros não chegaram ao final.
☕🌀
Next stop: Base Rate Neglect — quando um caso parece tão convincente que esquecemos completamente de perguntar o quão provável ele era antes de começarmos a investigação.
Sem comentários:
Enviar um comentário