☕ 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

sábado, 12 de junho de 2010

☕👄💣 KUCHISAKE-ONNA — O CHAMADO DE PRODUÇÃO QUE NINGUÉM DEVERIA ATENDER

 

Bellacosa Mainframe e a assustadora Kuchisake-Onna

☕👄💣 KUCHISAKE-ONNA — O CHAMADO DE PRODUÇÃO QUE NINGUÉM DEVERIA ATENDER

Se você trabalhou anos em produção de mainframe, sabe que existe uma regra não escrita:

Quando o telefone toca às 3 da manhã, raramente vem coisa boa.

Agora imagine receber uma chamada em uma rua vazia.

Uma mulher se aproxima.

Ela usa máscara.

Ela olha diretamente para você e faz apenas uma pergunta:

"Eu sou bonita?"

Nesse exato momento, você acaba de iniciar um dos jobs mais perigosos da história do folclore japonês.

Bem-vindos ao caso de Kuchisake-Onna, a Mulher da Boca Rasgada, uma lenda urbana que há décadas assombra o imaginário japonês e continua aterrorizando novas gerações.


O DATASET MAIS ASSUSTADOR DO FOLCLORE JAPONÊS

Kuchisake-Onna (口裂け女) significa literalmente:

"Mulher da Boca Cortada".

Segundo a lenda, ela aparece usando uma máscara cirúrgica — algo extremamente comum no Japão.

À primeira vista, parece apenas mais uma pessoa caminhando pela rua.

Mas então ela faz a pergunta fatal:

"Watashi, kirei?"

"Eu sou bonita?"

Se a vítima responder "não", ela é morta imediatamente.

Se responder "sim", a mulher remove a máscara.

É então que o sistema sofre um ABEND.

Sua boca está rasgada de uma orelha à outra.

Uma cicatriz grotesca atravessa todo o rosto.

Ela então faz a segunda pergunta:

"E agora?"

Nesse momento não existe resposta correta.

É como um programa COBOL preso em loop infinito sem condição de saída.


O BUG LÓGICO DA MALDIÇÃO

A genialidade da lenda está justamente na armadilha.

A pergunta parece simples.

Mas qualquer resposta leva ao desastre.

Se disser que ela continua bonita, ela pode cortar seu rosto para deixá-lo igual ao dela.

Se disser que ela é horrível, ela o mata.

Ou seja:

Você entrou em um fluxo sem rollback.

Um job condenado desde o primeiro EXEC.

Por isso muitos estudiosos classificam Kuchisake-Onna como uma das primeiras lendas urbanas modernas do Japão.

Ela funciona quase como um algoritmo psicológico.

Não depende de força física.

Não depende de poderes sobrenaturais espetaculares.

Depende apenas de uma decisão impossível.


O IPL DA LENDA

Existem diversas versões para a origem da Mulher da Boca Rasgada.

A mais famosa remonta ao período Heian, entre os séculos VIII e XII.

Segundo a história, ela era uma mulher extremamente bonita.

Seu marido, consumido pelo ciúme, acreditava que ela o traía.

Tomado pela fúria, rasgou sua boca com uma espada.

Enquanto a mutilava, teria gritado:

"Quem vai achar você bonita agora?"

Após a morte, seu espírito teria retornado para buscar vingança.

Como acontece com muitos sistemas antigos, ninguém sabe exatamente qual é a versão original.

Existem dezenas de forks da mesma história.

Mas o núcleo do código permanece o mesmo.

Trauma.

Vaidade.

Violência.

Vingança.


O INCIDENTE DE PRODUÇÃO DE 1979

Foi em 1979 que a lenda sofreu seu maior upgrade.

E foi aí que ela deixou de ser apenas folclore.

Virou pânico nacional.

Durante aquele ano começaram a surgir relatos por todo o Japão.

Crianças afirmavam ter visto a Mulher da Boca Rasgada.

Professores relatavam boatos.

Pais organizavam grupos para escoltar alunos.

Algumas escolas passaram a recomendar que as crianças voltassem para casa em grupos.

A mídia amplificou o fenômeno.

Em pouco tempo o país inteiro estava falando dela.

Imagine uma falsa mensagem JES2 circulando em milhares de consoles simultaneamente.

Foi exatamente esse o efeito.

O mito se espalhou mais rápido que qualquer mecanismo tradicional de comunicação.

Muito antes da internet.

Muito antes das redes sociais.

Muito antes dos smartphones.


ENGENHARIA SOCIAL SOBRENATURAL

Do ponto de vista psicológico, Kuchisake-Onna é fascinante.

Ela explora vulnerabilidades profundamente humanas.

Primeiro:

O medo da deformidade.

Segundo:

O medo do desconhecido.

Terceiro:

A incapacidade de tomar decisões sob pressão.

Ela age exatamente como um atacante especializado em engenharia social.

A vítima acredita estar participando de uma conversa simples.

Na realidade já foi comprometida.

A pergunta é apenas o vetor de ataque.

O exploit acontece na resposta.


AS TÉCNICAS DE CONTORNO

Como todo problema em produção, logo surgiram soluções improvisadas.

Segundo algumas versões da lenda, é possível escapar respondendo:

"Você está normal."

Outras sugerem responder com outra pergunta.

Há versões que afirmam que oferecer doces pode distraí-la.

Outras dizem que ela fica confusa se você responder algo ambíguo.

Na linguagem mainframe:

São workarounds.

Nenhum oficialmente homologado.

Nenhum garantido.

Todos criados por usuários desesperados tentando evitar um crash inevitável.


A MÁSCARA QUE SE TORNOU UM ÍCONE

Existe um detalhe que torna a lenda ainda mais poderosa.

