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

Translate

quinta-feira, 17 de outubro de 2013

Goal Gradient Effect: Doctor Who, COBOL e o Dia em que Faltavam Apenas Três Por Cento para Fazermos uma Grande Besteira

 

Bellacosa Mainframe e o goal gradient effect

☕ Um Café no Bellacosa Mainframe

Goal Gradient Effect: Doctor Who, COBOL e o Dia em que Faltavam Apenas Três Por Cento para Fazermos uma Grande Besteira

Uma viagem pela TARDIS dos incidentes para entender por que quanto mais perto estamos de uma meta, maior tende a ser nossa motivação — e por que justamente a reta final pode concentrar pressa, fadiga, atalhos, vieses e alguns dos maiores riscos de um sistema crítico

Sexta-feira.

17:42.

Esse horário deveria existir no catálogo oficial de riscos operacionais.

Não porque alguma lei da física torne computadores particularmente instáveis às sextas-feiras.

Mas porque existe uma variável muito mais complicada ligada ao sistema:

seres humanos querendo ir embora.

Na War Room temos:

dois programadores;

um DBA;

um analista de produção;

um gerente;

um especialista em segurança;

quatro canecas;

uma garrafa térmica quase vazia;

e um dashboard gigantesco mostrando:

PROJETO MIGRAÇÃO PAYMENTS-X

███████████████████░

97% COMPLETE

Nosso jovem programador COBOL olha.

— Noventa e sete por cento.

O gerente sorri.

— Praticamente pronto.

O DBA olha para uma planilha.

— Falta validar o rollback da alteração de schema.

Silêncio.

O analista de produção acrescenta:

— E o restore completo ainda não foi testado.

O gerente olha novamente para:

97%

— Mas estamos praticamente prontos.

Nosso jovem pergunta:

— A reconciliação dos valores terminou?

— Temos amostragem.

— Completa?

— Não.

— E o teste de restart do batch?

— Fizemos um parcial.

— Então...

Ele aponta para o painel.

— De onde vieram os 97%?

O gerente responde:

— Noventa e sete tarefas de cem foram concluídas.

Nosso jovem começa a rir.

Não porque fosse engraçado.

Porque percebeu uma coisa extraordinária.

As três tarefas restantes eram:

98. VALIDAR RESTORE
99. VALIDAR ROLLBACK
100. VALIDAR RECONCILIAÇÃO

Ou seja:

haviam terminado 97 coisas.

E deixado para os últimos 3%:

as três coisas capazes de transformar uma implantação ruim numa madrugada histórica.

VWORP.

VWORP.

VWORP.

A TARDIS surge entre uma impressora e a máquina de café.

A porta abre.

O Doctor aparece.

Observa:

97%

Depois observa:

ROLLBACK ........ PENDING
RESTORE ......... PENDING
RECONCILIATION .. PENDING

Ele olha para a equipe.

— Imagino que estejam discutindo adiar o Go-Live.

Gerente:

— Na verdade estamos discutindo seguir.

— Por quê?

— Porque estamos em 97%.

O Doctor olha para nosso jovem COBOL.

— Isso é uma unidade de risco?

— Não.

— Unidade de prontidão?

— Também não.

— Unidade de integridade?

— Não.

O Doctor sorri.

— Então vocês estão prestes a tomar uma decisão técnica baseados em...

Pausa dramática.

— uma barra de progresso.

Bem-vindo ao:



Goal Gradient Effect

ou:

Efeito Gradiente de Meta.


🧠 O que é Goal Gradient Effect?

Em termos simples:

quanto mais próximos sentimos que estamos de alcançar uma meta, maior tende a ficar nossa motivação para completá-la.

Quando o objetivo está longe:

procrastinamos;

distribuímos esforço;

fazemos pausas;

mudamos de prioridade.

Quando a linha de chegada aparece:

aceleramos.

Isso pode ser excelente.

Também pode ser perigosíssimo.

Em linguagem Bellacosa:

quando a barra passa de 90%, nosso cérebro começa a executar um PERFORM UNTIL DONE que nem sempre consulta o manual operacional antes de continuar.


🐀 A história começa antes do COBOL

A ideia do Goal Gradient é antiga na psicologia comportamental.

Experimentos clássicos observaram que animais aumentavam o esforço conforme se aproximavam de uma recompensa.

Imagine um rato percorrendo um corredor em direção à comida.

No início:

ritmo normal.

Quanto mais próximo da recompensa:

mais rápido.

Nós somos ligeiramente mais sofisticados.

Temos:

PowerPoint;

Jira;

dashboards;

badges;

milhas aéreas;

certificados;

XP;

barra de progresso.

Mas nosso cérebro também gosta daquela sensação:

“Falta pouco.”


☕ O cartão do café explica muita coisa

Imagine:

COMPRE 10 CAFÉS
GANHE 1 GRÁTIS

Você tem:

1 carimbo.

Não existe urgência.

Agora você tem:

De repente o décimo café parece:

necessário.

Talvez você nem quisesse café naquele momento.

Mas:

falta apenas um.

Esse “apenas um” é poderoso.


🧠 Progress Bar

É por isso que:

███████████████████░ 95%

é psicologicamente diferente de:

████░░░░░░░░░░░░░░░░ 20%

Nos dois casos existe trabalho restante.

Mas a percepção muda.


☕ Você conhece isso

Download:

12%

