 |
| Bellacosa Mainframe e o plan cotinuation bias |
☕ Um Café no Bellacosa Mainframe
Plan Continuation Bias: Doctor Who, COBOL e o Dia em que Todo Mundo Sabia que Deveria Parar — Mas Continuou Mesmo Assim
Uma viagem pela TARDIS dos incidentes para entender por que equipes continuam executando planos que já deixaram de fazer sentido
02:41.
Madrugada de implantação.
Café número cinco.
Mudança prevista para terminar à 01:30.
Ainda não terminou.
O rollback continua possível.
Pelo menos tecnicamente.
Mas ninguém quer pronunciá-lo em voz alta.
Na tela:
MIGRATION STATUS
------------------------------
STEP 01 OK
STEP 02 OK
STEP 03 OK
STEP 04 OK
STEP 05 WARNING
STEP 06 DELAYED
STEP 07 NOT STARTED
WINDOW REMAINING: 00:49
O gerente pergunta:
— Quanto falta?
Especialista:
— Pouco.
— Quanto é pouco?
— Mais dois passos.
Nosso programador COBOL iniciante olha para o relógio.
Depois para um log.
RECONCILIATION WARNING
UNMATCHED RECORDS: 184
Pergunta:
— Não deveríamos voltar?
O especialista responde:
— Depois de chegar até aqui?
O gerente concorda.
— Se fizermos rollback agora, perdemos toda a madrugada.
Outro analista:
— Vamos terminar. Falta pouco.
O jovem olha novamente para os 184 registros.
Agora são 247.
Ninguém parece interessado.
Porque o grupo já investiu:
quatro horas;
uma janela;
uma dúzia de profissionais;
aprovação;
planejamento;
pressão;
expectativa.
Parar agora parece derrota.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se no canto da sala.
O Doctor sai.
Olha para o relógio.
Olha para os registros divergentes.
Olha para a equipe.
— Por que vocês continuam?
O gerente responde:
— Porque estamos quase terminando.
O Doctor observa o painel.
— Essa resposta fala sobre o passado.
Silêncio.
— Eu perguntei por que o próximo passo ainda é a melhor decisão.
Eis nosso monstro da semana:
Plan Continuation Bias
Ou:
Viés de Continuação do Plano
A tendência de persistir em um plano originalmente razoável mesmo depois que novas informações mostram que ele deveria ser revisado, interrompido ou abandonado.
🌀 Nossa TARDIS já está ficando cheia de monstros
Até aqui encontramos:
Swiss Cheese Model — várias barreiras podem falhar.
Normalization of Deviance — desvios repetidos começam a parecer normais.
Hindsight Bias — depois do desastre, tudo parece óbvio.
Confirmation Bias — buscamos evidências para provar aquilo em que já acreditamos.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — consenso social elimina divergência.
Authority Gradient — alguém percebe o risco, mas não consegue contrariar quem possui mais autoridade.
Agora temos:
Plan Continuation Bias
E ele é especialmente perigoso porque costuma aparecer depois de todos os outros.
A equipe já:
escolheu um plano;
investiu recursos;
criou expectativas;
obteve aprovações;
está sob pressão;
e quer terminar.
Então a capacidade de dizer:
“Precisamos parar”
começa a desaparecer.
🧠 O que exatamente é Plan Continuation Bias?
Plan Continuation Bias descreve a tendência de continuar seguindo um plano mesmo quando as circunstâncias que justificavam aquele plano mudaram.
Inicialmente:
PLANO A
faz sentido.
Depois surgem novas informações:
RISCO NOVO
TEMPO MENOR
SINAL ANORMAL
PREMISSA INVALIDADA
Mas a mente continua:
PLANO A
porque já começamos.
Esse é o ponto crítico.
O plano deixou de ser tratado como hipótese operacional.
Virou compromisso psicológico.
✈️ A aviação conhece muito bem esse problema
O conceito é bastante discutido em fatores humanos na aviação.
Um voo aproxima-se do destino.
Meteorologia piora.
Combustível diminui.
Pista complica.
Alternativa existe.
Mas quanto mais próximo o avião chega do pouso, maior pode ser a pressão psicológica para concluir a aproximação original.
O plano era:
pousar aqui.
Novos dados podem exigir:
arremeter.
Ou:
alternar.
Mas continuar parece emocionalmente mais natural.
Em aviação, isso se relaciona fortemente com situações conhecidas como get-there-itis: a pressão para chegar ao destino planejado apesar da mudança das condições.
Agora substitua:
avião → sistema;
pouso → go-live;
alternativa → rollback.
Pronto.
Estamos numa War Room.
☕ Bellacosa Mainframe: “já estamos com 90%”
Uma das frases favoritas do Plan Continuation Bias:
“Já fizemos 90%.”
Parece argumento forte.
Mas não responde à pergunta correta.
A pergunta correta é:
“Com o que sabemos agora, executar os 10% restantes ainda é a melhor decisão?”
O esforço passado não pode mudar o risco futuro.
Se os últimos 10% podem destruir produção, os primeiros 90% são irrelevantes para essa decisão.
💸 Sunk Cost entra pela porta dos fundos
Plan Continuation Bias frequentemente caminha ao lado do famoso:
Sunk Cost Fallacy.
Custos afundados.
Imagine:
projeto já consumiu R$ 50 milhões.
Nova análise mostra que continuar provavelmente consumirá mais R$ 30 milhões sem benefício proporcional.
Alguém diz:
— Não podemos parar depois de gastar cinquenta milhões.
Mas os cinquenta já foram gastos.
Não voltarão.
A pergunta racional deveria ser:
“Vale a pena gastar os próximos trinta?”
Em incidentes:
“Já passamos quatro horas nessa implantação.”
Essas quatro horas já foram gastas.
A pergunta é:
“A próxima hora ainda faz sentido?”
🧠 O passado não deveria votar sobre o próximo passo
Essa frase merece destaque:
O passado explica como chegamos aqui. Não deveria decidir sozinho para onde vamos.
Cada ponto de decisão deveria considerar:
estado atual;
informação atual;
risco atual;
opções atuais.
Mas humanos carregam o investimento anterior.
Emoção chama isso de:
“Não desperdiçar.”
Engenharia deveria perguntar:
“Qual é o menor risco daqui para frente?”
👻 Easter Egg nº 1 — O corredor interminável
Imagine Doctor Who.
O Doctor e seus companions estão correndo por um corredor.
Companion:
— Estamos correndo há vinte minutos.
Doctor:
— Sim.
— Não deveríamos voltar?
— Não! Já corremos vinte minutos nesta direção.
Isso seria obviamente absurdo.
Se descobrirmos que o monstro está na frente, o fato de termos corrido vinte minutos não é argumento para continuar.
Mas em projetos e mudanças fazemos exatamente isso.
Com PowerPoint.
🧲 Anchoring Bias encontra Plan Continuation Bias
Plano original:
realizar migração Big Bang.
Isso vira âncora.
Depois surgem problemas.
A equipe continua interpretando tudo em torno da premissa:
a migração acontecerá hoje.
Não pergunta:
“Ainda deveria?”
Pergunta apenas:
“Como conseguimos terminar?”
Percebe a diferença?
A própria existência do plano passou a ser tratada como fato.
🔎 Confirmation Bias ajuda a manter o plano vivo
A equipe quer continuar.
Então começa a valorizar:
etapas que funcionaram;
métricas positivas;
evidências de progresso.
E minimizar:
warnings;
diferenças;
atrasos;
riscos.
Exemplo:
18 VALIDAÇÕES OK
2 WARNINGS
Alguém:
— Dezoito deram certo.
Excelente.
Mas e se um dos dois warnings for crítico?
Quantidade de indicadores verdes não anula semanticamente um vermelho.
👥 Groupthink aumenta a pressão
Gerente:
— Acho que devemos continuar.
Especialista:
— Também.
Outro:
— Já chegamos longe demais.
Agora o analista que pensa em rollback observa:
todo mundo concordando.
Ele começa a duvidar.
Groupthink transforma persistência em consenso.
🪜 Authority Gradient fecha a armadilha
Agora imagine que o diretor está presente.
— Precisamos concluir hoje.
O júnior pensa:
“Deveríamos rollbackar.”
Mas não fala.
Ou fala suavemente:
— Talvez fosse interessante considerar...
Ninguém reage.
Continuação.
Temos:
PLAN CONTINUATION BIAS
+
GROUPTHINK
+
AUTHORITY GRADIENT
=
“VAMOS SÓ TERMINAR”
Esse trio merece respeito.
🧀 E o Swiss Cheese?
Cada decisão de continuar pode abrir mais um buraco.
Exemplo:
barreira 1:
janela operacional.
Ultrapassada.
barreira 2:
reconciliação.
Incompleta.
barreira 3:
validação.
Parcial.
barreira 4:
rollback.
Cada vez menos tempo.
barreira 5:
equipe.
Cansada.
Os buracos começam a se alinhar.
Observe que o acidente talvez não tenha uma decisão absurda.
Tenha apenas várias decisões individualmente compreensíveis de:
“mais um pouco.”
🚨 O perigo do “mais um passo”
Essa frase é irmã de:
“Só mais cinco minutos.”
“Vamos terminar esta etapa.”
“Já que chegamos até aqui...”
“Rollback agora seria pior.”
Às vezes são verdadeiras.
Mas precisam de evidência.
Não podem virar reflexo.
⏳ A janela operacional muda a qualidade da decisão
Imagine uma mudança entre:
00:00 e 04:00.
À 00:30, rollback possui três horas disponíveis.
Às 03:40, faltam vinte minutos.
Mesmo se o estado técnico fosse idêntico, o risco operacional mudou.
Logo:
um plano pode ser bom às 00:30 e ruim às 03:40.
Decisão precisa considerar tempo.
Tempo não é apenas relógio.
É parte do sistema.
🧠 Fadiga muda tudo
Às 01:00:
equipe fresca.
Às 05:00:
mesma equipe?
Biologicamente, não.
Cansaço afeta:
atenção;
memória;
decisão;
comunicação;
tempo de reação.
Plan Continuation Bias frequentemente ocorre justamente quando equipes estão mais cansadas.
Ou seja:
quanto mais precisamos reavaliar,
menos capacidade temos de reavaliar.
Maravilhoso.
💤 Easter Egg nº 2 — RC=00 às 04:59
Existe uma lei informal da operação:
um job que termina às 01:00 com RC=00 é agradável.
Um job que termina às 04:59 com RC=00, cinco minutos antes da abertura, recebe tratamento religioso.
Ninguém quer olhar demais.
Mas talvez seja justamente quando deveríamos.
🔥 Escalation of Commitment
Outro conceito relacionado é escalation of commitment.
A pessoa ou organização continua investindo numa decisão ruim porque já está comprometida com ela.
Exemplo:
projeto atrasado.
Mais dinheiro.
Continua atrasado.
Mais equipe.
Mais consultoria.
Mais integração.
Agora parar fica ainda mais doloroso.
Então continua.
Cada investimento aumenta pressão psicológica para justificar os anteriores.
É uma espiral.
🧮 Um programa não conhece sunk cost
COBOL não pensa:
IF HORAS-GASTAS > 8
CONTINUE-POR-ORGULHO
END-IF.
Seria um código curioso.
O sistema responde apenas ao estado presente.
Nós é que carregamos a história emocional do esforço.
💻 Exemplo COBOL: conversão de arquivo
Imagine uma migração.
Arquivo antigo:
100 milhões de registros.
Conversão inicia.
Depois de 85 milhões:
erros começam.
INVALID-DATE COUNT: 3
Continua.
90 milhões:
INVALID-DATE COUNT: 21
Continua.
95 milhões:
INVALID-DATE COUNT: 842
Alguém:
— Já processamos 95%.
Outro:
— Não faz sentido voltar.
Pergunta correta:
por que os erros estão crescendo?
Talvez os últimos 5% contenham dados históricos com formato diferente.
Talvez continuá-los cause milhares de corrupções.
95% completo não transforma os últimos 5% em seguros.
📈 Tendência importa mais que fotografia
Outro aprendizado.
Não olhe apenas:
ERROR COUNT = 842
Olhe:
85% → 3
90% → 21
95% → 842
Isso é uma tendência explosiva.
O estado está mudando.
Uma decisão baseada em dados de 85% já pode estar inválida.
🧠 Plano precisa ter hipóteses explícitas
Antes da mudança:
PREMISSA 1:
reconciliação ficará em zero.
PREMISSA 2:
tempo por etapa <= 30 min.
PREMISSA 3:
rollback disponível até 03:00.
PREMISSA 4:
erros críticos = zero.
Agora se uma premissa quebra:
reavaliar.
Isso é muito melhor que:
“vamos vendo.”
Porque define antecipadamente quando o plano deixa de ser o plano.
🛑 Abort Criteria
Uma ferramenta extraordinária:
critérios de aborto.
Antes de começar, defina:
ABORT IF:
- divergence > 0
- elapsed > X
- rollback margin < Y
- severity 1 condition appears
- validation Z fails
Por que antes?
Porque durante execução estaremos emocionalmente envolvidos.
Critérios definidos antes funcionam como proteção contra nosso eu futuro.
🚦 GO / HOLD / ROLLBACK
Talvez o mundo não precise ser apenas:
GO / NO-GO.
Podemos ter:
GO
Continuar.
HOLD
Parar temporariamente e investigar.
ROLLBACK
Retornar.
ABORT
Encerrar plano.
“HOLD” é especialmente útil.
Pessoas resistem menos a uma pausa que a um abandono definitivo.
E às vezes vinte minutos de HOLD evitam quatro horas de incidente.
🧠 Precommitment novamente
No episódio anterior vimos precommitment.
Aqui ele se torna central.
Antes:
“Se restarem menos de 45 minutos de rollback, voltamos.”
Durante:
03:16.
Faltam 44 minutos.
Sem debate emocional.
Rollback.
Claro que realidade pode exigir exceção.
Mas agora exceção precisa ser justificada.
Não continuidade.
🔄 Inverta o ônus da prova
Isso é poderoso.
Quando condição crítica ocorre, mude:
de:
“Por que deveríamos parar?”
para:
“O que prova que é seguro continuar?”
Essa inversão muda completamente a War Room.
Em condição normal:
continuação é default.
Após trigger crítico:
pausa é default.
Precisamos de evidência para retomar.
🕰️ Checkpoints obrigatórios
Plan Continuation Bias prospera quando um fluxo segue continuamente.
Crie checkpoints:
STEP 1
↓
CHECKPOINT
STEP 2
↓
CHECKPOINT
STEP 3
↓
CHECKPOINT
Em cada checkpoint:
Isso força reflexão.
☕ Bellacosa Mainframe: “checkpoint cognitivo”
Mainframeiro entende checkpoint.
Programas batch longos usam checkpoints para evitar reprocessamento completo.
Então por que decisões humanas não?
Imagine:
COGNITIVE CHECKPOINT
------------------------------
OBJECTIVE STILL VALID? Y/N
ASSUMPTIONS VALID? Y/N
NEW RISKS? Y/N
ROLLBACK POSSIBLE? Y/N
CONTINUE? Y/N
Simples.
Mas poderoso.
🔁 Restart também pode ser armadilha
No mainframe adoramos restart.
Job abenda.
Corrige.
Restart.
Excelente.
Mas cuidado.
Talvez a melhor decisão não seja restartar do ponto de falha.
Talvez dados anteriores tenham ficado inconsistentes.
Plan Continuation Bias pode aparecer assim:
“Só precisamos restartar.”
Pergunta:
o estado anterior ainda é confiável?
Restart pressupõe integridade do checkpoint.
Valide.
🧩 O problema do “quase pronto”
“Quase pronto” não possui valor técnico universal.
Um processo pode estar:
99% completo;
e ainda ser 0% utilizável.
Exemplo:
migração financeira.
99,9% das contas migradas.
0,1% incorretas.
Pode ser inaceitável.
Percentual de progresso e percentual de segurança são coisas diferentes.
🧠 Completion Bias
Existe ainda uma tendência humana a gostar de completar tarefas.
Checklist quase terminado incomoda.
Queremos fechar.
Isso pode contribuir para continuar.
Último item.
Só falta um.
Mas o último pode ser exatamente:
validação crítica.
Não pule porque o cérebro quer o check verde.
📋 Checklist não é videogame
Checklist serve para controle.
Não para obter 100% de achievements.
Se item crítico falha, a meta não é marcar rapidamente.
É entender.
🚨 “Production is waiting”
Outra pressão:
produção esperando.
Usuários esperando.
Executivos esperando.
Mercado esperando.
Isso cria sensação de urgência.
Mas existe uma diferença entre:
urgência operacional
e
pressa cognitiva.
Urgência exige rapidez.
Pressa elimina pensamento.
🔎 O que mudou desde que o plano foi aprovado?
Pergunta extremamente útil:
“O que mudou desde a decisão original?”
Talvez:
volume;
dados;
horário;
infraestrutura;
dependência;
equipe;
risco;
rollback.
Se alguma condição mudou materialmente, decisão anterior precisa ser revalidada.
🧠 Decisão antiga não é autorização eterna
Change aprovado terça-feira.
Execução sábado.
Durante execução surge condição nova.
A aprovação não cobre automaticamente realidade desconhecida.
Governança não deveria dizer:
“Está aprovado, continue.”
Deveria dizer:
“Está aprovado dentro destas premissas.”
Se premissas mudam:
novo julgamento.
🏦 Em sistemas financeiros
Imagine batch de fechamento.
Processamento começou.
Diferença contábil aparece.
Mas fechamento precisa terminar até 06:00.
Equipe continua para “não perder janela”.
Agora talvez complete dentro do horário.
Com números errados.
O KPI foi cumprido.
A realidade não.
🔐 Em segurança
Migração de firewall.
Algumas regras não funcionam.
Equipe libera bypass temporário.
Agora está quase concluído.
Alguém percebe exposição.
Resposta:
— Terminamos primeiro e corrigimos amanhã.
Plan Continuation Bias.
Normalization of Deviance pode vir amanhã:
“Esse bypass ficou funcionando, nunca aconteceu nada...”
Olha nossos monstros se reproduzindo.
☁️ Cloud e deploy automatizado
Pipeline:
BUILD OK
UNIT TEST OK
DEPLOY OK
SMOKE TEST WARNING
TRAFFIC 25%
Equipe:
— Build e deploy deram certo.
Mas smoke test avisou.
O pipeline está dizendo:
pare.
Automação pode fornecer checkpoint objetivo.
Não transforme warning em decoração.
🤖 IA e agentes
Agora um exemplo moderno.
Agente recebe plano:
consultar dados;
gerar mudança;
executar;
validar.
Se durante passo 2 dados contradizem premissas, um agente mal projetado pode continuar porque seu workflow original manda.
Isso é quase um Plan Continuation Bias artificial.
Sistemas agentes precisam:
replanejamento;
condições de parada;
avaliação intermediária;
rollback;
confidence thresholds.
A mesma teoria aparece em humanos e máquinas.
🧠 O plano é uma hipótese sobre o futuro
Essa definição é maravilhosa:
Um plano é apenas uma hipótese sobre como o futuro deveria acontecer.
Ele diz:
Se fizermos A, depois B, provavelmente chegaremos a C.
Mas o futuro responde.
Se aparece:
D;
E;
Z;
o plano precisa aprender.
Não veneramos planos.
Usamos planos.
🗺️ Mapas não são território
O plano é mapa.
Produção é território.
Se o mapa diz:
existe ponte.
E você chega e a ponte caiu...
não avance com o carro porque:
“mas está desenhada no mapa.”
Atualize o plano.
👨💻 Dica para programador COBOL iniciante
Quando executar atividade longa, não pense apenas:
“Qual é o próximo passo?”
Pergunte periodicamente:
“Ainda devemos estar fazendo esta atividade?”
Essa pergunta é muito mais madura.
É possível executar perfeitamente um plano que não deveria mais existir.
🧪 Como detectar Plan Continuation Bias
Escute frases:
“Já chegamos até aqui.”
“Agora falta pouco.”
“Não podemos jogar tudo fora.”
“Só mais uma tentativa.”
“Vamos terminar e corrigir depois.”
“Rollback agora vai parecer ruim.”
“Já gastamos demais para parar.”
“Diretoria espera conclusão hoje.”
Acenda uma luz amarela.
Não significa que continuar seja errado.
Significa que motivos psicológicos podem estar substituindo razões técnicas.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Já investimos muito.”
Pergunte:
“Se estivéssemos começando agora, com as informações atuais, escolheríamos continuar?”
Essa pergunta é brutalmente poderosa.
Se resposta:
“não”...
talvez sunk cost esteja dirigindo.
🎯 Pergunta Bellacosa nº 2
Outra:
“O que precisaríamos ver para parar?”
Se resposta for:
“Nada.”
Problema.
Você não possui plano.
Possui compromisso incondicional.
🎯 Pergunta Bellacosa nº 3
E outra:
“Qual é nosso último ponto seguro de retorno?”
Todo profissional precisa saber.
Não descubra depois que passou.
🧠 Point of No Return
Algumas mudanças possuem ponto após o qual rollback fica:
impossível;
caro;
arriscado.
Esse ponto precisa ser explicitamente identificado.
Exemplo:
00:00 START
01:00 SAFE ROLLBACK
02:00 SAFE ROLLBACK
02:30 LAST SAFE ROLLBACK
03:00 FORWARD FIX ONLY
Às 02:25:
decisão crítica.
Não simplesmente:
“mais cinco minutos.”
🛑 Last Safe Moment
Um conceito muito útil:
último momento seguro para decidir.
Não confunda com último momento possível.
Você pode tecnicamente decidir às 02:59.
Mas talvez isso deixe um minuto de rollback.
Imprudente.
🧯 Forward Fix também pode ser âncora
Às vezes rollback é realmente pior.
Então seguimos com forward fix.
Tudo bem.
Mas precisamos saber:
por que?
Não porque:
“já estamos aqui.”
Mas porque:
“dados atuais mostram que forward fix possui risco menor que rollback.”
Essa é engenharia.
📊 Decision Log
Registre:
02:15
Issue: reconciliation divergence
Decision: HOLD
02:27
Cause identified: duplicate restart marker
Decision: fix and rerun validation
02:42
Validation clean
Decision: GO
Isso cria aprendizado.
Também revela quando decisões foram tomadas apenas por pressão.
🧠 Post-mortem sem Hindsight Bias
Depois que tudo dá errado, parecerá óbvio que deveríamos ter parado.
Cuidado.
Nosso velho Hindsight Bias retorna.
Pergunte:
“No momento da decisão, quais sinais estavam disponíveis?”
Talvez continuar fosse razoável às 02:00.
Irrazoável às 03:00.
Não pinte toda timeline com conhecimento posterior.
🔬 O momento de virada
Em post-mortem, procure:
quando continuar deixou de ser a melhor opção?
Esse é um ponto fascinante.
Não necessariamente quando incidente começou.
Pode ser quando:
premissa quebrou;
rollback ficou apertado;
warning apareceu;
validação falhou.
Essa é a fronteira decisória.
🧠 Decision Inertia
Mesmo quando percebemos que contexto mudou, pode existir inércia decisória.
Plano já está em movimento.
Parar exige ação.
Continuar exige apenas não interromper.
Isso cria assimetria.
É psicologicamente mais fácil:
não fazer nada e continuar.
Por isso triggers automáticos ajudam.
🚦 Default seguro
Imagine:
falhou validação crítica.
Pipeline automaticamente:
STATUS: HOLD
Agora alguém precisa autorizar continuar.
Muito melhor que pipeline continuar automaticamente e alguém precisar correr para pará-lo.
Design de defaults importa.
🧀 Uma nova fatia de queijo
Podemos criar uma barreira específica:
FATIA:
STOP CONDITIONS
Buracos possíveis:
Novamente, teoria encontra operação.
👥 Incident Commander como guardião do replanejamento
Durante crise, Incident Commander pode perguntar periodicamente:
“Objetivo ainda é o mesmo?”
“Plano ainda é válido?”
“Estamos continuando por evidência ou inércia?”
Isso é função poderosa.
Não apenas coordenar tarefas.
Coordenar decisão.
🪫 Energia organizacional também acaba
Depois de seis horas:
atenção cai.
Paciência cai.
Qualidade de comunicação cai.
Talvez decisão correta seja trocar equipe.
Handover.
Outro turno.
Fresh eyes.
Persistir com as mesmas pessoas porque:
“elas conhecem o problema”
pode ser útil.
Ou pode perpetuar tunnel vision.
👀 Fresh Eyes
Uma pessoa nova pergunta:
— Por que continuamos?
E ninguém consegue responder sem dizer:
“Porque começamos.”
Isso é diagnóstico.
Fresh eyes quebram Plan Continuation Bias.
🔁 Rotate the skeptic
Durante operação longa, designe alguém periodicamente para perguntar:
“Deveríamos continuar?”
Não precisa executar.
Seu papel é desafiar continuidade.
É quase um Devil’s Advocate temporal.
📋 Checklist anti-Plan Continuation Bias
Antes de seguir:
[ ] As premissas originais continuam válidas?
[ ] Alguma condição material mudou?
[ ] Ainda temos margem segura para rollback?
[ ] Estamos dentro da janela planejada?
[ ] Os warnings estão estáveis ou crescendo?
[ ] Estamos confundindo progresso com segurança?
[ ] Continuar é melhor que rollback ou apenas menos doloroso?
[ ] Se começássemos agora, escolheríamos este plano?
[ ] O que faria a equipe parar?
[ ] Essa condição já aconteceu?
Se a última resposta for sim...
talvez a decisão já esteja tomada.
Estamos apenas evitando admiti-la.
🧬 Regeneração organizacional
Depois de identificar Plan Continuation Bias, uma organização madura cria:
critérios de aborto;
checkpoints;
last safe moment;
decision logs;
HOLD automático;
rollback testado;
precommitment;
fresh eyes;
autoridade de STOP;
reavaliação explícita.
E muda a linguagem.
De:
“precisamos terminar”
para:
“precisamos escolher o menor risco a partir daqui.”
Isso é maturidade operacional.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Plan Continuation Bias é a tendência de continuar um plano mesmo quando novas informações indicam que ele deveria ser reconsiderado.
Progresso passado não prova que continuar é correto.
Custos já gastos não deveriam decidir investimentos futuros.
“Quase pronto” não significa “seguro”.
Tempo e fadiga mudam o contexto.
Planos precisam de critérios explícitos de parada.
Rollback precisa ser tratado como opção legítima, não como fracasso.
Checkpoints forçam reavaliação.
O plano é uma hipótese, não uma promessa.
Pergunte o que mudou desde a decisão original.
E principalmente:
Continuar porque ainda faz sentido é engenharia. Continuar porque já começamos é psicologia.
🕰️ De volta às 02:41
Nosso programador olha novamente:
UNMATCHED RECORDS: 247
Agora:
UNMATCHED RECORDS: 391
Ele respira.
Authority Gradient ainda existe.
Groupthink ainda ronda.
Mas ele aprendeu.
— Solicito HOLD.
O gerente olha.
— Agora?
— Sim.
— Falta pouco.
— Justamente. Nosso último ponto seguro de rollback é 03:00. Temos dezenove minutos. Os registros divergentes estão aumentando.
Silêncio.
O Doctor sorri ao fundo.
O especialista pergunta:
— Qual recomendação?
— Parar, entender a divergência e decidir em dez minutos. Se não explicarmos, rollback.
O gerente olha para o relógio.
— HOLD.
Todos param.
Investigação.
Descobrem que o próximo passo transformaria os registros inconsistentes em estado definitivo.
Rollback executado às 02:56.
Produção anterior restaurada.
Mudança adiada.
Às 03:11, ambiente está estável.
Ninguém gosta.
A madrugada inteira “foi perdida”.
O gerente suspira:
— Trabalhamos cinco horas e voltamos ao ponto de partida.
O Doctor responde:
— Não.
— Como não?
— À meia-noite vocês tinham um sistema funcionando e uma hipótese.
Aponta para os logs.
— Agora têm um sistema funcionando e conhecimento.
Pausa.
— Isso é progresso.
O gerente pensa.
Nosso programador bebe o café já frio.
Talvez tenha gosto de vitória.
Ou de café às três da manhã.
É difícil distinguir.
🥚 Easter Egg final
Na manhã seguinte aparece um membro novo:
BELLACOSA.BIAS(TARDIS)
Dentro:
IF PLAN-IS-WORKING
CONTINUE
ELSE
PERFORM REASSESS
END-IF.
IF ONLY-REASON = 'WE-CAME-THIS-FAR'
PERFORM STOP-AND-THINK
END-IF.
Comentário:
* THE DESTINATION DOES NOT MAKE THE ROAD SAFE.
Outro:
* TURNING BACK IS ALSO A DECISION.
E finalmente:
* SOMETIMES THE FASTEST WAY FORWARD
* IS TO STOP.
Nosso programador fecha o membro.
Horas depois alguém pergunta sobre a implantação cancelada:
— Deu errado?
Ele pensa alguns segundos.
Responde:
— Não exatamente.
— Como assim?
— Descobrimos que daria errado antes de cruzar o ponto onde não dava mais para voltar.
A pessoa parece decepcionada.
Nenhum desastre.
Nenhuma manchete.
Nenhuma madrugada heroica recuperando produção.
Apenas uma mudança interrompida.
Isso não rende histórias espetaculares.
Mas talvez seja exatamente o tipo de história que sistemas críticos precisam produzir com mais frequência.
A TARDIS desaparece ao longe.
VWORP.
VWORP.
VWORP.
No quadro da War Room fica escrita uma última pergunta:
“Se ainda não tivéssemos começado, escolheríamos continuar agora?”
Se a resposta for não...
talvez seja hora de parar.
☕🌀
Next stop: Alarm Fatigue — quando o sistema grita tantas vezes que, no dia em que realmente precisa ser ouvido, ninguém mais presta atenção.