A máscara.

No Japão, máscaras cirúrgicas são comuns há décadas.

Por causa disso, qualquer pessoa mascarada pode ativar um gatilho psicológico associado ao mito.

Essa é a força das melhores lendas urbanas.

Elas não vivem em castelos assombrados.

Não vivem em florestas misteriosas.

Vivem no cotidiano.

Na esquina.

No ônibus.

Na rua vazia.

Na caminhada para casa.

É exatamente aí que o cérebro humano começa a preencher os espaços em branco.


O LEGADO NO CINEMA E NA CULTURA POP

Kuchisake-Onna tornou-se uma das figuras mais importantes do horror japonês.

Sua influência aparece em filmes, mangás, animes, videogames e séries de televisão.

Ela ajudou a consolidar um tipo específico de terror japonês:

O horror do encontro casual.

A ideia de que o sobrenatural não está escondido em algum lugar distante.

Ele está esperando na próxima esquina.

Essa abordagem influenciou inúmeras obras posteriores.

De certa forma, ela é uma ancestral espiritual de várias entidades assustadoras que surgiriam nas décadas seguintes.


O RCA FINAL

Se um sysprog fosse contratado para investigar Kuchisake-Onna, provavelmente encontraria a seguinte causa raiz:

O monstro nunca foi a boca cortada.

O monstro nunca foi a máscara.

O monstro nunca foi o fantasma.

O verdadeiro problema sempre esteve no ser humano.

Na obsessão pela aparência.

Na crueldade.

Na insegurança.

No julgamento.

No medo de não ser aceito.

Kuchisake-Onna sobrevive há gerações porque fala diretamente dessas falhas.

Ela é um dump psicológico da sociedade.

Um relatório de erros que nunca foi corrigido.

Um bug humano executado continuamente através dos séculos.

E talvez seja exatamente por isso que sua pergunta continua tão assustadora.

Porque, no fundo, todos nós sabemos que algumas perguntas não possuem resposta segura.

Principalmente quando são feitas por alguém que já perdeu tudo.

Inclusive a própria humanidade.

☕👄💣 STATUS FINAL DO JOB:

KUCHISAKE-ONNA CONTINUA EM EXECUÇÃO.

SEM PATCH.

SEM ROLLBACK.

SEM DATA PREVISTA PARA ENCERRAMENTO.

terça-feira, 8 de junho de 2010

☕ Lei da Recorrência — ou: nada acontece só uma vez, você é que não prestou atenção☕ Lei da Recorrência — ou: nada acontece só uma vez, você é que não prestou atenção

 

Bellacosa Mainframe e lei da recorrência

☕ Lei da Recorrência — ou: nada acontece só uma vez, você é que não prestou atenção

 

Vou confessar logo de cara: a Lei da Recorrência sempre me assombrou. Principalmente quando eu jurava que “isso nunca mais vai acontecer”… e pronto, lá estava ela de novo, batendo na porta, usando outra roupa, mas com o mesmo cheiro de déjà-vu.

📜 Origem da Lei da Recorrência

A ideia de recorrência aparece em vários lugares:

  • Na filosofia (Nietzsche e o “eterno retorno”)

  • Na matemática (funções recursivas)

  • Na física (ciclos naturais)

  • Na psicologia (padrões de comportamento)

  • E, claro, no mainframe 😄

A essência é simples e cruel:

aquilo que não é compreendido, resolvido ou encerrado… retorna.

🧠 Recorrência em modo Bellacosa

No mundo real, a recorrência aparece assim:

  • Você muda de emprego, mas o mesmo tipo de problema aparece

  • Troca de sistema, mas os erros se repetem

  • Muda de cidade, mas carrega os mesmos conflitos

  • Refatora o código, mas mantém a mesma lógica ruim

O cenário muda. O padrão não.

🖥️ Recorrência no Mainframe (easter egg técnico)

Todo veterano já viu:

  • Abend recorrente em fim de mês

  • Job que falha sempre no feriado

  • Programa que “só dá problema em produção”

  • Correção rápida que vira permanente

E o clássico comentário:

* ESTE PROBLEMA JA ACONTECEU EM 2003

A recorrência ri disso.

📺 Curiosidades & Easter Eggs

  • Em Groundhog Day (Feitiço do Tempo), o filme inteiro é sobre recorrência

  • Em Re:Zero, o sofrimento do protagonista é um loop recorrente

  • No Japão, ciclos são respeitados — as estações, os rituais, os hábitos

🗣️ Fofoquices filosóficas

A recorrência é educada: ela avisa antes de ensinar.
Ignorada, ela vira pedagógica.
Persistente, ela vira trauma.

E sim, ela adora pessoas que dizem:

“dessa vez vai ser diferente”
…sem mudar nada.

🛠️ A prática da antirrecorrência

Para quebrar ciclos, é preciso:

  • Consciência (ver o padrão)

  • Registro (documentar)

  • Decisão (mudar algo real)

  • Ação sustentada (não só promessa)

No mainframe: post-mortem decente.
Na vida: autocrítica honesta.

🧘 Como entender a Lei da Recorrência

Pergunte-se:

  • Onde já vi isso antes?

  • O que eu evitei aprender da última vez?

  • O que continua igual em mim?

A recorrência não acusa. Ela repete.

🌏 Significado e importância

Ela nos ensina:

  • Que padrões governam mais que eventos

  • Que repetir erros é mais fácil que mudar hábitos

  • Que evolução exige ruptura consciente

No Japão, isso conversa com karma, mujo e kaizen.
No mainframe, com melhoria contínua e disciplina operacional.

☕ Conclusão Bellacosa

A Lei da Recorrência não quer te punir.
Ela quer ver se você aprendeu.

