| Bellacosa Mainframe e a engenharia militar parte viii |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo VIII — Liderança, Moral e Disciplina: O Fator Humano na Engenharia dos Sistemas Críticos
Quando um Programador COBOL Descobre que o Maior Ativo de um Mainframe Nunca Foi o Hardware... Sempre Foram as Pessoas
A chuva caía sem parar.
O castelo permanecia cercado havia quase quatro meses.
As muralhas continuavam intactas.
Os depósitos ainda estavam abastecidos.
As armas funcionavam.
Os arqueiros permaneciam em suas posições.
Mesmo assim...
o velho comandante observava tudo com preocupação.
O jovem samurai aproximou-se.
— Mestre...
as defesas continuam fortes.
Por que parece preocupado?
O velho apontou para um soldado sentado próximo ao portão.
Depois para outro que dormia durante a guarda.
Depois para um grupo discutindo.
Em seguida respondeu:
— Porque os muros continuam firmes.
Mas começo a enxergar rachaduras onde nenhuma pedra consegue alcançar.
O jovem não compreendeu.
— Onde?
O comandante colocou a mão sobre o próprio peito.
— Aqui.
Dentro das pessoas.
Uma fortaleza não cai apenas quando suas muralhas desabam.
Ela cai quando seus defensores deixam de acreditar que vale a pena defendê-la.
Séculos depois...
08h17 da manhã.
Uma grande mudança em produção havia sido concluída com sucesso.
Nenhum ABEND.
Nenhum SQLCODE inesperado.
Nenhum problema no CICS.
Tudo parecia perfeito.
Então um operador perguntou:
— Alguém avisou a equipe do faturamento que o horário do processamento mudou?
Silêncio.
Naquele instante, o arquiteto percebeu que toda a engenharia havia funcionado.
O único problema estava justamente onde quase nunca aparece nos diagramas.
As pessoas.
Pegue seu café.
Hoje falaremos sobre o componente mais complexo de qualquer Data Center.
O ser humano.
1. A ilusão da tecnologia
Existe uma frase muito comum.
"Nosso problema é tecnológico."
Na maioria das vezes...
não é.
Grandes incidentes costumam nascer de:
comunicação deficiente;
documentação incompleta;
pressa;
treinamento insuficiente;
suposições equivocadas;
medo de perguntar;
falta de liderança.
O computador apenas revela problemas que já existiam entre as pessoas.
2. O comandante invisível
Quando pensamos em um comandante imaginamos alguém empunhando uma espada.
Na realidade...
bons líderes passam boa parte do tempo ouvindo.
Observando.
Perguntando.
Conectando especialistas.
Removendo obstáculos.
Na engenharia de software ocorre exatamente igual.
O melhor líder raramente é quem escreve mais código.
É quem permite que toda a equipe produza melhor.
3. Disciplina não é rigidez
Muitos confundem disciplina com autoritarismo.
Na engenharia militar disciplina significa previsibilidade.
Cada pessoa conhece:
sua missão;
seu horário;
seus procedimentos;
seus limites;
seus responsáveis.
No Data Center isso reduz riscos.
Quando todos seguem padrões, os incidentes tornam-se mais fáceis de investigar e resolver.
4. O Manual Existe por um Motivo
O jovem programador frequentemente pergunta:
"Por que preciso seguir exatamente este procedimento?"
Porque alguém, anos atrás, descobriu da maneira mais difícil o que acontece quando ele não é seguido.
Cada checklist.
Cada runbook.
Cada procedimento.
Cada convenção de nomenclatura.
Normalmente nasceu depois de um problema real.
A documentação é uma coleção de cicatrizes transformadas em conhecimento.
5. Moral é um Recurso Estratégico
Napoleão dizia que o moral pesa mais que muitos fatores materiais.
Um exército cansado, desorganizado e sem confiança dificilmente vence.
Em projetos de software acontece algo semelhante.
Equipes motivadas:
compartilham conhecimento;
pedem ajuda;
corrigem erros rapidamente;
documentam melhor;
ensinam iniciantes.
Já equipes desmotivadas escondem problemas, evitam responsabilidades e deixam de colaborar.
6. O Mestre e o Aprendiz
No Japão feudal existia uma longa tradição de aprendizado contínuo.
O conhecimento era transmitido por observação, prática e repetição.
No universo COBOL encontramos o mesmo modelo.
O veterano explica.
O novato observa.
Depois executa.
Depois ensina outro iniciante.
Assim o conhecimento sobrevive durante décadas.
Nenhum manual substitui completamente a experiência compartilhada.
7. O perigo do Herói Solitário
Existe um personagem presente em muitas equipes.
O Herói.
É a única pessoa que entende determinado sistema.
Resolve tudo.
Nunca documenta.
Nunca ensina.
Todos dependem dele.
No começo parece eficiente.
Com o tempo torna-se um enorme risco operacional.
Na engenharia militar isso seria equivalente a possuir apenas um engenheiro capaz de levantar a ponte levadiça.
Se ele desaparecer...
todo o castelo ficará vulnerável.
8. Conhecimento Distribuído
Organizações maduras distribuem conhecimento.
Promovem:
pair programming;
revisões de código;
treinamentos;
rotação de atividades;
documentação viva;
simulações.
O objetivo não é criar especialistas isolados.
É criar equipes resilientes.
9. O Valor da Confiança
Imagine um comandante que nunca acredita em seus oficiais.
Cada decisão precisa de aprovação.
Cada detalhe exige confirmação.
A velocidade desaparece.
Confiar não significa abandonar controle.
Significa desenvolver pessoas para que possam decidir corretamente.
No desenvolvimento de software isso acelera entregas sem comprometer qualidade.
10. O Erro como Professor
Em muitos ambientes existe medo de errar.
Consequência?
Problemas são escondidos.
Na engenharia madura ocorre o contrário.
O incidente é investigado.
Não para encontrar culpados.
Mas para descobrir causas.
Post-mortems bem conduzidos fortalecem toda a organização.
O erro deixa de ser vergonha.
Passa a ser oportunidade de aprendizado.
11. Goblin Slayer e a Confiança
Goblin Slayer possui enorme experiência.
Mesmo assim depende constantemente de sua equipe.
A Sacerdotisa protege.
A Arqueira observa.
O Anão improvisa.
O Lagarto cria novas soluções.
Cada integrante complementa os demais.
Nenhum vence sozinho.
Essa talvez seja uma das maiores lições da obra.
Competência individual importa.
Competência coletiva decide campanhas.
12. Shogun e a Liderança Silenciosa
Em Shogun, diversos líderes influenciam mais pelo exemplo do que pelos discursos.
Eles permanecem calmos durante crises.
Escutam antes de decidir.
Controlam emoções.
Inspiram confiança.
No Data Center, durante um incidente crítico, a serenidade do líder costuma definir o comportamento de toda a equipe.
Pânico é contagioso.
Calma também.
13. O Briefing
Antes de qualquer operação militar existe um briefing.
Objetivo.
Cronograma.
Riscos.
Responsáveis.
Plano alternativo.
Critérios de sucesso.
Mudanças em produção deveriam seguir exatamente essa lógica.
Quando todos entendem o contexto, as decisões tornam-se muito melhores.
14. A Debriefing
Depois da missão...
vem o debriefing.
O que funcionou?
O que não funcionou?
O que aprendemos?
Esse hábito transforma experiência em conhecimento organizacional.
Projetos que ignoram essa etapa repetem os mesmos erros durante anos.
15. Comunicação também é Engenharia
Uma mensagem mal escrita pode causar um incidente.
Uma documentação ambígua pode atrasar uma implantação.
Um requisito incompleto pode produzir semanas de retrabalho.
Comunicação não é habilidade secundária.
É parte da engenharia.
Programadores excelentes escrevem código claro.
Engenheiros excelentes também escrevem explicações claras.
16. O Peso da Cultura
Toda equipe desenvolve uma cultura.
Algumas valorizam aprendizado.
Outras valorizam culpa.
Algumas recompensam colaboração.
Outras recompensam competição.
A cultura invisível determina como as pessoas agem quando ninguém está observando.
Por isso ela é tão importante quanto qualquer arquitetura técnica.
17. Curiosidade Histórica
Os grandes castelos japoneses não dependiam apenas de samurais. Ferreiros, carpinteiros, cozinheiros, médicos, escribas, mensageiros, agricultores e artesãos desempenhavam funções essenciais para manter a fortaleza funcionando. Uma muralha impecável seria inútil se faltassem alimentos, manutenção ou comunicação.
Nos sistemas corporativos ocorre o mesmo. Analistas de negócios, operadores, DBAs, administradores de sistemas, especialistas em segurança, desenvolvedores, arquitetos e equipes de suporte formam um ecossistema onde cada função contribui para a continuidade da operação.
18. Easter Egg — O Manual Esquecido
Conta-se que um administrador veterano mantinha uma pasta bastante antiga.
Na capa estava escrito apenas:
NÃO JOGAR FORA
Durante anos ninguém abriu aquele material.
Parecia obsoleto.
Até que um incidente extremamente raro aconteceu.
Um equipamento antigo precisou ser reiniciado seguindo exatamente uma sequência específica.
O procedimento existia apenas naquele manual.
No final da última página havia uma anotação escrita à mão.
Se você está lendo isto,
é porque tivemos o mesmo problema novamente.
Boa sorte.
Bellacosa, 1998.
Todos riram.
Depois perceberam algo importante.
Documentação nunca envelhece.
Ela apenas espera o próximo profissional que precisará dela.
19. Checklist do Líder Técnico
Antes de considerar uma equipe preparada, pergunte:
✔ Todos conhecem os objetivos do projeto?
✔ Existe documentação atualizada?
✔ O conhecimento está distribuído?
✔ Há sucessores para funções críticas?
✔ Os procedimentos são claros?
✔ Os iniciantes recebem mentoria?
✔ Os incidentes geram aprendizado?
✔ A comunicação é transparente?
✔ As mudanças possuem briefing?
✔ Existe debriefing após implantações?
✔ As pessoas sentem segurança para fazer perguntas?
✔ A equipe aprende continuamente?
Conclusão — O Castelo Era Feito de Pessoas
Meses depois do fim do cerco, o jovem comandante caminhava pelas ruas do castelo.
As muralhas permaneciam majestosas.
As torres continuavam altas.
Os portões eram impressionantes.
Mesmo assim...
agora ele observava outra coisa.
Via os ferreiros reparando ferramentas.
Os cozinheiros preparando refeições.
Os mensageiros cruzando os corredores.
Os carpinteiros reforçando telhados.
Os arqueiros treinando novos soldados.
O velho engenheiro aproximou-se.
— O que você aprendeu?
O rapaz respondeu sorrindo.
— Passei meses acreditando que nossa fortaleza era feita de pedra.
Hoje entendo que ela sempre foi feita de pessoas.
Na sala de operações, o processamento encerrava mais um dia sem incidentes.
Não porque todos os servidores fossem perfeitos.
Nem porque todos os programas COBOL fossem impecáveis.
Mas porque centenas de profissionais trabalhavam juntos, compartilhando conhecimento, revisando procedimentos, ensinando novos colegas e aprendendo continuamente.
O jovem programador desligou seu terminal.
Pela primeira vez compreendeu que o maior patrimônio de um Data Center não estava nas CPUs, nos discos ou nos cabos de fibra óptica.
Estava na experiência acumulada de pessoas que, durante décadas, haviam transformado erros em procedimentos, dúvidas em documentação e desafios em conhecimento.
Porque uma fortaleza pode ser reconstruída.
Um servidor pode ser substituído.
Um programa pode ser recompilado.
Mas uma equipe que aprende junta...
essa se torna praticamente impossível de derrotar.
E é justamente essa equipe que mantém funcionando, dia após dia, os sistemas críticos sobre os quais milhões de pessoas confiam suas vidas financeiras, profissionais e pessoais.
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Uma campanha completa sobre estratégia, logística, inteligência, segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.
Um Data Center analisado como uma fortaleza em guerra
A série Engenharia Militar sem Mistérios para Programadores COBOL compara castelos, exércitos, muralhas, cadeias de comando, logística, inteligência e operações militares com os ambientes IBM Z responsáveis por bancos, governos, seguros, transportes e serviços essenciais.
Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL, Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF, monitoramento, contingência, liderança, documentação e continuidade operacional.
Índice da campanha
Links completos da série Engenharia Militar
Esta relação permanece disponível no HTML da página para mecanismos de busca, leitores de tela, navegadores sem JavaScript e ferramentas de arquivamento.
- Engenharia Militar sem Mistérios para Programadores COBOL
- Prólogo — O Chamado do Guardião
- Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
- Capítulo II — Estratégia, Operação e Tática
- Capítulo III — A Cadeia de Comando
- Capítulo IV — Logística
- Capítulo V — As Muralhas Invisíveis
- Capítulo VI — Inteligência, Reconhecimento e Espionagem
- Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
- Capítulo VIII — Liderança, Moral e Disciplina
- Capítulo IX — Inovação, Evolução e o Futuro
- Capítulo X — O Legado do Engenheiro
- Capítulo XI — O Guardião Invisível
- Capítulo XII — A Fortaleza Invisível
- Capítulo XIII — Os Sentinelas da Madrugada
- Capítulo XIV — A Civilização Invisível
- Capítulo XV — Engenharia de Cerco
- Glossário IBM Z + Engenharia Militar
- Apêndice A — Correspondências Históricas e Técnicas
- Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
- Os 10 Animes Mais Emblemáticos Sobre Logística Militar
- Os 10 Animes Mais Emblemáticos Sobre Tática Militar
- Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
- Especial — Guerrilha Urbana
- Especial — Guerrilha no Campo e na Floresta
Sem comentários:
Enviar um comentário