 |
| Bellacosa Mainframe e a loss aversion |
☕ Um Café no Bellacosa Mainframe
Loss Aversion: Doctor Who, COBOL e o Dia em que o Medo de Perder Pesou Mais que a Chance de Melhorar
Uma viagem pela TARDIS dos incidentes para entender por que perder algo que já temos pode parecer muito mais doloroso do que ganhar algo equivalente — e como isso distorce decisões em sistemas críticos
08:42.
Segunda-feira.
Reunião de arquitetura.
Café quente.
Na tela:
SISTEMA ATUAL
CUSTO ANUAL: R$ 8,2 milhões
INCIDENTES CRÍTICOS/ANO: 6
INTERVENÇÕES MANUAIS/MÊS: 170
JANELA BATCH UTILIZADA: 94%
ESPECIALISTAS DISPONÍVEIS: 3
Abaixo:
PROPOSTA DE MELHORIA
INVESTIMENTO: R$ 2,1 milhões
ECONOMIA ESTIMADA/ANO: R$ 3 milhões
REDUÇÃO DE INTERVENÇÕES: 80%
ROLLBACK POSSÍVEL: SIM
MIGRAÇÃO INCREMENTAL: SIM
Nosso jovem programador COBOL olha para os números.
— Parece uma boa oportunidade.
O gerente responde:
— Talvez.
— O que preocupa?
— Podemos perder estabilidade.
— Mas hoje já temos seis incidentes críticos por ano.
— Eu sei.
Outro especialista entra:
— Podemos perder conhecimento.
— Mas hoje só três pessoas conhecem profundamente o sistema.
— Justamente.
Nosso programador franze a testa.
— Então estamos com medo de perder uma situação que já não é tão boa?
Silêncio.
O gerente aponta para o sistema atual.
— Pelo menos sabemos como ele funciona.
Nosso jovem olha para:
170 INTERVENÇÕES MANUAIS/MÊS
— Mais ou menos.
Então surge a frase inevitável:
“Melhor garantir o que temos do que arriscar perder tudo.”
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do projetor.
A porta abre.
O Doctor sai.
Olha para as duas opções.
Depois pergunta:
— Quanto vale manter o sistema atual?
O gerente responde:
— Muito.
— Quanto?
Silêncio.
— E quanto dói imaginar perdê-lo?
O gerente hesita.
— Bastante.
O Doctor sorri.
— Ah.
Pausa.
— Então talvez vocês estejam confundindo valor com apego.
Bem-vindo ao:
Loss Aversion
Ou:
Aversão à Perda
A tendência de sentir perdas com mais intensidade do que ganhos equivalentes.
Em linguagem Bellacosa:
Perder R$ 100 dói mais do que ganhar R$ 100 alegra.
E em tecnologia:
perder algo conhecido pode parecer pior do que ganhar algo objetivamente melhor.
🧠 O que é Loss Aversion?
Imagine duas situações.
Situação A
Você ganha R$ 1.000.
Situação B
Você perde R$ 1.000.
Matematicamente, magnitude:
igual.
Em experiência psicológica:
normalmente não.
A perda tende a pesar mais.
Esse padrão foi estudado profundamente na economia comportamental, especialmente na Prospect Theory, associada a Daniel Kahneman e Amos Tversky.
A ideia central:
humanos não avaliam ganhos e perdas de forma simétrica.
Uma perda de determinada magnitude costuma provocar impacto emocional maior do que um ganho equivalente.
☕ O que isso tem a ver com COBOL?
Tudo.
Imagine:
programa antigo.
Estável.
Feio.
Pouco documentado.
Mas funciona.
Surge proposta:
modernizar.
Equipe pensa imediatamente:
“O que podemos perder?”
estabilidade;
conhecimento;
desempenho;
compatibilidade;
controle.
Pergunta raramente aparece com mesma força:
“O que perdemos todos os dias mantendo como está?”
tempo;
capacidade;
margem;
automação;
talentos;
oportunidades.
Loss Aversion joga luz forte nas perdas da mudança...
e sombra nas perdas da permanência.
🧠 Loss Aversion + Status Quo Bias
Esse casamento é praticamente inevitável.
Status Quo Bias:
“Prefiro o atual porque já existe.”
Loss Aversion:
“Mudar significa abrir mão do que já tenho.”
Resultado:
o estado atual ganha valor psicológico adicional apenas por ser nosso.
Mesmo que objetivamente não seja melhor.
🎁 Endowment Effect
Existe um conceito relacionado:
Endowment Effect
Ou efeito dotação.
Algo passa a parecer mais valioso simplesmente porque já nos pertence.
Exemplo simples:
uma caneca.
Antes de receber:
vale R$ 30.
Depois que é sua:
você talvez só aceite vendê-la por R$ 60.
A posse alterou a percepção.
Agora pense:
um sistema.
Um processo.
Uma arquitetura.
Um fornecedor.
Uma equipe.
A organização passa a dizer:
“Nossa solução.”
E isso pode aumentar apego.
☕ Bellacosa Mainframe: “nosso legado”
A palavra:
“nosso”
é poderosa.
“Nosso mainframe.”
“Nosso framework.”
“Nosso sistema.”
“Nosso processo.”
Isso pode significar orgulho legítimo.
Mas também pode criar resistência.
A pergunta precisa ser:
“Se não fosse nosso hoje, quanto pagaríamos para adotá-lo agora?”
Excelente teste.
👻 Easter Egg nº 1 — A chave da TARDIS
Companion:
— Doctor, você trocaria a TARDIS por uma nave nova?
Doctor:
— Nunca.
— Mesmo se fosse mais rápida?
— Nunca.
— Mais segura?
— Nunca.
— Mais confiável?
— Nunca.
— Então isso é análise técnica?
Doctor olha para a TARDIS.
— Absolutamente não.
Às vezes apego é apenas apego.
E tudo bem.
Só não chame de arquitetura.
🧠 Loss Aversion não é covardia
Importante.
Evitar perda pode ser racional.
Sistemas críticos devem ser conservadores.
Se mudança ameaça:
dados;
continuidade;
segurança,
é correto ser cuidadoso.
O problema aparece quando:
o medo da perda recebe peso maior do que a análise do risco real.
Não queremos:
“mude sempre.”
Queremos:
“compare corretamente.”
⚖️ Ganho e perda precisam usar a mesma régua
Exemplo:
Migrar pode gerar:
RISCO DE PERDA:
R$ 2M em caso de falha
Manter pode gerar:
CUSTO CERTO:
R$ 3M/ano extra
Se organização olha obsessivamente para os R$ 2M possíveis...
mas ignora os R$ 3M anuais certos,
temos distorção.
🧠 Loss Aversion + Omission Bias
Nosso capítulo anterior encaixa perfeitamente.
Agir pode causar perda visível.
Não agir pode permitir perda futura.
Mas a ação tem autor.
A perda causada pela mudança parece:
“Nós perdemos.”
A perda causada pela inação parece:
“Aconteceu.”
Logo:
Loss Aversion pode empurrar Omission Bias.
🌀 Drift Into Failure
Sistema perde margem lentamente.
1%.
2%.
5%.
Nada dramático.
Essas perdas pequenas e graduais podem ficar psicologicamente invisíveis.
Já uma mudança que ameaça perder 10% de estabilidade de uma vez parece gigantesca.
Resultado:
aceitamos pequenas perdas acumuladas para evitar uma perda imediata possível.
Drift agradece.
🧠 Losses salientes versus losses silenciosas
Perda imediata:
visível.
Perda gradual:
diluída.
Exemplo:
não automatizar.
Custa 20 min/dia.
Parece pequeno.
Em um ano:
83 horas.
Mas ninguém sente 83 horas de uma vez.
Então Loss Aversion não é acionada da mesma forma.
💸 Technical Debt e Loss Aversion
Refatorar custa hoje.
Você “perde”:
tempo de feature;
capacidade;
prazo.
Manter dívida custa ao longo do tempo.
Como custo futuro é fragmentado:
parece menor.
Present Bias entra junto.
🧠 Loss Aversion + Present Bias
Present Bias:
“Não quero pagar agora.”
Loss Aversion:
“Não quero abrir mão do que já tenho.”
Resultado:
“Deixa como está.”
Uma combinação fortíssima contra melhoria contínua.
💻 Exemplo COBOL: a rotina antiga
Programa:
PERFORM 1000-CALCULO
PERFORM 2000-VALIDACAO
PERFORM 3000-GRAVACAO
Equipe descobre:
nova estrutura reduziria metade da manutenção.
Mas exige:
refactor;
testes;
regressão.
Sênior:
— Podemos perder estabilidade.
Correto.
Mas também:
cada mudança atual leva cinco dias em vez de um.
Essa diferença também é perda.
🧠 Opportunity Cost volta
Loss Aversion foca no que perderemos ao escolher B.
Mas toda escolha também abandona algo.
Se mantemos A:
perdemos a oportunidade de B.
Esse é custo de oportunidade.
Ele é menos emocional porque nunca chegamos a “possuir” B.
Mas economicamente conta.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Não quero perder isso.”
Pergunte:
“O que estamos perdendo para continuar mantendo isso?”
Essa pergunta reequilibra.
🧠 Sunk Cost Fallacy + Loss Aversion
Sunk Cost:
“Já investimos R$ 10 milhões.”
Loss Aversion:
“Cancelar significa perder esses R$ 10 milhões.”
Mas eles já foram gastos.
Cancelar não cria a perda.
Apenas torna a perda impossível de negar.
Isso é importante.
💰 Paper Loss psicológico
Às vezes uma perda já existe economicamente, mas não psicologicamente.
Enquanto projeto continua:
a organização pode pensar:
“Ainda vamos recuperar.”
Cancelar força reconhecer:
“Perdemos.”
Logo:
continuar pode servir para evitar a sensação da perda.
Não o prejuízo.
🧠 Escalation of Commitment novamente
Projeto ruim.
Mais dinheiro.
Porque parar cristaliza perda.
Investir mais mantém esperança.
Loss Aversion pode ser combustível poderoso da escalada de compromisso.
☕ “Só mais seis meses”
Projeto:
R$ 20M gastos.
Falta R$ 10M.
Valor futuro caiu para R$ 3M.
Alguém:
“Se parar agora, perdemos R$ 20M.”
Não.
Os R$ 20M já saíram.
Continuar pode transformar:
perda de 20
em:
perda de 30.
🧠 Prospect Theory e referência
Uma parte importante da Prospect Theory é que percebemos resultados em relação a um:
ponto de referência.
Se temos algo:
perdê-lo dói.
Se nunca tivemos:
não obter pode doer menos.
Isso ajuda a explicar por que:
tirar benefício existente é muito mais difícil que não oferecer o mesmo benefício inicialmente.
Em sistemas:
remover uma feature pouco usada pode provocar resistência enorme.
📊 Feature ninguém usa... até retirar
Analytics:
USUÁRIOS/MÊS:
12 de 20.000
Equipe decide remover.
De repente:
— Essa feature é crítica!
— Sempre usamos!
— Não pode remover!
Talvez seja crítica para alguns.
Investigue.
Mas existe também Endowment Effect.
Algo que estava disponível passa a parecer valiosíssimo quando ameaça desaparecer.
🧠 Retirement de sistemas
Aplicação possui:
10 usuários.
Custo anual enorme.
Ao propor desligamento:
resistência.
Por quê?
Perder acesso é concreto.
Economia organizacional é abstrata.
Loss Aversion torna decommissioning politicamente difícil.
☕ O relatório de 1989
Relatório impresso toda manhã.
Ninguém parece usar.
Tentam cancelar.
Às 09:03:
telefone toca.
— Cadê meu relatório?
— Para que usa?
— Sempre recebi.
Talvez esse seja o documento oficial mais poderoso do Endowment Effect.
🧠 Loss Aversion + Normalization of Deviance
Sistema tem workaround.
Remover exige mudança.
Usuários pensam:
“Podemos perder essa flexibilidade.”
Mesmo que workaround cause erro.
O desvio normalizado passa a ser percebido como benefício adquirido.
Perigoso.
🔐 Segurança e Loss Aversion
Security diz:
“Vamos remover privilégio excessivo.”
Usuário:
— Vou perder acesso!
Essa perda é concreta.
Benefício:
redução de risco.
Abstrato.
Loss Aversion favorece manter privilégio.
Por isso least privilege encontra tanta resistência.
🧠 Privilege creep
Usuário recebe acesso temporário.
Depois precisa remover.
Mas:
“Eu uso às vezes.”
Agora tirar parece perda.
Mesmo que nunca devesse ter sido permanente.
Acesso temporário precisa:
data de expiração.
Automação.
Senão Endowment Effect aparece.
🔄 Expiring Defaults
Uma excelente defesa:
acesso temporário expira automaticamente.
Para manter:
justifique novamente.
Isso inverte o default.
🧠 Status Quo Bias + Default Effect + Loss Aversion
Se permissão é permanente:
remover parece perda.
Se expira:
renovar parece ganho adicional.
A arquitetura de defaults altera comportamento.
Muito interessante.
👥 Pessoas e reorganização
Loss Aversion também aparece em equipes.
Mudança de processo:
“Vamos perder autonomia.”
Talvez.
Mudança de ferramenta:
“Vamos perder produtividade.”
Talvez.
Mas pode existir ganho.
A resistência não deve ser ridicularizada.
Perdas percebidas são reais psicologicamente.
Gestão precisa reconhecer.
🧠 Change Management
Uma mudança bem conduzida não comunica apenas:
“O que vamos ganhar.”
Também responde:
“O que vocês têm medo de perder?”
Conhecimento?
Controle?
Status?
Conforto?
Identidade?
Essa pergunta revela a verdadeira resistência.
☕ “Resistência à mudança” é rótulo preguiçoso
Dizer:
“As pessoas resistem à mudança.”
explica pouco.
Pergunte:
“Que perda elas antecipam?”
Talvez exista:
risco legítimo;
custo de aprendizado;
perda de autonomia.
Agora podemos tratar.
🪜 Authority Gradient
Gerência quer retirar ferramenta.
Equipe sabe que vai perder uma função crítica.
Mas não consegue contestar.
Aqui Loss Aversion pode estar do lado certo.
Nem toda resistência é viés.
É preciso ouvir.
🧠 Viés não invalida preocupação
Essa é uma regra essencial nesta série.
Identificar um possível bias não significa:
“Você está errado.”
Significa:
“Vamos verificar se essa percepção está recebendo peso proporcional.”
📈 Loss Aversion e métricas
Imagine proposta:
80% chance de economizar R$ 10M;
20% chance de perder R$ 2M.
Muitos líderes focarão fortemente nos R$ 2M de perda.
Isso pode ser racional dependendo do risco.
Mas precisamos calcular valor esperado e impacto.
🧮 Expected Value
Simplificando:
0,80 × +10M = +8M
0,20 × -2M = -0,4M
Valor esperado:
+7,6M.
Isso não significa automaticamente:
faça.
Porque distribuição, risco de ruína e tolerância importam.
Mas transforma sentimento em análise.
🧠 Risk of Ruin
Se a perda possível quebra empresa:
mesmo excelente valor esperado pode ser inaceitável.
Portanto:
não use Loss Aversion como desculpa para ignorar riscos reais.
A pergunta é:
a perda é desagradável ou existencial?
Muito diferente.
🏦 Mainframe e risco assimétrico
Em sistema financeiro:
pequeno ganho de performance pode não justificar risco de perda de integridade.
Ser conservador pode ser correto.
Loss Aversion vira viés apenas quando peso excede justificativa técnica.
🎯 Pergunta Bellacosa nº 2
“Essa perda ameaça o sistema ou apenas nos deixa desconfortáveis?”
Excelente distinção.
🧠 Loss Aversion + Optimism Bias?
Curiosamente podem coexistir.
Sobre status quo:
otimistas:
“Vai continuar funcionando.”
Sobre mudança:
aversos:
“Podemos perder tudo.”
Assim avaliamos:
permanência com lente cor-de-rosa;
mudança com lente apocalíptica.
Perfeito para imobilidade.
📊 Decision framing
A forma como apresentamos decisão altera percepção.
Exemplo:
“Há 90% de chance de sucesso.”
versus:
“Há 10% de chance de falha.”
Matematicamente iguais.
Psicologicamente podem não ser.
Isso chama atenção para:
framing effects.
Talvez outro capítulo.
🧠 Gain Frame versus Loss Frame
Opção:
“Economizaremos 30%.”
Parece boa.
“Podemos perder 70% do gasto atual.”
Outro impacto.
Como apresentamos importa.
Em decisões críticas:
mostre os dois frames.
🎯 Pergunta Bellacosa nº 3
“Como a decisão parece se descrevemos em termos de ganhos e depois em termos de perdas?”
Se preferência muda muito:
framing pode estar influenciando.
🧪 Como combater Loss Aversion
Passo 1 — Liste ganhos e perdas dos dois lados
Não só mudança.
Passo 2 — Quantifique
Dinheiro.
Tempo.
Risco.
Margem.
Passo 3 — Inclua opportunity cost
O que perdemos por não mudar?
Passo 4 — Separe sunk cost
Não deixe custo passado contaminar.
Passo 5 — Use reversibilidade
Piloto.
Rollback.
Canary.
Passo 6 — Reduza tamanho da aposta
Mudança incremental.
Passo 7 — Mostre dois frames
Ganho e perda.
Passo 8 — Defina risk tolerance
Qual perda é aceitável?
Passo 9 — Pergunte o que realmente está sendo protegido
Tecnologia?
Controle?
Identidade?
Passo 10 — Reavalie depois
A percepção mudou?
🧠 Small Bets
Loss Aversion cresce com tamanho da perda possível.
Então uma defesa prática é:
reduzir blast radius.
Não substitua tudo.
Teste uma parte.
Agora a perda máxima fica menor.
Isso torna decisão mais racional.
🧪 Pilot
Sistema novo.
Em vez de:
Big Bang.
Use:
5% de usuários.
Meça.
Rollback.
Aprenda.
Agora Loss Aversion não precisa dominar porque risco foi diminuído objetivamente.
🧠 Reversibility reduz sensação de perda
Se podemos voltar:
mudar não significa abandonar para sempre.
Isso reduz peso psicológico.
Feature flags são ótimas nesse sentido.
💻 COBOL strangler modernization
Em vez de:
“Jogar tudo fora.”
Podemos:
envolver COBOL com APIs;
separar uma função;
mover componente onde fizer sentido;
comparar.
Agora não estamos “perdendo o mainframe.”
Estamos construindo opções.
☕ Não faça a discussão virar “legado versus futuro”
Isso ativa identidade e Loss Aversion.
Melhor:
“Quais workloads ficam melhores em cada arquitetura?”
Muito mais produtivo.
🧠 Loss Aversion em incidentes
War Room.
Temos sistema degradado.
Rollback pode perder uma hora de processamento.
Continuar pode produzir perda de dados.
A equipe hesita porque rollback cristaliza perda imediatamente.
Isso é crítico.
🛑 Cut Losses
Às vezes a melhor ação é:
aceitar pequena perda conhecida para evitar perda maior.
Esse princípio aparece em finanças, engenharia e incidentes.
Mas psicologicamente é difícil.
📊 Exemplo
Continuar:
50% chance de recuperar
50% chance de corromper 1M registros
Rollback:
perda certa de 30 min de processamento
A perda certa dói.
Então equipe pode apostar no continue.
Isso é onde Loss Aversion e risk-seeking in losses podem aparecer.
🧠 Curiosidade fascinante da Prospect Theory
Quando pessoas estão no domínio das perdas, podem tornar-se mais dispostas a correr riscos para evitar reconhecer uma perda certa.
Isso parece paradoxal.
Somos avessos à perda...
mas justamente para evitar uma perda garantida podemos aceitar uma aposta pior.
Exemplo:
rollback = perda certa.
Continuar = talvez salve tudo.
A organização aposta.
E pode perder muito mais.
🎰 Double or Nothing corporativo
Projeto ruim.
Cancelar:
perda certa de R$ 5M.
Continuar:
30% de recuperar.
70% de perder mais R$ 5M.
Alguém pensa:
“Vamos tentar.”
Agora Loss Aversion vira gambling.
🧠 Sunk Cost + Loss Domain Risk Seeking
Essa combinação explica projetos que continuam absurdamente.
A organização não quer cristalizar a perda.
Então aceita risco crescente.
É exatamente o oposto da prudência.
☕ “Já estamos no prejuízo”
Essa frase pode mudar comportamento.
Pessoa se torna:
mais agressiva;
mais disposta a apostar.
Porque quer voltar ao zero.
Mercado financeiro conhece muito isso.
TI também deveria.
🎯 Pergunta Bellacosa nº 4
“Estamos aceitando risco adicional apenas para evitar registrar uma perda que já existe?”
Pergunta poderosa.
📓 Incident Decision Board
Durante crise:
OPTION A: ROLLBACK
Known loss: 30 min processing
Max loss: controlled
OPTION B: CONTINUE
Possible gain: avoid rollback
Possible loss: data corruption
Agora decisão deixa de ser:
“Não quero perder 30 minutos.”
Vira:
comparação de riscos.
🧠 Outcome Bias depois
Se continuamos e funciona:
“Viu? Foi corajoso.”
Talvez tenha sido uma aposta ruim que deu certo.
Outcome Bias legitima.
Se falha:
“Era óbvio.”
Hindsight Bias.
Decision log ajuda.
📝 Predecision Record
Antes:
DECISION: CONTINUE
RATIONALE:
Expected impact lower than rollback
KNOWN RISKS:
Data inconsistency
CONFIDENCE:
60%
Depois avaliamos processo.
Não só outcome.
🧠 Loss Aversion + Authority Gradient
Diretor possui projeto.
Cancelar significa:
“perder” reputação.
Equipe técnica pode perceber.
Mas não confronta.
Agora uma aversão à perda pessoal vira risco organizacional.
👥 Groupthink
Todos sabem que parar significa reconhecer perda.
Ninguém quer ser quem pronuncia:
“fracassou.”
Então sala converge em:
“vamos mais um pouco.”
Groupthink protege loss aversion coletiva.
🧠 Psychological Safety novamente
Uma cultura madura precisa permitir:
“Essa hipótese não funcionou.”
Sem transformar em:
“alguém falhou como pessoa.”
Isso reduz necessidade de defender investimentos ruins.
💡 Experimentos não “perdem” quando invalidam hipótese
POC não atingiu meta?
Talvez seja sucesso.
Aprendeu cedo.
Se organização enxerga isso como fracasso:
pessoas escondem resultados negativos.
Loss Aversion gera bad science corporativa.
🧪 Cheap Learning
O melhor experimento é aquele que permite:
descobrir barato.
Então:
perda pequena hoje
pode evitar enorme perda amanhã.
Isso é oposto do Present Bias.
🧠 Stop-Loss novamente
Defina antes:
STOP IF:
Cost > X
Failure rate > Y
Benefit < Z
Quando trigger chega:
parar não é “aceitar derrota.”
É executar governança.
☕ O STOP não é fracasso
Em operação:
STOP pode proteger dados.
Em projeto:
cancelamento pode proteger capital.
Em código:
deletar solução pode reduzir complexidade.
Perder algo pode ser a forma de preservar algo maior.
🧠 Pruning
Biologia remove galhos.
Sistemas também precisam.
Aplicações.
Features.
Permissões.
Processos.
Código.
Uma organização incapaz de abrir mão acumula complexidade indefinidamente.
💾 Digital Hoarding arquitetural
“Nunca desligue nada.”
Resultado:
centenas de aplicações.
Milhares de interfaces.
Dependências desconhecidas.
Loss Aversion pode produzir acumulação tecnológica.
🧠 Complexity has carrying cost
Cada coisa mantida possui:
patch;
monitoramento;
documentação;
segurança;
skills;
licença.
Não remover também custa.
🎯 Pergunta Bellacosa nº 5
“Quanto estamos pagando por ano apenas para evitar a sensação de desligar isto?”
Essa dói.
Por isso é boa.
📋 Checklist anti-Loss Aversion
[ ] O que exatamente temos medo de perder?
[ ] Essa perda é objetiva ou emocional?
[ ] Quanto vale o que estamos protegendo?
[ ] Qual é o custo de continuar?
[ ] Qual oportunidade perdemos se não mudar?
[ ] Estamos presos por sunk cost?
[ ] A perda possível é reversível?
[ ] Podemos reduzir o blast radius?
[ ] Estamos avaliando ganhos e perdas com a mesma régua?
[ ] O framing da decisão está influenciando?
[ ] Estamos correndo mais risco para evitar reconhecer uma perda certa?
[ ] Existe stop-loss?
[ ] Se não possuíssemos a solução atual, escolheríamos comprá-la hoje?
[ ] Estamos protegendo valor ou identidade?
🧬 Regeneração organizacional
Uma organização madura contra Loss Aversion aprende a:
quantificar perdas atuais;
medir opportunity costs;
separar sunk costs;
criar pilotos reversíveis;
reduzir apostas;
definir stop-loss;
aceitar cancelamentos;
aposentar sistemas;
remover privilégios;
e tratar aprendizado como valor.
Principalmente:
ela entende que:
perder uma coisa pequena pode ser exatamente o preço necessário para não perder algo muito maior.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Loss Aversion é a tendência de sentir perdas mais intensamente que ganhos equivalentes.
Aquilo que já possuímos tende a parecer mais valioso.
Status Quo Bias fica mais forte quando mudança é percebida como perda.
Sunk Cost Fallacy pode transformar cancelamento em dor psicológica, mesmo quando economicamente é racional.
Omission Bias pode surgir porque agir cria perdas visíveis.
Present Bias torna custos imediatos mais salientes que benefícios futuros.
Em situações de perda, pessoas podem aceitar riscos maiores para tentar evitar uma perda certa.
Reversibilidade e pequenas apostas reduzem distorção.
Opportunity Cost também é perda, mesmo sendo menos visível.
Retirar, desligar e cancelar também podem ser boas decisões de engenharia.
E principalmente:
Não proteja aquilo que possui apenas porque dói imaginar perdê-lo. Proteja aquilo cujo valor futuro realmente merece ser protegido.
🕰️ De volta à reunião das 08:42
Nosso jovem abre uma nova tabela.
O QUE PODEMOS PERDER SE MUDARMOS
- estabilidade temporária
- tempo de migração
- treinamento
- dinheiro inicial
Depois:
O QUE PERDEMOS SE NÃO MUDARMOS
- R$ 3M/ano
- margem batch
- 170 intervenções/mês
- disponibilidade de skills
- velocidade de mudança
O gerente observa.
— Nunca olhamos dessa forma.
O Doctor responde:
— Normal.
— Por quê?
— Uma perda que ainda não possuímos parece menos real.
Eles decidem:
não fazer Big Bang.
Piloto.
10% do fluxo.
Rollback validado.
Três meses.
Resultado:
intervenções caem.
Performance permanece.
Nova fase.
Depois outra.
Um ano depois:
grande parte da funcionalidade modernizada.
Algumas rotinas COBOL permanecem.
Porque continuam sendo a melhor opção.
Outras são removidas.
Porque já não são.
O gerente encontra nosso programador.
— Então não perdemos o mainframe.
Ele sorri.
— Nunca foi esse o objetivo.
— E qual era?
— Parar de confundir mudança com perda.
O Doctor coloca as mãos nos bolsos.
— Excelente.
🥚 Easter Egg final
No dia seguinte aparece:
BELLACOSA.BIAS(LOSS)
Dentro:
IF FEAR-OF-LOSS = 'HIGH'
PERFORM CALCULATE-STAY-COST
END-IF.
IF CURRENT-SYSTEM = 'OURS'
PERFORM ASK-IF-WE-WOULD-BUY-TODAY
END-IF.
IF CERTAIN-LOSS < POSSIBLE-CATASTROPHE
PERFORM REVIEW-RISK
END-IF.
Comentário:
* WHAT YOU HAVE
* IS NOT AUTOMATICALLY
* WHAT YOU SHOULD KEEP.
Outro:
* SMALL LOSSES CAN PROTECT
* BIGGER VALUES.
Mais um:
* DON'T GAMBLE THE SYSTEM
* JUST TO GET BACK TO ZERO.
E naturalmente:
* BAD WOLF HATED LOSING.
* THE DALEKS DID TOO.
Nosso jovem fecha o membro.
Pouco depois chega mensagem:
— Temos uma rotina antiga que custa muito, mas ninguém quer desligar.
Ele pergunta:
— Por quê?
— Medo de perder funcionalidade.
— Quem usa?
— Não sabemos.
— Então primeiro vamos descobrir o que realmente perderíamos.
Analytics.
Entrevistas.
Logs.
Descobrem:
três usuários.
Uma única função crítica.
Extraem a função.
Desligam o restante.
Nenhum desastre.
Nenhuma revolução.
Apenas uma coisa curiosa:
depois de desligado, quase ninguém sente falta.
O Doctor provavelmente sorriria.
Porque aquilo parecia extremamente valioso enquanto estava prestes a desaparecer.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro fica:
Às vezes o medo de perder protege o que importa. Às vezes protege apenas aquilo com que nos acostumamos. Engenharia é descobrir a diferença.
☕🌀
Next stop: Framing Effect — quando duas descrições matematicamente equivalentes conseguem levar a decisões completamente diferentes apenas porque uma diz “90% de sucesso” e a outra diz “10% de falha”.
Sem comentários:
Enviar um comentário