☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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

terça-feira, 8 de abril de 2014

Anchoring Bias: Doctor Who, COBOL e o Dia em que o Primeiro Palpite Virou o Centro Gravitacional da War Room

 

Bellacosa Mainframe e o anchoring bias

☕ Um Café no Bellacosa Mainframe

Anchoring Bias: Doctor Who, COBOL e o Dia em que o Primeiro Palpite Virou o Centro Gravitacional da War Room

Uma viagem pela TARDIS dos incidentes para entender por que a primeira informação que recebemos — um número, um alerta, um comentário do senior ou um rótulo no ticket — pode influenciar tudo aquilo que pensamos depois, mesmo quando novas evidências começam a apontar em outra direção

03:07.

War Room.

O café já não está quente.

Mas ninguém reclama.

No telão:

INCIDENTE P1

APLICAÇÃO:
PAYMENTS-X

SINTOMA:
LATÊNCIA ELEVADA

INÍCIO:
02:52

STATUS:
INVESTIGANDO

Nosso jovem programador COBOL acabou de entrar.

Ainda está tentando entender:

quem está na sala;

qual componente falhou;

qual foi a última mudança;

e por que existem seis pessoas falando ao mesmo tempo.

Então alguém diz:

— Isso está com cara de Db2.

Pronto.

Cinco segundos.

Uma frase.

Nenhuma prova.

Nenhum trace.

Nenhuma análise.

Mas algo aconteceu.

O jovem olha para o dashboard de Db2.

O DBA começa a procurar locks.

O gerente pergunta:

— Tivemos problema de database ontem também, não?

Outro analista:

— Tivemos.

Nosso jovem abre:

DB2 ACCOUNTING

Depois:

DB2 LOCKS

Depois:

DB2 BUFFERPOOL

Nem percebe que ainda não olhou:

MQ.

Network.

CICS.

API externa.

Volume de entrada.

Certificados.

Fila downstream.

O primeiro comentário:

“tem cara de Db2”

não provou nada.

Mas organizou:

toda a busca.

VWORP.

VWORP.

VWORP.

A TARDIS surge ao lado do monitor.

A porta abre.

O Doctor sai.

Olha para a sala.

— Qual é a causa?

Gerente:

— Provavelmente Db2.

Doctor:

— Evidência?

Silêncio.

— Quem falou primeiro?

Todos apontam para:

um analista.

Doctor:

— E por que vocês continuam olhando Db2?

Gerente:

— Porque parece Db2.

Doctor:

— Interessante.

Ele pega uma caneta.

Escreve no quadro:

FIRST INFORMATION
        ↓
ATTENTION
        ↓
INTERPRETATION
        ↓
DECISION

Depois escreve:



ANCHORING BIAS

Ou:

Viés de Ancoragem.

Em linguagem Bellacosa:

é quando a primeira informação que entra na cabeça ganha peso demais e passa a influenciar tudo o que vem depois.


🧠 O que é Anchoring Bias?

Anchoring Bias é a tendência de nossas estimativas, julgamentos e decisões ficarem influenciados por uma informação inicial.

Essa informação funciona como:

âncora.

Depois fazemos ajustes.

Mas normalmente:

ajustamos pouco.

Imagine alguém perguntar:

“Essa mudança vai levar mais ou menos de 10 dias?”

Depois:

“Quanto tempo você acha?”

Mesmo que você não queira,

o número:

10

entrou no sistema.

Agora sua estimativa talvez fique:

8;

12;

Se a pergunta tivesse sido:

“mais ou menos de 100 dias?”

a estimativa poderia:

mudar.

O primeiro número:

não é neutro.


☕ Bellacosa Definition

“A âncora é o primeiro valor que entra no working-storage da cabeça e depois ninguém lembra de fazer INITIALIZE.”


💻 COBOL cerebral

Imagine:

01 WS-ESTIMATE PIC 9(03).

MOVE 10 TO WS-ESTIMATE.

Depois você começa:

a recalcular.

Mas em vez de:

começar do zero,

você faz:

ADD 2 TO WS-ESTIMATE.

ou:

SUBTRACT 3 FROM WS-ESTIMATE.

Resultado:

continua orbitando:

Esse é o mecanismo psicológico clássico chamado:

insufficient adjustment

ou:

ajuste insuficiente.


🧠 A primeira informação não precisa ser boa

Esse é o problema.

Pode ser:

aleatória;

incompleta;

desatualizada;

mal interpretada;

irrelevante.

Mesmo assim:

gruda.


👻 Easter Egg nº 1 — Dalek Estimator

Manager Dalek:

— HOW LONG WILL THE PROJECT TAKE?

Programmer:

— I don’t know yet.

Dalek:

— TWO WEEKS?

Programmer:

— Probably three.

Doctor:

— Why three?

Programmer:

— Because two felt optimistic.

Doctor:

— Congratulations.

— For what?

— You just estimated relative to a completely invented number.


🧠 Anchoring em estimativas de projeto

Talvez seja:

o exemplo corporativo mais comum.

Gerente:

— Isso é coisa de um dia, certo?

Pronto.

Agora o desenvolvedor pensa:

“Não, um dia é pouco.”

Mas talvez responda:

“Três.”

Sem aquela âncora,

talvez dissesse:

sete.

Ou dez.


☕ A frase:

“isso é simples”

é uma âncora.

Assim como:

“isso não deve levar mais de duas horas.”


🧠 Planning Fallacy encontra Anchoring

Gerente define:

prazo inicial otimista.

Esse prazo vira:

anchor.

Depois surgem:

novas informações.

Integração.

Teste.

Security.

Data migration.

Mas ao invés de:

reestimar do zero,

começamos:

adicionar dias.

10 dias
+ 2
+ 3
+ 5

Talvez o projeto real fosse:

Mas ficamos:

presos ao primeiro 10.

Planning Fallacy + Anchoring.


🎯 Pergunta Bellacosa nº 1

“Se ninguém tivesse mencionado esse número, qual seria minha estimativa?”

Excelente para planejamento.


🧠 Anchoring na War Room

Agora:

primeira hipótese.

— É Db2.

Essa frase cria:

âncora causal.

A partir daí:

logs Db2 parecem:

mais importantes.

Warnings:

ganham significado.

Outros sinais:

parecem ruído.


🧠 Confirmation Bias chega depois

Anchoring escolhe:

a hipótese.

Confirmation Bias procura:

provas.

Sequência:

FIRST GUESS
↓
ANCHOR
↓
SEARCH FOR SUPPORT
↓
CONFIRMATION

Perigoso.


☕ Anchoring planta.

Confirmation Bias:

rega.


🧠 Streetlight Effect entra

Se a âncora é:

Db2,

e Db2 tem:

muita telemetria,

Streetlight Effect ajuda:

ficar ali.

Agora temos:

primeira hipótese

ferramentas boas.

O resto da cadeia desaparece.


🧠 Search Satisfaction

Encontramos:

um lock.

Pronto.

Search Satisfaction:

“achei.”

A âncora:

parece confirmada.


🧠 Premature Closure

Agora dizemos:

“é Db2.”

A hipótese virou:

conclusão.


🧠 Diagnosis Momentum

Depois:

o próximo turno recebe:

“Db2 incident.”

A âncora agora:

viaja.

Esse é o motivo pelo qual Anchoring é tão central.

Ele é:

o primeiro dominó.


☕ O primeiro comentário da War Room

pode ser:

mais importante do que parece.


🧠 Anchoring e Recency Bias

Último incidente:

Db2.

Hoje:

problema parecido.

A memória recente:

gera âncora.

— Deve ser Db2 de novo.

Recency dá:

conteúdo.

Anchoring dá:

peso.


🧠 Representativeness Heuristic

Sintoma:

parece incidente antigo.

Logo:

mesma causa.

A semelhança:

vira âncora.


🎯 Pergunta Bellacosa nº 2

“Essa hipótese nasceu da evidência atual ou da semelhança com algum caso antigo?”


🧠 Anchoring e Framing Effect

Ticket:

DB2 PERFORMANCE ISSUE

Antes mesmo de abrir:

log,

você já está:

ancorado.

Compare:

PAYMENT LATENCY

Muito diferente.

O título:

é âncora.


☕ Ticket title

não deveria:

resolver o incidente

antes da equipe.


🧠 Anchoring em números

Outro clássico.

Você pergunta:

— Quantos clientes foram afetados?

Alguém:

— Uns 500.

Mais tarde descobre:

estimativa real ainda não existe.

Mas o número:

500

vai parar:

no status.

Depois:

“cerca de 600.”

Depois:

“aproximadamente 700.”

Talvez fossem:

12 mil.

O primeiro número:

organizou todos os ajustes.