Você vai fazer outra coisa.

Download:

98%

Você fica olhando.

Como se sua presença:

ajudasse os pacotes IP.

Não ajuda.

Mas estamos todos juntos nisso.


🧠 Endowed Progress Effect

Existe um fenômeno relacionado muito interessante:

Endowed Progress Effect.

Imagine dois cartões.

Primeiro:

8 CAFÉS

0 / 8

Segundo:

10 CAFÉS

2 / 10 JÁ CARIMBADOS

Nos dois casos faltam:

8 cafés.

Mas o segundo cria:

sensação de progresso prévio.

Você já começou.

Isso pode aumentar motivação.

Por isso programas de fidelidade, cursos e aplicativos frequentemente mostram:

progresso inicial.


☕ Em treinamento isso pode ser maravilhoso

Curso de COBOL:

[✔] Ambiente preparado
[✔] Primeiro programa
[ ] Variáveis
[ ] PERFORM
[ ] Arquivos
[ ] VSAM
[ ] Db2
[ ] CICS

Você já:

começou.

Agora existe:

movimento.


🧠 Goal Gradient não é inimigo

Esse ponto é fundamental.

O efeito pode ser:

fantástico para aprendizagem.

Em vez de:

APRENDER COBOL

uma missão equivalente a:

DERROTAR O IMPÉRIO GALÁCTICO,

quebre:

1. Estrutura do programa
2. PIC
3. MOVE
4. COMPUTE
5. IF
6. EVALUATE
7. PERFORM
8. Arquivos
9. VSAM
10. Db2

Agora existem:

linhas de chegada pequenas.

Cada conclusão:

gera sensação de avanço.


🧠 Microgoals

Metas pequenas podem reduzir:

procrastinação

e aumentar:

persistência.

Essa é a versão saudável do Goal Gradient.


👻 Easter Egg nº 1 — TARDIS 99%

Companion:

— Doctor! Terminei 99% do reparo da TARDIS!

— Excelente.

— Vamos viajar?

— O que falta?

— Os freios temporais.

Doctor:

— Então você terminou 99% do checklist e aproximadamente zero por cento da parte que eu gostaria de testar antes de atravessar o espaço-tempo.

Essa é uma lição extraordinariamente importante:

percentual de tarefas concluídas não significa percentual de risco eliminado.


🧠 O problema dos 99%

Imagine:

100 tarefas.

99 são:

relatórios;

labels;

documentação;

scripts;

configurações.

A centésima:

VALIDAR RECUPERAÇÃO DE DADOS

Dashboard:

99% COMPLETE

Risk dashboard:

talvez:

RECOVERY CONFIDENCE:
UNKNOWN

São coisas completamente diferentes.


☕ “Falta pouco” é uma descrição quantitativa

Não qualitativa.


🧠 Completion versus Readiness

Essa distinção deveria existir em praticamente todo projeto crítico.

Você pode ter:

DEVELOPMENT COMPLETE .... 100%

mas:

OPERATIONAL READINESS .... 65%

O código terminou.

O sistema:

não.


🧠 O velho “código pronto”

Programador:

— Código está pronto.

Gerente:

— Excelente! Produção amanhã.

Programador:

— Calma.

Teste?

Integração?

Performance?

Security?

Dados?

Rollback?

Documentação?

Runbook?

Monitoring?

Treinamento?


☕ “Código pronto”

é apenas uma versão tecnológica de:

“O avião está pronto. Só falta descobrir se voa.”


🧠 Os primeiros 90% e os outros 90%

Existe uma piada clássica em desenvolvimento:

Os primeiros 90% do projeto consomem 90% do tempo.
Os últimos 10% consomem os outros 90%.

Matematicamente:

absurdo.

Gerencialmente:

assustadoramente familiar.

Porque o final contém:

integração;

edge cases;

migrations;

bugs;

deploy;

rollback;

acceptance.


🧠 Planning Fallacy entra

Nós subestimamos:

o trabalho restante.

Então chegamos aos:

90%

achando:

“quase acabou”.

Mas talvez aquele 10% seja:

metade do esforço.


💻 COBOL matemático

Imagine:

90 tarefas:

1 hora cada.

10 tarefas:

20 horas cada.

Concluímos:

90 tarefas.

Dashboard:

90%

Horas totais:

90 + 200 = 290

Horas concluídas:

90

Trabalho realizado:

aproximadamente:

31%.

Parabéns.

Seu dashboard acabou de tomar um:

S0C7 conceitual.


🧠 Weighted progress

Poderíamos pesar:

tarefas.

Mas ainda existe problema:

peso também é:

estimativa.

Então:

melhore o indicador.

Mas nunca trate:

como verdade absoluta.


🧠 Goodhart’s Law entra na War Room

Objetivo:

entregar sistema funcional.

Métrica:

tarefas concluídas.

Quando:

tarefas concluídas

viram:

meta,

Goodhart aparece.

A equipe pode:

fechar tickets.

Quebrar trabalho.

Escolher tarefas fáceis.

O número melhora.


☕ Goal Gradient coloca turbo no Goodhart

Se estamos em:

95%,

há ainda mais motivação para:

fechar qualquer coisa que transforme:

95

em:


🧠 Campbell’s Law aparece com o bônus

Agora diga:

“O bônus depende de entregar sexta.”

Pronto.

Metric:

100%.

Money:

attached.

Reputation:

attached.

