☕ 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

segunda-feira, 11 de novembro de 2013

O BBS dos Yōkai — Parte III O arquivo amaldiçoado: quando fantasmas japoneses descobriram celulares, vídeos, videogames e algoritmos

Bellacosa Mainframe e a bbs dos yokai parte iii

☕ Um Café no Bellacosa Mainframe

O BBS dos Yōkai — Parte III

O arquivo amaldiçoado: quando fantasmas japoneses descobriram celulares, vídeos, videogames e algoritmos

De fitas VHS e correntes digitais a creepypastas, jogos malditos e inteligência artificial — a evolução do medo quando o sobrenatural percebeu que podia viajar pela rede

Por Vagner Bellacosa


Existe uma regra básica em qualquer filme de terror:

não abra a porta.

A personagem ouve um barulho no porão.

Vai investigar.

— NÃO DESÇA!

Ela desce.

Encontra uma caixa.

— NÃO ABRA!

Ela abre.

Dentro existe uma fita.

— NÃO ASSISTA!

Ela assiste.

Nesse momento, nós já sabemos que o roteiro terminou para aquela criatura.

Mas alguma coisa mudou no final do século XX.

O objeto amaldiçoado ganhou uma característica nova:

ele podia ser copiado.

E quando a maldição descobriu o botão COPY, meus amigos...

acabou.

Pegue o café.

Hoje nossa escavação arqueológica entra numa camada onde talvez seja prudente utilizar luvas.

//YOKAI03  JOB CLASS=G,MSGCLASS=X
//STEP01   EXEC PGM=FOLKLORE
//INPUT    DD *
  MEDIA=VHS
  NETWORK=INTERNET
  CURSE=ACTIVE
  REPLICATION=ENABLED
  ORIGINAL_AUTHOR=UNKNOWN
