 |
| Bellacosa Mainframe e o actor observer bias |
☕ Um Café no Bellacosa Mainframe
Actor-Observer Bias: Doctor Who, COBOL e o Dia em que o Meu Erro Tinha Contexto — Mas o Seu Era Incompetência
Uma viagem pela TARDIS dos incidentes para entender por que explicamos nossos próprios erros pelas circunstâncias, mas os erros dos outros por personalidade, descuido ou falta de competência
03:16.
Madrugada.
War Room.
Café número cinco.
Produção degradada.
Na tela:
SEV-1
TRANSACTION FAILURE RATE: 18%
QUEUE DEPTH: 84.000
CUSTOMER IMPACT: HIGH
O DBA olha para o desenvolvedor.
— Quem fez o deploy?
— Minha equipe.
— Então começou depois da mudança de vocês?
— Sim, mas havia um problema de infraestrutura também.
O DBA cruza os braços.
— Sempre tem uma desculpa.
Nosso jovem programador COBOL observa.
Dez minutos depois descobrem uma query cara.
O DBA havia alterado uma configuração no dia anterior.
O desenvolvedor pergunta:
— Quem mexeu no parâmetro?
— Eu.
— Então foi erro seu?
O DBA reage imediatamente.
— Não é tão simples.
— Como assim?
— O volume cresceu muito, o ambiente estava pressionado, o parâmetro fazia sentido com os dados que eu tinha e ninguém informou que aquela aplicação mudaria o padrão de acesso.
Nosso jovem fica em silêncio.
Interessante.
Quando o desenvolvedor errou:
“Sempre tem uma desculpa.”
Quando o DBA participou:
“Não é tão simples.”
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do monitor.
A porta abre.
O Doctor sai.
Olha para o DBA.
Depois para o desenvolvedor.
— Quando ele errou, qual foi a explicação?
— Falta de cuidado.
— E quando você errou?
— Contexto.
O Doctor sorri.
— Ah.
— O quê?
— Um dos recursos mais elegantes do cérebro humano.
Pausa.
— Para os outros, personalidade. Para nós, circunstâncias.
Bem-vindo ao:
Actor-Observer Bias
Ou:
Viés Ator-Observador
A tendência de explicar o nosso próprio comportamento principalmente pelas circunstâncias em que estávamos inseridos, enquanto explicamos o comportamento das outras pessoas principalmente por características pessoais.
Em linguagem Bellacosa:
“Eu fiz porque a situação estava complicada. Você fez porque é descuidado.”
🌀 O ponto exato onde essa viagem encontra o capítulo anterior
No Fundamental Attribution Error, vimos a tendência de olhar para outra pessoa e concluir:
“Ela fez isso porque é incompetente.”
Agora vamos um passo além.
Actor-Observer Bias acrescenta a assimetria:
quando somos nós:
“Você não entende o contexto.”
Quando são os outros:
“O problema é a pessoa.”
É o clássico:
MEU ATRASO
=
TRÂNSITO
SEU ATRASO
=
IRRESPONSABILIDADE
Em produção:
MEU RESTART ERRADO
=
PRESSÃO DA WAR ROOM
SEU RESTART ERRADO
=
FALTA DE EXPERIÊNCIA
A diferença parece engraçada.
Até começar a contaminar RCA, liderança, promoção, colaboração entre equipes e resposta a incidentes.
🧠 Ator e observador enxergam mundos diferentes
Existe uma razão intuitiva para isso.
Quando somos o ator, vemos:
pressão;
prazo;
mensagens;
alertas;
informação incompleta;
cansaço;
restrições.
Vivemos a situação por dentro.
Quando somos o observador, frequentemente vemos apenas:
a pessoa;
a ação;
o resultado.
O contexto desaparece.
Então o cérebro preenche o espaço vazio com:
personalidade.
☕ Bellacosa Mainframe: o operador que cancelou o job
Imagine.
Job aparentemente travado.
Operador cancela.
O cancelamento provoca reprocessamento de quatro horas.
No dia seguinte:
— Como ele pôde cancelar sem verificar?
Resposta fácil:
“Falta de experiência.”
Agora coloque você no console.
03:32.
Usuários ligando.
Gerente perguntando a cada dois minutos:
“Vai voltar quando?”
Job sem output há 40 minutos.
Runbook diz:
IF NO PROGRESS > 30 MIN
CANCEL AND RESTART
Você cancela.
Depois descobrem:
o job estava em uma fase longa de SORT que não escrevia mensagens.
De fora:
“Ele deveria saber.”
De dentro:
“Segui o runbook com a informação disponível.”
Actor-Observer Bias vive nessa diferença.
👻 Easter Egg nº 1 — Companion vs Doctor
Companion aperta um botão errado.
Doctor:
— Por que você fez isso?
— A nave estava explodindo!
— Ainda assim deveria ter pensado.
Cinco minutos depois o Doctor puxa uma alavanca errada.
Companion:
— Por que fez isso?
— Situação completamente diferente.
— Estávamos na mesma nave.
— Sim, mas eu tinha contexto.
Pausa.
— Você sempre tem contexto?
— Sou o Doctor.
Perfeito.
🧠 Actor-Observer Bias não significa que todas as explicações situacionais estejam corretas
Importante.
Às vezes a pessoa realmente:
não sabia;
não revisou;
agiu mal;
violou processo.
O viés não diz:
“personalidade nunca importa.”
Diz:
nossa forma de distribuir peso entre pessoa e contexto pode mudar dependendo de quem está sendo avaliado.
O problema é a assimetria.
🎯 A pergunta central
Em vez de:
“Por que ele fez isso?”
pergunte:
“Se eu estivesse nas mesmas condições, com a mesma informação, o que eu poderia ter feito?”
Essa pergunta é desconfortável.
E por isso útil.
🧠 Actor-Observer Bias + Fundamental Attribution Error
Os dois são parentes próximos.
Fundamental Attribution Error
Tendência geral de superestimar fatores pessoais ao explicar o comportamento dos outros.
Actor-Observer Bias
Tendência a explicar:
meu comportamento → contexto;
comportamento alheio → personalidade.
Ou seja:
Actor-Observer Bias enfatiza a diferença de perspectiva.
☕ Exemplo no COBOL
Seu colega esquece de inicializar uma variável.
Bug.
Você pensa:
“Como alguém esquece isso?”
Na semana seguinte você esquece.
Sua explicação:
“Eu estava mexendo em três copybooks, o requisito mudou e tive que resolver uma emergência.”
Verdade.
Mas talvez seu colega também tivesse uma história semelhante.
🧠 Self-Serving Bias entra pela porta lateral
No capítulo anterior vimos:
Self-Serving Bias:
sucesso → mérito interno;
fracasso → fatores externos.
Agora:
Actor-Observer Bias:
meu comportamento → contexto;
comportamento dos outros → pessoa.
Os dois juntos criam uma blindagem excelente.
Quando eu erro:
contexto.
Quando você erra:
você.
Quando eu acerto:
competência.
Quando você acerta:
teve boas condições.
A diplomacia corporativa agradece.
😄 Algoritmo universal da autoestima
IF PERSON = ME
IF RESULT = GOOD
MOVE 'COMPETENCE' TO CAUSE
ELSE
MOVE 'CONTEXT' TO CAUSE
END-IF
ELSE
IF RESULT = BAD
MOVE 'PERSONALITY' TO CAUSE
ELSE
MOVE 'LUCK' TO CAUSE
END-IF
END-IF
Compila perfeitamente na psicologia humana.
🧠 Narrative Bias cria a versão conveniente
O cérebro gosta de histórias.
Para mim:
“Eu estava sob pressão, recebi dados incompletos, o sistema estava instável e precisei decidir rápido.”
Narrativa rica.
Para o outro:
“Ele foi afoito.”
Narrativa compacta.
Percebe?
Nossa própria história possui:
capítulos.
A história do outro cabe em uma etiqueta.
☕ “Fulano é difícil”
Essa frase é perigosíssima.
Talvez Fulano tenha:
questionado requisito;
pedido evidência;
negado mudança arriscada.
O observador transforma:
comportamento contextual
em:
traço permanente.
Depois tudo que Fulano faz passa pelo filtro:
“Ele é difícil.”
Confirmation Bias aparece.
🔎 Confirmation Bias consolida o rótulo
Uma vez que alguém virou:
“descuidado”;
“difícil”;
“fraco”;
“afoito”,
começamos a notar eventos compatíveis.
Esquecemos os outros.
Agora Actor-Observer Bias virou reputação.
🧠 Recency Bias pode piorar
Pessoa errou ontem.
Hoje faz outra coisa.
O erro recente domina avaliação.
“Está vendo? Ele é assim.”
Talvez sejam dois eventos contextuais.
Mas Recency + Attribution transforma comportamento recente em identidade.
🧠 Representativeness Heuristic também
Pessoa se encaixa no protótipo:
“júnior inseguro.”
Então hesitou.
Conclusão:
“Falta confiança.”
Talvez hesitou porque percebeu risco.
A categoria engoliu o contexto.
🪜 Authority Gradient torna a assimetria ainda mais injusta
Chefe erra:
“A decisão era difícil.”
Júnior erra:
“Faltou maturidade.”
Mesmo tipo de erro.
Mesmo sistema.
Mas posições alteram interpretação.
Isso é muito comum.
Quanto maior o cargo:
mais contexto concedemos.
Quanto menor:
mais personalidade atribuímos.
☕ O executivo “tomou uma decisão difícil”
O operador:
“cometeu erro.”
Interessante diferença de vocabulário.
Framing Effect aparece.
🧠 Framing e Actor-Observer
Compare:
“O operador ignorou o alerta.”
versus:
“O operador recebeu 417 alertas durante o turno e priorizou incorretamente este.”
A primeira descreve pessoa.
A segunda descreve pessoa + contexto.
Mesmo fato.
Outra compreensão.
🔔 Alarm Fatigue
Esse é um exemplo perfeito.
Observador:
“Ele ignorou alerta crítico.”
Ator:
“Era o alerta número 286.”
Se você só vê o evento crítico retrospectivamente:
parece absurdo.
Se vê o fluxo inteiro:
talvez a decisão seja compreensível.
Não correta.
Compreensível.
Essa diferença é fundamental.
🧠 Hindsight Bias torna tudo pior
Depois do incidente sabemos:
aquele alerta era o importante.
Operador não sabia.
Nós olhamos para timeline e pensamos:
“Como não percebeu?”
Porque agora o alerta está destacado em vermelho num PowerPoint.
Naquele momento:
era um entre centenas.
Actor-Observer + Hindsight é uma dupla cruel.
🧠 Outcome Bias muda o julgamento
Dois operadores tomam mesma decisão.
Operador A:
restart.
Sistema volta.
Resultado:
“boa iniciativa.”
Operador B:
restart.
Sistema piora.
Resultado:
“impulsivo.”
Mesma ação.
Outro resultado.
Outcome Bias altera a personalidade que atribuiremos ao ator.
☕ Herói de um lado, irresponsável do outro
Às vezes separados apenas pela sorte.
🧠 Action Bias
Manager grita:
“Faça alguma coisa!”
Operador age.
Depois ação piora sistema.
Post-mortem:
“Operador deveria ter analisado mais.”
Mas a cultura premiou ação imediata.
Contexto importa.
Actor-Observer Bias deixa o observador esquecer a pressão que ajudou a criar.
🧠 Omission Bias
Outro caso:
operador não age.
Depois:
“Faltou iniciativa.”
Mas ele havia sido punido no incidente anterior por agir sem aprovação.
Agora a organização produz comportamento e depois atribui o comportamento à pessoa.
☕ Organização esquizofrênica operacional
Segunda:
“Não aja sem aprovação.”
Quarta:
“Por que não tomou iniciativa?”
Sexta:
“Precisamos de gente com senso de dono.”
Talvez primeiro precisemos de critérios claros.
🧠 Normalization of Deviance
Prática comum:
todo mundo pula etapa.
Uma pessoa pula.
Dá errado.
Observador:
“Fulano não segue processo.”
Mas todos faziam igual.
Resultado negativo transformou comportamento coletivo em defeito individual.
🌀 Drift Into Failure
Equipe inteira adaptou-se ao sistema degradado.
Um indivíduo finalmente encontra a condição errada.
Incidente.
Agora:
“Foi erro dele.”
Mas o contexto foi construído durante meses.
Actor-Observer Bias ajuda a esconder o drift.
🧀 Swiss Cheese Model como antídoto
Pergunte:
quais barreiras existiam?
Documentação.
Validação.
Peer review.
Automação.
Monitoramento.
Rollback.
Se cinco barreiras falharam:
a personalidade de uma pessoa explica pouco.
🎯 Pergunta Bellacosa nº 1
Quando ouvir:
“Ele é descuidado.”
Pergunte:
“Qual comportamento específico estamos descrevendo?”
Troque adjetivo por fato.
Não:
“descuidado.”
Mas:
“executou mudança sem validar parâmetro.”
Agora dá para investigar.
🎯 Pergunta Bellacosa nº 2
“Que condições existiam naquele momento?”
Pressão?
Fadiga?
Ambiguidade?
🎯 Pergunta Bellacosa nº 3
“Quando nós fizemos algo parecido, que explicação demos?”
Aqui o espelho aparece.
🎯 Pergunta Bellacosa nº 4
“Aplicaríamos o mesmo julgamento se o resultado tivesse sido diferente?”
Outcome Bias.
🎯 Pergunta Bellacosa nº 5
“Se outra pessoa competente estivesse nas mesmas condições, esse comportamento ainda seria plausível?”
O famoso substitution test.
🧠 O teste da substituição
Pegue Carlos.
Troque por Maria.
Depois João.
Depois você.
Mesma interface.
Mesmo runbook.
Mesma pressão.
Se vários poderiam errar:
o sistema precisa entrar na análise.
☕ Bellacosa Swap Test
CARLOS → MARIA → JOÃO → VOCÊ
Se o risco permanece:
não estamos discutindo apenas personalidade.
🧠 Context Reconstruction
Em post-mortem, tente reconstruir:
o que a pessoa via?
que alertas?
qual informação?
qual tela?
qual documentação?
qual relógio?
qual pressão?
Isso aproxima observador da perspectiva do ator.
🕰️ Timeline cognitiva
Não basta:
03:10 operador executa restart
Inclua:
03:03 incident commander pede ETA
03:05 usuários escalam impacto
03:06 dashboard mostra queue ↑
03:07 runbook sugere restart
03:08 alerta DB2 inconclusivo
03:10 restart executado
Agora ação ganha contexto.
🧠 Work-as-Imagined versus Work-as-Done
Gestão imagina:
operador lê runbook com calma.
Realidade:
quatro chats;
telefone;
alertas;
SDSF;
gerente;
usuario.
O observador costuma avaliar Work-as-Done usando Work-as-Imagined.
Isso cria julgamentos injustos.
☕ O runbook de laboratório
Passo 1:
“analise cuidadosamente.”
Claro.
Às 14h com café.
Às 03h com SEV-1, essa frase pode precisar de muito mais estrutura.
🧠 Cognitive Load
Memória de trabalho humana é limitada.
Quanto mais tarefas simultâneas:
maior chance de erro.
Se processo exige:
lembrar 17 passos;
comparar cinco telas;
responder chat
e não errar,
a causa não deveria ser resumida a:
“faltou atenção.”
🧠 Fatigue
Fadiga muda desempenho.
Plantão longo.
Noite.
Interrupções.
Ator sente isso.
Observador vê apenas:
ação errada.
Por isso staffing e descanso também são controles operacionais.
🧠 Time Pressure
Prazo muda comportamento.
Algo que parece:
“imprudência”
pode ser resposta adaptativa a:
“precisamos em 10 minutos.”
De novo:
entender não significa aprovar.
Significa desenhar solução real.
🧠 Incentives
Se bônus depende de:
zero atraso,
equipe pula testes.
Depois:
“faltou disciplina.”
Talvez incentivo produziu exatamente aquilo.
Actor-Observer Bias protege quem desenhou KPI e culpa quem respondeu a ele.
☕ KPI tem personalidade?
Não.
Mas cria comportamento.
🧠 Fundamental Attribution Error em times
Aplicação culpa infra.
Infra culpa aplicação.
Cada lado conhece profundamente seu contexto.
Conhece pouco do contexto alheio.
Então:
nosso problema = circunstância;
problema deles = incompetência.
Actor-Observer Bias em escala organizacional.
👥 Silo Bias
Silos aumentam porque cada equipe enxerga:
seu contexto completo
e:
o output da outra.
Quanto menor a transparência entre equipes:
mais fácil atribuir falha a caráter profissional.
🔗 Observabilidade compartilhada como antídoto social
Distributed tracing.
Logs comuns.
Timeline compartilhada.
Change records.
Quando todos veem o mesmo contexto:
menos espaço para:
“eles fizeram besteira.”
☕ Correlation ID como diplomata corporativo
Às vezes uma simples cadeia ponta a ponta resolve discussões que vinte reuniões não resolvem.
🧠 Actor-Observer Bias em code review
Você vê código de colega:
“Que solução estranha.”
Depois descobre:
requisito exigia compatibilidade com sistema de 1996.
Contexto muda percepção.
Antes de chamar código de ruim:
pergunte:
“Que restrição estou deixando de ver?”
💻 Legacy code e contexto perdido
Código de 1988 parece absurdo em 2026.
Mas talvez fosse excelente sob:
memória limitada;
CPU cara;
compilador antigo;
restrições de storage.
Julgar decisão histórica com contexto atual é uma forma temporal de erro de atribuição.
Hindsight também entra.
☕ O GO TO ancestral
Você olha:
GO TO 9000-EXIT.
— Bárbaros!
Talvez em 1978 houvesse outra convenção, outra ferramenta, outra pressão.
Contexto histórico importa.
🧠 Actor-Observer Bias e carreira
Você perde prazo:
“Dependências.”
Colega perde:
“Má organização.”
Você muda de emprego:
“Buscando crescimento.”
Colega muda:
“Sem compromisso.”
O cérebro gosta de autobiografias generosas.
🧠 Performance Review
Gestores precisam cuidado especial.
Avalie padrão de comportamento ao longo do tempo.
Não converta:
um incidente
em:
identidade.
“Ele é ruim sob pressão” pode nascer de uma única madrugada desastrosa.
🧠 Recency + Attribution = rótulo
Último erro fica fresco.
A avaliação anual chega.
O erro domina.
Agora traço permanente.
Isso é perigoso.
Registros longitudinais ajudam.
📝 Incident Contribution Log
Não para ranking.
Para compreender exposição.
Quantas vezes a pessoa:
atuou corretamente?
detectou riscos?
interveio?
Se só documentamos falhas:
base de avaliação já nasce enviesada.
🧠 Survivorship Bias curioso
As milhares de decisões corretas somem porque nada aconteceu.
A única decisão errada vira incidente.
Então observador superestima taxa de erro daquele profissional.
☕ O operador invisível
500 noites tranquilas.
Uma noite ruim.
Agora todos lembram daquela.
Operação segura é cheia de trabalho que não produz histórias.
🧠 Actor-Observer Bias e segurança
Usuário clica phishing.
Security:
“Usuário descuidado.”
Security configura regra errada:
“Ambiente era muito complexo.”
Espelho.
O correto:
examinar contexto nos dois casos.
🔐 Phishing
Usuário recebeu mensagem:
perfeitamente escrita;
aparentemente interna;
em momento esperado;
com domínio parecido.
A pergunta não deveria ser apenas:
“Por que clicou?”
Mas:
“Por que essa mensagem era plausível?”
🧠 Social Engineering explora contexto
Atacantes sabem:
pressão;
autoridade;
urgência;
rotina.
Se segurança ignora contexto humano:
culpa vítima em vez de melhorar controle.
🤖 Actor-Observer Bias com IA
Usuário aceita recomendação ruim de IA.
Gestor:
“Ele confiou demais.”
Gestor implementa automação errada:
“O modelo teve comportamento inesperado.”
Muito interessante.
Quem observa humano vê decisão.
Quem opera sistema vê complexidade.
Precisamos simetria.
🧠 Automation Bias
A ferramenta pode contribuir.
Mas humano continua dentro do sistema.
Analise:
UI;
confidence score;
explicabilidade;
tempo;
authority.
Não apenas:
“usuário aceitou.”
🤖 AI as teammate
Quanto mais IA entra na operação, mais teremos perguntas:
quem é ator?
humano?
modelo?
designer?
gestor?
Sistema sociotécnico torna atribuições individuais ainda menos suficientes.
🧠 Decision Environment
Uma boa investigação olha para:
ambiente decisório.
Que opções estavam disponíveis?
Quais pareciam seguras?
Qual informação era visível?
Qual custo havia para discordar?
Isso transforma julgamento em engenharia.
☕ O botão gigante vermelho
Se interface coloca:
RESTART ALL
enorme
e:
inspect logs
escondido,
o design está votando.
Não diga depois que usuário “escolheu livremente” sem considerar esse contexto.
🧠 Choice Architecture
A forma como opções são apresentadas influencia decisões.
Framing Effect retorna.
Default.
Posição.
Cor.
Confirmação.
Tudo compõe contexto do ator.
🧠 Status Quo Bias
Pessoa mantém processo antigo.
Observador:
“Resistente a mudanças.”
Talvez mudanças anteriores tenham dado errado.
Talvez não haja treinamento.
Talvez risco pessoal seja alto.
Contexto antes de rótulo.
🧠 Loss Aversion
Profissional evita nova ferramenta.
“Conservador.”
Talvez tenha muito a perder:
produtividade;
credibilidade;
controle.
Compreender perda percebida ajuda adoção.
🧠 Present Bias
Pessoa escolhe workaround rápido.
“Preguiçosa.”
Talvez backlog enorme e SLA impossível.
Present Bias pode existir.
Mas ambiente também o incentiva.
Não use viés como novo rótulo moral.
☕ Isso é importante
Descobrir um bias não deveria virar:
“Você é enviesado.”
Todo mundo é.
A pergunta útil:
“Que processo reduz o efeito desse viés?”
🧠 Just Culture novamente
Just Culture é um ótimo contrapeso ao Actor-Observer Bias.
Em vez de:
“quem é a pessoa?”
pergunta:
comportamento esperado?
erro não intencional?
risco assumido?
violação deliberada?
condições locais?
controles?
Isso preserva accountability sem simplificação.
🧠 Accountability simétrica
Uma regra saudável:
use a mesma pergunta para:
sênior;
júnior;
gestor;
operador.
O que aconteceu?
Que informação havia?
Que decisão foi tomada?
Que processo influenciou?
Isso reduz status social na atribuição.
🎯 Pergunta Bellacosa nº 6
“Estamos dando ao nosso erro mais contexto do que ao erro deles?”
Provavelmente a melhor frase do capítulo.
🪞 Mirror Test
Escreva:
“Quando nossa equipe fez X, foi porque prazo estava apertado.”
Agora:
“Quando a outra equipe fez X, foi porque prazo estava apertado.”
Ainda acredita?
Depois inverta:
“Quando nossa equipe fez X, faltou planejamento.”
Dói?
Talvez tenha achado o viés.
🧠 Role Reversal
Troque nomes no post-mortem.
Esconda equipe.
Peça avaliação.
Depois revele.
Se julgamento muda:
temos algo para discutir.
🧪 Blind Review
Para decisões importantes, você pode apresentar:
dados;
timeline;
ações
sem nomes.
Perguntar:
“A decisão foi razoável?”
Isso reduz atribuição baseada em reputação.
📊 Process Review versus Person Review
Primeiro avalie:
processo decisório.
Só depois:
conduta individual.
Isso reduz confusão.
🧠 Counterfactual Context
Pergunte:
“Se removêssemos a pressão temporal, a pessoa provavelmente faria igual?”
Se não:
pressão é fator causal importante.
Outra:
“Se interface validasse valor, erro existiria?”
Não.
Então interface participa.
🧠 Causal contribution ≠ blame share
Não precisamos distribuir porcentagens de culpa.
Isso vira contabilidade moral.
Melhor identificar:
fatores alteráveis.
O que podemos melhorar?
☕ 37% culpa do operador, 42% processo...
Não.
Isso não é RCA.
É campeonato.
🧠 Improvement orientation
A pergunta final:
“O que mudaremos?”
Se resposta:
“a pessoa precisa prestar mais atenção”
fraco.
Se:
validação;
alerta;
runbook;
peer review;
training específico;
muito melhor.
🧠 Strong fixes again
Fraco
“Tenha cuidado.”
Melhor
Checklist.
Melhor
Validação.
Melhor
Default seguro.
Melhor
Automação que impede erro.
Sempre que possível.
💻 COBOL e design tolerante
Se campo precisa de 1–9:
não aceite 99.
IF WS-OPTION < 1 OR WS-OPTION > 9
DISPLAY 'OPCAO INVALIDA'
PERFORM READ-AGAIN
END-IF
Não culpe usuário por valor que o programa poderia rejeitar facilmente.
🧠 Observability e contexto
Se operador toma decisão com dados ruins:
melhore dados.
Dashboard deve mostrar:
baseline;
tendência;
impacto;
confidence.
Boa informação reduz dependência de julgamento improvisado.
🧠 Runbook com rationale
Não escreva apenas:
“restart service.”
Escreva:
“restart if queue > X AND consumer rate = 0 for Y min.”
Agora contexto está embutido no procedimento.
☕ Procedimento bom empresta experiência ao profissional cansado
Linda função.
🧠 Actor-Observer Bias na retrospectiva
Perguntas úteis:
qual contexto estávamos vendo?
que contexto a outra equipe via?
o que não sabíamos sobre eles?
que informação compartilhada teria mudado decisão?
Isso melhora coordenação.
👥 Cross-team Incident Review
Faça cada equipe explicar:
o que enxergava naquele momento.
Não apenas:
o que sabe agora.
Isso reduz julgamento retrospectivo.
🧠 Shared timeline
Monte:
APP VIEW
DB2 VIEW
OPS VIEW
NETWORK VIEW
BUSINESS VIEW
Às 03:10 cada um via coisa diferente.
Agora divergências fazem sentido.
☕ O mesmo incidente tem cinco câmeras
Actor-Observer Bias acontece porque geralmente assistimos só à nossa.
🧠 Doctor Who e perspectiva
A própria ideia da TARDIS serve como metáfora perfeita.
O Doctor pode ver:
passado;
presente;
futuro.
Nós não.
No incidente real:
cada pessoa vê apenas um pedaço.
Depois que juntamos tudo, parece que alguém deveria ter visto o quadro completo.
Mas ninguém tinha uma TARDIS.
Esse é o Hindsight Bias encontrando Actor-Observer.
👻 Easter Egg nº 2 — perspectiva temporal
Companion:
— Era óbvio que deveríamos ter parado.
Doctor:
— Agora.
— Como assim?
— Agora você viu todos os eventos.
Pausa.
— Naquele minuto você tinha apenas três.
— Então eu não errei?
— Talvez tenha errado.
— Ah.
— Mas primeiro precisamos julgar a decisão com o universo que você conhecia, não com o que descobrimos depois.
Essa é uma das melhores regras de post-mortem.
🧠 Decision Quality at Time T
Avalie decisão usando:
informação disponível em T
Não em:
T + 3 horas.
Essa disciplina reduz muitos vieses da série.
📝 Snapshot decisório
Guarde:
03:14
KNOWN:
- queue rising
- DB2 normal
- consumer uncertain
UNKNOWN:
- external API degraded
DECISION:
restart consumer
Depois:
root cause API.
Agora podemos avaliar se restart era razoável sem fingir que operador deveria conhecer informação futura.
🧠 Actor-Observer Bias e aprendizado contínuo
Se julgamos outros moralmente:
eles escondem erros.
Se escondem erros:
perdemos dados.
Se perdemos dados:
não aprendemos.
Logo, atribuição injusta reduz observabilidade humana.
☕ Medo é um log compressor
Pessoas contam menos quando sabem que qualquer erro vira rótulo.
🧠 Psychological Safety
Segurança psicológica permite dizer:
“Eu fiz isso porque achei X.”
Essa explicação é ouro.
Sem ela:
recebemos versão defensiva.
Just Culture melhora qualidade do RCA.
🧠 Self-Serving Bias ainda existe
Claro.
Pessoas também podem racionalizar.
Por isso não dependemos apenas de relatos.
Cruzamos:
logs;
timeline;
tickets;
dados.
Com empatia + evidência.
Não ingenuidade.
☕ Nem tribunal, nem conto de fadas
Boa investigação fica no meio.
📋 Checklist anti-Actor-Observer Bias
[ ] Estou descrevendo fato ou personalidade?
[ ] Que contexto a outra pessoa tinha?
[ ] Que informação eu tenho agora que ela não tinha?
[ ] Eu explicaria meu próprio erro da mesma maneira?
[ ] Estamos concedendo mais contexto à nossa equipe?
[ ] A pressão temporal influenciou?
[ ] Havia fadiga ou sobrecarga?
[ ] A interface ou ferramenta favorecia a decisão?
[ ] O processo era realmente executável?
[ ] O comportamento era comum ou excepcional?
[ ] O resultado está contaminando nosso julgamento?
[ ] Outra pessoa competente poderia agir igual?
[ ] Existe efeito de hierarquia no julgamento?
[ ] O que mudaria no sistema para reduzir recorrência?
[ ] Estamos transformando evento em identidade?
🧪 Como combater Actor-Observer Bias — passo a passo
Passo 1 — Remova adjetivos
“Descuidado.”
“Fraco.”
“Afoito.”
Troque por comportamento observável.
Passo 2 — Reconstrua contexto
Telas.
Tempo.
Informação.
Passo 3 — Faça o Mirror Test
Como explicamos erros próprios?
Passo 4 — Faça o Substitution Test
Outra pessoa poderia fazer igual?
Passo 5 — Avalie decisão com dados da época
Não com hindsight.
Passo 6 — Procure pressões do sistema
SLA.
KPI.
Hierarquia.
Passo 7 — Separe execução de decisão
Quem pediu?
Quem aprovou?
Quem executou?
Passo 8 — Examine barreiras
O erro deveria ter sido contido?
Passo 9 — Preserve accountability justa
Erro não é igual a violação deliberada.
Passo 10 — Transforme contexto em melhoria
Validação.
Automação.
Runbook.
Training.
Observabilidade.
🧠 Uma curiosidade importante: contexto não é desculpa
Existe medo de que contextualizar vire:
“passar pano.”
Não.
Contextualização é condição para prevenir.
Se você não entende por que comportamento ocorreu:
não consegue mudar condições.
Responsabilidade pode continuar existindo.
Mas agora ela é informada.
☕ “Ele fez errado” e “o sistema favoreceu o erro” podem ser verdade ao mesmo tempo
Esse “e” aparece muito nesta série.
🧠 Accountability sem humilhação
Pode dizer:
“A decisão não estava de acordo com o controle esperado.”
E:
“O controle era difícil de executar sob pressão.”
Então:
corrige comportamento;
corrige sistema.
Muito mais forte.
🧠 Violation versus error
Erro involuntário:
uma coisa.
Atalho habitual:
outra.
Violação consciente e injustificável:
outra.
Misturar tudo em:
“erro humano”
ou:
“culpa do sistema”
também é ruim.
🧠 Just Culture como equilíbrio
Nem:
“a pessoa é o problema.”
Nem:
“a pessoa nunca é responsável.”
Mas:
“qual comportamento ocorreu, em qual contexto, e qual resposta é justa e útil?”
💡 Bellacosa Three-Layer Review
Podemos usar:
1. PERSON
O que fez?
2. CONTEXT
Por que parecia razoável?
3. SYSTEM
Como reduzir chance/impacto?
Simples.
Poderoso.
🧠 Actor-Observer Bias em IA operacional
Imagine humano aprova ação errada sugerida por agente.
Depois:
“Analista deveria verificar.”
Correto.
Mas talvez UI mostre:
CONFIDENCE: HIGH
RECOMMENDED ACTION
em destaque.
Sem evidência.
Sem contra-hypothesis.
O ambiente influenciou decisão.
Corrija ambos:
treinamento humano;
design da ferramenta.
🤖 Human Factors não desaparecerão com agentes
Talvez fiquem mais importantes.
Porque agora o humano observará:
modelos;
recomendações;
scores.
E decidirá quando confiar.
A interface entre cognição humana e automação vira nova camada crítica.
🧠 Attribution to AI
Quando IA acerta:
“Nossa automação é incrível.”
Quando erra:
“Usuário deveria ter percebido.”
Self-Serving + Actor-Observer.
Incrível combo moderno.
☕ O agente também merece logs
Quem recomendou?
Com qual contexto?
Qual modelo?
Qual ferramenta?
Qual confidence?
Assim atribuição pode ser técnica.
🧠 Continuous Improvement
Depois de cada incidente:
não pergunte só:
“Quem fez?”
Pergunte:
quem viu o quê?
quando?
por que aquela ação parecia razoável?
que sinal faltou?
que controle poderia ajudar?
Isso transforma atribuição em melhoria.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Actor-Observer Bias é a tendência de explicar nosso comportamento pelo contexto e o comportamento dos outros por características pessoais.
Ele é parente próximo do Fundamental Attribution Error e do Self-Serving Bias.
Ator vê contexto; observador vê ação e resultado.
Hindsight Bias dá ao observador informação que o ator não possuía.
Outcome Bias pode transformar a mesma ação em heroísmo ou imprudência.
Authority Gradient pode fazer erros de chefes parecerem “decisões difíceis” e erros de juniores parecerem “falta de maturidade”.
Alarm Fatigue, fadiga, pressão, incentivos e interfaces moldam comportamento.
Contextualizar não significa eliminar accountability.
Mirror Test e Substitution Test ajudam a criar simetria.
Uma decisão deve ser julgada com as informações disponíveis naquele momento.
A melhor investigação descreve comportamento, reconstrói contexto e melhora o sistema.
E principalmente:
Antes de transformar o erro de alguém em personalidade, tente viver cinco minutos dentro do console, do prazo, da informação e da pressão que aquela pessoa tinha.
🕰️ De volta à War Room
DBA:
— O desenvolvedor deveria ter previsto isso.
Nosso programador pergunta:
— O documento técnico mencionava essa dependência?
— Não.
— O ambiente de teste reproduzia?
— Não.
— O DBA sabia que o padrão de SQL mudaria?
— Também não.
Ele olha para os dois.
— Então talvez tenhamos duas decisões imperfeitas tomadas por pessoas com pedaços diferentes do sistema.
Silêncio.
O Doctor sorri.
— Isso é bem menos emocionante que incompetência.
— É.
— E mais útil.
Montam timeline.
Descobrem:
desenvolvimento não conhecia limite do banco.
DBA não conhecia nova carga.
Change review não juntou os dois.
A causa não era:
“desenvolvedor ruim.”
Nem:
“DBA ruim.”
Era uma interface organizacional ruim.
🔧 Um mês depois
O change template ganha:
EXPECTED DB ACCESS PATTERN:
____________________
VOLUME CHANGE:
____________________
DBA REVIEW REQUIRED IF:
>20% increase
Também:
performance test integrado.
Na mudança seguinte:
o mesmo risco aparece.
Desta vez:
antes da produção.
Nenhuma War Room.
Nenhum dedo apontado.
Nenhum personagem precisava tornar-se vilão.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(ACTOR-OBSERVER)
Dentro:
IF PERSON = 'ME'
PERFORM CHECK-IF-I-AM
OVERUSING-CONTEXT
END-IF.
IF PERSON = 'THEM'
PERFORM CHECK-THEIR-CONTEXT
END-IF.
IF JUDGMENT-USES-ADJECTIVE
PERFORM DESCRIBE-BEHAVIOR
END-IF.
Comentário:
* MY CONTEXT COUNTS.
* YOURS DOES TOO.
Outro:
* JUDGE THE DECISION
* WITH THE DATA AVAILABLE THEN.
Mais um:
* PERSONALITY IS NOT
* A ROOT CAUSE CODE.
E naturalmente:
* BAD WOLF HAD CONTEXT.
* SO DID EVERYONE ELSE.
Nosso jovem fecha o membro.
Horas depois alguém comenta:
— A equipe de operações fez uma besteira ontem.
Ele quase concorda.
Mas pergunta:
— O que aconteceu?
— Reiniciaram cedo demais.
— Por quê?
— Não sei.
Ele sorri.
— Então ainda sabemos o que fizeram.
Pausa.
— Ainda não sabemos por que fizeram.
Investigam.
O runbook realmente mandava reiniciar.
Atualizam.
A próxima equipe não repete.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
Com nós mesmos, conhecemos a história inteira. Com os outros, quase sempre vemos apenas uma cena. Engenharia madura começa quando paramos de julgar o filme inteiro por um único frame.
☕🌀
Next stop: Dunning-Kruger Effect — quando saber pouco pode produzir uma confiança surpreendentemente grande, enquanto quem conhece profundamente o sistema começa justamente a enxergar todas as maneiras pelas quais pode estar errado.
Sem comentários:
Enviar um comentário