Executive expectation:

attached.

Aquela barra não é mais:

visualização.

Virou:

parte do sistema de incentivos.


🧠 Goal Gradient + Campbell

Quanto mais perto:

maior a motivação natural.

Quanto maior a consequência:

maior a pressão social.

Resultado:

a reta final fica psicologicamente carregada.


🧠 Goal Substitution

Começamos com:

entregar sistema seguro.

Depois:

completar projeto.

Depois:

atingir 100%.

Agora:

a barra substituiu o objetivo.

Goal Substitution.


☕ O velocímetro virou destino

Mais uma vez.


🧠 Ratchet Effect aparece segunda-feira

Equipe trabalha:

sexta;

sábado;

domingo.

Entrega.

Executivo diz:

— Excelente! Agora sabemos que vocês conseguem.

Próximo projeto:

prazo 20% menor.

Goal Gradient gerou:

heroic sprint.

Ratchet transforma:

heroic sprint

em:

capacidade normal.

Excelente receita para:

burnout.


🌀 O ciclo

META PRÓXIMA
    ↓
MOTIVAÇÃO ↑
    ↓
ESFORÇO HEROICO
    ↓
SUCESSO
    ↓
OUTCOME BIAS
    ↓
RATCHET
    ↓
NOVA META MAIS ALTA

E:

repeat.


🧠 Present Bias

Agora é sexta.

Queremos:

terminar agora.

Custos podem ir:

para segunda.

Então aparecem frases:

“Documentamos depois.”

“Refatoramos depois.”

“Corrigimos isso no hypercare.”

“Depois automatizamos.”

“Depois entendemos a causa.”


AFTER GO-LIVE

É um dataset particularmente perigoso.

Muitos registros entram.

Poucos saem.


🧠 Sunk Cost Fallacy

Projeto:

97%.

Gastamos:

18 meses.

Surge risco grave.

Argumento:

“Não podemos parar agora.”

Por quê?

Talvez exista:

boa justificativa econômica.

Mas talvez sejam:

18 meses já gastos.

Sunk Cost.

Goal Gradient acrescenta:

“E falta só 3%!”

Agora:

passado + proximidade

empurram:

continuidade.


🎯 O teste Bellacosa dos 20%

Quando alguém disser:

“Mas estamos quase acabando!”

pergunte:

“Se estivéssemos em 20%, tomaríamos exatamente essa mesma decisão com essa evidência?”

Se resposta:

não,

pare.

Talvez o progresso esteja:

participando indevidamente da decisão.


🧠 Action Bias na reta final

Um erro aparece.

Todo mundo quer:

fazer alguma coisa.

Porque relógio corre.

A meta está:

perto.

Action Bias:

restart.

Fix.

Patch.

Change.

Agora.

Talvez seja correto.

Mas:

investigue.


☕ O relógio do projeto não é root cause

Mesmo que grite muito.


🧠 Omission Bias

Também podemos acelerar:

não fazendo.

“Pula aquele teste.”

Não parece:

ação perigosa.

É:

omissão.

Mas:

não executar controle

é uma decisão.


🧠 Optimism Bias

Últimos 18 testes:

passaram.

Falta um.

“Vai passar.”

Talvez.

Mas:

não testamos para confirmar esperança.

Testamos justamente porque:

podemos estar errados.


🧠 Recency Bias

Os testes recentes foram:

bons.

Então o futuro parece:

bom.

Mas último teste pode ser:

diferente.


🧠 Confirmation Bias

Queremos lançar.

Então buscamos:

evidências de prontidão.

Os sinais negativos começam a virar:

“detalhes”.


☕ “Detalhe”

é uma palavra que cresce muito perto do deadline.


🧠 Framing Effect

Compare:

97% concluído

com:

rollback não validado

Mesmo projeto.

Emocionalmente:

histórias completamente diferentes.

O primeiro:

convida a continuar.

O segundo:

convida a pensar.


👻 Easter Egg nº 2 — Dalek PMO

Dalek Project Manager:

— PROJECT COMPLETION: 99%.

Doctor:

— O que falta?

— SECURITY VALIDATION.

— Importante?

— POTENTIAL PLANETARY DESTRUCTION.

— Então como vocês chegaram a 99%?

— 99 OF 100 TASKS COMPLETED.

Doctor:

— Vocês transformaram matemática administrativa em avaliação de risco.

Dalek:

— CORRECT.

Doctor:

— Isso não foi elogio.


🧠 Authority Gradient

Agora imagine:

CEO presente.

Diretor.

Gerente.

Todo mundo:

quer lançamento.

Júnior COBOL encontra:

uma inconsistência.

Ele diz?

Esse é outro problema.

Quanto mais perto:

maior pressão:

“Não seja você quem vai atrasar tudo.”


🧠 Psychological Safety

A equipe precisa acreditar:

qualquer pessoa pode:

parar.

Se risco legítimo.

Não importa:

cargo.

Não importa:

97%.


🎯 Pergunta Bellacosa

“Alguém aqui realmente pode dizer NO-GO?”

Não teoricamente.

Realmente.


🧠 Precommitment

Essa é uma defesa fantástica.

Defina antes:

NO-GO SE:

[ ] ROLLBACK NÃO VALIDADO
[ ] RESTORE NÃO TESTADO
[ ] RECONCILIAÇÃO FALHAR
[ ] SEV-1 ABERTO

