 |
| Bellacosa Mainframe e a brooks law rules |
☕ Um Café no Bellacosa Mainframe
Brooks's Law Rules sem Mistérios
Quando um Programador COBOL Descobriu que Colocar Mais Pessoas na Matrix Não Fazia o Tempo Andar Mais Devagar
"Nove mulheres não fazem um bebê nascer em um mês. Da mesma forma, vinte programadores não entregam um projeto de seis meses em apenas duas semanas." — Inspirado em Frederick P. Brooks Jr.
Prólogo — A Reunião de Emergência na Nebuchadnezzar
A situação era crítica.
Faltavam apenas vinte dias para entregar a nova versão da Matrix.
Neo.
Trinity.
Morpheus.
Link.
Tank.
Todos trabalhavam sem parar.
Mesmo assim.
O cronograma continuava atrasado.
A reunião começou.
O Arquiteto entrou na sala.
Projetou um gráfico.
Prazo: 20 dias
Trabalho restante: 90 dias
Silêncio.
Então um executivo da Matrix levantou a mão.
Sorriu confiante.
— Tenho a solução.
Neo perguntou.
— Qual?
O executivo respondeu:
— Vamos contratar cinquenta programadores.
Todos ficaram olhando.
Morpheus fechou os olhos.
O Oráculo deu um leve sorriso.
Neo perguntou:
— Eles conhecem COBOL?
— Não.
— Conhecem CICS?
— Não.
— Conhecem Db2?
— Também não.
— Conhecem o negócio?
— Ainda não.
— Conhecem a arquitetura?
— Nunca viram.
Neo respirou profundamente.
O Oráculo então falou.
"Vocês não contrataram cinquenta programadores. Contrataram cinquenta aprendizes que precisarão aprender com aqueles que já estão atrasados."
Naquele instante, Neo compreendeu a Lei de Brooks.
O que é a Brooks's Law?
A Brooks's Law afirma:
"Adding manpower to a late software project makes it later."
Em português:
"Adicionar pessoas a um projeto atrasado fará com que ele atrase ainda mais."
Essa é uma das leis mais famosas da Engenharia de Software.
Ela parece contraintuitiva.
Mas faz completo sentido quando entendemos como projetos realmente funcionam.
A origem da Lei de Brooks
A frase foi criada por Frederick Phillips Brooks Jr., engenheiro da IBM e gerente do desenvolvimento do OS/360, um dos maiores e mais complexos sistemas operacionais da história dos mainframes.
Em 1975, Brooks publicou o livro clássico:
The Mythical Man-Month
Até hoje considerado uma das obras mais importantes da Engenharia de Software.
O livro nasceu da experiência prática.
Brooks percebeu que aumentar equipes durante crises normalmente piorava a situação.
Quem foi Frederick Brooks?
Frederick Brooks trabalhou na IBM durante um período decisivo da computação.
Entre suas contribuições estão:
liderança do projeto IBM System/360;
coordenação do desenvolvimento do OS/360;
estudos sobre arquitetura de computadores;
pesquisa em Engenharia de Software.
Seu trabalho moldou a forma como planejamos projetos até hoje.
Matrix explica perfeitamente
Imagine que Neo precisa salvar Zion.
Faltam dois dias.
Morpheus decide recrutar:
100 pessoas completamente novas.
Nenhuma conhece:
a Matrix;
os Sentinelas;
Zion;
a Nebuchadnezzar.
O que acontece?
Antes de ajudar...
essas pessoas precisarão aprender.
E quem ensinará?
Justamente Neo e Trinity.
Os dois que já estavam sem tempo.
O paradoxo da produtividade
Muitos gestores pensam:
10 pessoas
↓
10 meses
Logo.
20 pessoas
↓
5 meses
Infelizmente software não funciona assim.
Porque existe algo invisível.
Comunicação.
A matemática escondida
Imagine uma equipe.
2 pessoas.
Existem apenas:
1 canal de comunicação.
Agora.
5 pessoas.
Existem:
10 canais.
Agora.
10 pessoas.
45 canais.
Agora.
20 pessoas.
190 canais.
Cada novo integrante aumenta exponencialmente a quantidade de comunicação necessária.
O COBOL conhece isso muito bem
Imagine um banco.
Projeto crítico.
Equipe original:
6 especialistas COBOL.
Prazo apertado.
Gestão decide contratar:
12 novos desenvolvedores Java.
Eles são excelentes profissionais.
Mas nunca viram:
JCL;
CICS;
Db2;
VSAM;
RACF;
IMS;
JES2.
Resultado.
Os seis especialistas passam semanas ensinando.
Quem desenvolve?
Quase ninguém.
Como nasce o problema?
Projeto atrasa.
↓
Gestão entra em pânico.
↓
Contrata mais pessoas.
↓
Treinamento aumenta.
↓
Reuniões aumentam.
↓
Integração aumenta.
↓
Produtividade cai.
↓
Projeto atrasa ainda mais.
Matrix Reloaded
Neo pergunta ao Arquiteto.
— Quantos Escolhidos existiram?
O Arquiteto responde.
— Muitos.
Imagine se, em vez de treinar um Escolhido, resolvessem treinar mil simultaneamente.
O conhecimento seria distribuído.
Mas muito mais lentamente.
O efeito psicológico
Existe um fenômeno interessante.
Equipes pequenas criam ritmo.
Todos sabem quem faz o quê.
Quando a equipe cresce rapidamente.
Aparecem:
dúvidas;
alinhamentos;
reuniões;
conflitos;
dependências.
O trabalho deixa de ser apenas programação.
Passa a ser coordenação.
O Programador COBOL Padawan
Imagine.
Primeira semana.
Você entra em um projeto.
Recebe:
8 milhões de linhas COBOL;
1.200 JCLs;
centenas de COPYBOOKs.
Você pergunta:
— Por onde começo?
Alguém precisa responder.
Esse alguém interrompe o próprio trabalho.
O Agente Smith adora isso
Porque quanto maior a equipe desorganizada.
Maior:
ruído;
retrabalho;
conflitos;
inconsistências.
Smith não precisa criar bugs.
A comunicação cria sozinha.
Um exemplo inspirado na Matrix
Neo está lutando contra Smith.
No meio da batalha chegam cinquenta novos soldados.
Todos perguntam ao mesmo tempo:
Onde atiro?
Quem é Smith?
O que é Zion?
Onde fica a saída?
Como funciona a Matrix?
Neo para de lutar.
Começa a responder perguntas.
Smith agradece.
Quando Brooks NÃO se aplica?
Essa é uma pergunta importante.
A Lei de Brooks não é absoluta.
Adicionar pessoas pode funcionar quando:
o trabalho pode ser dividido facilmente;
existem módulos independentes;
a documentação é excelente;
a arquitetura é clara;
há tempo para treinamento;
o projeto ainda está no início.
Por isso compreender o contexto é essencial.
O impacto no Mainframe
Ambientes IBM Z possuem características particulares.
Conhecimento de:
COBOL;
CICS;
Db2;
MQ;
RACF;
JCL;
z/OS.
Não se aprende em dois dias.
Logo.
Projetos críticos dependem muito da experiência acumulada.
Curiosidade
Brooks também criou outra frase famosa.
"The bearing of a child takes nine months, no matter how many women are assigned."
Essa analogia mostra que algumas atividades possuem limites naturais.
Software também.
O custo invisível
Cada novo integrante precisa:
ambiente;
acessos;
documentação;
mentor;
revisão;
treinamento;
integração.
Tudo isso consome tempo da equipe experiente.
Atenção!
A Lei de Brooks não significa:
"Nunca contratar."
Ela significa:
"Contratar tarde demais não resolve problemas estruturais."
A diferença
Crescimento planejado
Equipe aumenta gradualmente.
Crescimento desesperado
Equipe dobra durante a crise.
Matrix e a Frota de Zion
Imagine construir cem naves.
Contratar cem pilotos no último dia não acelera a construção.
Talvez nem existam naves suficientes para treiná-los.
Ferramentas ajudam
Hoje temos recursos que reduzem parte desse problema.
Wikis técnicas.
IBM ADDI.
Diagramas automáticos.
Pair Programming.
IA.
Documentação viva.
Vídeos internos.
Onboarding estruturado.
Mesmo assim.
Aprendizado continua levando tempo.
O papel da IA
A IA pode acelerar bastante o onboarding.
Ela ajuda a:
explicar programas COBOL;
resumir COPYBOOKs;
gerar diagramas;
responder dúvidas;
localizar dependências.
Mas não substitui o conhecimento do negócio.
Nem a experiência adquirida durante anos.
Os riscos
Comunicação excessiva
Retrabalho
Treinamento insuficiente
Burnout dos especialistas
Mais reuniões
Mais conflitos
Decisões inconsistentes
Erros clássicos
Dobrar a equipe durante a crise.
Não investir em documentação.
Ignorar curva de aprendizado.
Acreditar que programação é totalmente paralelizável.
Subestimar o conhecimento do negócio.
Boas práticas
Planeje crescimento cedo.
Documente continuamente.
Faça onboarding estruturado.
Divida responsabilidades.
Automatize tarefas repetitivas.
Preserve tempo dos especialistas.
Desenvolva novos profissionais antes da emergência.
Aplicabilidade
A Brooks's Law aparece em:
COBOL;
Java;
C#;
Python;
Cloud;
DevOps;
IA;
ERP;
Mobile;
Sistemas Bancários.
Sempre que conhecimento especializado é necessário.
O ensinamento do Oráculo
O Oráculo entrega um quebra-cabeça de mil peças para Neo.
Depois coloca cinquenta pessoas ao redor da mesa.
Ela pergunta:
— Terminaremos mais rápido?
Neo pensa.
Algumas pessoas começam a procurar peças.
Outras perguntam onde ficam as bordas.
Outras discutem a estratégia.
Depois de alguns minutos.
Neo sorri.
— Primeiro precisamos aprender a trabalhar juntos.
Ela responde:
"Exatamente. O tempo investido em coordenação cresce junto com a equipe."
Lições para um Programador COBOL Padawan
Se você ingressar em um grande projeto IBM Z, não se preocupe por não produzir imediatamente como os profissionais mais experientes.
Existe uma curva natural de aprendizado.
Você precisará conhecer:
a arquitetura;
o negócio;
os padrões da empresa;
os ambientes;
as ferramentas;
a cultura da equipe.
Ao mesmo tempo, quando você se tornar experiente, lembre-se de documentar e compartilhar conhecimento.
Essa atitude reduz o impacto descrito pela Lei de Brooks e torna o crescimento da equipe muito mais saudável.
Curiosidades
O livro The Mythical Man-Month também apresentou conceitos que continuam atuais:
No Silver Bullet (não existe solução mágica para produtividade).
Conceitualização é mais difícil que codificação.
Comunicação é um dos maiores custos invisíveis de projetos.
A importância de arquiteturas consistentes.
Mesmo cinquenta anos depois, essas ideias permanecem extremamente relevantes.
Conclusão — Nem Mesmo Neo Poderia Ensinar Toda Zion em Dois Dias
Na Matrix, Neo tornou-se poderoso porque teve tempo para aprender.
Treinou.
Errou.
Praticou.
Recebeu orientação de Morpheus, Trinity e do Oráculo.
Ninguém nasce especialista em COBOL, CICS ou Db2.
A Lei de Brooks nos lembra justamente disso.
Projetos atrasados raramente precisam apenas de mais pessoas.
Frequentemente precisam de:
planejamento melhor;
documentação adequada;
arquitetura clara;
prioridades bem definidas;
comunicação eficiente.
Para um Programador COBOL, essa talvez seja uma das lições mais importantes da carreira.
Conhecimento leva tempo para ser construído.
E tempo não pode ser multiplicado simplesmente aumentando o número de cadeiras na sala.
No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada na porta da sala do Arquiteto:
"Programadores podem ser contratados em um dia. Experiência, confiança e entendimento do negócio não."
Porque, assim como Neo precisou aprender a enxergar o código verde da Matrix antes de transformá-la, toda equipe precisa de tempo para se tornar realmente produtiva. É exatamente essa realidade que Frederick Brooks transformou em uma das leis mais importantes da história da Engenharia de Software.
Sem comentários:
Enviar um comentário