Se algo está sempre voltando, não é azar.
É lição pendente.

E como todo bom sistema legado ensina:

enquanto você não resolver a causa,
o problema volta — com outro nome,
outro horário,
e muito mais caro.

segunda-feira, 7 de junho de 2010

Hora feliz... pensa que um viajante não come?

A Brigite comanda o Espectáculo


Bom visitar um pais é uma experiência única, conhecer o povo, a cultura, as relíquias religiosas, as jóias arquitectónicas, ruínas arqueológicas e tesouros do passado.

Porem se não provarmos da culinária local, não podemos dizer que imergimos no pais. Eu sou uma pessoa de mente aberta e estômago de avestruz, adoro provar sabores, conhecer a culinária local




Um ícone da culinária são os biscoitinho secos e chá de hortelã bem doce que provei de norte a sul do Egipto.

De comidas posso dizer que provei carne de camelo, comi frango, búfalo... provei espagueti, arroz árabe, pão egípcio, batatas fritas e assadas, azeitonas, grão de bico, lentilha e outros quitutes mais.

Agora a gloria foi provar caldo de cana, nossa em Portugal não existe, então só quando visitava o Brasil tirava a barriga da miséria. Mas desta vez, não sempre que via um engenho, eu pedia para parar o bus e corria para comprar uma garrafinha. Ajuda aos navegantes o caldo de cana no Egito se chama ;  Gasab

Quando o caldo de cana atravessa as fronteiras gasab garapa 

Brasil Egito e Alemanha saboreando o caldo de cana




domingo, 6 de junho de 2010

Groupthink: Doctor Who, COBOL e o Dia em que Todo Mundo Concordou — e Mesmo Assim Estava Errado

Bellacosa Mainframe e o groupthink

☕ Um Café no Bellacosa Mainframe

Groupthink: Doctor Who, COBOL e o Dia em que Todo Mundo Concordou — e Mesmo Assim Estava Errado

Uma viagem pela TARDIS dos incidentes para entender por que grupos inteligentes podem tomar decisões ruins quando ninguém quer ser a voz discordante

10:06.

War Room aberta.

Sete pessoas na chamada.

Aplicação.

Db2.

Rede.

Operação.

Segurança.

Gestão.

E nosso programador COBOL iniciante, que ainda está naquela fase maravilhosa da carreira em que faz perguntas que os veteranos aprenderam a evitar.

O incidente parece sério.

Usuários reclamam.

Fila crescendo.

Alguns timeouts.

Um job mais lento.

O gerente pergunta:

— Alguma hipótese?

O especialista mais experiente responde:

— Deve ser infraestrutura.

Outro concorda:

— Também acho.

Terceiro:

— Faz sentido.

Quarto:

— Sim, principalmente depois daquela mudança.

Quinto:

— Concordo.

Sexto:

— Vamos nessa linha.

Nosso jovem programador olha para um gráfico.

Pensa:

“Mas esse gráfico parece mostrar outra coisa.”

Olha para os seis profissionais mais experientes.

Todos concordam.

Então ele pensa novamente:

“Talvez eu esteja entendendo errado.”

E não diz nada.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se no canto da sala.

O Doctor sai.

Escuta durante cinco minutos.

Depois pergunta:

— Quantas pessoas aqui acreditam que é infraestrutura?

Seis mãos.

Ele olha para o programador.

— E você?

O jovem hesita.

— Eu... também.

O Doctor inclina a cabeça.

— Interessante.

Pausa.

— Você acreditava nisso antes de ouvir os outros?

Silêncio.

Eis nosso monstro da semana:


Groupthink

Ou:

Pensamento de Grupo

O fenômeno pelo qual um grupo pode buscar consenso, harmonia ou coesão com tanta força que começa a perder capacidade crítica.


🌀 Onde estamos na nossa viagem?

Nossa TARDIS já encontrou uma bela coleção de criaturas perigosas.

Primeiro veio o Swiss Cheese Model.

Aprendemos que sistemas possuem várias barreiras e que todas podem falhar.

Depois estudamos Normalization of Deviance.

Descobrimos que desvios repetidos sem desastre podem virar normalidade.

Depois veio Hindsight Bias.

O passado parece óbvio quando já conhecemos o final.

Em seguida, Confirmation Bias.

Escolhemos uma hipótese e começamos a amar demais tudo que confirma nossa crença.

Depois, Anchoring Bias.

A primeira informação vira referência e puxa o resto da investigação.

Agora damos um passo coletivo.

Não é mais apenas um cérebro enganando a si mesmo.

É um grupo inteiro reforçando o mesmo engano.


🧠 O que é Groupthink?

O termo Groupthink ficou fortemente associado ao trabalho do psicólogo Irving Janis.

A ideia central é que grupos muito coesos podem priorizar concordância e unidade em detrimento de análise crítica.

Isso pode acontecer quando as pessoas:

  • evitam discordar;

  • censuram dúvidas;

  • presumem que todos concordam;

  • seguem autoridade sem questionar;

  • minimizam alternativas;

  • tratam críticas externas como inconvenientes;

  • valorizam velocidade de consenso acima de qualidade de decisão.

Em resumo:

GRUPO PRECISA DECIDIR
        ↓
UMA OPINIÃO GANHA FORÇA
        ↓
OUTRAS PESSOAS CONCORDAM
        ↓
DIVERGÊNCIA DIMINUI
        ↓
CONSENSO PARECE EVIDÊNCIA
        ↓
A DECISÃO FICA MAIS FRÁGIL

O perigo aparece quando:

“Todo mundo concorda” substitui “os dados suportam”.


☕ Bellacosa Mainframe: a reunião onde todos concordam