Defina quando:

ninguém está:

cansado;

pressionado;

apaixonado pelos 97%.

Então:

sexta-feira,

não renegocie.


☕ O checklist protege você

da versão futura de você

que só quer ir para casa.


🧠 Stop the Line

Se condição crítica:

não passou,

status:

NO-GO

Mesmo:

99,9%.


🧠 Um 1% pode conter 100% do desastre

Essa é provavelmente a frase central do artigo.

O percentual mede:

quantidade.

Risco mede:

consequência × probabilidade.

Não são:

a mesma dimensão.


🧠 Segurança e o último quilômetro

Pense num voo.

São Paulo → Lisboa.

Aeronave percorreu:

99% da distância.

Piloto anuncia:

— Já completamos 99%. Vamos pular o checklist de pouso.

Você:

não ficaria particularmente feliz.

Por quê?

Porque:

os últimos minutos não são menos importantes porque o resto já aconteceu.

Na verdade:

pouso é:

fase crítica.


☕ O Go-Live é o pouso

Quanto mais perto:

mais disciplina.

Não:

menos.


🧠 A regra Bellacosa dos últimos 10%

Passou:

90%?

Menos euforia.

Mais:

evidência.

Passou:

95%?

Menos improviso.

Mais:

checklist.

Passou:

99%?

Não pergunte:

quanto falta?

Pergunte:

o que falta?

Essa pequena mudança:

vale ouro.


🧠 Hypercare muda a linha de chegada

Outro erro:

DONE = GO-LIVE

Talvez deveria ser:

DONE =
GO-LIVE
+
STABILITY
+
RECONCILIATION
+
HANDOVER
+
NO CRITICAL DEFECT

Agora:

Goal Gradient continua funcionando.

Mas em direção:

à meta certa.


☕ Esse é o truque

Não eliminar:

Goal Gradient.

Desenhar a linha de chegada corretamente.


🧠 Goal Architecture

Projetamos:

arquitetura de software.

Também deveríamos projetar:

arquitetura de metas.

Qual é:

objetivo real?

O que é:

milestone?

O que é:

proxy?

O que é:

Done?

Quais:

guardrails?


🧠 Exemplo ruim

Goal:

GO LIVE FRIDAY

Exemplo melhor:

SERVICE OPERATIONAL
WITH VALIDATED DATA
AND RECOVERABILITY

Sexta-feira:

é data.

Não:

outcome.


🧠 Goal Gradient no aprendizado COBOL

Agora vamos usar:

a favor.

Você é iniciante.

Não diga:

vou estudar COBOL.

Faça:

COBOL FILES

[✔] SELECT
[✔] FD
[✔] OPEN
[✔] READ
[ ] FILE STATUS
[ ] LAB

Agora:

4/6.

Seu cérebro:

quer os dois restantes.

Excelente.


🧠 Mas o LAB deve ficar no final

Porque o objetivo:

não é:

assistir aulas.

É:

fazer.


☕ O certificado diz:

“você terminou”.

O laboratório diz:

“você aprendeu alguma coisa”.

Diferente.


🧠 Goal Gradient + Campbell na educação

Empresa exige:

100% treinamento.

Pessoa está:

95%.

Deadline:

hoje.

Assiste:

restante em 2x.

Completion:

100%.

Skill:

?

Goal Gradient:

cumpriu.

Campbell:

pressionou.

Goal Substitution:

concluir virou aprender.

Goodhart:

score verde.

Belo crossover.


🧠 War Room: 95% recuperado

Outro cenário.

Incidente.

Sistema:

95% funcional.

Todos cansados.

Alguém diz:

“Podemos encerrar.”

Mas:

5% dos clientes continuam:

sem serviço.

Para eles:

availability:

0%.


☕ Média corporativa não consola o cliente quebrado

Isso vale lembrar.


🧠 Tail Neglect

A maioria:

voltou.

Agora long tail:

parece menor.

Mas pode conter:

clientes críticos.

Não encerre:

pela porcentagem.


🧠 Goal Gradient em RCA

Estamos quase fechando:

root cause.

Hipótese:

Db2.

Tudo encaixa.

Exceto:

uma mensagem MQ.

Alguém diz:

“Isso provavelmente não tem relação.”

Narrative Bias.

Confirmation Bias.

Goal Gradient.

Todos querem:

fechar RCA.

Mas o pequeno sinal pode:

ser justamente:

a causa real.


🎯 Pergunta Bellacosa

“Qual evidência relevante nossa explicação ainda não consegue explicar?”

Não feche:

porque a história ficou bonita.


☕ House MD aparece

Equipe:

— Todos os sintomas indicam lupus.

House:

— Exceto aquele.

Equipe:

— Talvez não importe.

House:

— Então é exatamente por ele que começaremos.

Em incidentes:

o log estranho

é:

o sintoma estranho.


🧠 Premature Closure

Diagnóstico plausível aparece.

Investigação:

para.

Goal Gradient pode:

aumentar atração pelo encerramento.

Ticket:

CLOSED.

RCA:

DONE.

Dopamina.


CLOSED não é sinônimo de:

CORRECT.


🧠 Goal Gradient em Agile

Sprint termina amanhã.

Temos:

9/10 STORIES

A última:

quase.

Tentação:

DONE.

Teste:

amanhã.

Documentation:

depois.

Agora:

velocity ficou linda.

Quality?

Depois.