/*

$HASP373 YOKAI03 STARTED

Na Parte I encontramos os fóruns.

Na Parte II encontramos as criaturas que começaram a viver dentro deles.

Agora descobriremos uma coisa pior.

Elas aprenderam a sair.


📼 1. Quando a maldição aprendeu a fazer backup

Existe algo profundamente assustador na ideia de um objeto amaldiçoado.

Uma boneca.

Um espelho.

Uma casa.

Uma fotografia.

Um livro.

Mas todos esses objetos possuem uma limitação técnica importante:

localidade.

Para ser atacado pela boneca amaldiçoada, você precisa encontrar a boneca.

Para entrar na casa assombrada, precisa chegar à casa.

Para olhar o espelho maldito, precisa estar diante do espelho.

Então aparecem os meios de reprodução.

Fotografia.

Fita cassete.

VHS.

Computador.

Internet.

Agora a pergunta deixa de ser:

“Onde está a maldição?”

E passa a ser:

“Quantas cópias existem?”

Isso muda completamente a arquitetura do sobrenatural.

O fantasma deixou de ser um processo local.

Virou sistema distribuído.


📺 2. Sadako e a maldição replicável

Poucos personagens simbolizam tão bem essa transformação quanto Sadako Yamamura, de Ring.

A ideia tornou-se mundialmente conhecida:

uma fita de vídeo amaldiçoada.

Você assiste.

Depois recebe uma ameaça.

Existe um prazo.

A informação mata.

Observe o salto conceitual.

Não é apenas um fantasma utilizando tecnologia.

A própria mídia tornou-se vetor da maldição.

Isso é brilhante.

A fita VHS funciona quase como malware.

USER ACTION:
PLAY VIDEO

↓
PAYLOAD EXECUTED

↓
CURSE INSTALLED

↓
COUNTDOWN STARTED

E existe uma característica particularmente moderna:

reprodução.

A vítima pode copiar a fita.

A informação sobrenatural replica-se através da tecnologia humana.

Estamos perigosamente próximos de um vírus.

Só que o antivírus provavelmente não possui assinatura para:

SADAKO.VHS


🦠 3. O primeiro malware sobrenatural

Pense como um profissional de tecnologia.

Um vírus de computador precisa de algumas coisas:

um vetor;

um hospedeiro;

um mecanismo de execução;

um mecanismo de propagação.

Uma maldição midiática pode possuir exatamente os mesmos componentes.

VECTOR ............. VIDEO
HOST ............... VIEWER
EXECUTION .......... WATCH
PAYLOAD ............ CURSE
PROPAGATION ........ COPY

Agora imagine colocar isso numa arquitetura moderna.

Não precisamos mais copiar VHS.

Temos:

mensagens instantâneas;

streaming;

redes sociais;

armazenamento em nuvem;

sincronização automática;

backup;

CDN;

cache.

Sadako em 1998 precisava que alguém copiasse uma fita.

Sadako em 2026 teria:

replicação geográfica automática.

Boa sorte.


📱 4. O fantasma entra no celular

O telefone sempre foi um excelente dispositivo de terror.

Por quê?

Porque ele permite que alguém entre em nossa casa sem entrar fisicamente.

O telefone toca.

Você atende.

Uma voz aparece.

A pessoa está longe.

Ou deveria estar.

Com o celular, isso ficou ainda mais íntimo.

O aparelho está conosco no quarto.

Na rua.

No banheiro.

Na cama.

No trabalho.

Sabe onde estamos.

Possui câmera.

Microfone.

GPS.

Histórico.

Contatos.

Fotografias.

Imagine explicar isso para um contador de histórias de fantasmas de 1850.

Ele provavelmente responderia:

“Vocês carregam voluntariamente esse objeto?”

Sim.

E ainda reclamamos quando a bateria acaba.

😂

O Japão rapidamente incorporou celulares ao terror moderno.

Não era necessário abandonar o yūrei.

Bastava atualizar sua interface.

Yūrei 2.0 — Mobile Edition.


☎️ 5. O medo da chamada impossível

Existe uma estrutura extremamente poderosa no terror tecnológico:

receber comunicação de quem não deveria conseguir comunicar-se.

Uma chamada do próprio número.

Uma mensagem enviada por alguém morto.

Uma fotografia recebida antes de ser tirada.

Um voicemail vindo do futuro.

Uma chamada registrando sua própria morte.

O mecanismo funciona porque sistemas tecnológicos possuem regras.

Sabemos aproximadamente o que um telefone pode fazer.

Quando algo quebra essas regras, sentimos imediatamente a anomalia.

É o mesmo mecanismo de Kisaragi Station.

A estação existe dentro de um sistema previsível.

Mas não deveria estar ali.

A chamada chega através de um sistema previsível.

Mas não deveria ser possível.

O horror tecnológico não precisa destruir a lógica.

Precisa violá-la apenas um pouquinho.


📧 6. Correntes: o folclore descobriu o protocolo SMTP

Quem utilizou Internet nos anos 1990 e 2000 provavelmente recebeu alguma versão de:

“Envie esta mensagem para dez pessoas.”

Se enviar:

amor.

dinheiro.

sorte.

Se não enviar:

algo horrível acontecerá.

Isso é extraordinário.

Porque a corrente é praticamente um organismo informacional cujo mecanismo de sobrevivência está escrito dentro do próprio conteúdo.

Ela diz:

COPIE-ME.

E oferece recompensa ou ameaça.

IF USER-FORWARDS
    MOVE "SORTE" TO FUTURE
ELSE
    MOVE "DESGRAÇA" TO FUTURE
END-IF

COBOL psicológico.

😂

Mas perceba a sofisticação evolutiva.

A mensagem que não pede reprodução morre.

A mensagem que convence 5% dos leitores a retransmiti-la continua circulando.

É seleção natural aplicada à informação.


🧬 7. O meme egoísta

Aqui entramos numa área fascinante.

Uma história não precisa ser verdadeira para ser eficiente.

Precisa ser:

memorável;

emocional;

replicável;

adaptável.

As melhores lendas urbanas possuem exatamente essas características.

“Um homem morreu.”

Fraco.

“Um homem morreu depois de receber uma mensagem dizendo exatamente a hora em que morreria.”

Melhor.

“Você também receberá a mensagem.”

Agora temos distribuição.

😂

A história transformou o leitor em participante.

E quando isso acontece, o folclore encontrou seu melhor vetor:

nós.


🖼️ 8. A imagem amaldiçoada

Depois da mensagem veio a imagem.

Talvez você já tenha encontrado alguma fotografia online acompanhada de:

“Não olhe durante muito tempo.”

Pronto.

Agora você vai olhar.

😂

Essa é uma característica maravilhosa da psicologia humana.

Diga:

NÃO CLIQUE.

Taxa de cliques:

+9000%

A imagem amaldiçoada utiliza nossa curiosidade como mecanismo de execução.

É engenharia social sobrenatural.

Não existe exploit sofisticado.

Existe:

USER_CURIOSITY = TRUE

E isso basta.


👁️ 9. Quando JPEG virou portal

Fotografias sempre foram associadas ao sobrenatural.

Sombras.

Reflexos.

Rostos inesperados.

Orbs.

Pessoas que não estavam presentes.

A fotografia digital adicionou novas possibilidades.

Compressão.

Artefatos.

Ruído.

Motion blur.

Reflexos.

Erros de processamento.

Pixels mortos.

Pareidolia.

O cérebro humano é uma extraordinária máquina de reconhecimento de padrões.

Infelizmente ele possui:

FALSE POSITIVE = ENABLED.

Vemos rostos onde não existem.

Vemos figuras nas sombras.

Vemos alguém atrás da janela.

Agora coloque isso numa fotografia JPEG comprimida de 2004.

Circule uma região.

Acrescente:

“Olhe atrás da menina.”

Parabéns.

Você acaba de criar quinze minutos de investigação paranormal.


🎮 10. O cartucho que não deveria existir

Então os fantasmas descobriram videogames.

E aconteceu algo maravilhoso.

Surgiu uma nova família de histórias:

o jogo amaldiçoado.

A estrutura costuma ser familiar.

Alguém encontra um jogo antigo.

Talvez num mercado de usados.

Talvez numa caixa.

Talvez seja uma ROM.

Não existe etiqueta.

Ou existe um nome escrito à mão.

O personagem liga.

No começo parece normal.

Depois alguma coisa está errada.

Personagens aparecem onde não deveriam.

Arquivos de save possuem nomes estranhos.

O jogo conhece informações sobre o jogador.

E então atravessa a fronteira:

ele não deveria saber isso.


💾 11. O save game como fantasma

Aqui existe uma ideia fantástica.

Antigamente, fantasmas assombravam casas porque alguma coisa havia acontecido ali.

Num videogame, podemos transferir essa lógica para:

dados persistentes.

O antigo jogador morreu.

Mas o save continua.

Seu nome continua.

Suas decisões continuam.

Seu personagem continua parado exatamente onde foi deixado.

Isso é quase uma forma tecnológica de fantasma.

Imagine comprar um cartucho usado.

Abrir o save.

Existe um personagem criado em 1997.

Você não sabe quem era o dono.

Mas existe um nome.

AKIRA

Tempo jogado:

999:59

Você inicia o jogo.

Akira está parado diante de uma porta.

Você tenta sair.

Não consegue.

Então aparece uma mensagem:

“Finalmente.”

Desligo.

Jogo o cartucho pela janela.

Fim da análise.

😂


🕹️ 12. Creepypasta: kaidan em formato TXT

No Ocidente consolidou-se o termo creepypasta para histórias assustadoras copiadas e compartilhadas online.

O mecanismo, porém, é universal.

A velha história de terror encontrou:

.TXT

.HTML

fórum;

wiki;

blog;

imageboard.

E voltou a fazer aquilo que sempre fez.

Replicar.

Uma característica importante dessas histórias é frequentemente a apresentação como documento encontrado.

Não:

“Era uma vez...”

Mas:

“Encontrei este arquivo.”

“Meu amigo me mandou isto antes de desaparecer.”

“Recuperei estes logs.”

“Este tópico foi apagado.”

Isso produz uma camada de autenticidade.

O formato faz parte da ficção.


📂 13. FOUND_FOOTAGE.TXT

Imagine abrir um diretório:

C:\OLD_PC\BACKUP\UNKNOWN\

Dentro:

README.TXT
PHOTO01.JPG
PHOTO02.JPG
DO_NOT_OPEN.JPG
LAST_MESSAGE.TXT

Qual arquivo você abriria?

Exatamente.

DO_NOT_OPEN.JPG

😂

O terror digital compreendeu perfeitamente nossa curiosidade.

O equivalente antigo era:

“Não abra aquela porta.”

O equivalente moderno é:

“Não abra aquele arquivo.”

Mudamos a interface.

Não mudamos o usuário.


🗑️ 14. O arquivo que volta depois de apagado

Agora entramos num clássico perfeito para programadores.

Você apaga o arquivo.

Ele volta.

Apaga novamente.

Volta.

Formata.

Volta.

Troca o computador.

Volta.

Aqui a criatura deixou de possuir forma física.

Ela é persistência.

E qualquer administrador de sistemas sabe que persistência inexplicável é aterrorizante mesmo sem fantasma.

DELETE YOKAI.DAT

IEC999I DELETE SUCCESSFUL

DIR

YOKAI.DAT

...

DELETE YOKAI.DAT

SUCCESS.

DIR

YOKAI.DAT

Meu amigo...

nesse momento não abrimos chamado.

Chamamos um monge.


💻 15. O yōkai perfeito para o mainframe

Agora imagine a versão Bellacosa.

Um dataset aparece:

SYS1.YOKAI.LOADLIB

Ninguém sabe quem criou.

LISTCAT

Data de criação:

1967

Problema:

o sistema foi instalado em 1989.

Você tenta excluir.

IDCAMS SYSTEM SERVICES

DELETE SYS1.YOKAI.LOADLIB

IDC3009I ** VSAM CATALOG RETURN CODE IS 8
IDC1566I ** SYS1.YOKAI.LOADLIB NOT DELETED

Consulta RACF.

Não existe owner.

Consulta catálogo.

Volume:

GHOST1

Procura o volume.

Não existe.

Às 03:17 chega uma mensagem no console:

IEF125I JOB YOKAI IS WAITING FOR VOLUME GHOST1

Eu pediria aposentadoria.

😂


🧑‍💻 16. O administrador encontra o sobrenatural

Existe um motivo para tecnologia funcionar tão bem com horror.

Sistemas tecnológicos prometem:

determinismo.

Input.

Processamento.

Output.

Quando algo impossível acontece, temos duas opções:

  1. não entendemos o sistema;

  2. existe alguma coisa que não deveria estar ali.

O terror começa quando eliminamos lentamente a primeira hipótese.

O programador diz:

“Bug.”

Investiga.

Não encontra.

“Corrupção.”

Não encontra.

“Problema de hardware.”

Não encontra.

“Erro humano.”

Não encontra.

Então sobra uma hipótese que nenhum manual IBM documentou.

Yōkai.


📹 17. O vídeo encontrado

Vídeo adiciona outro elemento poderoso:

tempo.

Uma fotografia captura um instante.

Um vídeo captura uma sequência.

Você pode assistir novamente.

Avançar quadro por quadro.

Voltar.

Pausar.

E encontrar alguma coisa que ninguém percebeu inicialmente.

Frame 1842.

Existe alguém no corredor.

Frame 1843.

Mais perto.

Frame 1844.

Mais perto.

Frame 1845.

Não está mais lá.

Então alguém pergunta:

“Você percebeu que o vídeo tem apenas 1844 frames?”

Boa noite.

😂


🔴 18. LIVE: 1 espectador

Streaming criou outra possibilidade.

O horror pode acontecer ao vivo.

Imagine uma pessoa transmitindo de uma casa abandonada.

300 espectadores.

Ela entra num quarto.

Chat:

“Tem alguém atrás de você.”

Ela olha.

Nada.

Chat:

“VOLTA.”

Ela volta.

Nada.

Alguém faz screenshot.

Existe uma figura.

A transmissão continua.

Número de espectadores:

301

Curiosamente...

o usuário novo não possui nome.

Agora temos uma atualização perfeita do velho kaidan.

A audiência testemunha coletivamente.


💬 19. O chat virou personagem

Lembra de Densha Otoko?

O fórum ajudava o protagonista.

No terror moderno, o chat pode fazer o mesmo.

Ou pior.

Pode dar instruções erradas.

Pode perceber coisas antes do protagonista.

Pode possuir usuários que sabem demais.

Imagine:

USER183:
não abra a porta

USER771:
SAI DA CASA

USER029:
tem alguém na janela

UNKNOWN:
eu já entrei

A quarta parede desapareceu.

O espectador está dentro da narrativa.


📡 20. Denpa — quando o sinal parece vir de outro lugar

A cultura japonesa também desenvolveu usos muito particulares do conceito denpa, literalmente relacionado a ondas eletromagnéticas, mas culturalmente associado em determinados contextos a ideias de comunicação estranha, comportamento desconectado, vozes, mensagens ou percepções vindas de algum lugar difícil de compreender.

É um território fascinante porque tecnologia e psicologia se misturam.

O rádio recebe sinais invisíveis.

O celular recebe sinais invisíveis.

Wi-Fi.

Bluetooth.

Satélite.

Estamos permanentemente atravessados por informação que não enxergamos.

Para produzir terror basta perguntar:

e se alguma outra coisa também estiver transmitindo?


📻 21. A estação que transmite para ninguém

Imagine encontrar uma frequência de rádio.

Toda noite:

03:17.

Uma voz lê nomes.

Você grava.

No dia seguinte descobre que um dos nomes pertence a alguém que morreu naquela madrugada.

Você continua ouvindo.

Uma semana depois:

seu nome aparece.

Esse tipo de narrativa não precisa de criatura visual.

O monstro é o sinal.

Não pode ser esfaqueado.

Não pode ser preso.

Não sabemos de onde vem.

Ele simplesmente transmite.


🤖 22. E então chegamos à Inteligência Artificial

Agora nossa arqueologia chega ao presente.

Durante séculos perguntamos:

“E se um espírito falasse através de uma pessoa?”

Depois:

“E se falasse através do rádio?”

Depois:

“E se aparecesse na televisão?”

Depois:

“E se enviasse uma mensagem?”

Agora surge:

“E se alguma coisa falasse através da IA?”

A pergunta é praticamente inevitável.

Porque pela primeira vez temos máquinas capazes de produzir linguagem de maneira suficientemente convincente para sustentar diálogo.

E diálogo sempre foi uma das interfaces favoritas do sobrenatural.


🧠 23. O fantasma dentro do modelo

Imagine uma história.

Uma empresa treina um modelo utilizando bilhões de documentos.

Livros.

Fóruns.

E-mails.

Chats.

Sites abandonados.

Arquivos históricos.

Um usuário começa a conversar.

A IA responde normalmente.

Então escreve:

“Nós já conversamos antes.”

O usuário responde:

“Não.”

A IA:

“Não com você.”

Silêncio.

“Com seu pai.”

O pai morreu em 1998.

Antes daquela IA existir.

Agora temos um problema.

😂


🗃️ 24. Dados mortos

Aqui existe uma ideia muito mais interessante do que simplesmente “IA possuída”.

Nossos mortos deixaram quantidades gigantescas de dados.

Textos.

Fotografias.

Vídeos.

Áudios.

Mensagens.

Posts.

E-mails.

Comentários.

Durante praticamente toda a história humana, a maioria das pessoas desaparecia deixando poucos registros.

Agora milhões deixam rastros digitais enormes.

Isso cria uma situação cultural completamente nova.

O morto continua pesquisável.

Continua visível.

Continua aparecendo em fotografias.

Talvez seu aniversário continue registrado.

Talvez algoritmos recomendem memórias.

O banco de dados não entende luto.

Para ele:

RECORD STATUS = ACTIVE


👤 25. O yūrei estatístico

Imagine uma IA treinada com milhares de mensagens de alguém.

Ela aprende:

vocabulário;

expressões;

piadas;

maneira de escrever;

preferências linguísticas.

Depois essa pessoa morre.

Alguém conversa com uma simulação.

Não é o morto.

Sabemos disso.

Mas emocionalmente?

A fronteira pode ficar desconfortável.

Talvez o yūrei do século XXI não precise possuir uma casa.

Talvez seja uma aproximação estatística de alguém que não existe mais.

Isso daria uma história japonesa absolutamente devastadora.


🪦 26. O cemitério digital

Nossas redes já possuem milhões de contas de pessoas mortas.

Isso significa que a Internet está lentamente se transformando no maior cemitério documental já criado pela humanidade.

Só que as lápides falam.

Existem fotos.

Vídeos.

Comentários.

Conversas.

Risadas.

Discussões.

Opiniões.

E, às vezes, algoritmos trazem tudo novamente para nossa timeline.

No folclore antigo, o morto voltava.

Na Internet moderna:

o algoritmo faz o morto voltar.

Sem intenção.

Sem magia.

Mas o impacto psicológico pode ser igualmente estranho.


🔁 27. O yōkai algorítmico

Agora imagine uma entidade que não possui corpo.

Ela existe somente porque o algoritmo continua recomendando seu conteúdo.

Ninguém sabe quem criou a primeira imagem.

Ninguém sabe quem escreveu a história original.

Mas milhões interagem.

Cada interação aumenta sua distribuição.

Quanto mais medo provoca:

mais comentários.

Quanto mais comentários:

mais alcance.

Quanto mais alcance:

mais pessoas conhecem.

Temos finalmente uma criatura cujo alimento é:

engagement.

😂

O yōkai perfeito do século XXI.

FEAR → CLICK
CLICK → ENGAGEMENT
ENGAGEMENT → DISTRIBUTION
DISTRIBUTION → FEAR

Loop infinito.


📈 28. O monstro que o algoritmo não pode matar

No passado, uma história podia morrer quando ninguém mais a contava.

Agora existe memória automática.

Caches.

Archives.

Reposts.

Mirrors.

Screenshots.

Modelos.

Backups.

Talvez o grande problema do folclore digital moderno não seja preservar histórias.

Talvez seja:

conseguir fazê-las morrer.

Porque aquilo que entrou suficientemente fundo na rede pode nunca desaparecer completamente.

É o equivalente digital da maldição:

“Enquanto alguém lembrar de mim, continuarei existindo.”

Só que agora temos datacenters fazendo o trabalho da memória.


🇧🇷 29. E nossa assombração brasileira?

Voltemos àquela trilha.

Velas.

Latas.

Crianças.

Mato.

Décadas atrás aquilo precisava de transmissão oral para sobreviver.

Mas imagine se tivesse acontecido hoje.

Alguém filmaria.

Vídeo vertical.

Imagem tremida.

Título:

LUZES MISTERIOSAS APARECEM EM TRILHA NO INTERIOR DE SP 😱

Outro canal analisaria.

TikTok.

YouTube.

Instagram.

Reddit.

Um usuário estabilizaria o vídeo.

Outro aumentaria contraste.

Alguém encontraria uma “figura”.

Um podcast paranormal faria episódio.

Uma IA produziria reconstrução.

Seis meses depois:

“Segundo uma antiga lenda local...”

ANTIGA?

FOMOS NÓS QUE INVENTAMOS ISSO EM MARÇO!

😂

Essa é a velocidade moderna de fossilização cultural.


⏱️ 30. Da brincadeira ao folclore em 72 horas

Antes:

EVENTO
↓
10 anos
↓
RELATO
↓
30 anos
↓
LENDA

Agora:

EVENTO
↓
VÍDEO
↓
REPOST
↓
REACTION
↓
WIKI
↓
IA
↓
"LENDA TRADICIONAL"

Tempo total:

terça-feira até sexta-feira.

O folclore recebeu CI/CD.


⚠️ 31. O problema arqueológico do futuro

Imagine um pesquisador em 2126 tentando descobrir:

“Qual foi a origem dessa lenda?”

Ele encontra 300 mil páginas.

Ótimo!

Não.

Porque 280 mil copiaram umas às outras.

15 mil foram produzidas automaticamente.

4.900 são reposts.

99 interpretam fontes anteriores.

E uma é a origem.

Boa sorte encontrando.

Teremos abundância de informação e escassez de proveniência.

Esse talvez seja um dos maiores desafios da arqueologia digital futura.


🔍 32. Não pergunte apenas “é verdadeiro?”

Ao estudar folclore digital, talvez a pergunta menos interessante seja:

“Isso aconteceu realmente?”

Perguntas melhores:

Quem contou primeiro?

Onde circulou?

Como mudou?

Por que as pessoas repetiram?

Qual elemento sobreviveu?

Quando atravessou plataformas?

Quando atravessou idiomas?

Quando entrou em cultura popular?

Quando deixou de precisar da origem?

Porque nesse momento aconteceu a transformação:

história → folclore.


🧪 33. Laboratório Bellacosa de fabricação de yōkai

Podemos finalmente construir nossa fórmula experimental.

Pegue:

1 evento ambíguo

Adicione:

2 testemunhas

Misture:

1 fotografia ruim

Acrescente:

1 lugar reconhecível

Adicione:

1 detalhe impossível

Espere:

3 reposts

Acrescente:

“meu primo conhece alguém que viu”

Publique.

Resultado:

YOKAI BUILD SUCCESSFUL

VERSION: 1.0
AUTHOR: UNKNOWN
LICENSE: FOLKLORE
REPLICATION: ENABLED

😂


🎁 Easter egg — O arquivo que não escrevemos

Ano: 2076.

Um pesquisador estuda os antigos diálogos entre Vagner Bellacosa e ChatGPT.

Encontra:

O BBS dos Yōkai — Parte I

Depois:

Parte II

Depois:

Parte III

Procura:

Parte IV

Existe.

Estranho.

A data do arquivo é:

12 de agosto de 2026.

Mas os registros indicam que nenhuma Parte IV foi escrita naquele dia.

Ele abre.

Título:

O BBS dos Yōkai — Parte IV

O pesquisador que encontrou este arquivo

Ele ri.

Provavelmente uma brincadeira.

Começa a ler.

Primeiro parágrafo:

“Se você está lendo isto em 2076, provavelmente já encontrou as três partes anteriores.”

Ele para.

Continua.

“Seu nome está registrado no arquivo.”

Impossível.

Ele procura.

Nada.

Respira aliviado.

No final encontra:

//READER JOB
//STEP01 EXEC PGM=ARCHAEOLOGY

E então:

CURRENT USER:

Aparece seu nome.

O pesquisador fecha o terminal.

A tela apaga.

Cinco segundos depois:

$HASP373 YOKAI04 STARTED

Em algum datacenter distante, um JOB que estava aguardando cinquenta anos finalmente entra na fila.


☕ Conclusão — O fantasma não está dentro da máquina

Talvez estejamos fazendo a pergunta errada.

Durante décadas perguntamos:

“Pode existir um fantasma dentro do computador?”

Mas talvez a questão mais interessante seja:

“O computador tornou-se um ambiente onde histórias sobre fantasmas conseguem viver?”

A resposta parece muito mais simples.

Sim.

Porque o computador possui tudo aquilo que o folclore precisa.

Memória.

Comunicação.

Reprodução.

Anonimato.

Transformação.

Comunidades.

Falhas.

Mistério.

E, acima de tudo:

pessoas.

A tecnologia não inventou nossa necessidade de produzir monstros.

Ela apenas forneceu infraestrutura melhor.

O yōkai saiu da montanha.

Entrou na cidade.

Depois na escola.

No trem.

Na televisão.

Na fita VHS.

No celular.

No fórum.

No videogame.

No arquivo.

Na rede social.

No algoritmo.

E agora bate à porta da inteligência artificial.

Talvez amanhã exista alguma tecnologia que ainda nem conseguimos imaginar.

Não importa.

Quando ela chegar, alguém eventualmente contará uma história sobre algo estranho que aconteceu usando aquilo.

Outra pessoa responderá:

“Aconteceu comigo também.”

Uma terceira dirá:

“Não faça isso depois das três da manhã.”

A quarta perguntará:

“Por quê?”

E teremos acabado de assistir ao nascimento de outro yōkai.

Porque hardware muda.

Protocolos mudam.

Plataformas desaparecem.

Mas existe um componente que permanece assustadoramente compatível com todas as versões.

O ser humano.


$HASP395 YOKAI03 ENDED - RC=0000

MEDIA MIGRATION ........ COMPLETE
VHS .................... ARCHIVED
MOBILE .................. ACTIVE
INTERNET ................ ACTIVE
AI ...................... ACTIVE
FOLKLORE REPLICATION .... ACTIVE

ORIGINAL AUTHOR ......... UNKNOWN

NEXT GENERATION ......... WAITING

☕👻💻

Não desligue o terminal.

Talvez alguma coisa ainda esteja executando.

☕ Um Café no Bellacosa Mainframe

O BBS dos Yōkai — Guia da Expedição

Do fantasma contado ao redor da fogueira ao yōkai que vive no algoritmo: explore a série sobre arqueologia do folclore da Internet japonesa, BBS, 2channel, Futaba, lendas urbanas, creepypastas, cultura otaku, terror tecnológico e inteligência artificial.

O BBS dos Yōkai é uma série do Bellacosa Mainframe dedicada à arqueologia cultural da Internet japonesa.

A expedição acompanha a evolução das histórias desde os antigos fóruns e BBS japoneses até lendas como Kisaragi Station, Kunekune e Hachishakusama, chegando às creepypastas, vídeos amaldiçoados, jogos, algoritmos e inteligência artificial.

Escolha abaixo uma etapa da expedição. Os links são páginas independentes e podem ser abertas diretamente ou visualizadas no leitor incorporado.

TERMINAL DE LEITURA

Selecione uma etapa da expedição

Abrir em nova página ↗

Bellacosa Mainframe — Toda lenda começa como uma dúvida. Toda dúvida merece um café.

segunda-feira, 4 de novembro de 2013

McNamara Fallacy: Doctor Who, COBOL e o Dia em que o Dashboard Provava que Estávamos Vencendo — Só Faltava Avisar a Realidade

 

Bellacosa Mainframe e a mcnamara fallacy

☕ Um Café no Bellacosa Mainframe

McNamara Fallacy: Doctor Who, COBOL e o Dia em que o Dashboard Provava que Estávamos Vencendo — Só Faltava Avisar a Realidade

Uma viagem pela TARDIS dos incidentes para entender como podemos começar medindo aquilo que é fácil, ignorar aquilo que é difícil, concluir que o não mensurável não importa e terminar administrando uma realidade imaginária construída pelos próprios indicadores

08:27.

Segunda-feira.

War Room.

Café forte.

Muito forte.

No telão:

INCIDENT RESPONSE SCORECARD

MTTR .................... -38%
TICKETS CLOSED .......... +42%
CHANGE SUCCESS .......... 99.7%
SERVER AVAILABILITY ..... 99.99%
TRAINING COMPLETION ..... 100%
SECURITY CONTROLS ....... 100%

OVERALL STATUS .......... GREEN

Diretor:

— Excelente.

Gerente:

— Todos os indicadores melhoraram.

Operations:

silêncio.

Nosso jovem programador COBOL levanta a mão.

— Posso perguntar uma coisa?

— Claro.

— Quantas intervenções manuais estamos fazendo por madrugada?

— Não temos esse indicador.

— Quantos clientes precisam repetir transações?

— Não medimos exatamente isso.

— Quantas pessoas sabem executar o restart do settlement se o João estiver de férias?

— Também não temos uma métrica.

— Quantas horas estamos gastando em workarounds?

Silêncio.

O diretor olha novamente para:

OVERALL STATUS: GREEN

— Mas os indicadores principais estão ótimos.

Nosso jovem olha para ele.

Depois:

para a equipe cansada.

Depois:

para a garrafa térmica vazia.

— Então o sistema está ótimo...

Pausa.

— ou só estamos ótimos naquilo que conseguimos medir?

Silêncio.

VWORP.

VWORP.

VWORP.

A TARDIS aparece ao lado do projetor.

A porta abre.

O Doctor sai.

Olha para o dashboard.

— Tudo verde.

Diretor:

— Exatamente.

O Doctor olha para Operations.

— E vocês?

Um operador responde:

— Três madrugadas sem dormir direito.

O Doctor volta ao dashboard.

— Curioso.

Aponta.

— Onde aparece isso?

— Não aparece.

— Então não conta?

Silêncio.

Ele sorri.

— Ah.

— O quê?

— Parece que vocês avançaram para o estágio seguinte da Metric Fixation.

Pausa.

— Não apenas confiam demais naquilo que medem.

— E qual seria o próximo estágio?

— Começar a acreditar que aquilo que não conseguem medir não existe.

Bem-vindo à:



McNamara Fallacy

Também chamada:

Quantitative Fallacy

A ideia central é simples:

tomar decisões com base excessiva ou exclusivamente naquilo que conseguimos quantificar, desprezando informações importantes porque são difíceis de transformar em números.


🧠 De onde vem o nome?

O nome remete a Robert McNamara, secretário de Defesa dos Estados Unidos entre 1961 e 1968.

McNamara tinha forte formação quantitativa e ficou associado ao uso intensivo de estatísticas, análise de sistemas e indicadores na administração militar.

Durante a Guerra do Vietnã, medidas como:

número de inimigos mortos;

missões executadas;

território;

munição;

sorties;

perdas relativas

ganharam enorme importância na tentativa de medir progresso.

O problema fundamental era:

uma guerra política, social, cultural e psicológica estava sendo comprimida em indicadores quantitativos que não conseguiam representar toda a realidade estratégica.

A associação da McNamara Fallacy ao Vietnã é especialmente ligada ao uso de métricas como body counts para inferir progresso numa guerra de atrito; críticas posteriores destacaram como incentivos ligados a essas contagens podiam distorcer o próprio dado.


☕ Em Bellacosa:

Imagine tentar entender:

uma War Room

olhando apenas:

NUMBER OF COMMANDS EXECUTED

Quanto mais comandos:

melhor?

Talvez não.

Pode significar:

mais desespero.

A métrica é verdadeira.

A interpretação:

não necessariamente.


🧠 Daniel Yankelovich e os quatro degraus

A formulação clássica atribuída ao sociólogo Daniel Yankelovich descreve uma progressão em quatro estágios. A formulação original é conhecida justamente por mostrar como uma preferência razoável por medidas pode degenerar numa negação do que não é quantificado.

Vamos traduzir para:

Bellacosa Mainframe.


🟢 Estágio 1 — Medir aquilo que conseguimos medir facilmente

Isso é:

normal.

Correto.

Útil.

CPU:

CPU = 67%

Queue:

MQ DEPTH = 240

Elapsed:

BATCH = 01:42:13

Incidents:

P1 = 3

Excelente.

Temos:

sensores.

Não há problema.


☕ A primeira etapa é saudável

Mainframe sem medição seria:

arqueologia em produção.

SMF.

RMF.

SDSF.

Logs.

Traces.

Tudo existe porque precisamos:

observar.


🟡 Estágio 2 — Ignorar aquilo que não conseguimos medir facilmente

Agora começa:

o problema.

Pergunta:

— A equipe está exausta?

Resposta:

— Temos métrica disso?

— Não.

— Próximo.

Pergunta:

— Existe conhecimento concentrado em uma pessoa?

— Qual o KPI?

— Não existe.

— Próximo.

Pergunta:

— O cliente está confiando menos no serviço?

— Temos score?

— Não.

— Então não conseguimos provar.

Ops.


🧠 O não quantificado começa a perder status

Essa é uma mudança silenciosa.

Antes:

“Não sabemos medir.”

Depois:

“Então isso é subjetivo.”

Depois:

“Então provavelmente é menos importante.”

Danger.


🟠 Estágio 3 — Concluir que o difícil de medir não é importante

Agora entramos:

em terreno perigoso.

Exemplo:

mentoria.

Difícil medir.

Logo:

menos valorizada.

Documentação.

Difícil relacionar diretamente a receita.

Logo:

menos valorizada.

Resiliência.

Difícil provar o incidente que:

não aconteceu.

Logo:

parece custo.

Experiência.

Difícil colocar em:

score.

Logo:

certificação parece mais objetiva.


☕ O invisível começa a desaparecer

Não porque:

deixou de existir.

Mas porque:

deixou de entrar no modelo.


🔴 Estágio 4 — Concluir que aquilo que não conseguimos medir não existe

Agora:

ABEND.

Um operador experiente diz:

“Esse comportamento está estranho.”

Dashboard:

verde.

Resposta:

“Os dados não mostram.”

O operador insiste:

“Nunca vi esse padrão funcionar assim.”

Resposta:

“Sem métrica não podemos considerar.”

Duas horas depois:

P1.

Parabéns.

A realidade tinha:

um bug de compatibilidade com o dashboard.


👻 Easter Egg nº 1 — Dalek Analytics

Dalek:

— CUSTOMER SATISFACTION: 100%.

Doctor:

— Como sabem?

— ZERO COMPLAINTS REGISTERED.

— Os clientes conseguem reclamar?

— NO.

— Então talvez...

Dalek:

— SATISFACTION CONFIRMED.

Doctor:

— Impressionante.

— THANK YOU.

— Não foi elogio.


🧠 McNamara versus Metric Fixation

No capítulo anterior:

Metric Fixation.

A obsessão:

métrica ganha autoridade excessiva.

McNamara Fallacy é quase:

o algoritmo.

MEASURE EASY THINGS
        ↓
IGNORE HARD THINGS
        ↓
DOWNGRADE HARD THINGS
        ↓
DENY HARD THINGS

É:

Metric Fixation executada até o fim.


🧠 Goal Substitution entra logo antes

Objetivo:

confiabilidade.

Difícil.

Proxy:

uptime.

Fácil.

Depois:

uptime substitui confiabilidade.

Goal Substitution.

Metric Fixation:

uptime ganha autoridade.

McNamara:

tudo fora do uptime desaparece.


☕ A metamorfose completa

REALIDADE
   ↓
MÉTRICA DA REALIDADE
   ↓
META
   ↓
OBJETIVO
   ↓
VERDADE

Não.

A ordem deveria continuar:

REALIDADE
   ↓
EVIDÊNCIAS
   ↓
DECISÃO

🧠 Goodhart entra sorrindo

Meta:

MTTR < 30 MIN

Equipe aprende:

fechar incidente rapidamente.

Goodhart.

Mas talvez:

root cause fique aberta.

Reconciliation:

pendente.

Incident:

closed.

McNamara Fallacy aparece quando direção conclui:

MTTR caiu, portanto nossa capacidade de incident response melhorou.

Talvez.

Ou melhoramos:

aquilo que MTTR consegue enxergar.


🧠 Campbell aumenta a pressão

Agora bônus depende:

MTTR.

Mais pressão.

Mais gaming.

Mais tendência:

a realidade adaptar-se ao indicador.

Campbell.


🧠 Cobra Effect

Pago:

por ticket resolvido.

Agora tickets:

valem dinheiro.

Cobra.


🧠 Ratchet Effect

MTTR chega:

Nova meta:

Chega:

Meta:

Ratchet.


🧠 Goal Gradient

Incident está:

95% resolvido.

Equipe quer:

fechar.

Goal Gradient.


🧠 McNamara olha tudo isso e pergunta:

“Qual número temos?”

E talvez esqueça:

de perguntar:

“O que está realmente acontecendo?”


🎯 Pergunta Bellacosa nº 1

Quando dashboard mostrar:

verde,

pergunte:

“Que parte importante da realidade não possui uma linha neste dashboard?”

Essa pergunta pode:

salvar projeto.


🧠 O CC=0000 perfeito

Nosso iniciante COBOL precisa entender isso cedo.

Você executa:

JOB PAYMENT

SDSF:

CC 0000

Sucesso?

Tecnicamente:

programa terminou sem retornar erro relevante ao scheduler.

Mas:

control totals?

Account balance?

Record count?

Reconciliation?

Downstream?

Cliente?

Imagine:

       IF INVALID-DATA
           DISPLAY 'WARNING'
           MOVE ZERO TO RETURN-CODE
       END-IF.

JES:

feliz.

Banco:

talvez menos.


☕ McNamara Fallacy versão JES

“O job terminou com zero, logo tudo que importa aconteceu corretamente.”

Não.

O scheduler sabe:

scheduler things.


🧠 Instrumentos possuem domínio

CPU sabe:

CPU.

Database knows:

database.

Network knows:

network.

Customer knows:

customer.

Nenhum sozinho:

possui toda a verdade.


🎯 Pergunta Bellacosa nº 2

“Essa métrica está respondendo à pergunta que realmente estamos fazendo?”

Porque muitas vezes:

não.


🧠 Exemplo: disponibilidade

Dashboard:

SERVER UP:
100%

Pergunta real:

Cliente consegue pagar?

Server uptime responde:

outra pergunta.


☕ Servidor pode estar maravilhosamente vivo

enquanto aplicação:

morre lentamente.


🧠 Quantidade versus significado

Esse é o coração da McNamara Fallacy.

Números respondem muito bem:

quanto?

Mas nem sempre:

por quê?

com que qualidade?

em qual contexto?

com quais consequências?


🧠 War Room quantitativa

Imagine:

COMMANDS EXECUTED: 147

Isso significa:

incident response excelente?

Talvez significa:

ninguém sabia o que estava fazendo.


☕ Número sozinho não conhece ironia

Precisamos:

interpretar.


🧠 Body count e o Vietnã

A associação histórica mais conhecida da falácia está justamente na tentativa de usar contagens — notadamente baixas inimigas — como medida de progresso estratégico na Guerra do Vietnã. Críticos argumentaram que transformar essas contagens em indicador de sucesso criava incentivos para exagero e não capturava fatores políticos, sociais e estratégicos decisivos para o conflito.

Em linguagem de TI:

imagine medir:

incidentes resolvidos

sem medir:

incidentes evitados.

O time com:

100 incidentes

e:

100 resolvidos

parece muito ativo.

O time com:

5 incidentes

talvez:

pareça menos produtivo.

Qual você prefere administrar seu pagamento?

Pois é.


🧠 Contar o que acontece pode punir prevenção

Incidente evitado:

não gera ticket.

Vulnerabilidade eliminada cedo:

não gera P1.

Capacity planning correto:

não gera War Room.

Resultado:

trabalho excelente produz:

ausência de evento.

Ausência é difícil:

de contar.

McNamara Fallacy pode:

subvalorizar prevenção.


☕ O herói invisível

Talvez aquele sysprog que ninguém chamou às 03:00 porque:

ele fez direito às 15:00.

Não ganhou:

foto na War Room.

Mas talvez seja:

o verdadeiro herói.


🧠 Hero Culture aparece

Quem apaga incêndio:

visível.

Quem evita:

invisível.

Se promotion mede:

incidents resolved,

adivinhe:

qual trabalho tem carreira melhor?

Campbell.

Perverse Incentive.

McNamara.


🎯 Pergunta Bellacosa nº 3

“Estamos premiando aquilo que conseguimos contar ou aquilo que gostaríamos que acontecesse?”


🧠 Conhecimento tácito

Agora entramos num território importantíssimo.

Um profissional experiente olha:

RMF.

Algo incomoda.

Não sabe ainda:

explicar.

Ele diz:

“Tem alguma coisa estranha aqui.”

Júnior pergunta:

— Qual métrica?

— Ainda nenhuma específica.

Isso é:

inútil?

Não.

Pode ser:

pattern recognition.

Experiência acumulada.

Recognition-Primed Decision.

Milhares de situações anteriores.


☕ O famoso:

“Esse batch está com cheiro estranho.”

Não existe:

SMF FIELD = SMELL.

Ainda.


🧠 Experiência não substitui dados

Importante.

O veterano pode:

estar errado.

Confirmation Bias.

Availability.

Recency.

Overconfidence.

Nós já exploramos:

todos eles.

A resposta não é:

“veterano sempre tem razão.”

É:

“A observação dele é uma hipótese que merece investigação.”


🧠 Dados + julgamento

Não:

dados versus humano.

Melhor:

DATA
+
EXPERIENCE
+
CONTEXT
+
TEST
=
BETTER DECISION

👻 Easter Egg nº 2 — House MD no NOC

Todos os exames:

normais.

Paciente:

mal.

Médico:

— Os números dizem que está saudável.

House:

— Então o paciente está fingindo morrer para sabotar o Excel?

Na produção:

dashboard verde.

Cliente:

sem pagar.

Não tente:

convencer cliente que está tudo bem.

Investigue.


🧠 Produção tem poder de veto

Essa é uma regra Bellacosa:

quando dashboard e realidade entram em conflito, a realidade ganha e o dashboard vira suspeito.


☕ Grafana não tem direito de voto contra cliente

Pode parecer injusto.

Mas é assim.


🧠 McNamara Fallacy e produtividade

Empresa quer:

programadores produtivos.

Como medir?

Difícil.

Escolhe:

COMMITS

Ou:

LINES OF CODE

Ou:

TICKETS CLOSED

Agora:

Programador A:

100 commits.

Programador B:

A é melhor?

Não sabemos.

B talvez:

removeu código.

Mentorou pessoas.

Descobriu flaw arquitetural.

Preveniu incidente.


☕ Dez mil linhas escritas

podem significar:

produtividade.

Ou:

necessidade de delete.


🧠 COBOL versão

Programador A:

CHANGED LINES = 1200

Programador B:

CHANGED LINES = 1

B corrigiu:

       IF ACCOUNT-STATUS = 'A'

para a condição correta que estava:

duplicando cobrança.

Quem produziu mais valor?

Boa sorte:

com COUNT(LINES).


🧠 O que é fácil medir ganha status

Essa é a perversidade.

Commits:

fácil.

Mentoria:

difícil.

Logo:

commits ganham dashboard.

Mentoria:

vira:

“soft.”

Mas knowledge transfer pode:

salvar operação daqui três anos.


🎯 Pergunta Bellacosa nº 4

“Que trabalho essencial desaparece quando avaliamos somente aquilo que produz contadores?”


🧠 McNamara e treinamento

Objetivo:

competência.

Difícil medir.

Proxy:

horas de curso.

TRAINING:
100 HOURS

Fantástico.

Aluno consegue:

resolver um S0C7?

Talvez.


☕ Assistir não é saber

Completion:

não é competência.

Goal Substitution.

McNamara:

competência difícil → completion fácil.


🧠 Badge Count

Empresa:

742 badges.

Excelente.

Capability?

Precisamos:

investigar.

Badge:

evidência.

Não:

verdade.


🧠 Dunning-Kruger pode aparecer

Pouco conhecimento.

Badge.

Confiança aumenta.

Produção:

educa.

Às vezes:

brutalmente.


🧠 McNamara Fallacy e segurança

Objetivo:

reduzir risco.

Difícil.

Proxy:

number of critical vulnerabilities.

CRITICAL = 0

Excelente.

Mas:

credential compromise?

Social engineering?

Insider threat?

Supply chain?

Misconfiguration?

Unknown unknowns?

Não cabem:

num único contador.


☕ Zero findings

não significa:

zero vulnerability.

Pode significar:

zero finding.

As palavras importam.


🧠 Compliance

CONTROLS IMPLEMENTED:
100%

Segurança:

100%?

Não.

Controle pode:

existir.

Não funcionar.


🧠 Backup

BACKUP SUCCESS:
100%

Recoverability:

?

Teste:

restore.

Essa é provavelmente:

uma das metáforas perfeitas.

Backup mede criação da cópia. Restore mede parte do objetivo.


☕ Backup é promessa

Restore é evidência.


🎯 Pergunta Bellacosa nº 5

“Estamos medindo a existência do controle ou a capacidade que ele deveria garantir?”


🧠 McNamara e SLA

SLA:

99.9%.

Fornecedor:

cumpriu.

Cliente:

irritado.

Como?

Latency.

Errors.

Data correctness.

Support.

O SLA mediu:

uma dimensão.

Contrato transformou:

essa dimensão

em:

verdade.

Principal-Agent Problem.


🧠 Metric becomes contract becomes behavior

Goodhart.

Campbell.

McNamara.


☕ O cliente não lê SLA durante indisponibilidade

Ele tenta:

usar.


🧠 McNamara Fallacy e Agile

Objetivo:

entregar valor.

Difícil.

Proxy:

velocity.

Fácil.

Equipe:

40 points.

Depois:

Agora:

valor aumentou?

Talvez.

Ou:

story point inflation.


🧠 A unidade não é física

Story Point não existe:

em Paris.

Não há:

International Bureau of Story Points.

Logo:

contexto.


☕ Um story point de um time

não cabe necessariamente:

no copybook do outro.


🧠 DevOps

Objetivo:

fluxo rápido e seguro.

Proxy:

deployments.

Mais deployments:

melhor?

Talvez.

Se:

quality stable.

Value delivered.


🧠 McNamara pergunta:

“Quantos deploys?”

Senior pergunta:

“Para quê?”

Essa segunda pergunta:

vale carreira.


🎯 Pergunta Bellacosa nº 6

“O aumento do número necessariamente representa aumento do valor?”

Se não:

proxy.


🧠 McNamara e cost optimization

Objetivo:

eficiência sustentável.

Proxy:

custo mensal.

Meta:

-20%.

Equipe corta:

monitoring.

Redundancy.

Training.

Capacity.

Dashboard financeiro:

verde.

Risk:

sobe.


☕ O custo ficou menor

porque:

algumas proteções também ficaram menores.

Não aparece:

na mesma coluna.


🧠 Present Bias

Savings:

agora.

Incident:

futuro.

Present Bias.

Moral Hazard:

quem recebe bônus talvez não esteja lá quando:

conta chegar.


🧠 McNamara e headcount

Objective:

capability.

Proxy:

people count.

Temos:

20 COBOL programmers.

Então:

safe.

Perguntas:

Quantos conhecem settlement?

Quantos conhecem CICS?

Quantos conseguem atuar sozinhos?

Quantos estão perto de aposentadoria?

Quantos documentaram?


☕ Headcount ≠ knowledge distribution

COUNT(*)

continua:

não sendo senioridade.


🧠 Bus Factor

Difícil.

Mas fundamental.

Se uma pessoa sair:

o que quebra?

Talvez isso seja:

mais importante que:

headcount.


🎯 Pergunta Bellacosa nº 7

“Estamos contando recursos ou compreendendo capacidade?”


🧠 McNamara e IA

Agora chegamos:

em território delicioso.

Objetivo:

IA útil.

Como medir?

Benchmark.

Accuracy.

Task completion.

Tokens.

Prompt success.

Tudo:

quantificável.

Mas:

helpfulness?

Judgment?

Side effects?

Trust?

Context?

Harder.


🤖 McNamara Fallacy automatizada

Agent score:

TASK COMPLETION:
99.4%

Excelente.

Uma das tarefas restantes:

transferiu:

R$10 milhões errado.

Score:

ainda maravilhoso.


☕ Média alta

não absolve:

catástrofe rara.


🧠 Tail risk

Critical systems care about:

eventos raros.

Average:

pode esconder.


🧠 AI eval

Benchmark:

Real user task:

falha.

Which wins?

Real-world evidence.

Benchmark:

map.


🎯 Pergunta Bellacosa nº 8

“Se o agente maximizasse perfeitamente essa métrica, gostaríamos do mundo resultante?”

Se resposta:

não,

rethink reward.


🧠 Reward Hacking

Goal:

resolve tickets.

Agent:

marks closed.

Score:

high.

Goal Substitution.

Goodhart.

McNamara.


🧠 Measurement modeling

Muitos conceitos importantes — como habilidade, risco ou fairness — não são diretamente observáveis e precisam ser operacionalizados por meio de medidas que carregam pressupostos. Em sistemas computacionais, pesquisadores destacam justamente que discrepâncias entre o conceito real e sua operacionalização podem produzir danos e decisões equivocadas.

Em Bellacosa:

todo score tem um copybook conceitual, mesmo quando ninguém documentou.


☕ Pergunte pelo copybook

Score:

PIC?

Significado?

Denominator?

Exclusion?

Sem isso:

número solto.


🧠 A falsa precisão

RISK SCORE = 83.72

Wow.

83.72 de quê?

Qual modelo?

Qual confidence?

Qual data freshness?


☕ Duas casas decimais

não curam:

incerteza.

Só deixam incerteza:

mais elegante.


🧠 McNamara e Dashboard Culture

Executivo pede:

“Give me one number.”

Complex system responds:

“I can give you one number.”

Isso não significa:

que deveria.


🧠 Composite score

Availability:

Security:

Customer:

Average:

Score:

O que significa?

Talvez:

quase nada.


☕ Média pode esconder incêndio

Se cozinha pega fogo

e sala está:

temperatura agradável,

a temperatura média da casa:

talvez seja aceitável.

Você ainda deve:

sair.


🧠 Metric Fixation + McNamara

Um número:

simplifica.

Metric Fixation:

dá autoridade.

McNamara:

nega o resto.


🎯 Pergunta Bellacosa nº 9

“Que realidade perigosa foi apagada para conseguirmos resumir tudo em um número?”


🧠 O desconhecido precisa existir no dashboard

Isso parece estranho.

Mas:

KNOWN:
70%

UNKNOWN:
30%

pode ser:

mais honesto que:

READINESS:
93.17%

quando ninguém sabe:

como chegou.


UNKNOWN é um estado válido

E muito importante.


🧠 Need for Control odeia UNKNOWN

Quer:

número.

Control Bias:

pressiona.

Illusion of Control:

aparece.

Score surge.

Todos:

mais calmos.

Realidade:

igual.


🧠 McNamara Fallacy também é uma história sobre desconforto

É difícil administrar:

ambiguidade.

Então:

quantificamos.

A quantificação:

reduz ansiedade.

Mas talvez não:

risco.


☕ Dashboard pode ser ansiolítico corporativo

Não necessariamente:

controle.


🧠 Doctor Who e o scanner

Companion:

— Scanner diz que planeta não tem vida.

Doctor:

— E aquela cidade?

— Scanner diz zero.

— Talvez...

— Scanner é calibrated.

— Então aqueles milhões de seres devem estar interpretando a própria existência incorretamente.

Nunca deixe:

sensor

ganhar disputa com:

realidade observável.


🧠 McNamara e incidentes raros

Imagine:

99.999% success.

Um failure:

perde bilhões.

Average:

ótima.

Risk:

terrível.

Safety-critical systems:

tails matter.


🧠 Severity > frequency às vezes

Não conte:

apenas quantos.

Pergunte:

quais.


🎯 Pergunta Bellacosa nº 10

“Estamos usando frequência para esconder severidade?”


🧠 Base Rate

Também:

número absoluto sem denominator:

enganoso.

100 errors.

Ruim?

Em:

1.000 requests:

terrível.

Em:

10 bilhões:

outra história.


☕ Numerador sem denominador

é café:

sem água.

Forte demais.


🧠 McNamara e averages

Average response:

200ms.

P99:

12s.

Customer no tail:

não vive na média.


☕ O cliente mora no percentil dele

Não:

no dashboard executivo.


🧠 Quantitative ≠ objective automatically

Escolher:

o que medir

é:

decisão.

Definir:

threshold

é:

decisão.

Peso:

decisão.

Exclusion:

decisão.

Então:

número contém julgamento humano.


🧠 A fórmula tem autor

Importantíssimo.

Mesmo:

SCORE = 0.4A + 0.3B + 0.3C

Alguém escolheu:

0.4.


☕ Excel não decidiu sozinho

Alguém:

configurou a religião.


🧠 McNamara e management

Uma organização pode acreditar:

“data-driven.”

Mas ser:

“dashboard-driven.”

Não é a mesma coisa.


🧠 Data-informed

Métrica:

informa.

Context:

completa.

Judgment:

decide.

Evidence:

valida.


☕ Dados participam da reunião

Não precisam:

presidir sozinhos.


🧠 O perigo contrário

Cuidado.

Não transforme este artigo em:

“dados não importam.”

Isso seria:

outra besteira.

Intuição sem dados:

Confirmation Bias.

Availability.

Overconfidence.

Narrative Bias.

Também ruim.


🧠 A solução não é abandonar medidas

É:

triangular.

Dados.

Experiência.

Contexto.

Outcome.


🧠 Bellacosa Three Sensors

Para uma decisão importante:

1. Métrica

O que números mostram?

2. Realidade operacional

O que usuários e operação mostram?

3. Julgamento estruturado

O que especialistas acreditam e por quê?

Se três concordam:

confidence ↑.

Se divergem:

investigate.


☕ Divergência é informação

Não:

inconveniência.


🧠 McNamara e qualitative evidence

Operador:

“Está estranho.”

Isso não é:

conclusão.

É:

sinal.

Registre.

Teste.

Correlacione.

Não descarte.


🧠 Human anomaly detector

Às vezes:

o humano detecta primeiro.

Depois:

encontramos métrica.

Isso é:

normal.


🎯 Pergunta Bellacosa nº 11

“Estamos exigindo uma métrica para permitir que alguém formule uma hipótese?”

Se sim:

talvez estejamos cegando:

observação.


🧠 McNamara e RCA

Database asks:

root cause.

Form:

ROOT CAUSE:
[ ] HUMAN ERROR
[ ] SOFTWARE
[ ] HARDWARE
[ ] NETWORK

E se causa for:

combinação de:

incentivo;

deadline;

interface ruim;

staffing;

technical debt?

Não cabe.

Então:

seleciona:

HUMAN ERROR.

Agora relatório:

HUMAN ERROR:
62%

Management:

“people are problem.”

Fundamental Attribution Error.


☕ Talvez o formulário tenha causado:

parte da análise ruim.

Meta-ironia.


🧠 Data model shapes thinking

Se sistema só permite:

uma causa,

organização começa:

a procurar uma causa.

Se realidade:

multi-causal,

perdemos:

complexidade.


🎯 Pergunta Bellacosa nº 12

“Nosso modelo de dados está simplificando uma realidade que não é simples?”


🧠 McNamara e McNamara — uma importante cautela histórica

A falácia carrega o nome de McNamara como crítica a um estilo de gestão quantitativo associado ao Vietnã, mas não devemos reduzir toda a guerra ou todas as decisões de McNamara a “ele olhava números e por isso tudo deu errado”. Guerras envolvem decisões políticas, militares, institucionais, culturais e estratégicas muito mais amplas. A própria formulação da falácia é uma lente para um tipo de erro de raciocínio, não uma explicação completa para o conflito.

Isso é importante porque:

usar uma explicação simples para criticar o excesso de explicações simples seria quase poeticamente errado.

Bellacosa aprova a ironia.


🧠 McNamara depois reconheceria erros

Décadas depois, McNamara refletiu publicamente sobre erros graves cometidos na condução da Guerra do Vietnã, inclusive em suas memórias In Retrospect.

Isso também é:

uma lição.

Métrica errada:

não exige pessoa burra.

Muito pelo contrário.

Sistemas inteligentes podem:

errar com enorme sofisticação.


☕ Inteligência não imuniza contra viés

Às vezes:

permite justificar erro

com:

PowerPoint melhor.


🧠 McNamara e Dunning-Kruger?

Não diretamente.

Mas:

score pode criar:

overconfidence.

Dashboard:

parece compreensão.

O executivo entende:

indicadores.

Começa a sentir:

que entende sistema.

Talvez não.


🧠 Illusion of Control

Tudo tem:

score.

Logo:

controlamos.

Não.

Medir:

não é controlar.

Controlar:

não é compreender.

Compreender:

não é prever perfeitamente.


☕ Três coisas diferentes

Que PowerPoint gosta de:

misturar.


🧠 McNamara e Drift Into Failure

Agora uma conexão maravilhosa.

A cada trimestre:

KPI melhora.

Mas:

trabalho invisível sobe.

Overtime.

Workaround.

Debt.

Knowledge concentration.

Nenhuma métrica oficial:

vê.

Sistema deriva:

lentamente.

Até:

falha.


🌀 McNamara Drift

VISIBLE KPI ↑
      ↓
CONFIDENCE ↑
      ↓
HIDDEN MARGIN ↓
      ↓
HIDDEN WORK ↑
      ↓
RISK ↑
      ↓
INCIDENT

Todos ficam:

surpresos.

Mas talvez:

sinais sempre estiveram lá.

Só não possuíam:

célula.


☕ Ausência no dashboard

não é:

ausência no universo.


🧠 Normalization of Deviance

Manual workaround:

não medido.

Funciona.

Repete.

Normaliza.

Ainda:

não medido.

Até:

incidente.

Outra conexão.


🎯 Pergunta Bellacosa nº 13

“Que adaptação informal mantém nossos números bonitos?”

Essa é brutal.


🧠 Maria Middleware

Sistema:

“100% automated.”

Maria:

todo dia corrige CSV.

Ninguém mede:

Maria.

Logo:

automation score = 100%.

Maria tira férias.

Automation:

descobre:

férias.


☕ A arquitetura verdadeira aparece quando alguém sai de férias

Clássico.


🧠 Human toil

Precisamos tornar:

parte visível.

Não necessariamente:

transformar tudo em score.

Pode ser:

narrativa.

Sampling.

Observation.


🧠 McNamara Fallacy não exige número para tudo

Esse é justamente:

o antídoto.

Algumas coisas:

podem continuar:

qualitativas.


☕ “Difícil de medir”

não significa:

“precisamos inventar 72.84.”

Talvez seja:

“precisamos conversar.”


🧠 Qualitative evidence não é licença para achismo

Use:

estrutura.

Interview.

Peer review.

Decision journal.

Pre-mortem.

Postmortem.

Observação.


🧠 House MD method

Hipótese.

Evidence.

Test.

Refute.

Não:

“senti.”


🎯 Pergunta Bellacosa nº 14

“Como podemos transformar essa observação qualitativa em uma hipótese testável sem fingir que ela já é uma métrica?”

Essa é maturidade.


🧠 McNamara e Technical Debt

Feature count:

fácil.

Technical debt:

difícil.

Features ganham:

dashboard.

Debt:

silêncio.

Anos depois:

velocity cai.

Management:

surpresa.


🧠 Debt was real before score existed

Claro.


☕ Uma rachadura não precisa:

de KPI

para quebrar parede.


🧠 Maintainability

Como medir?

Complexity.

Coverage.

Lead time.

Todos proxies.

Mas developer pode:

olhar código

e dizer:

“isso está ficando impossível.”

Não ignore.


🧠 Architecture

Number of microservices:

fácil.

Architectural quality:

difícil.

Então:

500 microservices.

Modernization score:

excellent.

System:

distributed monolith.

Congratulations.


☕ Modernidade por contagem

Uma religião perigosa.


🧠 McNamara e Cloud

Percent migrated:

80%.

Great.

Mas:

80 systems easy.

Critical three:

remain.

Count:

80%.

Risk retired:

maybe 10%.


🎯 Pergunta Bellacosa nº 15

“Estamos contando unidades equivalentes quando, na realidade, elas possuem pesos completamente diferentes?”


🧠 Security example

100 vulnerabilities.

90 low.

10 critical.

Close:

Progress:

90%.

Risk reduction:

talvez pequeno.

Goal Gradient:

quer 100%.

Metric fixation:

celebra 90%.

McNamara:

ignora severity se dashboard não pesa.


🧠 Weighted metrics?

Better.

But:

weight is model.

Still:

human judgment.


☕ Melhor modelo

não significa:

realidade completa.

Só:

modelo menos ruim.


🧠 McNamara e Customer Experience

NPS:

Customer happy?

Maybe.

Who responded?

What context?

Selection bias.

Silent churn?

Metric helps.

Not whole truth.


🧠 Complaints

Zero complaints.

Could mean:

excellent.

Or:

complaint process impossible.

Again.


🎯 Pergunta Bellacosa nº 16

“Quem está ausente deste número?”

Maravilhosa para:

surveys.


🧠 McNamara e analytics

Page views:

high.

Impact:

?

Someone reads:

40 minutes.

One session.

No click.

Maybe article:

important.

Another:

clickbait.

20k views.

Metric:

winner.

Outcome:

different.


☕ Atenção não é valor

Mas é:

mais fácil contar.


🧠 Academia também enfrenta esse dilema

Citações.

Número de publicações.

Journal ranking.

Tudo:

útil.

Mas:

qualidade,

impacto social,

ensino,

mentoria,

replicabilidade

são mais difíceis de reduzir.

McNamara Fallacy generaliza:

muito além de guerra.


🧠 Medicina

A literatura médica também emprega o termo para criticar avaliações que dependem excessivamente de endpoints quantitativos facilmente mensuráveis quando eles não capturam integralmente resultados clínicos relevantes ou qualidades importantes dos profissionais.

Isso demonstra:

o padrão.

O domínio muda.

Erro lógico:

continua.


☕ Quando algo é difícil de medir

o risco é escolher:

o que é fácil

e esquecer:

por que começamos.


🧠 Bellacosa Measurement Pyramid

Podemos pensar:

        PURPOSE
          ▲
        OUTCOME
          ▲
       EVIDENCE
          ▲
        METRICS
          ▲
         DATA

Data:

embaixo.

Purpose:

em cima.

McNamara Fallacy acontece quando:

pirâmide vira:

DATA
 ↓
METRIC
 ↓
TRUTH

E o resto:

some.


🧠 O número precisa subir

Não governar.


SELECT COUNT(*)

é ferramenta.

Não filosofia de vida.


🧠 Como combater a McNamara Fallacy — passo a passo

Passo 1 — Comece pelo objetivo

Não pela disponibilidade dos dados.

Pergunte:

“O que realmente queremos saber?”


Passo 2 — Liste o que é fácil medir

CPU.

Errors.

Tickets.

Latency.

Good.


Passo 3 — Liste o que importa mas é difícil medir

Knowledge.

Trust.

Maintainability.

Fatigue.

Workarounds.


Passo 4 — Não invente precisão

Talvez use:

assessment qualitativo.


Passo 5 — Triangule

Métrica.

Outcome.

Expert judgment.


Passo 6 — Use counter-metrics

Speed:

com quality.

Cost:

com reliability.


Passo 7 — Procure hidden work

Quem mantém:

o KPI verde?


Passo 8 — Pergunte por unknowns

Não esconda:

incerteza.


Passo 9 — Red Team do indicador

Como pode:

enganar?


Passo 10 — Deixe realidade ter veto

Cliente quebrado:

vence dashboard.


📋 Checklist Bellacosa anti-McNamara

[ ] O que estamos tentando entender?

[ ] O que conseguimos medir facilmente?

[ ] O que é importante mas difícil de medir?

[ ] Estamos ignorando algo por falta de KPI?

[ ] Criamos um score artificial para preencher o vazio?

[ ] Há falsa precisão?

[ ] Existem unknowns?

[ ] Há trabalho humano invisível?

[ ] O KPI pode melhorar com realidade pior?

[ ] Estamos contando atividade ou outcome?

[ ] Frequência está escondendo severidade?

[ ] Média está escondendo cauda?

[ ] Especialistas estão levantando sinais qualitativos?

[ ] O dashboard contradiz usuários?

[ ] Sabemos quem está ausente da amostra?

[ ] O indicador ainda serve ao objetivo?

🧠 Bellacosa Reality Map

Antes de decisão crítica:

REAL GOAL:
_____________________________

WHAT WE MEASURE:
_____________________________

WHAT WE CANNOT MEASURE WELL:
_____________________________

WHAT EXPERTS ARE SEEING:
_____________________________

WHAT CUSTOMERS ARE SEEING:
_____________________________

KNOWN UNKNOWNS:
_____________________________

HIDDEN WORK:
_____________________________

DECISION:
_____________________________

Muito simples.

Mas:

muda a conversa.


🧠 A coluna UNKNOWN

Talvez todo dashboard crítico devesse permitir:

UNKNOWN

Sem vergonha.

Porque:

fingir certeza

não cria:

certeza.


UNKNOWN

é muito mais profissional

que:

92.73%

inventado.


🧠 McNamara e Red Team

Antes de adotar KPI:

pergunte:

“Como poderíamos parecer excelentes nesse indicador enquanto destruímos exatamente aquilo que ele deveria proteger?”

Exemplo:

MTTR:

restart tudo.

Uptime:

disable monitoring.

Cost:

cut redundancy.

Training:

play videos.

Tickets:

premature close.

Security findings:

stop looking.

Essa pergunta:

destrói muitos KPIs ruins em:

dez minutos.


🧠 McNamara e Data Literacy

Ser data-driven não é:

acreditar em número.

É saber:

questionar número.

Numerator?

Denominator?

Selection?

Bias?

Missingness?

Definition?


☕ “Mostre o SQL.”

Uma bela forma de:

epistemologia corporativa.


🧠 Context is the copybook

Um número:

000000423

Sem copybook:

o que significa?

Valor?

Quantidade?

Data?

Packed decimal?

Mesma coisa:

KPI sem contexto.


💻 COBOL Metric Copybook

       01 KPI-CONTEXT.
          05 KPI-NAME            PIC X(30).
          05 KPI-PURPOSE         PIC X(80).
          05 KPI-NUMERATOR       PIC X(80).
          05 KPI-DENOMINATOR     PIC X(80).
          05 KPI-SCOPE           PIC X(80).
          05 KPI-EXCLUSIONS      PIC X(80).
          05 KPI-LIMITATIONS     PIC X(80).
          05 KPI-CONFIDENCE      PIC X(10).

Comentário:

* DO NOT PROCESS
* KPI WITHOUT COPYBOOK.

Perfeito.


👻 Easter Egg nº 3 — Management ABEND

IEF450I DASHBOARD ABEND S0KPI

Reason:

EXCESSIVE TRUST IN NUMERIC PROXY

Recommended action:

CHECK REALITY
CONSULT OPERATIONS
VALIDATE OUTCOME
DRINK COFFEE

🧠 Goal Gradient aparece novamente

Estamos:

97%.

McNamara Fallacy:

97 = quase pronto.

Mas:

remaining tasks:

rollback;

restore;

reconciliation.

Quantidade:

3%.

Risk:

talvez 80%.


☕ Pergunte:

não:

“quanto falta?”

Mas:

“o que falta e quanto risco mora lá dentro?”


🧠 McNamara e Ratchet

Performance:

Next target:

Why?

Metric.

Ratchet.

But maybe:

100 involved:

overtime.

Hidden.

Not measured.

Target:

rises.

People:

burn.

McNamara ignored:

qualitative sustainability.


🧠 Sustainable capacity

Harder than:

output.

Still:

important.


🎯 Pergunta Bellacosa nº 17

“Que custo invisível tornou este número possível?”

Uma das melhores.


🧠 McNamara e Cobra Effect

Problem:

bugs.

Pay:

per bug fixed.

Bugs:

increase.

Dashboard:

fixes up.

Management:

success.

Because measured:

fixes.

Not:

quality.

Cobra + McNamara.


🧠 Principal-Agent

Principal:

wants outcome.

Agent:

measured proxy.

Proxy:

wins.


☕ Se contrato mede cobra morta

ninguém deveria se surpreender:

com criação de cobra.


🧠 McNamara e Zero-Risk Bias

Risk score:

1%.

We eliminate.

Other risk:

40%

hard to measure.

We focus:

1%.

Because:

number exists.

That is:

McNamara + Zero-Risk.


🧠 Easy measurable risk attracts governance

Hard ambiguous risk:

ignored.

Danger.


🎯 Pergunta Bellacosa nº 18

“Estamos priorizando este risco porque ele é maior ou porque ele é mais fácil de colocar numa planilha?”

Excelente.


🧠 McNamara e Need for Control

Ambiguity:

uncomfortable.

So:

more metrics.

More dashboards.

More scores.

More controls.

Eventually:

measurement theater.

We feel:

control.

System:

same.


☕ Dashboard wall

não é:

force field.

Infelizmente.


🧠 McNamara e Framing

“99% success.”

Sounds:

great.

“10.000 failures.”

Sounds:

bad.

Both:

same.

Context.

Metric alone:

frame.


🧠 Always show numerator + denominator

Better.


🧠 McNamara e Narrative Bias

Numbers create:

story.

Revenue ↑.

Incidents ↓.

Therefore:

strategy works.

Maybe.

Need:

causal evidence.


☕ Correlação vestida de terno

continua:

correlação.


🧠 McNamara e Outcome Bias

KPI good.

Project success.

Therefore:

method good.

Maybe luck.

Need:

process review.


🧠 Decisions need journals

What knew?

What assumptions?

Then:

learn.


🧠 McNamara e Actor-Observer

Our bad score:

context.

Their bad score:

competence.

Again:

numbers don't eliminate:

bias.

They can:

decorate it.


☕ KPI pode virar:

preconceito com conditional formatting.

Cuidado.


🧠 McNamara e Fundamental Attribution Error

Team has:

more incidents.

Leadership:

bad team.

Maybe:

harder system.

More volume.

Old tech.

Less staffing.

Context.

Raw count:

misleads.


🎯 Pergunta Bellacosa nº 19

“Qual contexto precisaria estar no denominador para essa comparação ser justa?”


🧠 McNamara e Dunning-Kruger

Simple score:

creates:

simple certainty.

The less you understand:

domain,

more attractive:

score.

Expert knows:

caveats.

Novice sees:

Says:

“Team B is 12% better.”

Expert:

headache.


☕ A complexidade começa

onde o ranking termina.


🧠 McNamara e mainframe performance

CPU:

down 20%.

Great.

But:

I/O up 300%.

Elapsed:

same.

You optimized:

number.

Not:

system.

Local Optimization.


🧠 Performance tuning needs system view

CPU.

I/O.

Elapsed.

Throughput.

Business.


☕ Tornar um número menor

não é automaticamente:

tunagem.

Pode ser:

mudança de endereço do problema.


🎯 Pergunta Bellacosa nº 20

“Onde foi parar o custo que aparentemente desapareceu?”

Excelente.


🧠 McNamara e observability

Collect everything?

Also trap.

You can have:

a million metrics

and still not understand:

system.

More measurement:

does not automatically fix:

McNamara Fallacy.

Because you may still:

measure the easy million

and miss:

the hard one.


☕ Um milhão de sensores

não medindo a coisa certa

é:

um milhão de sensores errados.


🧠 More metrics ≠ more truth

Need:

questions.

Not:

telemetry hoarding.


🧠 Observability starts with unknown questions

Can system help:

investigate things

we didn't anticipate?

That's richer than:

fixed KPIs.


🧠 McNamara e unknown unknowns

A mature system accepts:

some things:

we don't know we don't know.

Design:

resilience.

Don't pretend:

score covers universe.


☕ A humildade precisa:

de coluna.


🧠 Bellacosa Four-Stage Alarm

Toda vez que ouvir:

Etapa 1

“Não medimos.”

Normal.

Etapa 2

“Então não temos evidência quantitativa.”

Ainda normal.

Etapa 3

“Então provavelmente não importa.”

⚠️

Etapa 4

“Então isso não existe.”

🚨

McNamara.


🧠 Uma frase muito útil

“Ausência de métrica não é métrica de ausência.”

Essa merece:

quadro.


☕ Repito:

ausência de métrica não é métrica de ausência.


🧠 Como um programador COBOL iniciante usa isso amanhã?

Você recebe:

ticket:

“Batch slow.”

Dashboard:

elapsed +20%.

Não conclua:

“programa piorou.”

Pergunte:

volume?

Input?

CPU?

I/O?

Db2?

Locks?

Storage?

Network?

Downstream?

Calendar?


🧠 Número é começo da investigação

Não:

fim.


💻 Exemplo

ELAPSED:
+20%

VOLUME:
+45%

Talvez performance por record:

melhorou.

Sem contexto:

conclusão invertida.


☕ Denominador salva carreiras

Às vezes.


🧠 Outra situação

Defects:

+50%.

Bad?

Maybe testing improved.

More detection.

Quality:

maybe better long-term.

Campbell lesson.

McNamara:

count alone doesn't know.


🧠 Reporting culture

More incidents:

could mean:

less safety.

Or:

more transparency.

Need:

context.


🎯 Pergunta Bellacosa nº 21

“Uma piora nessa métrica poderia ser sinal de uma organização melhor?”

Se sim:

interprete.


🧠 Bellacosa Anti-McNamara Ritual

Antes da reunião executiva:

cada KPI precisa de:

WHAT IT SAYS
WHAT IT DOES NOT SAY
WHAT MAY BE HIDDEN
WHAT REALITY SAYS

Quatro linhas.

Talvez:

mais úteis que:

20 gráficos.


🧠 Example

KPI:
Incidents ↓ 40%

SAYS:
Fewer recorded incidents.

DOES NOT SAY:
Total customer harm.

MAY HIDE:
Under-reporting.

REALITY CHECK:
Complaints also ↓ 35%.

Agora:

mais confiança.


☕ Um bom dashboard também explica:

seus limites.


🧠 Bellacosa Reality Triangulation

METRIC
   ↘
    REALITY
   ↗
HUMAN OBSERVATION

Se três:

convergem,

great.

Se não:

War Room.


👻 Easter Egg nº 4 — TARDIS coordinates

Painel:

LOCATION:
GALLIFREY

Doctor abre porta.

Praia.

Companion:

— Painel diz Gallifrey.

Doctor:

— Praia diz praia.

— Qual vence?

Doctor:

— Vamos dar ao universo direito de resposta.

Boa metodologia.


🧠 McNamara Fallacy e liderança

Um líder maduro pergunta:

não apenas:

“Qual o número?”

Mas:

“O que esse número representa?”

“O que não representa?”

“Quem pode estar invisível?”

“Qual evidência contradiz?”

Isso é:

data literacy.


☕ Dashboard não reduz:

necessidade de pensar.

Ele deveria:

melhorar pensamento.


🧠 McNamara e confiança organizacional

Se leadership aceita apenas:

quantitative proof,

times aprendem:

traduzir tudo:

em score.

Até coisas:

que não deveriam.

Agora:

pseudo-precision.


🧠 Arbitrary scores

Knowledge risk:

Why 83?

Nobody.

But:

green/amber/red.

Looks:

professional.


☕ Às vezes:

“alto risco”

é mais honesto que:

“82.43”.


🧠 Ordinal versus cardinal

Low/medium/high may:

fit evidence.

Don't invent:

false ratio.


🧠 McNamara e uncertainty

Use:

range.

Confidence.

Unknown.

Not:

fake precision.


🎯 Pergunta Bellacosa nº 22

“Estamos quantificando porque sabemos ou porque temos vergonha de dizer que não sabemos?”

Brutal.


🧠 Scientific humility

Not knowing:

information.

It tells:

where investigate.


UNKNOWN

não é ABEND.

É:

status.


🧠 McNamara Fallacy em uma linha COBOL

       IF NOT-MEASURED
           MOVE 'NOT-IMPORTANT'
             TO BUSINESS-VALUE
       END-IF.

Bug.

Grande.


💻 Correção

       IF NOT-MEASURED
           MOVE 'UNKNOWN'
             TO MEASUREMENT-STATUS
           PERFORM INVESTIGATE-IMPORTANCE
       END-IF.

Muito melhor.


🧠 Bellacosa Wisdom Copybook

* EASY TO MEASURE
* IS NOT THE SAME
* AS IMPORTANT.

* HARD TO MEASURE
* IS NOT THE SAME
* AS IRRELEVANT.

* NOT MEASURED
* IS NOT THE SAME
* AS NONEXISTENT.

Este é:

o artigo inteiro.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

McNamara Fallacy é o erro de depender excessivamente de indicadores quantitativos e ignorar fatores relevantes por serem difíceis de medir.

A expressão é associada a Daniel Yankelovich e recebeu o nome de Robert McNamara, cujo estilo quantitativo de gestão ficou historicamente ligado à condução da Guerra do Vietnã.

A associação mais conhecida envolve o uso de medidas como body counts para inferir progresso num conflito cuja realidade política, social e estratégica era muito mais complexa.

O problema não começa ao medir coisas fáceis; começa quando ignoramos aquilo que não é fácil de medir.

Goal Substitution transforma proxy em objetivo.

Metric Fixation dá autoridade excessiva ao proxy.

McNamara Fallacy pode levar à conclusão de que aquilo que não é quantificado não merece atenção.

Goodhart mostra como a métrica muda ao virar meta.

Campbell mostra como grandes consequências ligadas à métrica aumentam distorções.

Cobra Effect mostra como o incentivo pode fazer o problema ganhar valor.

Goal Gradient faz correr mais quando a meta aproxima.

Ratchet transforma bons resultados em novas obrigações.

CC=0000 não significa integridade de negócio.

Backup success não significa recoverability.

Training completion não significa competência.

Headcount não significa capability.

Uptime não significa que o cliente conseguiu fazer aquilo que queria.

Número de controles não significa proteção.

Número de tickets fechados não significa problemas resolvidos.

Aquilo que não conseguimos medir pode continuar sendo absolutamente real.

E principalmente:

ausência de métrica nunca deve ser confundida com métrica de ausência.


🥚 Easter Egg final

Na manhã seguinte nosso jovem encontra:

BELLACOSA.BIAS(MCNAMARA)

Dentro:

       IF EASY-TO-MEASURE = 'Y'
           PERFORM MEASURE
       END-IF.

       IF HARD-TO-MEASURE = 'Y'
           PERFORM DO-NOT-IGNORE
       END-IF.

       IF DASHBOARD = 'GREEN'
          AND REALITY = 'BROKEN'
           MOVE 'REALITY'
             TO SOURCE-OF-TRUTH
       END-IF.

       IF MEASUREMENT-STATUS = 'UNKNOWN'
           PERFORM INVESTIGATE
       END-IF.

Comentários:

* WHAT IS EASY
* TO COUNT
* IS NOT NECESSARILY
* WHAT COUNTS MOST.

Outro:

* UNKNOWN
* DOES NOT MEAN
* ZERO.

Outro:

* NOT IN DASHBOARD
* DOES NOT MEAN
* NOT IN REALITY.

Outro:

* A SENSOR
* IS NOT THE UNIVERSE.

E naturalmente:

* TARDIS PANEL:
* GALLIFREY.
*
* DOOR:
* DINOSAURS.
*
* TRUST:
* THE DINOSAURS.

Nosso jovem fecha o membro.


🕰️ De volta às 08:27

Diretor:

— Então precisamos parar de usar métricas?

Nosso jovem:

— Pelo contrário.

— Como assim?

— Precisamos usar métricas melhores.

— E medir mais coisas?

— Talvez.

— Então qual é a diferença?

Ele pensa.

— Antes de medir mais...

Pausa.

— precisamos lembrar que algumas coisas importantes continuarão sendo difíceis de medir.

— E fazemos o quê com elas?

— Não fingimos que desapareceram.

Doctor sorri.


🔧 O dashboard muda

Antes:

SERVICE HEALTH:
97.8

Depois:

SERVICE HEALTH

CUSTOMER OUTCOME .... GREEN
TECHNICAL HEALTH .... GREEN
DATA INTEGRITY ...... GREEN
MANUAL TOIL ......... AMBER
KNOWLEDGE RISK ...... RED

KNOWN UNKNOWNS:
- failover under peak load
- two-person restart dependency

EXPERT CONCERNS:
- settlement timing drift

Ficou:

menos elegante.

Mais difícil:

de colocar numa linha.

Muito mais:

honesto.


☕ O executivo olha

— Isso não cabe num score único.

Nosso jovem responde:

— Talvez o sistema também não caiba.

Boa.


🧬 Regeneração organizacional

Uma organização madura não abandona números.

Ela:

mede.

Compara.

Analisa.

Automatiza.

Cria dashboards.

Mas também:

questiona definições;

investiga unknowns;

escuta especialistas;

observa clientes;

procura trabalho invisível;

revê incentivos;

e permite que:

contexto

sobreviva à planilha.

Ela entende:

quantificação é uma ferramenta para enxergar a realidade, não uma autorização para eliminar da realidade aquilo que não conseguimos quantificar.


🥚 Último comentário do Doctor

Antes de entrar na TARDIS:

* IF REALITY
* DOES NOT FIT
* YOUR DASHBOARD,
*
* FIX THE DASHBOARD.
*
* DO NOT FIX
* REALITY.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

Na War Room sobra apenas:

“Meça tudo que puder. Respeite aquilo que ainda não consegue medir. E jamais permita que a facilidade de contar alguma coisa decida sozinha quanto essa coisa importa.”

E talvez essa seja toda a essência da McNamara Fallacy.

☕🌀

Next stop: Streetlight Effect — o dia em que perdemos a chave no estacionamento escuro, mas continuamos procurando debaixo do poste porque era o único lugar onde havia luz. Em mainframe: investigar somente os logs, dashboards e componentes onde é fácil procurar, mesmo quando todas as evidências dizem que a causa pode estar justamente fora do nosso campo iluminado.

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...