Imagine um incidente.

Um DBA famoso diz:

— É lock.

Outro DBA concorda.

O gestor conhece o primeiro DBA há 15 anos.

— Se ele diz que é lock, deve ser.

O analista de aplicação vê isso.

— Também acho provável.

Nosso programador iniciante encontra uma informação:

LOCK WAIT = NORMAL

Mas pensa:

“Eles sabem mais do que eu.”

Então fica calado.

A equipe passa 90 minutos investigando lock.

Depois descobre que o problema era MQ.

Esse é um exemplo clássico de como competência individual não garante inteligência coletiva.


🧠 Inteligência individual não soma automaticamente

Essa é uma ideia importante.

Coloque dez pessoas muito inteligentes numa sala.

Você não obtém automaticamente:

dez vezes mais inteligência.

Às vezes obtém:

uma opinião dominante repetida dez vezes.

Groupthink não depende de pessoas incompetentes.

Pode acontecer justamente com:

  • especialistas;

  • executivos;

  • equipes experientes;

  • organizações sofisticadas;

  • grupos de alta performance.

O problema não está no QI.

Está na dinâmica.


👻 Easter Egg nº 1 — “Everybody agrees”

Imagine uma nave em Doctor Who.

Todos os oficiais dizem:

— A criatura é inofensiva.

O Doctor pergunta:

— Como sabem?

— Porque todos concordamos.

Ele responde:

— Ah.

Pausa.

— Essa frase nunca termina bem.

Se todos chegaram à mesma conclusão usando a mesma informação e o mesmo raciocínio, talvez tenhamos apenas uma hipótese replicada.

Não várias análises independentes.


🧲 Anchoring Bias encontra Groupthink

Aqui nossos monstros começam a formar alianças.

Primeiro alguém lança:

“É rede.”

Isso é uma âncora.

Depois o especialista sênior concorda.

Outro também.

Agora surge pressão social.

Logo temos:

ANCHORING
“É rede.”

        ↓

GROUPTHINK
“Todo mundo acha que é rede.”

        ↓

CONFIRMATION BIAS
“Vamos procurar sinais de rede.”

        ↓

HINDSIGHT BIAS
“Era óbvio que era rede.”

Belíssima máquina cognitiva.

Terrível para produção.


🧀 Swiss Cheese + Groupthink

Lembra das fatias?

Uma delas pode ser:

revisão coletiva.

Em teoria, várias pessoas deveriam detectar coisas diferentes.

Mas se todas pensam igual, essa barreira perde diversidade.

Imagine code review.

Cinco revisores.

Todos vêm da mesma equipe.

Todos usam o mesmo padrão mental.

Todos confiam no autor.

Todos assumem que determinado risco não existe.

Cinco olhos.

Uma única perspectiva.

O queijo parece grosso.

Mas pode possuir um buraco enorme.


🧪 Code Review e consenso preguiçoso

Pull Request:

ALTERAÇÃO:
NOVA REGRA DE CÁLCULO

Primeiro reviewer:

— LGTM.

Segundo vê o LGTM do primeiro.

— Também.

Terceiro vê dois approvals.

— Aprovado.

Quarto nem quer ser o chato da festa.

— Ok.

Resultado:

quatro aprovações.

Análise profunda:

talvez uma.

Ou nenhuma.

Isso não significa que code review não funciona.

Significa que review perde valor quando aprovação social substitui inspeção técnica.


🧠 O fenômeno da autocensura

Uma parte especialmente perigosa do Groupthink é a autocensura.

Você vê problema.

Mas não fala.

Por quê?

Porque pensa:

“Talvez eu esteja errado.”

Ou:

“Não quero atrasar.”

Ou:

“Todo mundo já concordou.”

Ou:

“O gerente claramente quer seguir.”

Ou:

“Sou novo.”

Ou:

“O especialista é ele.”

Esse silêncio não aparece no log.

Mas pode ser a informação mais importante da reunião.


🪑 A cadeira vazia

Imagine que exista uma cadeira simbólica na War Room.

A cadeira da pergunta:

“E se estivermos errados?”

Essa cadeira deveria existir em toda investigação.

Porque grupos sob pressão convergem rápido.

E velocidade é útil.

Mas convergência prematura é perigosa.


🚨 Sintomas clássicos de Groupthink

Alguns sinais merecem atenção.

Frases como:

“Já estamos todos de acordo.”

“Não precisamos discutir isso.”

“Isso é óbvio.”

“Sempre fazemos assim.”

“Ninguém levantou objeção.”

“Se alguém discordasse, teria falado.”

Essa última é particularmente perigosa.

Silêncio não significa concordância.

Às vezes significa:

medo;

cansaço;

hierarquia;

pressão;

insegurança;

desinteresse;

ou simplesmente dificuldade de interromper.


🎭 Ilusão de unanimidade

Um grupo pode achar que existe consenso porque ninguém falou contra.

Exemplo:

gerente:

— Então fechamos rollback?

Silêncio.

— Ótimo, todos concordam.

Talvez não.

Talvez alguém pense:

“Não acho uma boa ideia.”

Mas nunca teve espaço.

A ausência de voz virou voto positivo.

Isso é péssima lógica.


🧠 Authority Gradient começa a aparecer

Existe um primo importante aqui:

Authority Gradient.

Quanto maior a distância percebida entre uma pessoa e outra em poder, senioridade ou status, maior pode ser a dificuldade de contestação.

Imagine:

vice-presidente;

gerente;

especialista;

júnior.

VP diz:

— Vamos subir.

Júnior pensa:

“Mas falta validação.”

Será que fala?

Depende da cultura.

Em ambientes maduros, deveria falar.