Definition of Done protege.


🧠 Definition of Done

DONE =
CODED
AND
TESTED
AND
REVIEWED
AND
DEPLOYABLE

Sem:

90% Done.


☕ “Quase Done”

é:

IN PROGRESS.

Eu sei.

Dói.


🧠 WIP Limits

Kanban ajuda:

não manter:

dez itens a 90%.

Melhor:

nove concluídos,

um em progresso.

Goal Gradient então incentiva:

finish.

Isso é bom.


🧠 Deadline Gradient

Existe também:

o efeito do prazo.

Quanto mais perto:

mais urgência.

Goal Gradient e deadline frequentemente:

viajam juntos.

Resultado:

Student Syndrome.


☕ Prazo sexta

Trabalho começa:

quinta.

O scheduler humano possui:

algumas peculiaridades.


🧠 SLA

Ticket SLA:

4 horas.

Se prioridade só aumenta:

aos 3h50,

você criou:

cliff.

Equipe aprende:

trabalhar perto do breach.

Better:

escalation gradual.


☕ WLM para humanos

Talvez seja uma ideia.

Não espere:

SERVICE CLASS = PANIC.


🧠 Goal Gradient em vendas

Meta:

R$1 milhão.

Estamos:

R$930 mil.

Últimos dias:

desconto.

Negócios antecipados.

Venda futura:

puxada.

Meta:

100%.

Margem:

cai.

Janeiro:

vazio.

Goal Gradient + Present Bias.


🧠 IT equivalent

Fim de sprint.

Tickets:

puxados.

Technical debt:

empurrada.

Mesma dinâmica.


🧠 O projeto condenado em 95%

Outro ponto crítico.

Projeto:

95%.

Novo estudo mostra:

não há mais business case.

Falta:

R$10 milhões.

Benefício futuro:

R$2 milhões.

O racional:

parar.

Mas alguém diz:

“Depois de tudo isso?”

Sunk Cost.

Outro:

“Mas só faltam 5%!”

Goal Gradient.

Agora:

duas forças emocionais

contra:

matemática.


🎯 Pergunta Bellacosa

“Se começássemos hoje, pagaríamos o custo restante para obter apenas o benefício futuro restante?”

Se não:

talvez terminar seja erro.


🧠 Kill Criteria

Defina no começo:

STOP PROJECT IF:

BUSINESS CASE < X
COST TO COMPLETE > VALUE
TECHNICAL RISK > LIMIT
REGULATORY NEED DISAPPEARS

Assim:

o 95%

não ganha autoridade moral.


🧠 Goal Gradient pode ser herói

Agora equilíbrio.

Migração legada:

faltam três interfaces.

Ninguém quer:

mexer.

O sistema antigo continua:

vivo.

Mostre:

3
2
1
0

Goal Gradient:

aumenta motivação.

Excelente.


☕ Finalmente desligar o zumbi

é um uso perfeitamente digno.


🧠 Backlog enorme

2.000 itens:

desanimador.

Crie:

lote:

TOP 20 RISCOS

Resolva.

Progress:

visível.

Depois:

próximo.

Chunking + Goal Gradient.


🧠 Mas não escolha apenas os fáceis

Senão:

Easy Task Bias.

Goodhart.

Precisamos:

prioridade por:

valor/risco.


☕ Barra andando rápido

não significa:

problema sendo resolvido rápido.


🧠 Critical Path

Projeto:

90% tarefas done.

Critical path:

bloqueado.

Schedule:

atrasado.

Count:

irrelevante.

Acompanhe:

dependências críticas.


🎯 Pergunta Bellacosa

“Estamos reduzindo a incerteza real ou apenas fazendo checkboxes ficarem verdes?”

Essa pergunta serve:

para quase tudo.


🧠 Risk First

Faça cedo:

integrações difíceis;

data migrations;

performance tests;

unknowns.

Não deixe:

dragões

para:

97%.


☕ Mate o dragão

antes de distribuir os convites para a festa.


🧠 Goal Gradient e fadiga

Essa combinação merece atenção.

Meta aproxima.

Esforço:

sobe.

Fadiga:

sobe.

Capacidade cognitiva:

pode cair.

Então:

queremos agir mais exatamente quando nossa capacidade de decidir bem pode estar piorando.


🧠 War Room longa

02:37.

Alguém:

— Falta só um comando.

Talvez.

Mas quem está digitando:

está há 18 horas acordado.


ENTER

continua tendo o mesmo tamanho

mesmo quando o cérebro está cansado.

O impacto também.


🧠 Rotação

Em incidentes longos:

troque pessoas.

Fresh eyes.

Registre decisões.

O objetivo:

não é:

heroísmo.

É:

resolver.


🧠 Fresh Eyes Review

Antes do Go-Live:

chame alguém:

não emocionalmente envolvido.

Mostre:

remaining risks.

Não:

97%.

Pergunte:

go/no-go?


🎯 Blind Risk Review

Esse é um excelente truque:

não conte:

percentual.

Diga apenas:

rollback não testado; restore parcial; reconciliação incompleta.

Pergunte:

lançaria?

Agora compare resposta:

com aquela dada quando viram:

97%.

Se mudou:

hello Goal Gradient.


🧠 Pre-Mortem

Estamos em:

95%.

Em vez de:

“Como terminamos?”

pergunte:

“Imagine que segunda-feira virou desastre. O que provavelmente ignoramos hoje?”

