 |
| Bellacosa Mainframe e o planning fallacy |
☕ Um Café no Bellacosa Mainframe
Planning Fallacy: Doctor Who, COBOL e o Dia em que uma Mudança de Seis Horas Foi Planejada para Quarenta Minutos
Uma viagem pela TARDIS dos incidentes para entender por que subestimamos tempo, esforço, riscos e complexidade — mesmo quando temos um histórico inteiro dizendo que estamos sendo otimistas demais
Segunda-feira.
10:02.
Sala de planejamento.
Café número um.
Nenhum incidente.
Nenhuma pressão.
Ainda.
Na tela:
MUDANÇA:
ALTERAÇÃO DE REGRA DE CÁLCULO
ATIVIDADES:
1. Deploy COBOL
2. Bind Db2
3. Restart CICS
4. Validação
5. Reconciliação
6. Liberação
TEMPO ESTIMADO:
40 minutos
Nosso jovem programador COBOL olha para a planilha.
Depois olha para o especialista.
— Quarenta minutos?
— Sim.
— Quanto levou a última mudança parecida?
Silêncio.
Alguém consulta o histórico.
ÚLTIMA: 4h17
ANTERIOR: 5h02
ANTERIOR: 3h48
ANTERIOR: 6h11
Nosso programador franze a testa.
— Então por que quarenta minutos?
O gerente responde:
— Porque agora conhecemos o processo.
O especialista complementa:
— Da última vez tivemos problemas excepcionais.
Outro:
— Desta vez vai ser mais simples.
Nosso jovem olha novamente para a tabela.
Quatro mudanças anteriores.
Todas muito acima de quarenta minutos.
Mas a reunião continua.
10:37.
Plano aprovado.
Janela:
00:00 → 01:00
Uma hora.
Porque quarenta minutos deixam vinte de margem.
Perfeito.
Ou quase.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se atrás do projetor.
A porta abre.
O Doctor sai.
Olha para a planilha.
Depois para os tempos históricos.
Depois para:
ESTIMATIVA: 40 MIN
— Interessante.
O gerente pergunta:
— Algum problema?
— Talvez.
O Doctor aponta para as quatro execuções anteriores.
— Vocês têm quatro experiências reais dizendo aproximadamente quatro a seis horas.
Depois aponta para a estimativa.
— E uma experiência imaginária dizendo quarenta minutos.
Pausa.
— E decidiram confiar na imaginária.
Bem-vindo ao:
Planning Fallacy
Ou:
Falácia do Planejamento
A tendência humana de subestimar quanto tempo, esforço, dinheiro ou recursos uma atividade futura exigirá — mesmo quando experiências anteriores mostram repetidamente que tarefas semelhantes levam mais tempo.
🌀 A TARDIS já percorreu uma longa estrada
Nossa série começou estudando como sistemas falham.
Depois descobrimos algo muito mais interessante:
sistemas falham também porque seres humanos possuem maneiras previsíveis de interpretar mal a realidade.
Já conhecemos:
Swiss Cheese Model — várias defesas podem falhar juntas.
Normalization of Deviance — desvios viram rotina.
Hindsight Bias — o passado parece previsível depois.
Confirmation Bias — buscamos provas daquilo que acreditamos.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — grupos convergem rapidamente.
Authority Gradient — hierarquia pode silenciar informação.
Plan Continuation Bias — continuamos mesmo quando deveríamos parar.
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 sabem e ninguém assume.
Normalcy Bias — esperamos que tudo volte ao normal.
Survivorship Bias — estudamos apenas quem sobreviveu.
Base Rate Neglect — ignoramos frequências reais.
Availability Heuristic — o que lembramos facilmente parece mais provável.
Outcome Bias — confundimos resultado com qualidade da decisão.
Overconfidence Bias — acreditamos que sabemos e controlamos mais do que realmente sabemos.
Agora chegamos a um fenômeno especialmente importante para projetos, mudanças, migrações e incidentes:
subestimar sistematicamente o futuro.
🧠 O que é Planning Fallacy?
Imagine uma tarefa.
Você pensa:
“Se tudo correr normalmente, termino em duas horas.”
O problema está escondido numa expressão:
“se tudo correr normalmente.”
Seu plano mental costuma representar:
o caminho ideal;
sem interrupções;
sem erro;
sem retrabalho;
sem dependência indisponível;
sem atraso humano;
sem mudança de requisito;
sem aquela coisa misteriosa que acontece sempre às 03:17.
Ou seja:
planejamos o futuro como se ele tivesse obrigação de cooperar.
Representando:
PLANO MENTAL:
START
↓
A
↓
B
↓
C
↓
DONE
Vida real:
START
↓
A
↓
ERRO
↓
CORREÇÃO
↓
B
↓
ESPERA
↓
DEPENDÊNCIA
↓
RETESTE
↓
C
↓
ROLLBACK
↓
NOVO TESTE
↓
DONE
O curioso?
Nós já sabemos disso.
E ainda planejamos como se o primeiro desenho fosse mais realista.
☕ Bellacosa Mainframe: “é só alterar um copybook”
Existem algumas palavras que deveriam provocar imediatamente uma pequena sirene no cérebro de qualquer mainframeiro.
Uma delas:
“Só.”
“É só alterar um copybook.”
“É só aumentar o campo.”
“É só recompilar.”
“É só fazer o bind.”
“É só restartar.”
“É só mudar um parâmetro.”
Toda frase que começa com:
“É só...”
merece uma investigação.
Porque muitas vezes o “só” esconde dependências.
💻 O famoso campo de 5 para 7 posições
Imagine:
01 WS-CODIGO PIC 9(5).
Negócio pede:
PIC 9(7).
Gerente:
— Mudança simples.
Programador iniciante:
— É só aumentar o campo.
Veterano sorri.
Porque sabe.
Copybook usado por:
17 programas.
3 arquivos.
2 interfaces.
DB2.
Relatório.
BMS.
MQ.
Sistema externo.
Agora:
“MUDAR 5 PARA 7”
virou:
IMPACT ANALYSIS
COPYBOOK
RECOMPILE
DATASET
LAYOUT
SORT
DB2
INTERFACE
TEST
REGRESSION
DEPLOY
RECONCILIATION
O código mudou em um minuto.
O sistema levou três semanas.
Isso é uma das belezas do mainframe.
A linha de código pode ser simples.
A história dela, não.
🧠 Por que subestimamos?
Porque nossa mente tende a usar algo chamado:
Inside View
Pensamos na tarefa específica.
Nosso plano.
Nossa equipe.
Nossa experiência.
Imaginamos:
primeiro faço isso, depois aquilo.
Cada passo parece curto.
Então somamos.
10 + 10 + 10 + 10
=
40 minutos
Perfeito.
Só esquecemos:
espera;
reunião;
permissão;
deploy;
problema;
rollback;
latência;
validação;
ambiguidade.
O Inside View conta a história ideal do projeto.
🔭 Outside View
Existe uma defesa extraordinária:
Outside View
Em vez de perguntar:
“Quanto achamos que esta atividade levará?”
Pergunte:
“Quanto atividades semelhantes realmente levaram?”
Nosso exemplo:
3h48
4h17
5h02
6h11
Talvez quarenta minutos não seja uma estimativa.
Talvez seja literatura fantástica.
📊 Reference Class Forecasting
Essa abordagem é conhecida como Reference Class Forecasting.
A ideia:
encontre uma classe de projetos parecidos;
observe resultados reais;
use essa distribuição para estimar o novo projeto;
só depois ajuste por diferenças concretas.
Exemplo:
Últimas 10 mudanças desse tipo:
2h50
3h20
3h42
4h01
4h17
4h50
5h02
5h35
6h11
7h03
Agora alguém diz:
“Nossa leva 40 minutos.”
Pergunta:
O que mudou materialmente para justificar essa redução?
Se houver resposta forte:
ótimo.
Se resposta for:
“Desta vez vai dar certo.”
temos Planning Fallacy.
👻 Easter Egg nº 1 — TARDIS não resolve cronograma
Companion:
— Doctor, quanto tempo vai levar?
— Dez minutos.
Corta para:
três planetas destruídos;
dois paradoxos;
uma invasão Cyberman;
um chá interrompido;
e 47 minutos de episódio.
Talvez até Time Lords sofram Planning Fallacy.
A diferença é que eles possuem máquina do tempo.
Nós temos Change Window.
Muito pior.
⏱️ A soma das tarefas não é o tempo do projeto
Esse ponto é importantíssimo.
Você pode ter:
Tarefa A: 10 min
Tarefa B: 15 min
Tarefa C: 20 min
Total ingênuo:
45 minutos.
Mas pode existir:
espera aprovação: 20
transição: 10
validação: 30
problema eventual: 25
comunicação: 10
Tempo real:
140 minutos.
O trabalho inclui:
tempo entre os trabalhos.
🧠 Queueing Time
Em sistemas, entendemos fila.
Mas curiosamente esquecemos filas humanas.
Você termina seu código.
DBA precisa fazer bind.
DBA está em outro incidente.
Sua atividade “de cinco minutos” espera 40.
Elapsed time ≠ CPU time.
O mainframeiro deveria entender isso perfeitamente.
😄 Easter Egg nº 2 — CPU TIME versus ELAPSED TIME
JCL mostra:
CPU TIME: 00:01:23
ELAPSED: 00:47:18
A humanidade inteira poderia aprender planejamento apenas olhando essa diferença.
Trabalho efetivo:
1 minuto.
Mundo real:
Planejamento também possui elapsed time.
🧠 Optimism Bias
Planning Fallacy frequentemente possui um companheiro:
Optimism Bias.
Tendemos a acreditar:
“As coisas provavelmente correrão bem conosco.”
Não é necessariamente ingenuidade.
Pode ser motivador.
Mas cronogramas precisam ser baseados em distribuição.
Não esperança.
🧠 Overconfidence Bias volta imediatamente
Nosso capítulo anterior encaixa perfeitamente.
Especialista:
— Eu faço isso em meia hora.
Por quê?
— Tenho experiência.
Overconfidence diz:
minha habilidade reduz quase toda variabilidade.
Planning Fallacy responde:
então posso estimar agressivamente.
A dupla transforma:
experiência
em:
cronograma impossível.
🎯 “Desta vez é diferente”
Talvez seja.
Mas precisamos explicar:
como?
Exemplo válido:
mudança anterior levava cinco horas porque deployment era manual.
Agora pipeline reduz essa etapa em duas horas.
Excelente.
Dados.
Outro:
“A equipe está mais preparada.”
Quanto?
Que etapa diminuiu?
Como medimos?
Sem evidência:
otimismo.
⚓ Anchoring Bias no cronograma
Alguém fala primeiro:
— Duas horas.
Pronto.
Agora toda negociação gira em torno de duas horas.
Outra pessoa pensa:
quatro.
Mas começa:
“Talvez três?”
A primeira estimativa virou âncora.
Isso é Planning Fallacy + Anchoring Bias.
👥 Groupthink do prazo
Gerente:
— Dá para sexta?
Primeira pessoa:
— Acho que sim.
Segunda:
— Sim.
Terceira olha.
Talvez pense:
não.
Mas todos estão concordando.
— Sim.
Groupthink transformou desejo em plano.
🪜 Authority Gradient
Diretor pergunta:
— Conseguimos fazer durante a janela de uma hora?
Especialista sabe:
provavelmente não.
Mas responde:
— Vamos tentar.
Adivinhe qual número entra na planilha?
Uma hora.
Agora o cronograma não representa engenharia.
Representa hierarquia.
💰 Pressão comercial também distorce
Planning Fallacy não é apenas viés individual.
Pode ser incentivado.
Exemplo:
fornecedor diz:
Projeto A:
6 meses.
Fornecedor B:
Fornecedor C:
Quem ganha?
Talvez C.
Então existe incentivo para subestimar.
Depois:
aditivo contratual.
Atraso.
Replanejamento.
Às vezes o sistema recompensa previsões otimistas.
🧠 Strategic Misrepresentation
Aqui precisamos separar uma coisa.
Planning Fallacy é geralmente uma distorção genuína.
A pessoa realmente acredita no prazo.
Outra coisa é prometer conscientemente prazo irreal para obter aprovação.
Isso é diferente.
Mas ambos podem coexistir em organizações.
☕ “Venda primeiro, resolva depois”
Equipe comercial vende três meses.
Engenharia descobre:
Planning Fallacy?
Talvez.
Incentivo?
Talvez.
Governança precisa distinguir.
📈 Dados históricos salvam novamente
Nosso arsenal está ficando repetitivo.
Isso é bom.
Porque algumas defesas combatem vários vieses.
Use:
últimas mudanças;
últimos projetos;
últimos incidentes;
tempo médio;
mediana;
percentis.
Não apenas:
melhor caso.
📊 Média pode enganar
Tempos:
1h
1h
1h
1h
10h
Média:
2h48.
Mediana:
1h.
Mas se o atraso de 10 horas acontece 20% das vezes, talvez sua janela precise considerar cauda.
Planejamento crítico precisa olhar distribuição.
🐉 Tail Risk
Caudas importam.
Um projeto pode normalmente levar:
2h.
Mas em 10%:
8h.
Se sua janela operacional é 3h:
temos problema.
Não basta usar “tempo típico”.
Precisamos pensar:
P50;
P80;
P90;
P95.
📊 P50 versus P90
Imagine histórico:
P50:
3h.
P90:
6h.
Se você precisa de confiança alta:
planeje mais perto de 6h.
Se usar 3h:
metade dos casos pode estourar.
Isso é escolha.
Não surpresa.
☕ Bellacosa Mainframe: Change Window
Mudança precisa caber em:
00:00–04:00
Tempo estimado:
3h30.
Parece caber.
Mas rollback leva:
1h.
Agora não cabe.
Porque janela precisa incluir:
execução;
validação;
decisão;
rollback.
O tempo de saída também é parte do plano.
🛑 Last Safe Moment volta
Do Plan Continuation Bias:
qual o último momento seguro de retorno?
Se mudança leva 3h e rollback 1h:
você não possui janela de 4h para executar.
Possui menos.
Precisa reservar saída.
🧠 Planning Fallacy alimenta Plan Continuation Bias
Plano previa:
40 minutos.
Após 50:
— Já estamos atrasados.
Uma hora:
— Falta pouco.
Duas:
— Já investimos demais.
Agora Planning Fallacy produziu Plan Continuation Bias.
Subestimamos.
Depois insistimos.
🚨 O atraso muda risco
Quando plano estoura:
equipe cansa;
janela diminui;
rollback aperta;
pressão aumenta.
Logo, erro de estimativa não é apenas problema de agenda.
É:
risco operacional.
🧀 Swiss Cheese e cronograma impossível
Imagine barreiras:
teste;
validação;
reconciliação;
rollback.
Cronograma apertado começa a consumir.
— Não dá tempo para teste completo.
Primeiro buraco.
— Validação pode ser reduzida.
Segundo.
— Reconciliação depois.
Terceiro.
Planning Fallacy pode literalmente criar buracos no Swiss Cheese.
🌀 Drift Into Failure
Ano 1:
mudanças têm 6h.
Pressão por janela menor.
Ano 2:
4h.
Ano 3:
3h.
Ano 4:
2h.
Processo continua funcionando porque pessoas improvisam.
A margem desaparece.
Planning Fallacy institucional pode alimentar drift.
🧠 Normalization of Deviance
Primeiro atraso:
exceção.
Depois:
normal.
Cronograma continua oficialmente 1h.
Tempo real:
3h.
Todos sabem.
Ninguém atualiza plano.
Agora o documento vive num universo.
Operação em outro.
🗺️ Work as Imagined versus Work as Done novamente
Planejamento:
00:00 deploy
00:20 restart
00:30 test
00:40 done
Vida real:
00:00 deploy
00:25 problema de acesso
00:48 autorização
01:15 deploy
01:40 bind
02:05 restart
02:30 teste
03:12 reconciliação
Se isso acontece repetidamente:
não temos incidente excepcional.
Temos estimativa ruim.
🔔 Alarm Fatigue do cronograma
Quando todos os projetos estão atrasados:
atraso deixa de parecer alerta.
“Projeto sempre atrasa.”
Normalization of Deviance.
Mas por que continuamos usando estimativas que nunca funcionam?
Talvez porque o plano não está servindo como previsão.
Está servindo como desejo.
🎯 Pergunta Bellacosa nº 1
Quando alguém estimar:
“Duas horas.”
Pergunte:
“Quanto levaram as últimas cinco atividades parecidas?”
🎯 Pergunta Bellacosa nº 2
Outra:
“O que precisa acontecer perfeitamente para caber nesse prazo?”
Se a lista for longa:
prazo frágil.
🎯 Pergunta Bellacosa nº 3
Outra:
“Que tempo estamos reservando para falha e recuperação?”
🎯 Pergunta Bellacosa nº 4
E:
“Qual percentil de confiança representa essa estimativa?”
Talvez:
duas horas = P30.
Quatro = P80.
Agora discussão fica madura.
🧪 Como combater Planning Fallacy
Passo 1 — Use Outside View
Antes de estimar:
histórico.
Passo 2 — Crie Reference Class
Compare com tarefas realmente parecidas.
Passo 3 — Separe esforço de elapsed time
Horas de trabalho ≠ duração calendário.
Passo 4 — Liste dependências
Quem precisa participar?
Passo 5 — Inclua validação
Teste também leva tempo.
Passo 6 — Inclua rollback
Saída faz parte do plano.
Passo 7 — Inclua margem
Não planeje até o último minuto.
Passo 8 — Use ranges
Não:
2h.
Mas:
P50 = 2h30; P90 = 5h.
Passo 9 — Registre estimativa versus real
Aprenda.
Passo 10 — Atualize modelo
Não repita o mesmo erro infinitamente.
📓 Estimation Journal
Antes:
EXPECTED:
2h
P90:
4h
MAIN RISKS:
DBA availability
MQ restart
reconciliation
Depois:
ACTUAL:
4h27
Pergunte:
por quê?
Com o tempo:
melhora calibração.
📊 Estimate Accuracy
Não puna apenas quem “errou prazo”.
Meça padrões.
Equipe A sempre estima metade do real?
Multiplique por fator histórico enquanto corrige processo.
Chamemos brincando de:
Bellacosa Reality Factor
Se:
Estimado médio: 2h
Real médio: 4h
Fator:
Próxima estimativa de 3h:
baseline realista:
6h.
Não é elegante.
Mas funciona melhor que fingir surpresa.
😄 Hofstadter’s Law entra para o café
Existe uma observação famosa conhecida como Lei de Hofstadter:
tarefas levam mais tempo do que esperamos, mesmo quando levamos em conta que levam mais tempo do que esperamos.
É humor.
Mas descreve maravilhosamente o Planning Fallacy.
💻 Desenvolvimento de software
Programador:
— Esse bug leva uma hora.
Primeiros 20 minutos:
descobre que não entende causa.
Depois:
ambiente não reproduz.
Depois:
log insuficiente.
Depois:
correção quebra teste.
Agora:
um dia.
Todo desenvolvedor conhece isso.
🐛 Debugging não é linha reta
Estimativa de debugging é particularmente difícil.
Porque, se você soubesse exatamente o problema, talvez já tivesse resolvido.
Incerteza faz parte.
Melhor:
ranges;
timeboxes;
checkpoints.
🧠 Unknown Unknowns voltam
Projeto novo contém coisas que nem sabemos que precisam ser feitas.
Isso não significa adicionar 10% arbitrário e acreditar que resolveu.
Pode exigir:
spikes;
prototipagem;
descoberta;
buffers.
🧪 Spike técnico
Antes de prometer:
faça pequeno experimento.
Exemplo:
“Precisamos integrar COBOL com nova API.”
Não estime projeto inteiro só por documentação.
Primeiro:
proof of concept.
Agora unknowns diminuem.
📚 Requirements também crescem
Planning Fallacy não acontece apenas porque somos ruins em estimar execução.
Escopo muda.
Negócio aprende durante projeto.
Isso precisa entrar no modelo.
Se projetos parecidos sempre crescem 20% de escopo:
trate isso como histórico.
💰 Custo também sofre
Projeto:
R$ 1 milhão.
Depois:
1,5.
Mesma estrutura.
Planning Fallacy existe em:
tempo;
dinheiro;
equipe;
complexidade.
👨💻 O COBOL iniciante e a estimativa
Chefe:
— Quanto leva?
Não responda imediatamente:
“uma hora.”
Faça perguntas.
Qual ambiente?
Há teste?
Copybook é compartilhado?
Precisa DB2?
Impact analysis?
Deploy?
Janela?
Rollback?
Depois:
“Alteração em si é pequena, mas ponta a ponta eu estimaria 1–3 dias, dependendo dos impactos.”
Isso é maturidade.
🧠 Não confunda precisão com confiança
“2 horas e 17 minutos.”
Parece científico.
Talvez seja invenção com casas decimais.
Às vezes:
“entre 3 e 5 horas”
é mais honesto.
📏 False Precision
Outro fenômeno relacionado.
Quanto mais incerta a tarefa, menos sentido existe em precisão excessiva.
Não faça:
ETA = 47 MIN
se erro histórico é:
±3h.
🪜 Authority Gradient e estimativa
Se gerente precisa ouvir “sexta”, equipe pode produzir sexta.
Depois:
sábado.
segunda.
quarta.
Uma cultura madura permite:
“Ainda não sabemos; preciso fazer descoberta.”
Isso reduz cronograma ficcional.
👥 Groupthink em projetos
Se todas as equipes dizem:
“sim, dá”
pergunte:
alguém fez estimativa independente?
Talvez todos estejam ancorados no prazo desejado.
📝 Independent Estimation
Antes de reunião:
cada especialista estima separadamente.
Depois compare.
Exemplo:
João: 2h
Maria: 5h
Carlos: 6h
Ana: 1h30
Excelente.
Há divergência.
Discuta.
Não force média silenciosa.
🎲 Planning Poker — com cuidado
Métodos de estimativa relativa podem ajudar.
Mas não eliminam Planning Fallacy.
Se todo grupo compartilha mesma visão otimista:
consenso continua errado.
Reference data melhora.
📊 Monte Carlo Simulation
Em planejamentos mais maduros, podemos modelar distribuição de duração e simular múltiplos cenários.
Não precisamos fazer cálculo avançado para toda mudança COBOL.
Mas a ideia importa:
futuro possui distribuição.
Não ponto único.
🧠 Prazos são probabilísticos
Quando dizemos:
“terminará sexta”
deveríamos mentalmente perguntar:
com qual confiança?
Talvez:
50%.
90%.
99%.
Essa diferença muda compromisso.
📆 Deadline versus Forecast
Outra distinção fundamental.
Deadline:
quando precisa terminar.
Forecast:
quando provavelmente terminará.
Se deadline é sexta e forecast é terça seguinte:
o problema não desaparece chamando terça de sexta.
Precisamos mudar:
escopo;
recursos;
sequência;
risco.
🧠 Plano não altera capacidade física
Essa ideia lembra Authority Gradient.
Diretor dizer:
“tem que acabar sexta”
não faz automaticamente o trabalho caber.
Cronograma não obedece hierarquia.
Tal como matemática.
🔥 O triângulo clássico
Tempo.
Escopo.
Recursos.
Qualidade/risco.
Se comprimimos tempo sem alterar nada:
alguma coisa absorve.
Frequentemente:
margem;
teste;
pessoas.
Isso pode produzir incidente.
🪫 Burnout como buffer escondido
Às vezes cronogramas “funcionam” porque pessoas trabalham:
noite;
fim de semana;
horas extras.
Projeto parece bem estimado.
Na verdade:
buffer foi retirado dos seres humanos.
Perigoso.
🧠 Survivorship Bias nas estimativas
Você lembra projetos entregues heroicamente.
Os cancelados desaparecem.
Conclui:
“Sempre damos um jeito.”
Talvez os sobreviventes só existam porque alguém trabalhou 80 horas.
Inclua custo humano.
🦸 Outcome Bias
Projeto atrasado, mas termina.
Diretor:
“No fim deu certo.”
Então planejamento irreal não é corrigido.
Outcome Bias protege Planning Fallacy.
Próximo projeto:
mesma estimativa.
🧠 Overconfidence + Outcome + Planning
Temos um círculo:
PLANO OTIMISTA
↓
EQUIPE COMPENSA
↓
RESULTADO BOM
↓
OUTCOME BIAS
↓
“PLANO ERA BOM”
↓
OVERCONFIDENCE
↓
PLANO AINDA MAIS OTIMISTA
Até quebrar.
Isso é praticamente Drift Into Failure organizacional.
🚧 Hidden Work
Outra pergunta poderosa:
“Que trabalho não aparece no cronograma?”
Comunicação.
Aprovação.
Análise.
Coordenação.
Documentação.
Waiting.
Essas coisas consomem tempo.
🧮 80% de utilização é diferente de 100%
Sistemas em 100% de utilização acumulam filas.
Pessoas também.
Se equipe está 100% alocada:
qualquer evento novo atrasa tudo.
Planejar como se pessoas tivessem disponibilidade infinita cria atraso sistêmico.
📈 Buffer não é desperdício
Um buffer bem dimensionado absorve variabilidade.
Sem buffer:
qualquer variação vira atraso.
Isso conecta Planning Fallacy com margem de segurança do Drift Into Failure.
🧠 Critical Chain e buffers
Existem abordagens de planejamento que usam buffers explícitos.
A ideia geral é saudável:
não esconder margem dentro de cada tarefa de forma aleatória.
Gerencie incerteza conscientemente.
🔍 Post-mortem de estimativa
Quando projeto termina:
não pergunte apenas:
atrasou?
Pergunte:
qual estimativa inicial?
quando percebemos erro?
quais dependências faltaram?
qual trabalho estava invisível?
qual risco materializou?
qual parte foi pura variabilidade?
Isso melhora próximo plano.
📉 Error Ratio
Exemplo:
ESTIMATED: 40 min
ACTUAL: 240 min
Razão:
6x.
Se isso ocorre repetidamente:
não é azar.
É modelo.
🧠 Uma estimativa errada é dado
Não vergonha.
Use.
Se pessoas são punidas por errar estimativa:
começam a esconder ou inflar.
Queremos aprendizado.
☕ Bellacosa Mainframe e SLA
Imagine batch:
estimado:
2h.
Real:
3h50.
SLA:
4h.
Equipe diz:
cumprimos.
Ótimo.
Mas margem:
10 min.
Planning Fallacy + Drift.
Cuidado.
Sucesso no SLA não significa estimativa saudável.
🔧 Capacity Planning
Planning Fallacy também vale para capacidade.
“Storage aguenta mais dois anos.”
Baseado em quê?
Se crescimento real:
20% ao mês,
talvez não.
Projection.
Trend.
Outside View.
🧠 Normalcy Bias
“Sempre conseguimos fechar dentro da janela.”
Sim.
Mas margem caiu:
90;
60;
30;
10 minutos.
Planning Fallacy olha para duração esperada.
Normalcy Bias olha para histórico de sucesso.
Drift olha para margem.
Os três juntos são perigosos.
🛑 Kill Criteria para projetos
Assim como mudança precisa de STOP criteria, projetos podem precisar:
se custo passar X;
se prazo passar Y;
se hipótese de negócio falhar;
reavaliar.
Sem isso:
Planning Fallacy inicial vira Plan Continuation Bias.
🎯 Pergunta Bellacosa nº 5
“Se o projeto levar o dobro, ainda faz sentido?”
Excelente.
Porque muitos projetos têm valor apenas dentro de determinadas condições.
🧪 Pre-mortem para prazo
Imagine:
“Estamos seis meses atrasados.”
Por quê?
Liste:
dependências;
aprovações;
bugs;
escopo;
turnover;
ambiente;
integração.
Agora veja quais já são plausíveis hoje.
Incorpore.
📋 Checklist anti-Planning Fallacy
[ ] Qual a duração de trabalhos semelhantes?
[ ] Estamos usando Inside View ou Outside View?
[ ] Que dependências existem?
[ ] Quanto tempo é trabalho e quanto é espera?
[ ] Incluímos teste?
[ ] Incluímos validação?
[ ] Incluímos rollback?
[ ] Incluímos comunicação e handoff?
[ ] Qual é P50?
[ ] Qual é P90?
[ ] Que margem existe?
[ ] O que pode atrasar?
[ ] Estamos aceitando prazo imposto sem evidência?
[ ] O sistema mudou desde a última vez?
[ ] Estamos usando “desta vez será diferente” sem explicar por quê?
[ ] Se levar 2x, qual o plano?
🧬 Regeneração organizacional
Uma organização madura contra Planning Fallacy:
mantém histórico;
mede estimado versus real;
usa reference classes;
trabalha com ranges;
expõe premissas;
preserva buffers;
inclui rollback;
protege tempo de validação;
faz pre-mortem;
e separa forecast de deadline.
Principalmente:
abandona o teatro da precisão.
Troca:
“fica pronto sexta”
por:
“Com base em 12 projetos semelhantes, temos 50% de chance até sexta e 90% até terça.”
Talvez seja menos elegante no PowerPoint.
É muito mais útil para administrar realidade.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Planning Fallacy é a tendência de subestimar tempo, custo e esforço necessários para tarefas futuras.
Planejamos frequentemente o caminho ideal, não a distribuição real.
Inside View conta a história do nosso projeto; Outside View pergunta o que aconteceu em projetos semelhantes.
Reference Class Forecasting é uma poderosa defesa.
Tempo de trabalho e elapsed time são diferentes.
Rollback e validação também consomem janela.
Buffers são proteção contra variabilidade, não desperdício automático.
Overconfidence e Optimism Bias alimentam estimativas agressivas.
Anchoring, Groupthink e Authority Gradient podem transformar prazo desejado em estimativa oficial.
Planning Fallacy frequentemente termina em Plan Continuation Bias.
E principalmente:
Um plano não fica realista porque cabe na planilha. Fica realista quando sobrevive ao contato com o histórico, as dependências e a incerteza.
🕰️ De volta à reunião das 10:02
TARDIS.
VWORP.
A planilha:
ESTIMATIVA:
40 MIN
O Doctor pergunta:
— Quanto levaram as quatro últimas?
Nosso programador lê:
— 4h17, 5h02, 3h48 e 6h11.
— Excelente.
— Excelente?
— Sim. Vocês possuem dados.
O gerente diz:
— Mas desta vez estamos mais preparados.
O Doctor responde:
— Ótimo. Quanto isso reduz?
Silêncio.
A equipe começa a decompor.
Deploy automatizado:
menos 30 minutos.
Novo script de validação:
menos 20.
Bind permanece.
CICS permanece.
Reconciliação permanece.
Rollback:
1h.
Calculam novamente.
Reference class.
A nova estimativa:
P50: 3h20
P90: 5h30
ROLLBACK: 1h
Janela de uma hora?
Impossível.
A mudança é movida para janela maior.
Durante execução:
4h02.
Quase exatamente dentro da distribuição histórica.
O gerente olha.
— Então nossa primeira estimativa estava errada por mais de três horas.
O programador sorri.
— Sim.
— Isso não é constrangedor?
O Doctor responde:
— Um pouco.
Pausa.
— Mas muito menos que descobrir às 03:00.
🥚 Easter Egg final
No dia seguinte surge:
BELLACOSA.BIAS(PLAN)
Dentro:
IF ESTIMATE = 'BEST-CASE'
PERFORM CHECK-HISTORY
END-IF.
IF SOMEONE-SAYS
'ONLY-FORTY-MINUTES'
PERFORM FIND-HIDDEN-WORK
END-IF.
IF DEADLINE < P90
PERFORM DISCUSS-RISK
END-IF.
Comentário:
* CPU TIME IS NOT ELAPSED TIME.
Outro:
* HOPE IS NOT A BUFFER.
Depois:
* THE FUTURE HAS QUEUES TOO.
E naturalmente:
* BAD WOLF ESTIMATED 20 MINUTES.
* IT TOOK THREE EPISODES.
Nosso jovem programador fecha o membro.
Pouco depois chega um pedido:
— Dá para alterar esse campo até amanhã?
Ele olha.
Antigamente responderia:
“Sim.”
Agora pergunta:
— Em quantos programas o copybook é usado?
— Não sei.
— Existem interfaces?
— Acho que sim.
— Precisa Db2?
— Talvez.
— Então ainda não tenho uma estimativa.
O gerente olha desconfiado.
— Você não consegue dizer quanto leva?
O jovem responde:
— Consigo dizer quanto leva depois que souber o que realmente estamos mudando.
Pausa.
— Antes disso eu só consigo inventar um número.
Em algum lugar do espaço-tempo:
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da sala permanece:
Se o histórico diz seis horas e o planejamento diz quarenta minutos, talvez o problema não esteja no relógio.
E essa talvez seja uma das maiores lições da Falácia do Planejamento:
o futuro sempre contém mais coisas do que cabem no nosso primeiro rascunho.
☕🌀
Next stop: Sunk Cost Fallacy — quando já gastamos tanto tempo, dinheiro e café num projeto que parar começa a parecer mais doloroso do que continuar fazendo algo que já não faz sentido.