Em ambientes autoritários, talvez não.

E aí temos mais um buraco no queijo.


✈️ Aviação aprendeu isso com sangue

Em aviação, diferenças excessivas de autoridade entre comandante e copiloto foram associadas historicamente a falhas de comunicação e decisão.

Por isso conceitos como Crew Resource Management valorizam comunicação, challenge-response e possibilidade de contestação operacional.

A informática tem muito a aprender com isso.

Uma War Room não deveria ser uma monarquia.


💻 COBOL e a voz do iniciante

Imagine nosso programador.

Ele observa:

INPUT COUNT = 100000
OUTPUT COUNT = 97842
REJECT COUNT = 2158

A soma bate.

Tudo parece normal.

Mas ele percebe:

ontem o reject era 12.

Hoje:

Pergunta:

— Esse aumento é esperado?

Veterano:

— Provavelmente.

Gerente:

— Precisamos liberar.

Silêncio.

Ele poderia ficar quieto.

Mas pergunta novamente:

— Temos evidência de que é esperado?

Essa segunda pergunta pode impedir um incidente.


🌱 O novo enxerga o estranho

Isso conecta com Normalization of Deviance.

Veteranos podem ter normalizado práticas.

O iniciante ainda vê estranheza.

Groupthink pode esmagar exatamente essa vantagem.

Se a cultura ensina:

“Não questione quem sabe mais.”

a organização perde um sensor valioso.

O iniciante não precisa estar certo.

Mas sua pergunta precisa poder existir.


🔎 Discordância não é oposição

Esse ponto é fundamental.

Discordar não significa:

  • atacar;

  • ser negativo;

  • atrasar;

  • desrespeitar;

  • sabotar.

Discordar pode ser uma função de segurança.

Uma equipe madura diferencia:

conflito de ideias

de

conflito pessoal.


🧠 Psychological Safety

Aqui entra outro conceito poderoso:

segurança psicológica.

Em termos simples:

as pessoas sentem que podem falar, perguntar, admitir erro e levantar preocupação sem sofrer punição social desproporcional.

Sem isso:

near misses desaparecem;

dúvidas somem;

problemas ficam escondidos;

consenso artificial cresce.


☕ Pergunta Bellacosa

Durante uma decisão importante, alguém deveria perguntar:

“Quem discorda?”

Mas faça direito.

Não diga com tom ameaçador:

“Alguém tem alguma objeção?”

Isso normalmente produz silêncio.

Prefira:

“Quero pelo menos uma hipótese contrária.”

Agora discordância deixa de ser inconveniente.

Vira tarefa.


🧪 Devil’s Advocate

Uma técnica clássica:

escolha alguém para defender a hipótese contrária.

Exemplo:

equipe acredita que é aplicação.

Uma pessoa recebe missão:

encontre evidências de que não é aplicação.

Isso cria discordância funcional.

Importante:

a pessoa não precisa acreditar na hipótese contrária.

Seu papel é testá-la.


🔴 Red Team

Em decisões maiores, podemos usar ideia de Red Team.

Um grupo tenta desafiar:

  • plano;

  • arquitetura;

  • hipótese;

  • mudança;

  • segurança;

  • estratégia.

Não para destruir por esporte.

Mas para encontrar fraquezas antes que produção encontre.

Porque produção possui um Red Team extraordinário.

Chamado realidade.


🧪 Pre-mortem contra Groupthink

Lembra do pre-mortem?

Antes de uma mudança:

“Suponha que falhou espetacularmente. O que aconteceu?”

Agora peça respostas individuais antes da discussão.

Isso é importante.

Se todos ouvirem primeiro a ideia do especialista, já estarão ancorados.

Individual primeiro.

Grupo depois.


✍️ Brainwriting antes de brainstorming

Outra técnica interessante:

cada pessoa escreve suas hipóteses silenciosamente.

Depois apresentam.

Isso reduz:

  • ancoragem;

  • influência de autoridade;

  • pressão social;

  • domination by loudest voice.

Brainstorming puramente oral pode favorecer quem fala primeiro ou mais alto.

Brainwriting democratiza.


🗳️ Voto simultâneo

Em decisões técnicas:

não pergunte:

— João acha A. Quem concorda?

Pronto.

João virou âncora.

Melhor:

cada pessoa escolhe independentemente.

Depois revela.

Você pode descobrir:

A: 3 votos
B: 2 votos
C: 2 votos

Agora existe diversidade real.

Se João falasse primeiro, talvez tivéssemos:

A: 7.


🧩 Independência antes da convergência

Essa é talvez a regra mais importante contra Groupthink:

primeiro pensem separados; depois pensem juntos.

Você quer diversidade antes do consenso.

Depois convergir.

Se convergimos cedo demais, perdemos informação.


🏢 Groupthink em projetos

Não acontece só em incidentes.

Projeto:

gerente:

— Vamos fazer Big Bang.

Equipe:

— Parece bom.

Alguém pensa:

“Talvez migração gradual seja mais segura.”

Mas não fala.

Meses depois:

incidente.

Post-mortem:

— Por que ninguém sugeriu abordagem gradual?

Talvez alguém tenha pensado.

Mas pensar não deixa log.


🚀 Groupthink em go-live

Reunião GO/NO-GO.

Todos cansados.

Projeto atrasado.

Diretoria quer lançamento.

Pergunta:

— Algum bloqueador?

Silêncio.

GO.

Esse é um momento clássico de pressão de conformidade.

Porque dizer NO significa:

atraso;

explicação;

custo;

conflito.

Logo, o sistema social favorece GO.

Mesmo se o sistema técnico disser talvez.


🛑 Stop the Line

Culturas maduras criam direito explícito de interromper operação.