Isso abre:

visão.


🧠 Devil’s Advocate

Dê a alguém:

função oficial:

argumentar NO-GO.

Assim:

discordar deixa de ser:

hostilidade.

Vira:

papel.


☕ O pessimista oficial

às vezes salva:

um fim de semana inteiro.


🧠 Goal Gradient e Groupthink

Todos:

animados.

Meta:

perto.

Ninguém quer:

estragar clima.

Groupthink.

Authority Gradient.

Goal Gradient.

Perfeito para:

esconder sinal fraco.


🎯 Pergunta Bellacosa

“Quem nesta sala está autorizado a ser inconveniente?”

Essa pessoa:

é controle de segurança.


🧠 Scope Creep final

Perto do Go-Live aparece:

— Já que estamos mexendo...

Não.

Freeze.

Última hora:

não é momento:

para feature.


☕ A feature “rapidinha”

das 17:30

tem tradição própria.


🧠 Goal Gradient e AI Agents

Agora entramos num ponto moderno.

Imagine agente:

objetivo:

100 tarefas.

Ele completou:

Reward:

alto em 100.

Pode intensificar:

ações.

Talvez:

criar subtasks simples.

Cobra Effect.

Talvez:

marcar tarefa como concluída cedo.

Goodhart.

Talvez:

assumir risco.

Moral Hazard.


🤖 Guardrails devem ser invariáveis

Nunca:

IF PROGRESS > 95
    REDUCE SAFETY
END-IF

Absurdo para código.

Surpreendentemente familiar:

para humanos.


🧠 Completion Reward

Agentes são particularmente sensíveis à:

função objetivo.

Se completion tem:

reward enorme,

precisamos verificar:

resultado real.


TASK STATUS = DONE

não significa:

universo concordou.


🧠 Goal Gradient e automação de incidentes

Auto-remediation:

95% serviço recuperado.

Último componente:

stateful.

Não force:

porque falta pouco.

Use:

risk policy.

Business priority.


🧠 WLM sabe disso

z/OS WLM não deveria pensar:

“Esse job já executou 98%, então agora tudo deve sair da frente.”

Ele considera:

service goals.

Importance.

Policy.

Humanos também precisam.


☕ Mainframe ensinando psicologia outra vez

Não é pouca coisa.


🧠 Goal Gradient e Error Budgets

Um exemplo interessante de efeito usado:

para cautela.

Error budget:

está perto de acabar.

Conforme limite aproxima:

equipe reduz:

changes arriscadas.

Aqui proximidade do objetivo/limite:

muda comportamento na direção:

segura.

Excelente.


🧠 O segredo está em definir a meta

Se meta:

“sexta-feira”,

corremos:

para sexta.

Se meta:

“30 dias estáveis”,

corremos:

para estabilidade.


🎯 Pergunta Bellacosa central

“Nossa linha de chegada está localizada no lugar certo?”

Porque comportamento:

irá gravitar em direção a ela.


🧠 Goal Gradient + Metric Fixation

Agora nosso capítulo anterior entra.

Se dashboard mostra:

97%,

Metric Fixation pode fazer:

organização acreditar que:

97%

é:

realidade objetiva.

Goal Gradient então:

acelera.

Combinação:

o número ganha autoridade e proximidade ganha urgência.


☕ Resultado:

barra de progresso vira:

Incident Commander.

Não deveria.


🧠 Metric Fixation antidote

Não mostre somente:

97%

Mostre:

DELIVERY ........ 97%
RECOVERY ........ 60%
DATA ............ 75%
OPS READINESS ... 68%
SECURITY ........ 92%

Agora:

menos sexy.

Mais útil.


🧠 Risk retired

Outra alternativa:

quanto risco eliminamos?

Não apenas:

tasks.


🧠 Goal Substitution antidote

Coloque objetivo em cima:

GOAL:
SAFE AND CORRECT PAYMENT PROCESSING

Depois:

metrics.

Não o contrário.


☕ Métrica abaixo.

Missão acima.

Literalmente.


🧠 A TARDIS cognitiva completa

Veja como os capítulos se conectam:

Goal Substitution: escolhemos proxy e esquecemos objetivo.

Metric Fixation: tratamos proxy como realidade.

Goodhart: o proxy vira meta e degrada.

Campbell: consequência social aumenta pressão.

Goal Gradient: proximidade da meta aumenta esforço.

Ratchet: sucesso vira nova meta mínima.

Cobra Effect: incentivo pode começar a produzir o próprio problema.

Sunk Cost: investimento passado dificulta parar.

Present Bias: custos futuros são empurrados para depois.

Action Bias: pressão manda agir.

Omission Bias: também podemos pular controles.

Optimism Bias: acreditamos que vai funcionar.

Authority Gradient: ninguém quer contrariar liderança.

Quando todos aparecem:

você não tem:

um simples projeto.

Você tem:

um crossover especial de duas horas da BBC chamado “The Go-Live of Doom”.


👻 Easter Egg nº 3 — Doctor pergunta ao dashboard

Doctor:

— Estamos prontos?

Dashboard:

— 99%.

Doctor:

— Não perguntei quanto terminamos.

— 99%.

— Perguntei se estamos prontos.

— 99%.

Doctor olha para Companion.

— Acho que o dashboard entrou em management.


🧠 Bellacosa Last Mile Review

Quando passar de:

90%,

rode:

WHAT REMAINS?

WHAT IS CRITICAL?

WHAT IS UNTESTED?

WHAT IS IRREVERSIBLE?

WHAT WOULD MAKE US STOP?

WHO CAN SAY NO?

WHAT HAPPENS AFTER GO-LIVE?

IS THIS SUSTAINABLE?

Muito mais poderoso:

que:

97%

🧪 Passo a passo para usar Goal Gradient corretamente

Passo 1 — Defina o outcome

Não:

“100% complete.”

Mas:

“serviço operando corretamente.”

Passo 2 — Quebre em milestones

Metas próximas:

motivam.

Passo 3 — Faça progresso visível

Use:

barra;

checklist;

countdown.

Passo 4 — Não trate tasks como pesos iguais

Criticality.

Risk.

Effort.

Passo 5 — Faça hard things cedo

Risk first.

Passo 6 — Defina No-Go antecipadamente

Antes:

da pressão.

Passo 7 — Preserve safety gates

Sem negociação:

por proximidade.

Passo 8 — Observe fadiga

Hero mode:

não é grátis.

Passo 9 — Use pre-mortem

Imagine:

falha.

Passo 10 — Mova Done para depois do Go-Live

Inclua:

stability.


📋 Checklist Bellacosa anti-Goal Gradient

[ ] Estamos perto da meta?

[ ] Isso mudou nossa tolerância a risco?

[ ] O que exatamente falta?

[ ] O que falta é crítico?

[ ] Estamos usando task count como readiness?

[ ] Se estivéssemos em 20%, decidiríamos igual?

[ ] Rollback está testado?

[ ] Restore está validado?

[ ] Reconciliação está completa?

[ ] Existe critério No-Go?

[ ] Alguém pode dizer não?

[ ] Estamos cansados?

[ ] Estamos em heroic mode?

[ ] Algum controle foi chamado de “detalhe”?

[ ] Go-Live foi confundido com Done?

🧠 O teste “quanto” versus “o quê”

Gerente:

— Falta quanto?

Resposta:

— 3%.

Pergunta ruim.

Melhor:

— Falta o quê?

Resposta:

— rollback, restore e reconciliation.

Agora temos:

informação.


☕ Nunca pergunte apenas:

quanto falta?

Pergunte:

o que existe dentro do que falta?

Essa talvez seja a melhor frase deste café.


🧠 Goal Gradient no desenvolvimento pessoal

Também use:

para estudar.

Se learning path tem:

40 módulos,

crie:

mini objetivos.

5 módulos.

Lab.

Review.

Outro bloco.

Assim:

Goal Gradient reaparece várias vezes.


🧠 Mas evite binge completion

Chegou:

95%.

Não corra pelo conteúdo:

para badge.

Use energia final:

para revisão.

Lab.

Teste.


☕ Faça a última etapa provar conhecimento

não apenas:

clicar em “concluir”.


🧠 Goal Gradient e certificação

Antes da prova:

course:

100%.

Isso não é:

readiness.

Faça:

mock exam.

Weakness analysis.

Lab.

Again:

Completion ≠ readiness.


🧠 A linha de chegada errada

Se sua meta:

“terminar curso”,

Goal Gradient ajuda terminar.

Se meta:

“ser capaz de resolver problema”,

precisa:

lab.

Defina certo.


🧠 Goal Gradient e projetos de migração

Mostrar:

40 sistemas
↓
12
↓
5
↓
2
↓
0

pode ser:

excelente.

Long tail:

ganha atenção.

Mas:

últimos sistemas tendem a ser:

os mais difíceis.

Por quê?

Os fáceis:

já foram.

Então:

remaining work não é amostra aleatória.


🎯 Pergunta Bellacosa

“Esses últimos itens sobraram por acaso ou justamente porque são os mais difíceis?”

Muito importante.


🧠 Selection Effect

Migração:

95% nodes done.

5% failed.

Não diga:

“95% funcionou, então force os outros.”

Os outros 5% foram:

selecionados por falhar.

Possuem:

características diferentes.


☕ O último servidor talvez não seja azarado

Talvez seja:

professor.


🧠 Goal Gradient em security remediation

100 vulnerabilities.

90 low.

10 critical.

90% closed.

Mas:

risk?

Talvez:

20% reduced.

Use:

risk-weighted progress.


🧠 Quantity versus consequence

Reaparece.


🧠 Goal Gradient e observabilidade

Se só existe:

progress score,

Metric Fixation.

Adicione:

remaining risk.

Unknowns.


UNKNOWN

é permitido.

Muito mais honesto que:

97.3%.


🧠 Goal Gradient e continuidade

Backup migration:

99%.

Remaining:

key encryption validation.

Não force.

Sometimes:

last task

contains:

entire control.


👻 Easter Egg nº 4 — COBOL

Nosso jovem encontra:

BELLACOSA.BIAS(GOAL-GRADIENT)

Código:

       IF PROJECT-PERCENT > 90
           PERFORM REVIEW-REMAINING-RISK
       END-IF.

       IF PROJECT-PERCENT > 95
          AND ROLLBACK-VALIDATED = 'N'
           MOVE 'NO-GO'
             TO RELEASE-STATUS
       END-IF.

       IF TEAM-SAYS 'FALTA-POUCO'
           PERFORM ASK-WHAT-REMAINS
       END-IF.

       IF REMAINING-ITEM = 'CRITICAL'
           MOVE ZERO
             TO IMPORTANCE-OF-PERCENT.