🧠 Incident impact estimation

Nunca confunda:

primeiro chute

com:

baseline.


🎯 Pergunta Bellacosa nº 3

“Esse valor veio de medição ou foi a primeira aproximação disponível?”


🧠 Anchoring em budget

Fornecedor:

R$1 milhão.

Negociação começa.

Mesmo que custo real:

R$300 mil,

o milhão:

vira referência.

Então:

R$700 mil

parece:

desconto.


☕ Isso explica parte da magia de:

“de R$999 por R$499.”

O cérebro compara:

com 999.

Não:

com valor real.


🧠 Anchoring em salário

Primeiro número:

define negociação.

Por isso:

anchor strategy

é conhecida em negociação.

Mesmo quem sabe:

pode ser influenciado.


🧠 Mainframe version

Vendor:

— Modernização custa US$ 20 milhões.

Diretor:

— Muito.

Vendor:

— Podemos fazer 14.

Agora 14 parece:

barato.

Mas ninguém perguntou:

qual deveria ser o custo baseado no trabalho?


🎯 Pergunta Bellacosa nº 4

“Estamos avaliando esse número pela realidade ou pelo número que veio imediatamente antes?”


🧠 Anchoring em performance

Historicamente:

batch leva:

40 minutos.

Novo hardware:

talvez deveria:

Mas todos continuam:

tratando 40 como referência.

Agora:

35 parece excelente.

Anchor:

legacy baseline.


☕ Baseline antigo

pode virar:

prisão.


🧠 Status Quo Bias

Anchoring frequentemente trabalha com:

status quo.

“sempre levou 40.”

Logo:

40 = normal.

Talvez:

não devesse mais.

Status Quo + Anchoring.


🧠 Cultural Debt entra

Decisão antiga:

certa.

Número antigo:

vira referência.

Arquitetura muda.

Negócio muda.

Mas âncora:

fica.

Exemplo:

“batch precisa terminar às 06:00.”

Por quê?

Porque:

há 20 anos agência abria:

08:00.

Hoje:

processo é:

online.

Mas 06:00 continua:

sagrado.

Anchoring temporal virou:

Cultural Debt.


☕ O primeiro SLA

pode sobreviver:

ao motivo que o criou.


🧠 Anchoring em architecture

Alguém diz:

“mainframe é caro.”

Pronto.

Toda discussão começa:

custo.

Mas:

qual custo?

Por transaction?

Reliability?

Security?

Migration?

Risk?

Primeiro frame:

ancora.


🧠 Anchoring tecnológico

“Cloud is cheaper.”

“Mainframe is legacy.”

“Microservices are scalable.”

“COBOL is old.”

Todas podem:

virar âncoras.

Depois buscamos:

evidência que encaixa.


🎯 Pergunta Bellacosa nº 5

“Estamos analisando tecnologia ou defendendo um rótulo que veio antes da análise?”


🧠 Anchoring e Dunning-Kruger

Iniciante:

não possui muitas referências.

Primeira explicação:

ganha peso enorme.

Senior diz:

— S0C7 é dado inválido.

Júnior:

aprende.

Depois:

todo S0C7:

“arquivo ruim.”

Mas pode ser:

overlay;

copybook;

bad address;

conversion;

data.

Primeiro ensinamento:

vira âncora simplificada.


☕ Conhecimento inicial

é necessário.

Mas deve:

ganhar nuance.


🧠 Ensino para COBOL iniciante

Quando ensinar:

S0C7 = DATA EXCEPTION

ótimo.

Mas acrescente:

“isso é sintoma técnico; ainda precisamos descobrir por que o dado chegou inválido.”

Assim:

evitamos âncora causal.


🧠 Anchoring em ABEND

S0C7:

dado.

S0C4:

memory/addressing.

S322:

timeout.

Mas:

abend code

é:

ponto inicial.

Não:

RCA completa.


🎯 Pergunta Bellacosa nº 6

“Estou usando o código de erro para orientar investigação ou para encerrar diagnóstico?”


🧠 Anchoring e Authority Bias

Senior:

— Isso é WLM.

Agora:

everyone WLM.

Por quê?

Porque:

senior.

Anchor ganha:

massa com autoridade.


☕ Senioridade aumenta:

prior probability.

Não:

certeza.


🧠 Anchoring e Diagnosis Momentum

Senior hipótese:

vira ticket.

Ticket:

vira handoff.

Handoff:

vira executive summary.

Agora:

anchor social.


🧠 Anchoring e números executivos

Diretor pergunta:

— Impacto é 10%?

Mesmo sendo pergunta,

já lançou:

anchor.

Equipe:

“talvez 15%.”

Se perguntasse:

— Quanto é o impacto?

Resposta poderia:

diferir.


🎯 Pergunta Bellacosa nº 7

“A pergunta já contém uma resposta sugerida?”

Essa é fantástica.


🧠 Leading Questions

“Não foi a mudança de ontem?”

“Isso é Db2, certo?”

“Não deve passar de duas horas, correto?”

Essas perguntas:

não são neutras.

Elas instalam:

âncora.


☕ Em investigação:

pergunte:

“O que aconteceu?”

antes de:

“Foi X?”


🧠 Interview bias

Ao perguntar para operador:

— O problema começou depois do deploy?

ele começa:

a procurar relação.

Better:

— Quando percebeu o primeiro sintoma?

Depois:

compare com deploy.


🧠 Anchoring em RCA meetings

Facilitador abre:

— Acredito que problema foi falta de teste.

Pronto.

RCA agora:

sobre teste.

Talvez fosse:

requirement;

incentive;

change;

monitoring.


🎯 Pergunta Bellacosa nº 8

“A primeira pessoa a falar deveria ser também a pessoa que propõe a causa?”

Às vezes não.


🧠 Independent hypothesis generation

Uma técnica muito boa:

antes da discussão,

cada especialista escreve:

top 3 hipóteses.

Depois:

compartilham.

Isso reduz:

anchor social.


☕ Primeiro pense.

Depois ouça.

Muito útil.


🧠 Anchoring e Groupthink

Primeiro senior:

X.

Restante:

adjust around X.

Depois:

consenso.

Mas talvez:

consenso nasceu:

da ordem de fala.

Groupthink + Anchoring.


🧠 Randomize order

In critical review:

juniors first.

Then seniors.

Reduces authority anchor.


🎯 Pergunta Bellacosa nº 9

“Se a ordem de fala fosse invertida, chegaríamos à mesma conclusão?”


🧠 Anchoring em estimativa COBOL

Gerente:

— Alteração pequena.

Programador:

— Talvez.

“Pequena” é:

anchor sem número.

Agora você procura:

como fazer pequeno.

Talvez:

copybook compartilhado;

20 programas;

DB2 package;

CICS map;

batch downstream.

Não pequeno.


☕ Adjetivo também pode:

ser âncora.


🧠 Anchoring verbal

“simples.”

“rápido.”

“baixo risco.”

“apenas.”

“só.”

Essas palavras:

moldam.


🎯 Pergunta Bellacosa nº 10

“Quem decidiu que isso era simples antes da análise?”


🧠 Anchoring e Goal Gradient

Projeto:

90%.

Essa porcentagem:

vira âncora.

Agora:

“falta pouco.”

Mesmo que:

risco restante:

alto.

Goal Gradient acelera.

Anchoring fixa:

90% como referência.


🧠 Metric Fixation

Percentual:

parece objetivo.

Anchor quantitativo.


☕ 97%

é apenas:

um número.

Mas pode dirigir:

uma reunião inteira.


🧠 Anchoring e McNamara Fallacy

Primeiro KPI:

availability.

Depois:

toda saúde do serviço

orbita:

availability.

Mesmo quando:

correctness;

customer impact;

manual toil

importam.

Métrica inicial vira:

anchor conceitual.


🧠 Goodhart

Depois:

anchor vira target.

Goodhart.


🧠 Anchoring e Zero-Risk Bias

Alguém fala:

“precisamos eliminar totalmente vulnerabilidades críticas.”

Zero:

anchor.

Agora:

qualquer risco residual:

parece intolerável.

Mesmo se:

trade-off piora.


🎯 Pergunta Bellacosa nº 11

“O valor zero foi escolhido por análise de risco ou por conforto psicológico?”


🧠 Anchoring em incident severity

Primeira pessoa:

— P2.

Ticket:

P2.

Impact grows.

Mas todos:

adjust slowly.

Maybe deveria:

P1.

Anchor de severidade.

Outro lado:

primeiro chama P1.

Mesmo depois:

baixo impacto,

continua:

panic.


☕ Severidade também tem:

inércia.


🧠 Re-anchor with evidence

Severity should:

update.

Not:

stay.


