 |
| Bellacosa Mainframe e o sunk cost fallacy |
☕ Um Café no Bellacosa Mainframe
Sunk Cost Fallacy: Doctor Who, COBOL e o Dia em que Já Tínhamos Gastado Demais para Admitir que Era Hora de Parar
Uma viagem pela TARDIS dos incidentes para entender por que tempo, dinheiro, esforço e orgulho já investidos podem nos prender a decisões que deixaram de fazer sentido
23:48.
Sexta-feira.
Sala de mudança.
Café número três.
Projeto iniciado há oito meses.
Orçamento inicial:
R$ 2.000.000
Gasto até agora:
R$ 4.700.000
Prazo original:
6 meses
Tempo transcorrido:
8 meses
Funcionalidades concluídas:
63%
Integração crítica:
ainda instável.
Testes:
atrasados.
Rollback:
complexo.
O gerente olha para a apresentação.
— Precisamos terminar.
Nosso jovem programador COBOL pergunta:
— Ainda vale a pena?
Silêncio.
O diretor responde:
— Depois de quase cinco milhões gastos?
O jovem insiste:
— Justamente.
Outro gerente entra na conversa:
— Não podemos jogar todo esse investimento fora.
O especialista complementa:
— Falta pouco.
Nosso programador olha para:
63%
Não parece exatamente “pouco”.
Mas ninguém quer falar sobre abandonar o projeto.
Porque abandonar significaria admitir que:
o dinheiro já gasto não volta;
os meses já utilizados não voltam;
as noites extras não voltam;
as decisões passadas talvez não fossem tão boas quanto pareciam.
Então surge a frase fatal:
“Agora precisamos continuar para recuperar o investimento.”
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se atrás do projetor.
A porta abre.
O Doctor sai.
Olha para a planilha.
— Quanto dinheiro vocês já gastaram?
— Quase cinco milhões.
— E quanto desse dinheiro volta se vocês continuarem?
Silêncio.
— Nenhum.
— E quanto volta se vocês pararem?
— Nenhum.
O Doctor sorri.
— Excelente.
O diretor parece irritado.
— O que há de excelente nisso?
— Agora podemos finalmente parar de fingir que o dinheiro passado participa da próxima decisão.
Bem-vindo ao:
Sunk Cost Fallacy
Ou:
Falácia do Custo Afundado
A tendência de continuar investindo em uma decisão, projeto, sistema ou estratégia porque já investimos muito nela — mesmo quando os custos passados não podem mais ser recuperados e a melhor decisão daqui para frente seria parar, mudar ou recomeçar.
🌀 Nossa TARDIS dos incidentes já percorreu bastante terreno
Até aqui conhecemos:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios viram rotina.
Hindsight Bias — depois do acidente tudo parece óbvio.
Confirmation Bias — procuramos evidências para aquilo em que já acreditamos.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — grupos podem errar em conjunto.
Authority Gradient — hierarquia pode silenciar informação importante.
Plan Continuation Bias — continuamos um plano que já deveria ser revisto.
Alarm Fatigue — alertas demais viram ruído.
Automation Bias — confiamos demais na máquina.
Drift Into Failure — sistemas derivam lentamente para a borda.
Diffusion of Responsibility — todos veem e ninguém assume.
Normalcy Bias — esperamos que tudo volte ao normal.
Survivorship Bias — olhamos apenas para quem sobreviveu.
Base Rate Neglect — esquecemos as frequências reais.
Availability Heuristic — o que lembramos facilmente parece mais provável.
Outcome Bias — confundimos resultado com qualidade da decisão.
Overconfidence Bias — superestimamos o quanto sabemos.
Planning Fallacy — subestimamos tempo, esforço e complexidade.
Agora chegamos à armadilha seguinte:
depois de investir demais, passamos a usar o passado como argumento para continuar.
🧠 O que é um sunk cost?
Sunk cost significa:
custo afundado.
É algo que já foi gasto e não pode ser recuperado independentemente da decisão futura.
Pode ser:
dinheiro;
tempo;
horas de trabalho;
licenças;
infraestrutura;
treinamento;
consultoria;
energia;
reputação;
orgulho.
Exemplo:
você gastou R$ 1 milhão num projeto.
Esse milhão já foi gasto.
A pergunta racional agora não é:
“Como recuperamos o milhão?”
Mas:
“Dado o estado atual, vale a pena gastar o próximo real?”
Essa mudança de pergunta é gigantesca.
💰 O dinheiro passado não vota
Imagine:
JÁ GASTO: R$ 5 milhões
CUSTO PARA TERMINAR: R$ 4 milhões
VALOR ESPERADO DO SISTEMA: R$ 2 milhões
Alguém diz:
— Mas já gastamos cinco!
Isso não transforma os quatro milhões futuros em bom investimento.
O passado explica:
como chegamos aqui.
Ele não muda automaticamente:
a qualidade do próximo investimento.
☕ Bellacosa Mainframe: o projeto que não pode morrer
Todo profissional veterano já encontrou um projeto desses.
Projeto começou com:
“Estratégico.”
Depois virou:
“Prioridade da diretoria.”
Depois:
“Já investimos demais para cancelar.”
E finalmente:
“Agora precisamos terminar nem que seja só para provar que funciona.”
Nesse momento, talvez o projeto já não esteja sendo guiado por valor.
Está sendo guiado por passado.
🧠 Sunk Cost Fallacy versus Plan Continuation Bias
Eles são parentes próximos.
Mas há diferença.
Plan Continuation Bias
Continuamos o plano porque já estamos executando e existe inércia para seguir.
“Agora falta pouco.”
Sunk Cost Fallacy
Continuamos porque já investimos recursos irreversíveis.
“Já gastamos demais para parar.”
Frequentemente aparecem juntos.
▶️ A dupla perfeita
Planejamento:
6 meses.
Planning Fallacy:
subestimamos.
Depois de oito meses:
Plan Continuation Bias:
“Estamos quase lá.”
E:
Sunk Cost Fallacy:
“Já gastamos demais para desistir.”
Agora temos um projeto praticamente imortal.
👻 Easter Egg nº 1 — O corredor errado
Imagine Doctor Who.
Doctor e companion caminham por um corredor durante duas horas.
Companion:
— Doctor, acho que estamos indo para o lado errado.
Doctor:
— Talvez.
— Então voltamos?
— Não podemos.
— Por quê?
— Já caminhamos duas horas.
Companion olha.
— Isso parece uma péssima razão.
Exatamente.
O esforço passado não torna a direção correta.
🍿 O exemplo clássico do cinema
Você compra ingresso para um filme.
Depois de 30 minutos percebe:
é horrível.
Você pensa:
“Já paguei, vou assistir até o fim.”
Mas o dinheiro não volta se você ficar.
A decisão real é:
o que você prefere fazer com as próximas duas horas?
Ficar.
Ou sair.
O preço do ingresso já desapareceu.
Agora troque filme por projeto de TI.
Infelizmente, às vezes o ingresso custa R$ 20 milhões.
💻 COBOL e o programa impossível de salvar
Imagine um programa antigo.
18.000 linhas
900 IFs
120 GO TOs
35 copybooks
Projeto de modernização começa.
Após meses:
tentam adaptar.
Remendar.
Refatorar.
Mais remendos.
Já gastaram milhares de horas.
Um arquiteto diz:
— Talvez seja mais barato reescrever este módulo específico.
Resposta:
— Impossível. Já gastamos seis meses tentando corrigir esse.
Sunk Cost.
Os seis meses não diminuem o custo futuro do remendo.
Talvez justamente provem que a abordagem não funciona.
🧠 Esforço passado pode ser evidência — mas não obrigação
Essa nuance é importantíssima.
O passado pode ensinar.
Exemplo:
gastamos seis meses e descobrimos:
arquitetura muito complexa.
Isso é informação valiosa.
Mas não significa:
“portanto precisamos continuar.”
Pode significar:
“portanto precisamos parar.”
O custo passado é dado histórico.
Não justificativa automática.
🌀 Outcome Bias entra pela porta
Imagine projeto arriscado.
Depois de muito investimento, finalmente funciona.
Todos dizem:
“Viu? Valeu a pena continuar.”
Talvez.
Mas cuidado.
Os projetos que continuaram e falharam podem ter desaparecido.
Agora temos:
Outcome Bias;
Survivorship Bias;
Sunk Cost.
Uma bela família.
🧠 Survivorship Bias protege histórias de persistência
Adoramos histórias:
“Quase desistimos, mas persistimos e vencemos.”
São inspiradoras.
Mas onde estão:
“Persistimos por mais dois anos e perdemos mais R$ 50 milhões”?
Essas histórias recebem menos palestras.
Survivorship Bias faz persistência parecer mais inteligente do que talvez seja.
🎰 “Nunca desista” pode ser péssimo conselho
Existem momentos para persistir.
Existem momentos para parar.
A regra madura não é:
“Nunca desista.”
É:
“Continue enquanto o valor futuro justificar o custo futuro.”
Muito menos épico.
Muito mais útil.
🧠 Escalation of Commitment
Sunk Cost Fallacy costuma aparecer junto de algo chamado:
Escalation of Commitment
A tendência de aumentar investimento numa decisão anterior, especialmente quando surgem sinais de que ela talvez esteja errada.
Exemplo:
projeto atrasado.
Solução:
mais dinheiro.
Continua atrasado.
Mais equipe.
Mais consultoria.
Mais prazo.
Agora parar fica ainda mais doloroso.
O investimento adicional aumenta o sunk cost.
E o sunk cost aumenta pressão para investir ainda mais.
Círculo.
🔄 Espiral do compromisso
INVESTIMOS
↓
PROBLEMA
↓
INVESTIMOS MAIS
↓
SUNK COST AUMENTA
↓
FICA MAIS DIFÍCIL PARAR
↓
INVESTIMOS MAIS
Um projeto pode continuar não porque melhora.
Mas porque abandonar ficou emocionalmente insuportável.
☕ O ego entra no orçamento
Às vezes o custo afundado não é dinheiro.
É:
reputação.
Diretor patrocinou projeto.
Cancelar pode parecer:
admitir erro.
Então projeto continua.
Nesse caso:
o próximo milhão pode estar protegendo uma decisão passada.
Não criando valor futuro.
🧠 Identity Investment
Quanto mais uma pessoa associa sua identidade a uma decisão:
“meu projeto”;
“minha arquitetura”;
“minha estratégia”;
mais difícil abandoná-la.
Agora crítica ao projeto pode parecer crítica à pessoa.
Isso aumenta escalada de compromisso.
🪜 Authority Gradient
Se o projeto pertence ao diretor:
quem diz:
“precisamos cancelar”?
O júnior?
O fornecedor?
O gerente que foi promovido pelo projeto?
Authority Gradient torna sunk cost organizacional ainda mais perigoso.
👥 Groupthink
Diretor quer continuar.
Gerentes concordam.
Ninguém quer ser a voz:
“Talvez devêssemos encerrar.”
Agora consenso social reforça investimento.
Groupthink transforma sunk cost em estratégia coletiva.
🔎 Confirmation Bias
Depois de investir milhões:
equipe começa a procurar evidências de que projeto ainda vai dar certo.
Qualquer pequena vitória:
“Viu? Estamos avançando.”
Problemas:
“normais.”
Críticas:
“pessimismo.”
Confirmation Bias protege o investimento emocional.
⚓ Anchoring Bias
Estimativa inicial:
R$ 2 milhões.
Mesmo quando custo vira R$ 8 milhões, pessoas continuam pensando:
“projeto de dois milhões que atrasou.”
Não.
Agora é outro projeto econômico.
A âncora original ficou obsoleta.
🧠 Planning Fallacy volta
Projeto foi estimado em seis meses.
Depois de seis:
faltam dois.
Depois de oito:
faltam dois.
Depois de dez:
faltam dois.
A famosa:
síndrome dos 90% concluídos.
Projeto permanece 90% pronto por dois anos.
😄 Easter Egg nº 2 — “90% complete”
Existe uma velha piada em software:
Os primeiros 90% do código consomem 90% do tempo.
Os últimos 10% consomem os outros 90%.
Planning Fallacy encontra matemática corporativa alternativa.
🚨 O “quase pronto” é combustível do sunk cost
Se projeto está:
90% completo,
parar parece absurdo.
Mas talvez os últimos 10% contenham:
integração;
performance;
segurança;
migração;
dados;
produção.
Ou seja:
o trabalho mais difícil.
Percentual de conclusão pode ser ilusão.
📊 Percent Complete é perigoso
Pergunte:
90% de quê?
Linhas de código?
Funcionalidades?
Valor?
Risco?
Você pode ter:
CODING: 95%
TESTING: 20%
MIGRATION: 0%
PRODUCTION READINESS: 10%
“90% pronto” vira frase de PowerPoint.
💾 Mainframe: migração parcialmente concluída
Imagine migração de 100 aplicações.
80 migradas.
20 restantes são:
as mais complexas;
mais críticas;
mais acopladas.
Alguém diz:
— Já migramos 80%, não podemos parar.
Mas talvez os últimos 20% custem mais que os primeiros 80.
Quantidade não representa esforço futuro.
🧠 Cost-to-Go
Essa é uma ideia central.
Em vez de olhar:
Cost Spent
olhe:
Cost-to-Go
Quanto falta gastar daqui para frente?
E:
Value-to-Go
Quanto valor ainda podemos obter?
A decisão deve olhar para o futuro.
📊 Uma conta simples
Projeto A:
GASTO:
R$ 10 milhões
FALTA:
R$ 5 milhões
VALOR FUTURO:
R$ 20 milhões
Continuar pode fazer sentido.
Projeto B:
GASTO:
R$ 10 milhões
FALTA:
R$ 8 milhões
VALOR FUTURO:
R$ 3 milhões
O fato de ambos terem gasto R$ 10 milhões não significa mesma decisão.
O sunk cost é igual.
O futuro não.
🧠 Expected Future Value
Pergunta madura:
“Qual o benefício esperado daqui para frente?”
Não:
“Quanto já gastamos?”
Claro que custo histórico importa para aprendizado e governança.
Mas não deveria dominar a decisão marginal.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Já investimos muito para parar.”
Pergunte:
“Se ainda não tivéssemos investido nada, começaríamos este projeto hoje nas condições atuais?”
Essa é brutalmente eficiente.
Se resposta for não:
sunk cost provavelmente está presente.
🎯 Pergunta Bellacosa nº 2
Outra:
“Qual é o custo daqui para frente?”
🎯 Pergunta Bellacosa nº 3
Outra:
“Qual valor futuro justifica esse custo?”
🎯 Pergunta Bellacosa nº 4
E:
“Estamos tentando criar valor ou justificar decisões antigas?”
Essa pergunta pode deixar a sala silenciosa.
Às vezes silêncio é útil.
🛑 Stop-loss
Finanças conhecem um conceito útil:
stop-loss.
Definir antecipadamente um ponto de saída.
Em projeto:
SE custo > X
SE prazo > Y
SE hipótese de valor falhar
SE condição crítica não for atendida
→ REAVALIAR
Não necessariamente cancelar automaticamente.
Mas parar e decidir novamente.
🧠 Kill Criteria
Podemos chamar:
Kill Criteria
Antes de começar:
“Em quais condições encerraremos?”
Isso é poderoso.
Porque depois de investir:
ficamos emocionalmente comprometidos.
Definir antes reduz viés.
☕ Bellacosa Mainframe: critérios antes do café virar intravenoso
Projeto começa.
Defina:
STOP / REASSESS IF:
- custo exceder 150%
- performance target falhar
- integração crítica inviável
- benefício econômico cair abaixo de X
- prazo ultrapassar Y
Agora você possui saída digna.
🧠 Precommitment
Outra vez.
Decisões prévias protegem nosso eu futuro.
Antes:
somos relativamente neutros.
Depois de milhões gastos:
não.
Precommitment cria estrutura.
🚦 Stage Gates
Projetos grandes podem ter pontos formais:
DISCOVERY
↓
GATE
PROTOTYPE
↓
GATE
BUILD
↓
GATE
MIGRATION
↓
GATE
Em cada gate:
ainda vale continuar?
Não:
já começamos, então prossiga.
🧠 Business Case não é documento fossilizado
Projeto aprovado em 2024.
Em 2026:
mercado mudou.
Tecnologia mudou.
Custos mudaram.
Business case precisa ser atualizado.
Não diga:
“Foi aprovado.”
Pergunte:
“Ainda é válido?”
📈 Opportunity Cost
Outro conceito central.
Continuar num projeto ruim não custa apenas dinheiro nele.
Custa:
o que você deixa de fazer com os mesmos recursos.
Equipe presa seis meses aqui.
Não trabalha em projeto melhor.
Esse é custo de oportunidade.
☕ O recurso mais caro pode ser o tempo
R$ 1 milhão pode voltar em receita futura.
Seis meses perdidos:
não voltam.
Especialmente em tecnologia.
Enquanto você insiste:
concorrente avança;
sistema envelhece;
equipe cansa.
Opportunity cost precisa entrar.
🪫 Burnout como sunk cost escondido
Projeto atrasado.
Equipe trabalhando noites.
Direção pensa:
já investimos muito esforço.
Então exige mais.
Agora sunk cost financeiro começa a consumir pessoas.
Muito perigoso.
Não use sacrifício anterior como justificativa para sacrifício futuro.
🧠 “Depois de tudo que fizemos...”
Essa frase é emocionalmente poderosa.
“Depois de todo esforço da equipe, não podemos cancelar.”
Talvez cancelar seja justamente respeitar o esforço e impedir desperdício adicional.
O trabalho passado continua tendo valor de aprendizado.
Mesmo se projeto acabar.
🧬 Knowledge is not wasted
Cancelar projeto não significa que tudo foi desperdiçado.
Você pode preservar:
código;
pesquisa;
POCs;
documentação;
aprendizado;
componentes reutilizáveis.
Sunk cost pode virar conhecimento.
Mas não precisa virar prisão.
👨💻 COBOL iniciante: jogar código fora dói
Você passa dois dias numa solução.
Descobre abordagem melhor.
Mas pensa:
“Não vou jogar fora dois dias.”
Então gasta outros cinco tentando salvar.
Todos nós fazemos isso.
A pergunta:
“Se eu visse essas duas soluções agora, sem saber qual escrevi, qual escolheria?”
Essa técnica remove ego e sunk cost.
🔀 Branch mental
Imagine:
Solução A:
já tem 2 dias investidos.
Precisa de mais 5.
Solução B:
zero investido.
Precisa de 2.
Escolha racional:
B.
Mas cérebro diz:
A.
Porque quer recuperar os dois dias.
Não consegue.
Eles já foram gastos.
🐛 Debugging e sunk cost
Você investiga hipótese Db2 por duas horas.
Nenhuma evidência.
Mas pensa:
“Agora vou até o fim.”
Porque abandonar parece admitir que perdeu duas horas.
Resultado:
mais três horas.
Melhor:
timebox.
⏱️ Hypothesis Timebox
Exemplo:
HIPÓTESE:
DB2
TIMEBOX:
20 MIN
SE EVIDÊNCIA FOR FRACA:
ROTACIONAR
Isso combate sunk cost durante incidentes.
🧠 Investigation Sunk Cost
Quanto mais tempo investigamos uma hipótese:
mais difícil abandoná-la.
Isso é uma forma pequena e muito prática de Sunk Cost Fallacy.
War Rooms sofrem disso diariamente.
⚓ Anchoring + Sunk Cost
Primeira hipótese:
rede.
Investe uma hora.
Agora existe:
âncora;
mais custo investido.
Muito mais difícil mudar para MQ.
Por isso checkpoints de hipótese são valiosos.
🔎 Confirmation Bias fica mais forte com investimento
Depois de horas:
qualquer sinal de rede parece:
“Finalmente!”
Mesmo que fraco.
Porque queremos justificar tempo gasto.
Isso é comportamento humano.
Não incompetência.
Processos devem compensar.
🧠 Escalation of Commitment em incidentes
Restart não funcionou.
Tenta novamente.
Depois terceira vez.
— Agora vai.
Por quê?
Porque já investimos.
Talvez devêssemos mudar abordagem.
😄 A definição Bellacosa do insanity loop
RESTART
↓
NÃO FUNCIONOU
↓
RESTART DE NOVO
↓
NÃO FUNCIONOU
↓
“VAMOS TENTAR MAIS UMA VEZ”
Talvez não seja troubleshooting.
Talvez seja religião.
🤖 IA e Sunk Cost Fallacy
Você investe meses numa solução de IA.
Modelo não entrega valor.
Mas empresa continua:
“Já gastamos muito.”
Tecnologia nova torna isso ainda mais comum porque existe hype, reputação e expectativa.
Pergunta permanece:
começaríamos hoje?
🧠 Vendor Lock-in psicológico
Não apenas lock-in técnico.
Empresa investiu:
licenças;
treinamento;
integrações.
Agora trocar fornecedor parece admitir desperdício.
Talvez manter seja correto.
Mas sunk cost não pode ser único argumento.
Avalie TCO futuro.
☁️ Cloud migration
Projeto de migração começa.
Descobre que algumas cargas são mais baratas on-premises.
Mas estratégia era:
“Tudo para cloud.”
Já investimos muito.
Então movemos mesmo assim.
Isso pode ser sunk cost + commitment to narrative.
Tecnologia deveria servir objetivo.
Não slogan.
🧠 Mainframe também
O contrário também pode acontecer.
“Já investimos décadas no mainframe, então tudo deve permanecer nele.”
Também é sunk cost.
A pergunta correta:
qual workload faz mais sentido onde?
Nem cloud por fé.
Nem mainframe por nostalgia.
Arquitetura é decisão presente.
☕ Isso é muito Bellacosa
Mainframe não precisa ser defendido com:
“já temos.”
Pode ser defendido quando:
performance;
custo;
segurança;
disponibilidade;
proximidade dos dados;
economia
fazem sentido.
Se não fizerem:
questione.
A melhor defesa de uma tecnologia é valor atual.
Não custo histórico.
🧠 Technology Tribalism
Sunk Cost pode virar identidade tecnológica:
“Somos Java.”
“Somos mainframe.”
“Somos cloud-first.”
“Somos SAP.”
Isso pode impedir decisões melhores.
Arquitetura madura pergunta:
qual ferramenta resolve este problema?
📊 TCO e sunk cost
Total Cost of Ownership futuro deve incluir:
operação;
licenças;
staff;
migração;
risco;
manutenção.
Custo passado:
registro financeiro.
Custo futuro:
decisão.
Não misture.
🚨 Segurança e sunk cost
Controle antigo custou milhões.
Nova arquitetura torna-o obsoleto.
Organização mantém porque:
foi caro.
Isso não o torna eficaz.
Security theater pode sobreviver décadas graças a sunk costs institucionais.
📋 Governance
Board precisa perguntar:
“Estamos mantendo isso porque funciona ou porque custou caro?”
Excelente pergunta.
🧠 Normalcy Bias
Projeto sempre recebe mais um trimestre.
Normalcy Bias:
vai melhorar.
Sunk Cost:
já gastamos demais.
Plan Continuation:
falta pouco.
Trio perigoso.
🌀 Drift Into Failure
Projeto ruim consome:
dinheiro;
pessoas;
atenção.
Outros sistemas recebem menos manutenção.
Agora insistência local cria risco global.
Sunk Cost pode alimentar Drift Into Failure em outras áreas.
👥 Diffusion of Responsibility
Projeto continua porque ninguém possui autoridade clara para cancelar.
Todo mundo acha:
decisão é do steering committee.
Steering acha:
sponsors querem.
Sponsors:
equipe técnica recomenda.
Ninguém encerra.
Responsabilidade diluída mantém sunk cost vivo.
🎯 Pergunta Bellacosa nº 5
“Quem possui autoridade real para dizer STOP?”
Se resposta não estiver clara:
temos outro risco.
🧠 Face-saving
Cancelar decisão pública pode gerar constrangimento.
Então líderes podem preferir gastar mais a admitir erro.
Isso é chamado em vários contextos de proteção de face.
Cultura madura precisa tornar mudança de rumo aceitável.
🛡️ Cancelar bem é competência
Uma organização deve celebrar:
projeto encerrado cedo após hipótese invalidada.
Isso economiza dinheiro.
Não é fracasso.
É:
detecção antecipada.
🧪 Fail Fast — com significado real
“Fail fast” virou clichê.
Mas aqui faz sentido:
descobrir cedo que hipótese não funciona.
Não:
produzir software ruim rapidamente.
A meta:
baratear aprendizado.
📈 Real Options
Você pode estruturar projetos para investir progressivamente.
Primeiro:
pequena aposta.
Depois:
evidência.
Depois:
mais investimento.
Isso reduz risco de grandes sunk costs antes de descobrir inviabilidade.
🔬 POC antes da fábrica
Antes de gastar R$ 20 milhões:
POC de R$ 100 mil.
Descobre limitação.
Excelente.
Alguns chamam:
“POC fracassou.”
Não.
POC cumpriu missão.
Descobriu cedo.
☕ A melhor falha custa barato
Uma das melhores frases para esta série:
Falhe enquanto o erro ainda cabe numa reunião pequena.
Não quando precisa de conselho, jurídico e imprensa.
🧠 Reversible versus Irreversible Decisions
Decisões reversíveis:
experimente.
Irreversíveis:
mais rigor.
Quanto mais caro for voltar:
mais importante evitar sunk cost psicológico futuro.
🔄 Exit Strategy
Antes de começar:
qual saída?
Projeto.
Contrato.
Tecnologia.
Migração.
Se não existe saída:
risco aumenta.
📋 Checklist anti-Sunk Cost
[ ] Quanto já gastamos?
[ ] Quanto desse gasto é recuperável?
[ ] Quanto ainda precisamos gastar?
[ ] Qual valor futuro esperamos?
[ ] Se começássemos hoje, faríamos igual?
[ ] Existem alternativas melhores agora?
[ ] Estamos continuando para criar valor ou justificar o passado?
[ ] Qual é o custo de oportunidade?
[ ] Qual é nosso kill criterion?
[ ] Quem pode interromper?
[ ] O business case ainda é válido?
[ ] A equipe está sendo usada como buffer?
[ ] Estamos confundindo persistência com competência?
[ ] Que conhecimento podemos preservar se pararmos?
🧪 Passo a passo para combater Sunk Cost Fallacy
Passo 1 — Separe passado e futuro
Colunas diferentes.
Passo 2 — Calcule cost-to-go
Quanto ainda falta?
Passo 3 — Recalcule value-to-go
Quanto valor ainda existe?
Passo 4 — Ignore temporariamente o gasto histórico
Pergunte:
começaríamos hoje?
Passo 5 — Liste alternativas
Talvez exista solução melhor agora.
Passo 6 — Considere custo de oportunidade
O que deixamos de fazer?
Passo 7 — Use stage gates
Reavalie formalmente.
Passo 8 — Crie kill criteria
Antes do apego emocional.
Passo 9 — Permita cancelamento sem caça às bruxas
Senão ninguém encerra nada.
Passo 10 — Preserve aprendizado
Parar não precisa apagar conhecimento.
📊 Decision Board
Uma tela simples:
PAST SPEND:
R$ 5M
COST TO GO:
R$ 4M
EXPECTED VALUE:
R$ 2.5M
ALTERNATIVE COST:
R$ 1.5M
ALTERNATIVE VALUE:
R$ 5M
Agora a decisão fica mais clara.
Não agradável.
Mas clara.
🧠 Uma decisão pode ter sido boa no passado e ruim agora
Importantíssimo.
Talvez iniciar projeto tivesse sido racional.
Circunstâncias mudaram.
Hoje parar pode ser racional.
Isso não significa:
decisão inicial foi estúpida.
Essa distinção reduz ego.
🌀 Hindsight Bias
Depois de cancelar:
“Nunca deveríamos ter começado.”
Talvez não.
Cuidado.
Com dados disponíveis na época, talvez fosse boa aposta.
O mundo mudou.
Ou descobrimos coisas.
Decisões têm tempo.
🧠 Dynamic Decision Quality
Uma decisão pode ser:
boa em janeiro;
ruim em agosto.
Reavaliar não é contradição.
É adaptação.
💻 COBOL: solução temporária virou projeto
Você cria workaround.
Funciona.
Investe tempo.
Depois arquitetura muda.
Agora workaround não faz mais sentido.
Mas:
“já investimos tanto nesse framework.”
Talvez esteja na hora de deletar.
Deletar código também é engenharia.
🗑️ Código removido não é trabalho perdido
Se uma rotina foi útil por cinco anos e depois apagada:
cumpriu sua função.
Software não precisa viver eternamente para justificar seu custo.
👻 Easter Egg nº 3 — Time Lords e apego
Companion:
— Doctor, você vai destruir essa máquina depois de passar três episódios construindo-a?
Doctor:
— Sim.
— Mas você trabalhou tanto!
— E?
— Não dói?
— Muito.
Pausa.
— Ainda assim ela continua sendo uma péssima ideia.
Isso é maturidade.
🧠 Em incidentes: quando parar uma investigação
War Room.
Hipótese:
network.
Tempo:
90 minutos.
Evidência:
nenhuma.
Não diga:
“já investimos 90 minutos.”
Diga:
“temos evidência suficiente para continuar?”
Se não:
rotacione.
📍 Hypothesis Board
NETWORK
TIME SPENT: 20m
CONFIDENCE: 40%
After 20m:
EVIDENCE: weak
CONFIDENCE: 15%
ACTION:
DEPRIORITIZE
A confiança deve cair com evidência fraca.
Não subir porque gastamos tempo.
🧠 Learning Value
Às vezes continuar investigação ainda faz sentido não porque hipótese principal seja provável, mas porque informação obtida tem valor.
Ótimo.
Declare isso.
“Vamos gastar mais 20 min porque o teste elimina três hipóteses.”
Agora existe valor futuro.
Não sunk cost.
💸 Orçamento anual e “use it or lose it”
Outro comportamento curioso.
Área recebeu orçamento.
Final do ano sobra.
Gasta porque:
senão perdemos ano que vem.
Não é exatamente sunk cost clássico, mas mostra como estruturas de incentivo podem criar gastos desconectados de valor.
Economia comportamental mora em toda organização.
🧠 Incentivos criam vieses sistemáticos
Se cancelar projeto prejudica carreira:
ninguém cancela.
Se terminar projeto ruim dá bônus:
todos terminam.
Viés individual vira comportamento institucional.
🏛️ Governance saudável
Board deveria premiar:
decisões de parar bem fundamentadas;
aprendizado;
reallocação de capital.
Não apenas:
quantos projetos chegaram ao fim.
Porque conclusão não é sinônimo de valor.
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Sunk Cost Fallacy é a tendência de continuar porque já investimos recursos irrecuperáveis.
Custos passados não devem dominar decisões futuras.
A pergunta correta é: vale investir o próximo recurso?
Sunk Cost frequentemente alimenta Escalation of Commitment.
Planning Fallacy cria atrasos; Sunk Cost dificulta abandonar o plano.
Plan Continuation Bias aparece quando o plano já está em execução.
Survivorship Bias torna histórias de persistência bem-sucedida mais visíveis que os fracassos.
Outcome Bias pode transformar persistência sortuda em “boa estratégia”.
Cost-to-go e value-to-go são mais úteis para decisão futura que gasto histórico.
Kill criteria e stage gates ajudam.
Cancelar cedo pode ser competência.
E principalmente:
O dinheiro, o tempo e o café de ontem já foram consumidos. A única coisa que ainda podemos decidir é o que fazer com o próximo real, a próxima hora e a próxima xícara.
🕰️ De volta à reunião
Projeto:
GASTO:
R$ 4.7M
FALTA:
estimativa R$ 3.2M
VALOR ATUAL ESPERADO:
R$ 1.8M
O diretor repete:
— Já gastamos quase cinco milhões.
Nosso programador responde:
— Eu sei.
— Então precisamos terminar.
— Por quê?
— Para não perder o investimento.
O Doctor pergunta:
— O investimento volta?
— Não.
— Então já foi perdido como caixa.
Silêncio.
O programador abre outra opção:
OPÇÃO B
REAPROVEITAR:
componentes existentes
CUSTO:
R$ 1.1M
VALOR:
R$ 4M
O diretor olha.
— Então você quer cancelar?
— Quero decidir entre A e B olhando para amanhã.
Não para ontem.
A reunião fica longa.
Desconfortável.
Finalmente:
projeto A encerrado.
Parte do código reaproveitada.
Equipe realocada.
Novo plano.
Ninguém comemora muito.
Cancelar não tem a adrenalina de um go-live.
Seis meses depois:
a solução alternativa entra em produção.
Custo total menor que o restante previsto do projeto original.
O diretor encontra o programador.
— Ainda dói pensar nos cinco milhões.
Ele responde:
— Claro.
— Então não foram desperdiçados?
Nosso jovem pensa.
— Parte talvez tenha sido.
Pausa.
— Mas gastar mais só para evitar admitir isso teria desperdiçado ainda mais.
O Doctor sorri.
— Finalmente.
VWORP.
VWORP.
VWORP.
🥚 Easter Egg final
Na manhã seguinte surge:
BELLACOSA.BIAS(SUNKCOST)
Dentro:
IF MONEY-SPENT > ZERO
CONTINUE
END-IF.
IF FUTURE-VALUE < FUTURE-COST
PERFORM REASSESS
END-IF.
IF ONLY-REASON-TO-CONTINUE =
'WE-SPENT-TOO-MUCH'
PERFORM STOP-AND-THINK
END-IF.
O programador encara o primeiro IF.
Sorri.
— Esse CONTINUE está perfeito.
Outro comentário:
* YESTERDAY'S MONEY
* CANNOT PAY TOMORROW'S VALUE.
Outro:
* PERSISTENCE IS NOT A BUSINESS CASE.
E naturalmente:
* BAD WOLF ALREADY PAID.
Nosso jovem fecha o membro.
Pouco depois recebe mensagem:
“Estamos investigando rede há duas horas. Queremos tentar mais um teste.”
Ele pergunta:
— Que nova evidência justifica?
Resposta:
— Nenhuma, mas já investimos bastante.
Nosso programador olha para a tela.
Sorri.
— Então o tempo investido está tentando tomar a próxima decisão.
— Como assim?
— Vamos voltar aos dados.
A hipótese de rede é abandonada.
Dez minutos depois encontram o problema numa aplicação downstream.
Nenhuma magia.
Nenhum heroísmo.
Apenas uma decisão pequena:
parar de pedir ao passado permissão para mudar de ideia.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room permanece:
Não continue para justificar aquilo que já gastou. Continue apenas se aquilo que ainda pode ganhar justificar aquilo que ainda terá de gastar.
☕🌀
Next stop: Status Quo Bias — quando mudar parece tão arriscado que continuamos usando um processo ruim principalmente porque ele já está lá, funciona “mais ou menos” e ninguém quer ser a pessoa que mexeu nele.