Qualquer pessoa pode dizer:

“STOP.”

Isso precisa ser real.

Não apenas slide corporativo.

Se o júnior diz STOP e depois é ridicularizado porque “não era nada”, ninguém mais usará.

Você treinou a organização a ficar em silêncio.


🧠 Consenso não é democracia perfeita

Outra nuance.

Groupthink não significa que consenso seja ruim.

Consenso é ótimo quando surge depois de:

  • diversidade;

  • análise;

  • contestação;

  • evidência;

  • alternativas;

  • validação.

O problema é:

consenso prematuro.


📊 Métrica interessante: dissent rate

Talvez equipes pudessem observar algo curioso:

quantas decisões importantes tiveram pelo menos uma objeção registrada?

Zero discordâncias durante meses pode parecer excelente.

Talvez não seja.

Em sistemas complexos, unanimidade permanente é suspeita.


🧠 Curiosidade: reuniões podem produzir conformidade

Seres humanos são animais sociais.

Pertencer ao grupo importa.

Discordar cria desconforto.

Esse mecanismo é antigo.

A operação de mainframe é moderna.

Nosso cérebro nem tanto.

Por isso precisamos de processos que compensem tendências humanas naturais.


🕸️ Groupthink e cultura de heróis

Imagine um especialista lendário.

Chamaremos de Carlos.

Carlos resolve tudo.

Durante incidente:

Carlos:

— É CICS.

Ninguém questiona Carlos.

Porque Carlos já salvou produção cinquenta vezes.

Isso parece racional.

Mas cria risco.

Carlos pode estar errado na quinquagésima primeira.

Expertise deveria aumentar peso de uma hipótese.

Não torná-la imune a teste.


🧙 O “Mago do Mainframe”

Toda empresa tem um.

A pessoa que sabe o comando misterioso.

O membro obscuro.

O parâmetro que ninguém entende.

Excelente.

Respeite.

Aprenda.

Mas nunca transforme conhecimento em autoridade incontestável.

Porque:

especialista é fonte de hipótese forte, não oráculo.


🧯 Near Miss + Groupthink

Imagine:

alguém quase executa mudança errada.

Uma pessoa comenta:

— Talvez devêssemos revisar o procedimento.

Equipe:

— Foi só distração.

Todos concordam.

Caso encerrado.

Isso pode ser Groupthink.

A hipótese “erro individual” é confortável.

Não exige questionar processo.

Near miss perdido.

Próximo episódio:

produção parada.


🧠 Groupthink e post-mortem

Post-mortem também pode sofrer.

Facilitador:

— Então concordamos que causa raiz foi erro humano?

Todos assentem.

Mas talvez:

  • treinamento estava ruim;

  • ferramenta era ambígua;

  • acesso excessivo;

  • procedimento desatualizado.

Se a primeira narrativa ganhou status social, alternativas morrem.

Por isso blameless post-mortem precisa estimular múltiplas explicações.


🔄 Como combater Groupthink: passo a passo

Passo 1 — Peça opiniões individuais primeiro

Antes da discussão:

cada pessoa escreve:

  • hipótese;

  • risco;

  • decisão recomendada.

Depois compartilham.


Passo 2 — Separe senioridade de ordem de fala

Não deixe sempre o mais sênior falar primeiro.

Às vezes faça:

júnior primeiro;

especialista depois;

gestor por último.

Isso reduz ancoragem hierárquica.


Passo 3 — Nomeie um Devil’s Advocate

Alguém precisa desafiar a hipótese dominante.

Formalmente.


Passo 4 — Registre alternativas

Quadro:

HIPÓTESE A — REDE
HIPÓTESE B — MQ
HIPÓTESE C — DB2
HIPÓTESE D — APLICAÇÃO

Não deixe alternativas desaparecerem só porque uma ficou popular.


Passo 5 — Pergunte explicitamente por evidência contrária

“Que dado torna nossa decisão errada?”

Excelente pergunta.


Passo 6 — Use confidence levels

Exemplo:

HIPÓTESE A
CONFIDENCE: 45%

Isso reduz certeza teatral.


Passo 7 — Crie ponto de revisão

“Reavaliamos em 20 minutos.”

Consenso não precisa ser permanente.


Passo 8 — Dê permissão explícita para discordar

Facilitador:

“Discordância é esperada. Quero ouvir riscos.”

Isso muda clima.


Passo 9 — Proteja quem levanta problema

Nunca puna socialmente falso positivo honesto.

Se alguém diz STOP e depois descobre que estava tudo certo, responda:

“Obrigado por levantar.”

Caso contrário você destrói o sensor.


Passo 10 — Documente opinião minoritária

Se houver discordância importante:

registre.

Talvez a minoria esteja errada.

Mas preserve.

Depois do resultado podemos aprender.


🧠 O perigo do “já decidimos”

Depois que uma decisão ganha investimento emocional, mudar fica difícil.

Agora entram:

  • sunk cost;

  • escalation of commitment;

  • plan continuation bias.

Outros monstros esperando no corredor.

Groupthink pode empurrar o grupo a continuar plano porque ninguém quer ser a primeira pessoa a dizer:

“Talvez devêssemos parar.”


🚦GO/NO-GO com voto secreto

Em mudanças críticas, uma técnica simples:

cada responsável responde independentemente:

GO;

NO-GO;

GO COM RISCO.

Depois revela.

Isso reduz pressão.

Se todos veem diretor dizendo GO primeiro, adivinhe qual palavra ficará popular.


🔬 Exemplo COBOL: revisão de cálculo financeiro

Programa calcula juros.

Especialista sênior diz:

— Fórmula está correta.

Três pessoas olham rapidamente.