🎯 Pergunta Bellacosa nº 12

“Se abríssemos o incidente agora, com os dados atuais, daríamos a mesma severidade?”


🧠 Anchoring e baseline técnico

CPU normal:

70%.

Por quê?

“sempre foi.”

Maybe:

bad design.

Baseline should:

reflect:

healthy state,

not:

historical habit.


🧠 Anchoring em capacity

Last year:

peak 80%.

Forecast:

starts:

But new customer:

changes workload.

Need:

new model.


☕ Forecast não é:

ano passado + 10%.

Às vezes.


🧠 Anchoring em orçamento anual

Budget previous year:

anchor.

New budget:

+5%.

But:

needs changed.

This is known:

incremental budgeting.

Anchoring explains part.


🧠 Ratchet Effect

Last performance:

anchor

and floor.

Then:

ratchet.


🎯 Pergunta Bellacosa nº 13

“Estamos construindo a nova meta a partir da necessidade atual ou apenas ajustando a antiga?”


🧠 Anchoring em fornecedores

Vendor reputation:

good.

New incident:

benefit of doubt.

Or bad:

every incident blamed.

Reputation:

anchor.

Fundamental Attribution Error.


☕ Marca também:

ancora.


🧠 Anchoring em pessoas

“Ele é excelente.”

Future mistake:

exception.

“Ele é ruim.”

Future success:

luck.

First impression:

anchor.

Halo Effect.

Horn Effect.


🧠 First Impression Bias

Related.

Anchoring can help explain:

persistence of first impression.


🎯 Pergunta Bellacosa nº 14

“Estou avaliando este evento ou reinterpretando-o à luz da reputação anterior?”


🧠 Anchoring e AI

Agora moderno.

Prompt:

“A causa parece ser Db2. Analise.”

Você acabou:

ancorar a IA.

Ela talvez:

procure Db2.

Better:

“Analise independentemente as possíveis causas. Uma hipótese anterior mencionou Db2, mas trate-a como não confirmada.”

Huge difference.


🤖 Prompt as anchor

Context window:

contains:

first hypothesis.

Model reasons:

from context.

Be careful.


🧠 AI debugging

“Find the bug in this loop.”

What if:

bug not loop?

Prompt narrows:

search space.

Streetlight + Anchoring.


🎯 Pergunta Bellacosa nº 15

“Estou pedindo à IA para investigar ou estou sugerindo a conclusão no próprio prompt?”


🧠 Anchoring e RAG

RAG retrieves:

top document.

First result:

maybe anchor.

Model then:

builds answer.

Need:

diverse retrieval.

Multiple sources.


🧠 Search ranking itself anchors

Top result:

more attention.

Streetlight.

Search Satisfaction.


☕ Primeiro resultado do Google

não recebe:

certificado de verdade.


🧠 Anchoring em AIOps

Classifier says:

70% Db2.

Operator:

anchors.

Maybe classifier:

prior.

Now:

human ignores:

new signal.

Automation Bias.


🧠 Automation Bias

If anchor comes from:

machine,

authority may:

increase.

“AI says Db2.”

Careful.


🎯 Pergunta Bellacosa nº 16

“Esse score da IA é evidência independente ou apenas uma priorização de hipóteses?”


🧠 Anchoring e security

SIEM alert:

“possible credential theft.”

Now analyst:

credential theft.

Could be:

service account rotation.

Alert label:

anchor.

Need:

raw evidence.


🧠 Anchoring e fraud

First transaction:

looks fraudulent.

Account:

labeled.

Future transactions:

interpreted through:

fraud anchor.

Maybe false positive.


🧠 Anchoring e legal/compliance

First audit finding:

“weak control.”

Years:

control viewed weak.

Even after:

improved.

Diagnosis Momentum + Anchoring.


☕ Label antigo

vira:

âncora nova.


🧠 Anchoring e Cultural Debt novamente

“Esse sistema é crítico demais para mexer.”

Talvez era verdade:

15 years ago.

Now:

architecture.

tools.

staff.

changed.

Anchor persists.

Culture:

forms around.


🎯 Pergunta Bellacosa nº 17

“Essa afirmação ainda é evidência atual ou apenas história acumulada?”


🧠 Anchoring e Sunk Cost

Investimos:

R$10 milhões.

Agora:

esse valor vira:

âncora.

“Não podemos abandonar.”

But future decision should:

consider future costs/benefits.

Not:

past.

Sunk Cost.


🧠 Anchoring e Escalation of Commitment

Original plan:

anchor.

New evidence:

bad.

But:

keep adjusting.

Not:

rethink.


☕ Plano antigo

pode virar:

coordenada fixa.

Mesmo quando:

mapa mudou.


🧠 Anchoring e Loss Aversion

Original price.

Original performance.

Original expectation.

Loss defined:

relative to anchor.

This is fundamental in prospect theory.

Our perception of gains/losses depends on:

reference point.

Anchors can become:

reference points.


🧠 Example

System target:

99.9%.

Actual:

99.8%.

Feels:

loss.

If old baseline:

98%.

Huge improvement.

Which frame?

Reference matters.


🎯 Pergunta Bellacosa nº 18

“Qual referência estamos usando para decidir se isso é bom ou ruim?”


🧠 Anchoring e SLA

SLA negotiated:

99.9%.

Years later:

customer needs:

99.99.

But old SLA:

anchor.

“Estamos above contract.”

Maybe:

business still fails.

Goal Substitution.


🧠 Contract anchor

Legal success.

Operational failure.


☕ SLA é:

piso contratual.

Não necessariamente:

definição de qualidade.


🧠 Anchoring e postmortem

First timeline:

contains:

“deployment caused issue.”

Later evidence:

maybe no.

But RCA draft:

built around.

Hard to:

rebuild.

Need:

facts-first.


🧠 Premature Narrative

Narrative Bias.


🎯 Pergunta Bellacosa nº 19

“Estamos revisando a hipótese ou apenas editando a história original?”


🧠 Anchoring e RCA tools

Form asks:

ROOT CAUSE:

Too early.

Field itself:

anchors.

Better:

LEADING HYPOTHESES:

Then:

confirmed root/contributors.

Data model influences:

thinking.


☕ Um campo obrigatório

pode induzir:

certeza prematura.


🧠 Anchoring e NOT NULL

Again:

ROOT_CAUSE NOT NULL

Organizational disaster.

Someone fills:

something.

That something:

anchors historical data.


🧠 AI training later

Old labels:

become:

training data.

Anchor at scale.


🎯 Pergunta Bellacosa nº 20

“Nosso sistema obriga alguém a dar uma resposta antes de existir evidência suficiente?”


🧠 Anchoring e order effects

Question order:

matters.

If ask:

“Is Db2 causing latency?”

then:

“What else?”

Db2 anchor.

Better:

“List plausible causes.”

Then:

evaluate Db2.


🧠 Checklist order

Even checklist can:

anchor.

Randomize or:

broad first.


☕ O primeiro item da checklist

também recebe:

holofote.


🧠 Anchoring e code review

Reviewer sees:

author comment:

“Fixes overflow.”

Now:

looks overflow.

Maybe:

security issue elsewhere.

Independent review:

first read code

before reading:

author hypothesis.

Sometimes useful.


🎯 Pergunta Bellacosa nº 21

“Quanta interpretação devemos mostrar ao revisor antes que ele faça sua primeira leitura?”


🧠 Anchoring em troubleshooting runbooks

Runbook:

“Latency → check Db2.”

This is:

explicit anchor.

Good if:

base rate high.

Bad if:

exclusive.

Better:

Latency:
1. confirm scope
2. identify affected path
3. check recent change
4. inspect key dependencies

Then specific branches.


☕ Runbook deveria:

guiar busca.

Não:

pré-julgar culpado.


🧠 Anchoring e heuristics

Heuristics are:

useful.

Expert:

“usually Db2.”

This prior:

helps.

But must:

update.

The mistake:

isn't starting with prior.

It's refusing:

to move enough.


🧠 Bayesian analogy

Prior:

Db2 50%.

Evidence:

network error.

Update:

should change.

Anchoring means:

update too little.


🎯 Pergunta Bellacosa nº 22

“A nova evidência mudou nossa probabilidade ou apenas nossa explicação verbal?”


🧠 Anchoring e confidence

Initial confidence:

60%.

Later:

contradictory evidence.

Still:

55%.

Maybe insufficient adjustment.

Could drop:

Be deliberate.


🧠 Re-estimation from scratch

Powerful technique.

After major new evidence:

discard old estimate and rebuild.


☕ Não faça:

“10 + mais 5 dias.”

Pergunte:

“Se eu estimasse hoje do zero?”