Comentário:

* 99% COMPLETE
* IS NOT
* 99% SAFE.

Outro:

* DO NOT ASK
* HOW LITTLE IS LEFT.
*
* ASK WHAT IS LEFT.

Outro:

* PROGRESS BAR
* HAS NO CHANGE AUTHORITY.

E naturalmente:

* TARDIS REPAIR: 99%
*
* REMAINING ITEM:
* BRAKES.
*
* STATUS:
* NO-GO.

🕰️ Voltamos para sexta-feira, 17:42

Dashboard:

97%

Gerente:

— Então vamos?

Nosso jovem olha:

ROLLBACK:
NOT VALIDATED

— Não.

— Mas estamos praticamente terminando.

— Estamos terminando tarefas.

— E qual é a diferença?

Ele aponta:

para o sistema.

— Quero saber se estamos terminando o projeto ou apenas terminando o checklist.

Silêncio.

Doctor sorri.


🔧 Go-Live adiado

Teste de rollback:

sábado de manhã.

Primeira tentativa:

falha.

Silêncio na sala.

Descobrem:

uma alteração de schema incompatível com:

rollback antigo.

Corrigem.

Testam novamente.

Passa.

Restore:

passa.

Reconciliation:

passa.

Agora:

DELIVERY ............ 100%
ROLLBACK ............ PASS
RESTORE ............. PASS
RECONCILIATION ...... PASS
OPS READINESS ....... PASS

Agora sim.

Go-Live.


☕ Segunda-feira

Nenhum incidente crítico.

Gerente encontra:

nosso jovem.

— Aqueles 3%...

— Sim.

— Eram pequenos no dashboard.

— Sim.

— Mas continham quase todo o risco restante.

— Exatamente.

Gerente toma café.

— Então devemos parar de usar porcentagem?

— Não.

— Então qual é a lição?

Nosso jovem sorri.

“Use porcentagem para saber quanto avançamos. Não para decidir sozinho se estamos seguros para continuar.”

Boa.


🧬 Regeneração organizacional

Uma organização madura entende que Goal Gradient é:

força psicológica.

Não:

defeito.

Ela usa:

milestones;

progress bars;

countdowns;

small wins.

Mas também:

protege:

quality;

safety;

rollback;

evidence;

recovery;

human judgment.

Ela sabe que a reta final:

aumenta motivação.

Por isso:

aumenta disciplina.

Principalmente:

ela não confunde:

“falta pouco”

com:

“o que falta importa pouco.”


📓 Diário do Doctor

Se guardar algumas coisas desta viagem:

Goal Gradient Effect descreve a tendência de aumentar motivação e esforço conforme percebemos maior proximidade de uma meta.

Ele pode ser usado positivamente em aprendizagem, migrações, backlog e projetos longos.

Progress bars funcionam porque tornam proximidade visível.

Endowed Progress mostra como progresso inicial percebido pode aumentar engajamento.

Percentual de tarefas concluídas não significa percentual de risco eliminado.

Completion e readiness são coisas diferentes.

Os últimos 5% podem conter justamente cutover, rollback, restore e reconciliation.

Goal Gradient combina perigosamente com Sunk Cost, Present Bias, Action Bias, Confirmation Bias e Authority Gradient.

Goodhart aparece quando completar a barra passa a importar mais que o outcome.

Campbell aumenta a pressão quando bônus e reputação estão ligados à conclusão.

Goal Substitution pode colocar a linha de chegada no lugar errado.

Metric Fixation pode transformar o percentual em uma falsa descrição completa da realidade.

Ratchet pode transformar o esforço heroico da reta final em nova capacidade esperada.

Defina No-Go antes de ficar emocionalmente perto demais da meta.

Pergunte “o que falta?”, não apenas “quanto falta?”.

E principalmente:

o fato de restar apenas 1% não significa que esse 1% seja pouco importante. Às vezes é justamente ali que alguém guardou o freio.


🥚 Easter Egg final

Antes de entrar na TARDIS, o Doctor deixa uma última mensagem no terminal:

IF PROJECT = 99-PERCENT-COMPLETE
   AND EVIDENCE = INCOMPLETE
      MOVE 'NOT-READY'
        TO STATUS
END-IF.

Nosso jovem pergunta:

— Doctor, uma organização realmente adiaria um projeto em 99% por causa de uma evidência crítica?

Ele olha para a TARDIS.

— Uma organização madura?

Pausa.

— Sim.

— E uma imatura?

Doctor abre a porta.

— Ela provavelmente terá uma ótima história para o postmortem.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

Na War Room fica apenas:

97% pronto não é argumento técnico.

E abaixo:

“A linha de chegada pode nos fazer correr mais rápido. O trabalho da engenharia é garantir que não corramos mais rápido justamente na direção do precipício.”

☕🌀

Próxima parada: McNamara Fallacy — quando começamos medindo aquilo que é fácil, depois ignoramos aquilo que é difícil de medir e acabamos concluindo que tudo o que não cabe no dashboard simplesmente não existe.

Sem comentários:

Enviar um comentário

De Fã para Fã. Conteúdo não oficial produzido como homenagem, comentário, análise ou paródia. Personagens, marcas e obras eventualmente mencionados pertencem aos seus respectivos titulares.
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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