Concordam.

Júnior faz cálculo manual.

Resultado diferente.

Agora aparecem duas opções culturais.

Cultura ruim:

— Você deve ter calculado errado.

Cultura boa:

— Excelente. Vamos comparar.

A segunda salva dinheiro.


💰 Groupthink em sistemas financeiros

Em banco, concordância rápida pode ser muito cara.

Imagine mudança em:

  • liquidação;

  • juros;

  • câmbio;

  • crédito;

  • reconciliação;

  • limites.

Uma premissa errada replicada por todos pode processar milhões corretamente...

segundo uma regra incorreta.

O mainframe fará exatamente o que mandamos.

Essa é sua elegância e seu terror.


🤖 Groupthink com IA

Agora um detalhe moderno.

Se várias pessoas usam a mesma IA para validar uma decisão, podemos criar algo curioso.

Cinco analistas perguntam ao mesmo modelo.

Recebem respostas parecidas.

Pensam:

“Cinco análises concordaram.”

Não necessariamente.

Talvez tenham consultado essencialmente a mesma fonte cognitiva.

Diversidade aparente.

Dependência comum.

Isso vale para ferramentas, dados e modelos.


🧠 Common Mode Failure cognitivo

Na engenharia existe ideia de falha de modo comum.

Várias redundâncias falham porque compartilham mesma dependência.

Groupthink pode ser algo semelhante.

Cinco revisores.

Todos usam:

mesma documentação;

mesma suposição;

mesmo dashboard;

mesma ferramenta;

mesmo especialista.

Não temos cinco barreiras independentes.

Temos cinco cópias da mesma fragilidade.


🧀 Swiss Cheese encontra Common Mode

Esse ponto é lindo para nossa série.

Você acredita possuir:

5 CAMADAS DE REVISÃO

Mas se todas compartilham a mesma premissa errada, os buracos já estão alinhados desde o começo.

A redundância é ilusória.


🛸 Doctor Who e as muitas perspectivas

Doctor Who funciona maravilhosamente como metáfora porque o Doctor raramente resolve tudo sozinho.

Companions fazem perguntas.

Percebem coisas.

Desafiam.

Trazem perspectiva humana.

Às vezes enxergam aquilo que o gênio alienígena não percebe.

Isso é uma bela lição organizacional:

diversidade não é decoração; é mecanismo de detecção.


👥 Diversidade cognitiva

Não precisamos apenas de pessoas diferentes.

Precisamos de perspectivas diferentes.

War Room ideal pode ter:

  • aplicação;

  • infraestrutura;

  • negócio;

  • operações;

  • segurança;

  • dados.

Cada uma observa outro pedaço.

Mas só funciona se puderem realmente discordar.

Se todos apenas seguem a voz mais forte, diversidade vira fotografia corporativa.


☕ Conselho Bellacosa para o iniciante

Você entrou numa reunião.

Todo mundo concorda.

Você vê algo estranho.

Não diga:

“Vocês estão todos errados.”

Talvez não seja a melhor estreia.

Use:

“Posso testar uma hipótese alternativa?”

Ou:

“Tem uma métrica que não estou conseguindo reconciliar com essa explicação.”

Ou:

“O que explicaria este dado se nossa hipótese principal estiver errada?”

Elegante.

Humilde.

Poderoso.


🧠 Humildade epistemológica

Palavra bonita para uma ideia simples:

posso estar errado.

Mas atenção:

ela vale para todos.

Júnior.

Sênior.

Especialista.

Gerente.

Doctor.

Uma equipe segura trabalha com:

“Acreditamos nisso com estas evidências.”

Não:

“Sabemos porque somos nós.”


📋 Checklist anti-Groupthink

Antes de decisão crítica:

[ ] Todos tiveram chance real de falar?

[ ] O mais sênior falou primeiro e ancorou?

[ ] Houve hipótese alternativa?

[ ] Alguém foi designado para contestar?

[ ] Temos evidências ou apenas consenso?

[ ] Existe dado contraditório?

[ ] Pessoas estão caladas por pressão?

[ ] O grupo está cansado ou com pressa?

[ ] Existe incentivo forte para uma decisão específica?

[ ] Podemos registrar opinião minoritária?

Se tudo está perfeito demais...

Talvez devêssemos olhar novamente.


🧬 Regeneração organizacional

Como regenerar depois de descobrir Groupthink?

Crie rituais que protejam dissenso.

Por exemplo:

opinião independente;

voto simultâneo;

red team;

devil’s advocate;

pre-mortem;

júnior falando primeiro;

hipóteses alternativas;

confidence score;

post-mortem blameless.

Com o tempo, discordância deixa de parecer problema.

Vira instrumento de qualidade.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Groupthink acontece quando busca por consenso reduz análise crítica.

Silêncio não significa concordância.

Especialistas podem criar âncoras poderosas.

Hierarquia pode sufocar informação.

Consenso não substitui evidência.

Diversidade só funciona se pessoas puderem discordar.

Opiniões independentes devem surgir antes da discussão coletiva.

Devil’s advocate e Red Team ajudam a desafiar certezas.

Proteja quem levanta riscos.

Uma voz discordante pode ser uma barreira de segurança.

E principalmente:

Se sete pessoas concordam, isso pode significar sete análises independentes — ou apenas uma ideia repetida sete vezes. Descubra qual das duas situações você tem.


🕰️ De volta à War Room

11:24.

A equipe está pronta para executar rollback.

O gerente pergunta:

— Então estamos todos de acordo?

Silêncio.

Nosso programador olha para a fila MQ.

Respira.

— Eu não estou.

A sala congela.

O gerente pergunta:

— Por quê?