🧪 Técnica Bellacosa nº 1 — Zero-Based Estimate

For project:

ignore old number.

Estimate:

tasks.

dependencies.

risk.

Then compare.


🧪 Técnica nº 2 — Blind Hypothesis Generation

Before hearing:

first guess,

write your own.


🧪 Técnica nº 3 — Multiple Anchors

If unavoidable:

consider:

best case;

likely;

worst.

Avoid:

single anchor.


🧪 Técnica nº 4 — Outside View

Look:

similar projects/incidents.

Base rates.

Not:

one internal guess.


🧪 Técnica nº 5 — Disconfirming Evidence

Ask:

what would move us away?


☕ A âncora só é perigosa

quando:

ninguém verifica a corrente.


🧠 Anchoring em estimates: three-point

Instead of:

“10 days.”

Use:

OPTIMISTIC: 8
LIKELY: 15
PESSIMISTIC: 30

More honest.

Still estimates.

But less:

single-number fixation.


🧠 Range

A range reduces:

false precision.


🎯 Pergunta Bellacosa nº 23

“Por que estamos exigindo um número único quando a realidade ainda é uma distribuição?”


🧠 Anchoring e False Precision

Manager says:

12.5 days.

Now:

precision anchor.

Looks:

scientific.

Maybe:

guess.

Metric Fixation.


☕ Decimal

não é:

evidence.


🧠 Anchoring em performance targets

“CPU should be below 70.”

Why 70?

Maybe:

historical threshold.

Everyone tunes:

But:

system may handle 85.

Or suffer at 60.

Threshold anchor.


🎯 Pergunta Bellacosa nº 24

“Qual evidência originou esse threshold?”


🧠 Anchoring e Alert Thresholds

Threshold:

500 queue depth.

At 499:

green.

At 501:

red.

Anchor boundary.

Reality continuous.

Metric Fixation.


🧠 Threshold crossing

Don't let:

number

replace:

trend/context.


☕ 499 e 501

não vivem:

em universos diferentes.

Só dashboard acha.


🧠 Anchoring em compliance

“100% compliant.”

Anchor:

But:

control effectiveness?

Different.

Again.


🧠 Anchoring em certification

Score:

80% pass.

Candidate:

79%.

Feels:

fail.

Maybe:

difference tiny.

Threshold anchor.

Necessary operationally.

But don't overinterpret:

competence gap.


🎯 Pergunta Bellacosa nº 25

“A fronteira operacional também representa uma diferença real de competência ou risco?”


🧠 Anchoring em customer complaints

First complaint:

“slow.”

Support:

latency.

Maybe issue:

wrong data.

Customer description:

anchor.

Important:

listen.

But translate:

symptom.


🧠 User explanation vs observation

User:

“database is down.”

Observation:

“screen doesn't load.”

Record:

observation.

Not:

diagnosis.


☕ Usuário pode:

ser excelente sensor.

Não necessariamente:

RCA engine.


🧠 Anchoring em incident severity wording

Customer says:

“everything is down.”

Maybe:

one feature.

Don't anchor:

“everything.”

Verify scope.


🎯 Pergunta Bellacosa nº 26

“O que foi observado diretamente e o que foi interpretação de quem reportou?”


🧠 Anchoring e Political/Organizational Pressure

Director:

— This cannot be security.

Now:

negative anchor.

Team maybe:

avoids security.

Anchoring also works:

by exclusion.


🧠 Authority anchor

“We know it's not network.”

Why?

“Network manager said.”

Evidence?

Hmm.


☕ “Não é nosso.”

também é:

âncora.


🧠 Anchoring and blind spots

If first message:

“application problem,”

infra stops thinking.

Silos.


🎯 Pergunta Bellacosa nº 27

“Qual área foi excluída cedo demais por causa do primeiro rótulo?”


🧠 Anchoring e Human Error

First report:

“operator entered wrong value.”

Now:

human error.

Later:

screen auto-filled.

But anchor:

person.

Fundamental Attribution.


🧠 Anchoring e moral judgment

Once person:

blamed,

evidence interpreted:

accordingly.

Blameless culture helps:

reset.


☕ Culpa também:

ancora.

E muito forte.


🧠 Anchoring e RCA legal defensiveness

Organization may anchor:

external cause.

Because:

safer.

Then:

search.

Principal-Agent.

Self-Serving.


🎯 Pergunta Bellacosa nº 28

“Nossa primeira hipótese também é a hipótese mais confortável politicamente?”


🧠 Anchoring e Near Misses

First incident:

classified low severity.

Similar future:

low.

But context:

changed.

Reassess.


🧠 Anchoring e recurring incidents

“Known issue.”

That label:

powerful anchor.

Maybe:

new issue.

Never assume identical.


☕ “Known issue”

é útil.

Mas pode:

matar curiosidade.


🧠 Anchoring em historical RCA

Previous RCA:

DB2.

New incident:

search old KB.

First article:

DB2.

Anchor.

Search engine:

amplifies.

Streetlight.

Diagnosis Momentum.


🧠 Search ranking bias

Top result:

not necessarily:

best match.


🎯 Pergunta Bellacosa nº 29

“Estamos repetindo o RCA anterior porque a evidência é semelhante ou porque ele foi o primeiro artigo recuperado?”


🧠 Anchoring e Incident Copilots

AI could:

de-bias.

Ask:

top 5 hypotheses

without:

current anchor.

Then:

score evidence.

But if fed:

“Db2 issue,”

will anchor.

Tool design matters.


🧠 Independent first pass

Agent A:

facts-only.

Agent B:

previous hypothesis.

Compare.

Great.


☕ Uma IA pode:

ser a segunda opinião

desde que:

não receba a primeira opinião

disfarçada de fato.


🧠 Anchoring e Confidence Drift

Initial:

Db2 40%.

After five people repeat:

Db2 80%.

No evidence.

Diagnosis Momentum.

Anchor grows:

through social reinforcement.


🎯 Pergunta Bellacosa nº 30

“Nossa confiança mudou porque surgiram dados ou porque o rótulo ficou familiar?”


🧠 Familiarity effect

Repeated statements:

feel truer.

Illusory Truth Effect.

This can reinforce:

anchors.


☕ Repetição

não é:

compilação.

Muito menos:

teste.


🧠 Anchoring e narrative compression

Executive asks:

one sentence.

Team says:

“Db2 lock.”

Now:

anchor disseminated.

Later:

correction harder.

Use careful:

“leading hypothesis.”


🧠 Preserve uncertainty

Words:

possible;

likely;

confirmed.

Again.


🎯 Pergunta Bellacosa nº 31

“A simplificação executiva preservou nosso nível real de certeza?”


🧠 Anchoring e memory

After incident:

people remember:

first explanation.

Even if later changed.

Primacy effect.

First info sticks.

Diagnosis Momentum.


🧠 Correction lag

Corrections often:

less memorable.

Need:

explicit update.


☕ Boato chega:

de Ferrari.

Correção:

de ônibus municipal.


🧠 Information Rollback

If first hypothesis wrong:

propagate correction.

Not enough:

update ticket.

Tell:

teams.

vendor.

executives.

KB.


🎯 Pergunta Bellacosa nº 32

“A correção viajou tão longe quanto a hipótese original?”


🧠 Anchoring e Cultural Memory

Years later:

“that outage was Db2.”

Maybe:

not.

Old anchor:

persists.

Then:

future architecture decisions.

Cultural Debt.


🧠 Anchoring e legacy modernization

Original migration estimate:

2 years.

Years later:

people still say:

“two-year project.”

Even if scope changed.

Anchor:

institutional.


🎯 Pergunta Bellacosa nº 33

“Estamos discutindo um número atual ou uma memória organizacional de um número antigo?”


🧠 Anchoring e leadership

A leader can reduce bias:

by speaking last.

Powerful.

If leader says first:

anchor.

So:

ask team first.


☕ Chefe falar por último

às vezes:

é arquitetura cognitiva.


🧠 Silent Brainwriting

Collect:

hypotheses before:

meeting discussion.

Excellent.


🧠 Anchoring e interviews

Security investigation:

don't tell witness:

current hypothesis.

Avoid contamination.

Same principle.


🎯 Pergunta Bellacosa nº 34

“Estamos coletando informação independente ou contaminando a testemunha com nossa teoria?”


🧠 Anchoring e baseline revalidation

Periodic:

ask:

why threshold?

why SLA?

why schedule?

why architecture rule?

Anchors age.


🧠 Anchor expiry date

Nice concept.

Every assumption:

review date.


☕ Talvez todo número histórico precise:

de validade.

Como certificado.


🧠 Anchoring e Goal Substitution final connection

Original metric:

becomes anchor for:

goal.

Then:

metric target.

