 |
| Bellacosa Mainframe e a bike shedding rules |
☕ Um Café no Bellacosa Mainframe
Bike Shedding Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Fazia Todos Discutirem a Cor da Bicicleta Enquanto a Usina Estava Prestes a Explodir
"A Matrix não precisa impedir você de resolver o problema. Basta convencer todos a discutir o problema errado."
Introdução — A Reunião Dentro da Matrix
Neo entra em uma enorme sala de reuniões.
Na parede existe um painel gigantesco.
No centro aparece um alerta crítico.
⚠️ Sistema Bancário Nacional
Fechamento Noturno em Risco
O problema é gravíssimo.
O processamento pode falhar.
Milhões de transações dependem daquela execução.
Neo pergunta:
— Quem está cuidando disso?
Morpheus responde.
— Eles.
Neo olha para a sala.
Os analistas discutem apaixonadamente.
Mas não sobre o processamento.
Não sobre o Db2.
Não sobre o COBOL.
Nem sobre o CICS.
Eles discutem:
a cor dos gráficos
o nome da nova aplicação
se o botão deveria ser azul ou verde
o tamanho da fonte
se o README usa Markdown ou AsciiDoc
qual editor é melhor
se comentários devem começar com "", ">", ou "*> "
Enquanto isso...
o Job continua falhando.
A Matrix sorri.
O Agente Smith também.
Você acaba de presenciar um clássico caso de Bike Shedding.
O que é Bike Shedding?
Bike Shedding é um fenômeno onde pessoas gastam enorme quantidade de tempo discutindo assuntos simples e pouco importantes, enquanto ignoram questões realmente críticas.
Em outras palavras:
Quanto mais simples o assunto, mais pessoas opinam. Quanto mais complexo, menos pessoas participam.
É um comportamento psicológico extremamente comum.
E perigosamente frequente em projetos de software.
A origem do termo
O conceito nasceu em 1957.
Foi apresentado pelo historiador e cientista britânico Cyril Northcote Parkinson.
No livro:
Parkinson's Law
Ele descreve uma situação fictícia.
Imagine uma comissão aprovando três projetos.
Primeiro
Construção de um reator nuclear.
Custo:
Bilhões.
Ninguém entende engenharia nuclear.
Resultado?
Aprovado em cinco minutos.
Segundo
Construção de um laboratório.
Pouca discussão.
Terceiro
Construção de um bicicletário.
Valor pequeno.
Todo mundo entende bicicletas.
Resultado?
Horas debatendo:
cor
localização
tamanho
telhado
pintura
O bicicletário consumiu mais tempo que a usina nuclear.
Assim nasceu:
Bike Shedding
Matrix explica perfeitamente
A Matrix vive desviando atenção.
Não precisa esconder a verdade.
Basta oferecer distrações.
Em projetos acontece igual.
Enquanto a arquitetura inteira desmorona...
todos discutem:
"Essa variável deveria chamar CLIENTE ou CLIENT?"
O paradoxo do conhecimento
Existe uma explicação psicológica interessante.
As pessoas evitam opinar sobre assuntos que não dominam.
Mas adoram opinar sobre aquilo que parece simples.
Por isso:
Arquitetura distribuída?
Silêncio.
Nome do programa?
Todo mundo vira especialista.
O Programador COBOL Padawan
Imagine.
Você participa da primeira reunião.
Tema oficial:
Modernização do Core Bancário.
Você imagina discussões sobre:
CICS
Db2
APIs
z/OS Connect
MQ
segurança
performance
Mas a reunião inteira é consumida por:
"O novo padrão de comentários terá três ou quatro traços?"
Exemplo COBOL
Existe um programa.
PROGRAM-ID. FATUR001.
A equipe precisa alterar:
Uma regra tributária nacional.
Impacto:
Milhões de clientes.
Mas a reunião debate durante uma hora:
FATUR001
ou
FATURA01
ou
FAT-001
ou
BILL001
A regra tributária?
Ainda ninguém analisou.
Como nasce o Bike Shedding?
Normalmente começa assim.
Alguém apresenta um assunto complexo.
O grupo sente dificuldade.
Então alguém muda para um detalhe simples.
Exemplo.
"Precisamos definir a arquitetura."
Silêncio.
Então alguém pergunta.
"A propósito...
qual será a cor do dashboard?"
Pronto.
Uma hora desaparece.
O efeito psicológico
Nosso cérebro gosta de participar.
Quando o assunto parece fácil...
todos querem contribuir.
Isso gera sensação de pertencimento.
Mas também desperdiça tempo.
Matrix Reloaded
Imagine Neo diante do Arquiteto.
O Arquiteto explica uma estrutura extremamente complexa.
Neo tenta entender.
Então alguém interrompe.
"Gostei desse terno branco.
Onde comprou?"
É exatamente isso que acontece nas empresas.
O Agente Smith ama Bike Shedding
Porque ele sabe:
Enquanto vocês discutem detalhes...
ninguém resolve o problema verdadeiro.
O impacto em projetos
Bike Shedding provoca:
reuniões intermináveis
atrasos
decisões lentas
perda de foco
desgaste da equipe
E o pior.
Dá sensação de produtividade.
Todos participaram.
Mas nada aconteceu.
Um exemplo no Mainframe
Projeto:
Migrar milhares de programas COBOL para Enterprise COBOL 6.5.
Questões realmente importantes:
compatibilidade
desempenho
testes
NUMPROC
TRUNC
ARCH
OPT
SSRANGE
RENT
Mas a reunião discute:
"O template do PowerPoint ficará azul IBM ou azul escuro?"
Outro exemplo
Projeto:
Criar API PIX.
Discussão:
REST.
OAuth.
TLS.
MQ.
CICS.
JSON.
Mas metade da Sprint foi consumida decidindo:
Qual será o ícone da documentação.
Como reconhecer Bike Shedding?
Faça uma pergunta simples.
"O tempo gasto discutindo isso é proporcional ao impacto?"
Se não...
provavelmente existe Bike Shedding.
Os sintomas
Reuniões longas.
Decisões pequenas.
Grandes decisões adiadas.
Muito debate.
Pouca entrega.
O custo invisível
Imagine.
15 pessoas.
Reunião de duas horas.
Discutindo:
Nome da aplicação.
São:
30 horas de trabalho.
Sem produzir uma linha de código.
O Programador Sênior
Os profissionais mais experientes normalmente fazem uma pergunta.
"Isso impede a entrega?"
Se não impede...
seguem adiante.
Matrix e a Escolha
Morpheus oferece duas pílulas.
A azul.
Discutir detalhes infinitamente.
A vermelha.
Resolver o problema.
Toda equipe escolhe diariamente.
Como evitar Bike Shedding?
Definir objetivo da reunião
Qual decisão precisa sair daqui?
Time Box
15 minutos.
Acabou.
Decide.
Priorizar impacto
Quanto maior o impacto...
mais atenção.
Nomear um facilitador
Alguém precisa trazer a conversa de volta.
Criar Parking Lot
Assuntos paralelos.
Anotados.
Resolvidos depois.
O papel do Scrum Master
Excelente Scrum Masters interrompem gentilmente.
"Esse assunto é importante.
Mas não agora."
Essa frase economiza semanas.
O COBOL ensina foco
Programadores COBOL antigos possuem uma característica interessante.
Eles perguntam:
"O que está quebrado?"
Não:
"O que poderia ficar bonito?"
Primeiro estabilidade.
Depois estética.
Atenção!
Existe diferença entre:
Detalhe importante
e
Detalhe pequeno.
Segurança pode parecer detalhe.
Não é.
Performance pode parecer detalhe.
Não é.
Mas discutir durante quarenta minutos:
ordem alfabética dos COPYBOOKs...
provavelmente é.
Os riscos
Escopo cresce
Projeto atrasa
Equipe desmotiva
Clientes esperam
Arquitetura piora
Porque ninguém teve tempo para ela.
Curiosidade
Google.
IBM.
Microsoft.
Amazon.
Todas treinam líderes para reduzir Bike Shedding.
Algumas utilizam:
Decision Records
RFCs
ADR (Architecture Decision Records)
Justamente para evitar discussões infinitas.
Um exemplo engraçado
Chamado:
"Erro no cálculo do IR."
Reunião.
Primeira hora.
Escolha do nome da branch.
Segunda hora.
Cor do dashboard.
Terceira hora.
Modelo do documento.
Quarta hora.
Finalmente alguém pergunta.
"O erro ainda existe?"
Sim.
O Oráculo explica
O Oráculo olha para Neo.
E pergunta.
"O que realmente importa?"
Essa pergunta encerra metade das reuniões inúteis do mundo.
Aplicabilidade
Bike Shedding aparece em:
Desenvolvimento
Infraestrutura
Cloud
Segurança
Banco de Dados
Mainframe
DevOps
IA
Projetos Ágeis
Gestão
É praticamente universal.
Boas práticas
Priorize valor
Cliente antes.
Estética depois.
Decisões reversíveis
Se puder mudar depois...
não desperdice horas.
Documente rapidamente
Decidiu.
Registre.
Siga em frente.
Use especialistas
Nem toda decisão precisa de vinte pessoas.
Faça perguntas
"Qual impacto?"
"Qual risco?"
"Qual benefício?"
Erros comuns
Querer consenso absoluto.
Confundir democracia com eficiência.
Dar o mesmo peso para toda decisão.
Ignorar prioridade.
Não encerrar discussões.
O ensinamento para o Programador COBOL Padawan
Você entrará em muitas reuniões.
Algumas serão fundamentais.
Outras parecerão infinitas.
Aprenda a distinguir.
Sempre pergunte:
"Essa conversa ajuda o cliente?"
Se não.
Talvez todos estejam apenas pintando o bicicletário.
Curiosidades adicionais
O conceito de Bike Shedding inspirou diversas práticas modernas de gestão:
Regra dos Dois Minutos para Decisões Simples: se a decisão é barata e reversível, decida rapidamente.
ADR (Architecture Decision Records): registrar decisões arquiteturais evita rediscussões constantes.
Disagree and Commit: popularizado pela Amazon, incentiva que, após uma decisão ser tomada, a equipe siga em frente mesmo sem consenso absoluto.
Impacto × Esforço: muitas organizações usam matrizes para concentrar energia nas decisões que realmente afetam o negócio.
Matrix Revela a Verdade
No final da trilogia, Neo compreende que o maior poder da Matrix nunca foi controlar máquinas.
Foi controlar a atenção das pessoas.
Na Engenharia de Software acontece exatamente o mesmo.
Projetos raramente fracassam porque ninguém sabia programar COBOL.
Eles fracassam porque energia, tempo e inteligência foram consumidos discutindo assuntos periféricos enquanto os problemas críticos permaneceram intocados.
Cada minuto debatendo a cor de um botão quando uma arquitetura precisa ser definida é como permitir que mais um Agente Smith se multiplique dentro da Matrix.
Conclusão — Não Pinte o Bicicletário Enquanto Zion Está Sob Ataque
Imagine que Zion esteja prestes a ser invadida.
As sentinelas aproximam-se.
O núcleo de energia está instável.
As comunicações falham.
Nesse cenário, ninguém pararia para discutir a cor da pintura da garagem das naves.
No entanto, em projetos de software isso acontece todos os dias.
Em ambientes IBM Z, onde aplicações COBOL movimentam bilhões de reais diariamente, o foco deve estar nas decisões que garantem disponibilidade, segurança, desempenho, confiabilidade e continuidade do negócio. Questões cosméticas têm seu lugar, mas não podem competir com decisões arquiteturais e operacionais críticas.
O Programador COBOL Padawan que deseja evoluir para um verdadeiro Arquiteto da Frota Estelar precisa desenvolver uma habilidade rara: distinguir o importante do apenas interessante. Antes de entrar em qualquer discussão, pergunte:
Isso reduz riscos para o negócio?
Isso melhora a qualidade do software?
Isso acelera a entrega de valor?
Ou estamos apenas discutindo a cor do bicicletário?
Porque, no universo Bellacosa Mainframe, existe uma regra que vale tanto para Zion quanto para um CPD bancário:
"Enquanto você debate detalhes sem importância, o verdadeiro problema continua executando em produção."
E essa talvez seja a maior ilusão criada pela Matrix.