— Porque se o deploy fosse a causa, eu esperaria degradação desde 02:00. Mas a fila só começou a crescer às 08:41.

O DBA olha.

O analista de rede abre outro gráfico.

Operação consulta logs.

Uma chamada externa começou a degradar exatamente às 08:39.

A hipótese muda.

Rollback cancelado.

A causa estava downstream.

O gerente olha para o jovem.

— Por que não falou antes?

Ele responde:

— Todo mundo parecia tão certo.

O Doctor coloca as mãos nos bolsos.

— E aí está o problema.

Pausa.

— Uma sala cheia de certeza pode ser um lugar bastante silencioso.

A equipe ri.

Um pouco desconfortável.

Mas aprende.

VWORP.

VWORP.

VWORP.

A TARDIS começa a desaparecer.


🥚 Easter Egg final

Mais tarde, nosso programador encontra um novo membro:

BELLACOSA.BIAS(UNIT)

Dentro existe:

       IF EVERYBODY-AGREES
           PERFORM ASK-WHY
       END-IF.

       IF NOBODY-DISAGREES
           PERFORM ASK-AGAIN
       END-IF.

No rodapé:

* SILENCE IS NOT CONSENSUS.

Logo abaixo:

* BAD WOLF WAS HERE.

Ele fecha o membro.

O telefone toca.

Nova mudança crítica.

GO/NO-GO em cinco minutos.

Na reunião, o diretor pergunta:

— Algum problema?

Antes que o silêncio seja confundido com concordância, nosso jovem diz:

— Podemos registrar os riscos individualmente antes de decidir?

O Doctor, em algum lugar do espaço-tempo, provavelmente sorri.

Porque nosso programador acabou de aprender algo que vai muito além de COBOL:

sistemas seguros não precisam apenas de pessoas inteligentes. Precisam de ambientes onde pessoas inteligentes possam dizer umas às outras que talvez estejam erradas.

☕🌀

Next stop: Authority Gradient — quando a hierarquia entra na War Room e transforma “acho que isso é perigoso” em “sim, senhor”.

sábado, 5 de junho de 2010

Visita ao bairro Copta no Cairo

Reduto cristão em meio a Cairo muçulmana.

Dentro da cidade do Cairo existe um bairro cristão onde se encontra a igreja Copta, hoje ligada a Igreja Católica Romana, mas em tempos idos, foi a sede da divulgação e guardiã de diversos documentos e relíquias.

São Marcos viveu em Alexandria, vários sábios e eruditos afluíam para esta região para compartilharem esse conhecimento, ainda hoje em escavações arqueológicas encontram fragmentos de escritos que constituem provas muito antigas dos livros Bíblicos.



Nesta região protegida dos extremistas existem museus, uma Sinagoga e diversas igrejas entre elas podemos citar a Igreja de São Jorge, que segundo a tradição foi ali martirizado e as correntes que o acorrentaram ainda estão ali, num outro ponto existe uma igreja construída sob uma antiga gruta que dizem ter abrigado São José, Maria e o Menino Jesus em sua fuga para o Egipto.

Também estão as ruínas romanas mais bem conservadas de todo o Cairo, resto da muralha e uma torre defensiva do quartel romano.

sexta-feira, 4 de junho de 2010

Necrópoles de Luxor: Conheça o Vale dos Reis

The Valley of the Kings 

O ponto alto da visita a Luxor, estamos visitando o Vale dos Reis a Necrópole mais famosa do mundo, onde estavam enterrado um grande numero de faraós egípcios, muitos deles grandiosos generais e conquistadores, hábeis políticos e grandes religiosos, porem todos foram suplantados pelo pequeno e insípido faraó Tutankhamon.



Mas graças aquelas pequenas ironias da vida. Tutankhamon cujo reinado foi um peidinho na historia do Egipto, se tornou o maior e mais famoso faraó do Mundo. Nao existe em nenhum registro um rei que ficou tão famoso e conhecido no mundo todo, tornando-se um ícone do mundo moderno.

Filmes, livros, gibis, fotos, lendas e maldiçoes o rei Tut se espalhou na cultura popular, que basicamente todo mundo, já ouviu ou ouvira falar nele.

Mas por que o faraó Tut ficou tão famoso? Graças ha um pequeno azar dos ladroes de túmulo. Enquanto todas as necrópoles do Vale dos Reis foram saqueadas, profanadas, roubadas, pilhadas e sacaneadas o nosso amigo Tut, foi esquecido e manteve seus tesouros originais guardados por quase 2500 anos, antes de ser profanado por arqueólogos modernos.

Traduzindo seu nome temos algo como "A imagem viva de Amon"  Tut (Imagem) Ankh (vida) Amon (deus egipcio), porem anteriormente seu nome era TutAnkhAton, porem como foi convertido a ponta da espada, trocou o deus. Outra curiosidade seu sarcófago e múmia são os únicos que ainda se encontram no Vale dos Reis.



Cavalgando uma mulinha no Vale dos Reis (Egito)

Donkey Rider

Tirando a parte da dozinha da Mulinha este passeio foi uma doideira, beirando o absurdo aquele mundareu de ocidentais, provenientes das maiores metrópoles e de países bem desenvolvidos. Se divertindo com algo tão simples e inocente como andar de mulinha.


Em Junho de 2010 numa grande viagem aventura no Egipto, tive a oportunidade de cavalgar uma mulinha com destino final o Vale do Reis no Egipto, foi super divertido a experiência... passar por vilarejos, ver egípcios em seus afazeres contidianos, ver fabricas, uma mesquita.

E se assistir com calma ate o final verá uns motoqueiros passando pelas mulas com caras divertidas, note como são rígidas as normas de segurança no Egipto.


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