Then:

culture.

Anchoring may:

start entire chain.


🧠 Anchoring e Metric Fixation

First dashboard:

defines:

attention.

Everything else:

secondary.

Again.


🧠 Anchoring e McNamara

First measurable variable:

becomes:

reference.

Hard-to-measure:

ignored.


🧠 Anchoring e Streetlight

First place:

look.

Then:

stay.


🧠 Anchoring e Search Satisfaction

First finding:

satisfies.


🧠 Anchoring e Premature Closure

First plausible story:

closes.


🧠 Anchoring e Diagnosis Momentum

First label:

travels.


☕ Anchoring é quase:

o boot loader

de muitos vieses.


🧠 Bellacosa Anti-Anchoring Protocol

Quando surgir:

primeiro número;

primeira hipótese;

primeiro rótulo;

faça:


Passo 1 — Identifique a âncora

O que entrou primeiro?


Passo 2 — Pergunte a origem

Data?

Guess?

Senior?

History?


Passo 3 — Faça estimativa independente

If possible:

before hearing others.


Passo 4 — Liste alternativas

Minimum:

3 plausible.


Passo 5 — Seek disconfirming evidence

Try:

move away.


Passo 6 — Re-estimate from zero

After major evidence.


Passo 7 — Use outside view

Historical base rates.


Passo 8 — Separate observation from interpretation

Facts first.


Passo 9 — Leader speaks last

Reduce authority anchor.


Passo 10 — Re-anchor deliberately

Anchor on:

objective evidence,

not:

first opinion.


📋 Checklist Bellacosa anti-Anchoring

[ ] Qual foi a primeira informação recebida?

[ ] Ela tinha evidência?

[ ] Era dado ou palpite?

[ ] Minha estimativa mudou pouco demais?

[ ] Eu faria a mesma estimativa sem conhecer esse número?

[ ] Listei hipóteses independentes?

[ ] A primeira pessoa a falar tinha autoridade?

[ ] O título do ticket contém diagnóstico?

[ ] Algum valor histórico virou baseline sem revisão?

[ ] Há evidência nova que deveria mover minha opinião?

[ ] Estou procurando confirmação?

[ ] A IA recebeu uma hipótese já embutida no prompt?

[ ] O threshold foi escolhido por análise ou tradição?

[ ] A correção da hipótese anterior foi propagada?

🧠 Bellacosa Anchor Card

ANCHOR:
________________________

SOURCE:
________________________

TYPE:
DATA / ESTIMATE / OPINION / HISTORY

INDEPENDENT ESTIMATE:
________________________

ALTERNATIVES:
________________________

EVIDENCE AGAINST:
________________________

NEW ESTIMATE:
________________________

🧠 O Teste do RESET

Pergunte:

“Se eu pudesse apagar da memória a primeira informação recebida, o que concluiria agora?”

Difícil.

Mas poderoso.


🧠 O Teste do Número Aleatório

Se alguém diz:

“10 dias,”

pergunte:

“Se tivessem dito 100, minha estimativa mudaria?”

Se sim:

anchor.


🧠 O Teste da Hipótese Morta

Assuma:

Db2 provado inocente.

Agora:

o que investiga?

Isso:

quebra anchor.


🧠 O Teste do Senior Ausente

Pergunte:

“Se o senior não tivesse dito nada, qual seria minha hipótese?”

Great.


👻 Easter Egg nº 2 — BELLACOSA.BIAS

Na manhã seguinte:

BELLACOSA.BIAS(ANCHORING)

Dentro:

       IF FIRST-VALUE-RECEIVED = 'Y'
           MOVE 'POSSIBLE-ANCHOR'
             TO COGNITIVE-STATUS
       END-IF.

       IF NEW-EVIDENCE = 'STRONG'
           PERFORM REESTIMATE-FROM-ZERO
       END-IF.

       IF SENIOR-SPEAKS-FIRST = 'Y'
           PERFORM REQUEST-INDEPENDENT-HYPOTHESES
       END-IF.

       IF TICKET-TITLE-CONTAINS-ROOT-CAUSE = 'Y'
          AND ROOT-CAUSE-CONFIRMED = 'N'
           DISPLAY
           'WARNING: FRAME MAY BECOME ANCHOR'
       END-IF.

Comentários:

* FIRST
* DOES NOT MEAN
* BEST.

Outro:

* EARLY
* DOES NOT MEAN
* TRUE.

Outro:

* A NUMBER
* CAN ENTER YOUR HEAD
* WITHOUT PERMISSION.

Outro:

* REESTIMATE
* DO NOT JUST ADJUST.

E naturalmente:

* FIRST DALEK SEEN:
* RED.
*
* DO NOT ASSUME
* ALL DALEKS
* ARE RED.

🕰️ De volta à War Room

03:32.

Todos:

Db2.

Nosso jovem pergunta:

— Podemos começar de novo?

Gerente:

— Como assim?

— Sem assumir Db2.

DBA:

— Mas temos locks.

— Sim.

— Então?

— Eles começaram depois do incidente.

Silêncio.

Ele escreve:

FACTS

02:52 latency
02:53 retries
02:57 queue growth
03:01 DB2 lock

Depois:

HYPOTHESES

external API
MQ
network
retry storm
DB2 contributor

A sala muda.


🔧 Quinze minutos depois

Descobrem:

um parceiro externo começou:

a responder lentamente.

Clients:

retry.

Workload:

cresce.

Db2:

sofre.

O lock:

era real.

Mas:

não original.


☕ O DBA pergunta:

— Então não era Db2?

Nosso jovem:

— Db2 participou.

— Mas não causou?

— Não primeiro.

Doctor sorri.

— Muito bom.


🧠 A diferença entre “primeiro observado” e “primeiro causal”

Importantíssima.

First alert:

not first cause.

First hypothesis:

not best hypothesis.

First number:

not correct baseline.

First estimate:

not reference truth.


🎯 Pergunta Bellacosa nº 35

“Primeiro em qual sentido?”

Primeiro a aparecer?

Primeiro a ser detectado?

Primeiro a ser mencionado?

Primeiro causal?

Completamente diferentes.


🧬 Regeneração organizacional

Uma organização madura não tenta:

eliminar âncoras.

Isso é impossível.

Nós precisamos:

de referências.

O cérebro precisa:

começar em algum lugar.

A maturidade está em:

saber que o primeiro lugar é apenas um ponto de partida.

Ela:

separa fatos de hipótese;

pede estimativas independentes;

usa base rates;

faz leaders falarem depois;

recalcula quando evidência muda;

e não pune:

mudança de opinião.

Principalmente:

ela entende que:

a primeira resposta tem vantagem psicológica, não privilégio epistemológico.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem:

Anchoring Bias é a tendência de depender excessivamente de uma informação inicial ao fazer julgamentos e estimativas.

Depois da âncora, frequentemente fazemos ajustes insuficientes.

A âncora pode ser um número, uma hipótese, uma palavra, um rótulo, um histórico ou a opinião de alguém com autoridade.

Em incidentes, o primeiro alerta pode ancorar toda a investigação.

Em projetos, o primeiro prazo pode dominar estimativas posteriores.

Em negociação, o primeiro preço altera a referência da conversa.

Em performance, um baseline histórico pode se tornar uma âncora obsoleta.

Em arquitetura, rótulos como “legacy”, “caro”, “impossível” ou “moderno” podem ancorar decisões.

Anchoring frequentemente antecede Confirmation Bias, Search Satisfaction, Premature Closure e Diagnosis Momentum.

Streetlight Effect pode manter a busca no componente escolhido pela âncora.

Recency Bias e Representativeness Heuristic ajudam a selecionar âncoras familiares.

Authority Bias torna a âncora de um especialista mais poderosa.

Metric Fixation pode transformar um número inicial em realidade oficial.

Goal Gradient pode fazer porcentagens de progresso virarem âncoras perigosas.

Sunk Cost e Escalation of Commitment podem transformar o plano original numa âncora difícil de abandonar.

A IA também pode ser ancorada pelo contexto, pelo prompt ou por classificações automáticas.

E principalmente:

a primeira informação merece ser considerada — nunca automaticamente obedecida.


🥚 Easter Egg final

Antes de entrar na TARDIS, o Doctor escreve:

FIRST != TRUE

Nosso jovem:

— Outra vez código que não compila.

Doctor:

— Corrija.

Ele escreve:

       IF FIRST-HYPOTHESIS = 'DB2'
           MOVE 'CANDIDATE'
             TO HYPOTHESIS-STATUS
           PERFORM GENERATE-ALTERNATIVES
       END-IF.

Doctor:

— Melhor.

O jovem pergunta:

— E se o senior tiver certeza?

Doctor:

— Ótimo.

— Ótimo?

— Significa que temos uma hipótese muito boa para tentar destruir.

Nosso jovem ri.

— E se ela sobreviver?

Doctor abre a porta.

— Então ela terá conquistado sua confiança.

Pausa.

“Não apenas chegado primeiro.”

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

Na War Room sobra apenas:

“Primeiro é posição temporal, não certificado de verdade.”

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

começar por uma hipótese é inevitável; permanecer preso a ela depois que a evidência mudou é escolha — e uma das escolhas mais caras que uma War Room pode fazer.

☕🌀

Próxima parada: Confirmation Bias — quando a âncora já está presa e começamos a vasculhar logs, métricas, memórias e opiniões procurando exatamente aquilo que provará que estávamos certos desde o começo.

sexta-feira, 14 de maio de 2010

Anchoring Bias: Doctor Who, COBOL e o Dia em que a Primeira Explicação Prendeu Toda a War Room

Bellacosa Mainframe e o anchoring bias

☕ Um Café no Bellacosa Mainframe

Anchoring Bias: Doctor Who, COBOL e o Dia em que a Primeira Explicação Prendeu Toda a War Room

Uma viagem pela TARDIS dos incidentes para entender por que a primeira informação costuma pesar demais — mesmo quando está errada

09:03.

O telefone toca.

Usuário:

— O sistema está lento.

Analista:

— Desde quando?

Usuário:

— Depois da mudança de ontem.

Pronto.

Duas frases.

Nenhum gráfico.

Nenhum log.

Nenhuma métrica.

Nenhum teste.

Nenhuma correlação comprovada.

Mas a War Room ainda nem começou e já temos nosso primeiro suspeito:

a mudança de ontem.

Às 09:08 alguém escreve no chat:

“Provável problema no deploy.”

Às 09:11 o gerente pergunta:

— Conseguimos fazer rollback?

Às 09:14 o programador abre o código alterado.

Às 09:19 alguém encontra uma instrução diferente.

Às 09:22:

— Deve ser isso.

Às 09:30 metade da equipe está investigando aplicação.

Enquanto isso, em outra tela, uma fila MQ cresce silenciosamente.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se ao lado do quadro branco.

O Doctor sai.

Lê:

HIPÓTESE PRINCIPAL:
ERRO NO DEPLOY

Pergunta:

— Que evidência temos?

Um analista responde:

— O problema começou depois da mudança.

— Isso é evidência de causalidade?

Silêncio.

— Bem... aconteceu depois.

O Doctor sorri.

— Ah.

Pausa.

— Então se chover depois do almoço, devemos investigar o sanduíche?

Eis nosso monstro da semana:


Anchoring Bias

Ou:

Viés de Ancoragem

A tendência de dar peso excessivo à primeira informação recebida, usando-a como referência para todas as avaliações seguintes.


🌀 Onde estamos na nossa viagem?

Até aqui já passamos por quatro monstros.

Primeiro, o Swiss Cheese Model.

Aprendemos que barreiras falham.

Depois veio a Normalization of Deviance.

Aprendemos que desvios podem virar rotina.

Depois encontramos o Hindsight Bias.

Descobrimos que o passado parece muito mais óbvio depois que conhecemos o final.

Então veio o Confirmation Bias.

Aprendemos que, depois de escolher uma teoria, nosso cérebro adora procurar provas que concordem com ela.

Agora finalmente encontramos o mecanismo que muitas vezes escolhe essa primeira teoria:

a âncora.


⚓ O que é Anchoring Bias?

Anchoring Bias acontece quando uma informação inicial influencia desproporcionalmente julgamentos posteriores.

Essa primeira informação funciona como uma âncora.

Mesmo quando recebemos novos dados, nossa avaliação tende a permanecer próxima daquele ponto inicial.

Em forma simples:

PRIMEIRA INFORMAÇÃO
        ↓
FORMA UMA ÂNCORA
        ↓
NOVOS DADOS SÃO INTERPRETADOS
A PARTIR DAQUELA REFERÊNCIA

Não significa que nunca mudamos de ideia.

Significa que começamos a investigação puxados por uma força invisível.


🧠 Um exemplo fora da informática

Imagine que alguém pergunte:

— Um produto custa mais ou menos de R$ 10.000?

Depois pergunta:

— Quanto você acha que ele custa?

Mesmo que R$ 10.000 tenha sido escolhido arbitrariamente, ele pode influenciar sua estimativa.

Agora troque preço por incidente.

Primeira frase do chamado:

“Problema de banco de dados.”

A equipe começa de um ponto.

Mesmo antes de validar.


☕ Bellacosa Mainframe: o poder destrutivo do assunto do chamado

Ticket:

ASSUNTO:
LENTIDÃO DB2

Talvez o usuário tenha colocado “Db2” porque viu uma mensagem SQL.

Agora chegam:

DBA;

analista COBOL;

infraestrutura;

suporte.

Primeira reação:

— Vamos olhar Db2.

Essa é uma âncora.

Mas talvez o banco esteja apenas esperando uma aplicação downstream.

Talvez seja rede.

Talvez seja MQ.

Talvez seja storage.

Talvez o SQLCODE seja consequência.

O nome do ticket não deveria determinar a investigação.

Mas frequentemente determina.


🧲 A primeira hipótese gruda

Anchoring Bias é particularmente perigoso porque opera antes mesmo do Confirmation Bias.

Observe:

1. ALGUÉM DIZ:
“É REDE.”

2. A EQUIPE ANCORA EM REDE.

3. COMEÇA A BUSCAR PROVAS.

4. CONFIRMATION BIAS ENTRA.

5. TODO TIMEOUT VIRA
“EVIDÊNCIA DE REDE”.

Então temos uma dupla dinâmica:

Anchoring escolhe o suspeito.

Confirmation Bias tenta condená-lo.

Maravilhoso.

Para o incidente.


👻 Easter Egg nº 1 — O primeiro monstro visto

Imagine Doctor Who.

A equipe entra numa nave.

Encontra marcas metálicas na parede.

Alguém grita:

— Cybermen!

A partir daí:

qualquer ruído metálico vira Cyberman.

Qualquer interferência vira Cyberman.

Qualquer porta automática vira Cyberman.

Até que o Doctor pergunta:

— Por que Cybermen?

Resposta:

— Porque foi a primeira coisa que pensamos.

Parabéns.

Encontramos a âncora.


🚨 A War Room começa antes da War Room

Esse é um ponto importantíssimo.

A investigação muitas vezes já chega contaminada.

Antes da primeira reunião, alguém escreveu:

“erro de aplicação”.

Ou:

“falha de infraestrutura”.

Ou:

“problema após deploy”.

Ou:

“usuário informou falha de banco”.

Essas frases parecem inocentes.

Mas moldam atenção.

Por isso linguagem importa.

Compare:

INCIDENTE:
Falha causada por deploy.

com:

OBSERVAÇÃO:
Sintomas começaram após o deploy.
Causalidade ainda não confirmada.

A segunda formulação é muito melhor.


🧠 A diferença entre cronologia e causalidade

Uma das âncoras mais comuns é:

“Começou depois de X.”

Isso é útil.

Mas não prova:

“Foi causado por X.”

Existe um velho problema lógico:

post hoc ergo propter hoc

“Depois disso, portanto por causa disso.”

Em incidentes:

deploy às 02:00.

erro às 02:15.

Logo:

deploy causou erro.

Talvez.

Mas também poderia haver:

certificado expirando;

pico de volume;

job concorrente;

manutenção externa;

timeout de fornecedor;

fila acumulada;

problema de storage.

A proximidade temporal faz do deploy um suspeito forte.

Não necessariamente culpado.


💻 Exemplo COBOL: o campo que parecia culpado

Programa novo entra em produção.

Após algumas horas:

SOC7

O primeiro dump mostra:

WS-VALOR

Alguém conclui:

— Campo numérico inválido.

Agora toda investigação vai para dados.

Só que o campo inválido é consequência de corrupção anterior em memória.

O problema real está em um índice incorreto.

Mas a primeira pista ancorou a equipe.

Isso acontece muito em debugging.

O ponto onde o programa quebra nem sempre é o ponto onde o erro nasceu.


🎯 Abend location não é necessariamente root cause

Essa frase vale ouro para iniciante COBOL.

O programa abenda na linha 500.

Você pensa:

problema na linha 500.

Talvez.

Ou talvez a linha 500 seja apenas onde a inconsistência finalmente ficou visível.

A origem pode estar:

linha 80;

arquivo de entrada;

copybook;

chamada externa;

campo redefinido;

índice;

memória;

retorno de programa anterior.

Não deixe o dump se transformar numa âncora absoluta.

Ele mostra onde morreu.

Não necessariamente onde ficou doente.


🧩 Anchoring Bias e debugging

Imagine:

IF WS-CODIGO = 'A'
    PERFORM PROCESSA-A
END-IF

Programa falha em PROCESSA-A.

Naturalmente você investiga PROCESSA-A.

Depois de uma hora, descobre:

WS-CODIGO nunca deveria ter recebido A.

A causa está numa leitura anterior.

A primeira falha observável ancorou sua investigação.

Esse é um ótimo exemplo.


📞 O perigo da frase do usuário

Usuários relatam sintomas usando o próprio modelo mental.

Exemplo:

“Banco não atualizou.”

Isso pode significar:

  • tela ainda mostra valor antigo;

  • cache;

  • mensagem atrasada;

  • processamento batch ainda não terminou;

  • integração não retornou;

  • transação rollbackou;

  • leitura está usando réplica;

  • problema visual.

O usuário não está mentindo.

Ele está descrevendo o mundo como enxerga.

Transformar sua interpretação em diagnóstico técnico cria âncora.


🔎 Descrição não é diagnóstico

Essa regra deveria estar em toda central de suporte:

“Relato inicial descreve percepção, não causa.”

Ticket bom:

Usuário informa que saldo exibido não mudou após operação realizada às 10:17.

Ticket ruim:

Banco não atualiza saldo.

O primeiro preserva observação.

O segundo injeta teoria.


🧠 Autoridade amplifica a âncora

Agora adicionemos outro ingrediente.

Gerente diz:

— Deve ser aplicação.

Pronto.

A âncora agora pesa o dobro.

Por quê?

Porque autoridade aumenta influência.

Isso começa a tocar em outro tema que veremos depois:

Authority Gradient.

Se uma pessoa de maior hierarquia lança a primeira hipótese, a equipe pode ter dificuldade de questionar.

Assim:

GERENTE:
“É APLICAÇÃO.”

ANALISTA:
“Talvez...”

PENSAMENTO:
“Tenho dados dizendo rede,
mas talvez eu esteja errado.”

Perigoso.


🧱 A primeira métrica também pode virar âncora

Não apenas pessoas criam âncoras.

Dashboards também.

Imagine o primeiro painel aberto:

CPU 92%.

Pronto.

“CPU.”

Depois descobrimos que CPU subiu porque milhares de retries foram disparados devido a um problema externo.

CPU era consequência.

Mas como foi o primeiro número vermelho, virou o centro da narrativa.


🔴 Vermelho atrai atenção

Interfaces operacionais também influenciam julgamento.

Um indicador vermelho parece importante.

Talvez seja.

Mas um indicador verde pode esconder problema.

Exemplo:

CPU: 95%    RED
MQ QUEUE: 47000   YELLOW
DB2: NORMAL   GREEN

Todo mundo olha CPU.

Mas a fila crescente pode ser muito mais relevante.

Design de observabilidade também pode criar âncoras.


🧀 Swiss Cheese + Anchoring

Vamos conectar com nosso primeiro episódio.

Uma das camadas de defesa é:

diagnóstico humano.

Se a equipe ancora numa hipótese errada, essa camada cria um buraco.

Exemplo:

real problema:

storage.

âncora:

rede.

Duas horas investigando rede.

Enquanto storage degrada.

O viés cognitivo torna-se mecanismo de propagação do incidente.


🌀 Normalization of Deviance + Anchoring

Imagine que um alerta aparece diariamente.

A equipe já o normalizou.

Então ocorre incidente.

Primeira hipótese:

“Não é esse alerta; ele sempre aparece.”

Essa própria normalização vira uma âncora.

Passamos a investigação inteira partindo do pressuposto:

esse sinal é irrelevante.

Mas talvez hoje o contexto seja diferente.


🕰️ Hindsight Bias + Anchoring

Depois do incidente, olhamos para trás.

Descobrimos que a primeira pista verdadeira apareceu às 08:15.

Agora pensamos:

“Essa deveria ter sido a âncora!”

Mas cuidado.

Hindsight Bias novamente.

Naquele momento existiam dezenas de outros sinais.

A grande pergunta continua:

o que tornaria aquele sinal distinguível antes?


🔍 Confirmation Bias + Anchoring

Essa combinação merece um quadro:

ANCHORING BIAS
“ACHO QUE É REDE.”
       ↓
CONFIRMATION BIAS
“VAMOS PROCURAR PROVAS DE REDE.”
       ↓
HINDSIGHT BIAS
“DEPOIS FICOU ÓBVIO QUE ERA REDE.”

Se ainda houver Normalization of Deviance no meio...

Temos quase um episódio especial de Natal.


🧪 Como combater Anchoring Bias

Agora vamos para prática.

Passo 1 — Separe fatos de interpretações

Quadro:

FATOS
- usuários relatam lentidão
- começou aproximadamente 09:00
- fila MQ cresceu 30%
- houve deploy às 02:00

INTERPRETAÇÕES
- deploy causou
- MQ é causa
- aplicação está lenta

Nunca misture.


📝 Passo 2 — Reescreva o incidente sem diagnóstico

Evite:

“Incidente de Db2.”

Use:

“Aumento de tempo de resposta em transações X e Y desde 09:00.”

Agora você preserva espaço de investigação.


🧠 Passo 3 — Pergunte: “Qual foi nossa primeira informação?”

Durante War Room:

Qual foi a primeira coisa que ouvimos?

Isso está influenciando demais?

Essa pergunta simples pode libertar a equipe.


🔀 Passo 4 — Gere hipóteses antes de discutir

Uma técnica excelente:

cada pessoa escreve hipóteses independentemente.

Depois compartham.

Por quê?

Se a primeira pessoa fala antes, ela pode ancorar as demais.

Exemplo:

cinco especialistas.

Cada um anota:

A — aplicação
B — rede
C — banco
D — MQ
E — volume

Depois comparam.

Isso reduz influência inicial.


🧭 Passo 5 — Estabeleça baseline

Âncoras frequentemente aparecem porque não sabemos o que é normal.

CPU 80%.

É alto?

Depende.

Se normalmente é 75%, talvez não.

Se normalmente é 20%, sim.

Conheça baseline.

Sem baseline, o primeiro número visto vira referência psicológica.


📊 Passo 6 — Use múltiplas referências

Não compare apenas:

agora versus imediatamente antes.

Compare:

  • mesma hora ontem;

  • média semanal;

  • período equivalente;

  • baseline histórico;

  • outros componentes.

Isso evita que um único ponto temporal se torne âncora.


🧪 Passo 7 — Teste hipótese independente da sequência

Pergunte:

Se eu não soubesse que houve deploy, o que os dados me fariam suspeitar?

Essa pergunta é poderosa.

Remove artificialmente a âncora.

Outra:

Se esse chamado tivesse chegado sem título, qual seria meu diagnóstico inicial?

Excelente exercício.


🧑‍🔬 Passo 8 — Faça blind analysis quando possível

Em alguns casos, alguém pode analisar métricas sem saber qual teoria está sendo defendida.

Isso reduz influência.

Exemplo:

— Veja esse gráfico e diga o que observa.

Em vez de:

— Veja se encontra evidência de problema de rede.

A segunda pergunta já ancora.


🎯 Passo 9 — Defina critérios de descarte

Hipótese:

rede.

Escreva:

DESCARTAR SE:
- latência externa normal
- packet loss normal
- componentes locais também afetados

Isso evita permanecer preso à teoria indefinidamente.


⏱️ Passo 10 — Coloque tempo máximo por hipótese

Exemplo:

20 minutos para validar rede.

Se não aparecer evidência forte:

reavaliar.

Isso previne “tunnel vision”.


🚇 Tunnel Vision

Anchoring Bias frequentemente leva a tunnel vision.

A equipe passa a olhar uma parte estreita do sistema.

Tudo fora daquele túnel desaparece.

Em sistemas distribuídos isso é extremamente perigoso.

Porque incidentes atravessam camadas.

Mainframe.

MQ.

API.

Cloud.

Rede.

Parceiro.

Banco.

Um problema pode nascer longe de onde aparece.


🛰️ O mapa inteiro importa

Imagine:

USUÁRIO
  ↓
FRONT-END
  ↓
API
  ↓
MQ
  ↓
CICS
  ↓
COBOL
  ↓
DB2

Erro aparece no CICS.

Âncora:

CICS.

Mas talvez MQ esteja entregando mensagens duplicadas.

Ou API esteja gerando retries.

Ou usuário esteja repetindo ação por lentidão.

Sistemas modernos e híbridos exigem visão ponta a ponta.


🧠 Curiosidade: números aleatórios também podem influenciar

O fenômeno de ancoragem é tão forte que estudos clássicos mostraram que até números inicialmente irrelevantes podem influenciar estimativas posteriores.

Isso ensina algo desconfortável:

nosso cérebro busca referências mesmo quando a referência não deveria importar.

Em incidentes, a primeira estimativa de impacto pode fazer isso.

Alguém diz:

“Acho que afetou 10%.”

Mesmo sem dados.

Mais tarde todas as estimativas começam próximas de 10%.

Cuidado.


💰 Anchoring Bias em impacto financeiro

Primeira estimativa:

R$ 1 milhão.

Depois surgem novos dados.

Talvez impacto seja R$ 5 milhões.

Mas gestores podem resistir a abandonar o primeiro número.

Por isso estimativas iniciais devem ser claramente marcadas:

ESTIMATIVA PRELIMINAR
BAIXA CONFIANÇA

Linguagem reduz risco cognitivo.


🧯 Em segurança cibernética

Alerta:

“Possível phishing.”

A equipe ancora em phishing.

Mas talvez seja:

account takeover;

malware;

token roubado;

insider;

configuração.

Novamente:

classificação inicial ajuda triagem.

Não deveria encerrar diagnóstico.


🏦 Em sistemas financeiros

Diferença contábil aparece.

Primeira hipótese:

arredondamento.

Porque ocorreu antes.

Essa âncora pode atrasar descoberta de:

duplicidade;

integração parcial;

fraude;

problema de data;

regra nova.

A primeira explicação plausível é uma das coisas mais perigosas em reconciliação.


👨‍💻 O COBOL iniciante e o poder de perguntar

Nosso programador iniciante tem uma arma poderosa:

não conhece todas as histórias antigas.

Pergunta:

— Por que estamos investigando Db2?

Veterano:

— Porque o ticket veio como Db2.

Silêncio.

Essa frase deveria soar estranha.

O iniciante pergunta:

— E se o ticket estiver errado?

Excelente.

Inocência metodológica.


☕ Pergunta Bellacosa

Quando perceber que todo mundo está olhando para o mesmo lugar, pergunte:

“Se ninguém tivesse sugerido essa hipótese primeiro, para onde olharíamos?”

Essa pergunta pode salvar horas.


👥 Groupthink começa a aparecer

Aqui enxergamos outro monstro no horizonte.

Se uma pessoa cria a âncora e o grupo converge rapidamente, podemos entrar em:

Groupthink.

Todos concordam.

Não necessariamente porque a evidência é forte.

Mas porque o consenso já nasceu.

Esse será outro episódio delicioso.

E perigosíssimo.


⚠️ Senioridade não elimina ancoragem

Um veterano pode ter mais referências.

Isso ajuda.

Mas também pode ancorá-lo em experiências anteriores.

“Vi isso em 2003. Era VSAM.”

Talvez.

Mas 2026 não é 2003.

Experiência cria atalhos mentais.

Atalhos são úteis.

Até pegarmos a saída errada.


🧠 Recognition-Primed Decision

Profissionais experientes frequentemente reconhecem padrões rapidamente.

Isso é valioso.

Mas existe diferença entre:

“Esse padrão se parece com X.”

e

“É X.”

A primeira é hipótese baseada em experiência.

A segunda pode virar âncora rígida.

A maturidade está em usar experiência sem casar com ela.


📋 Checklist anti-Anchoring

Antes de seguir uma hipótese, pergunte:

[ ] Qual foi nossa primeira informação?

[ ] Ela é fato ou interpretação?

[ ] Quem forneceu essa informação?

[ ] Existe viés de autoridade?

[ ] Houve mudança recente?

[ ] Estamos confundindo “depois” com “por causa de”?

[ ] Quais hipóteses teríamos sem essa informação?

[ ] Qual dado contradiz nossa âncora?

[ ] Estamos olhando o sistema inteiro?

[ ] Existe critério claro para abandonar essa hipótese?

Se você não consegue abandonar sua teoria...

Talvez já esteja ancorado.


🧬 Regeneração organizacional

Como a organização se regenera?

Primeiro:

padroniza descrição neutra de incidentes.

Depois:

separa observação de diagnóstico.

Cria hipótese board.

Evita títulos acusatórios.

Usa múltiplas hipóteses.

Registra nível de confiança.

Reavalia periodicamente.

Incentiva contestação respeitosa.

E principalmente:

transforma:

“É isso.”

em:

“Nossa hipótese principal agora é isso.”

Duas palavras mudam tudo:

“agora”

e

“hipótese”.


🛸 Doctor Who e a âncora temporal

Talvez Doctor Who seja a metáfora perfeita para Anchoring Bias porque o Doctor sempre possui algo que nós não temos:

capacidade de mudar de perspectiva temporal.

Nós enxergamos:

agora.

Ele pode ver:

antes;

depois;

outra linha temporal.

A melhor defesa contra ancoragem é justamente mudar de perspectiva.

Pergunte:

O que eu veria se estivesse em outro time?

O que eu concluiria sem conhecer o deploy?

O que eu pensaria se isso acontecesse ontem?

O que um iniciante observaria?

Mude o ponto de vista.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Anchoring Bias faz a primeira informação pesar demais.

Descrição inicial não é diagnóstico.

Ordem dos acontecimentos não prova causalidade.

O ponto onde o sistema falha pode não ser o ponto onde o erro nasceu.

A primeira métrica vermelha pode ser sintoma, não causa.

Autoridade torna âncoras mais fortes.

Gere hipóteses independentes antes de convergir.

Separe fatos de interpretações.

Defina critérios para abandonar hipóteses.

Experiência ajuda, mas também pode ancorar.

E principalmente:

A primeira explicação merece ser investigada — não obedecida.


🕰️ De volta à War Room

10:17.

A equipe continua investigando o deploy.

Rollback já está sendo preparado.

Nosso programador iniciante olha para a fila MQ.

QUEUE DEPTH: 18432

Pergunta:

— Isso é normal?

Alguém responde:

— Não sei. Estamos olhando aplicação.

Ele insiste:

— Mas começou quando?

Abrem histórico.

08:41.

O deploy havia terminado às 02:00.

Fila cresce desde 08:41.

Nenhuma alteração de aplicação nesse horário.

O Doctor se aproxima.

— Interessante.

A equipe olha.

Descobrem que um consumer downstream começou a responder lentamente depois de uma alteração de infraestrutura externa.

O deploy era inocente.

O rollback teria introduzido outro risco sem resolver nada.

O gerente olha para o quadro:

CAUSA PROVÁVEL:
DEPLOY

Apaga.

Escreve:

HIPÓTESE DESCARTADA:
DEPLOY

Depois:

CAUSA:
CONSUMER DOWNSTREAM DEGRADADO

Nosso programador pergunta:

— Então perdemos uma hora?

O Doctor responde:

— Não necessariamente.

— Como assim?

— Se vocês aprenderem por que perderam.

Ele aponta para o primeiro ticket:

PROBLEMA APÓS DEPLOY

Depois pega uma caneta e reescreve:

LENTIDÃO REPORTADA ÀS 09:03.
HOUVE DEPLOY ÀS 02:00.
CAUSALIDADE NÃO ESTABELECIDA.

— Melhor?

O iniciante sorri.

— Muito melhor.

VWORP.

VWORP.

VWORP.

A TARDIS começa a desaparecer.


🥚 Easter Egg final

Horas depois, nosso programador encontra um membro estranho:

BELLACOSA.BIAS(MORIARTY)

Dentro:

       IF FIRST-IDEA = TRUE
           MOVE 'SUSPECT' TO WS-STATUS
       END-IF.

       IF FIRST-IDEA = 'CERTA'
           DISPLAY 'PROVE IT'
       END-IF.

No comentário:

* THE FIRST CLUE IS NOT ALWAYS THE BEST CLUE.

Logo abaixo:

* 221B

Ele olha para o corredor.

Por um segundo acha que ouve um violino.

Talvez seja apenas o ar-condicionado.

Ou talvez seja outra âncora.

O telefone toca.

Novo incidente.

Chamado:

“Erro de rede.”

Nosso programador não chama imediatamente a equipe de rede.

Primeiro pergunta:

— O que exatamente foi observado?

Do outro lado:

— Timeout.

— Em qual etapa?

— Depois de clicar em confirmar.

— Todas as transações?

— Só algumas.

Ele abre o mapa do fluxo.

E sorri.

Ainda não sabe a causa.

Mas já aprendeu algo extremamente importante:

não saber ainda é muito melhor do que estar errado cedo demais.

☕🌀

Next stop: Groupthink — quando sete profissionais inteligentes entram numa War Room e, misteriosamente, saem com uma única opinião.

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...