 |
| Bellacosa Mainframe e a death march project rules |
☕ Um Café no Bellacosa Mainframe
Death March Project Rules sem Mistérios
Quando um Programador COBOL Descobriu que Algumas Missões da Matrix Já Estavam Condenadas Antes Mesmo de Neo Escolher a Pílula Vermelha
"Nem todo projeto fracassa por incompetência. Alguns já nascem impossíveis."
Prólogo — A Missão Impossível da Nebuchadnezzar
Era madrugada na Nebuchadnezzar.
Toda a tripulação foi convocada para uma reunião urgente.
Morpheus entrou na sala.
Projetou um enorme holograma.
PROJETO MATRIX NEXT
Neo perguntou:
— Qual é o objetivo?
Morpheus respondeu naturalmente.
— Reescrever toda a Matrix.
Neo arregalou os olhos.
— Quanto tempo temos?
— Três meses.
Trinity perguntou:
— Quantas pessoas estarão no projeto?
Morpheus respondeu.
— Vocês quatro.
Tank quase derrubou a cadeira.
Neo continuou.
— Quantas funcionalidades?
Morpheus respirou.
— Todas.
Smith.
Oráculo.
Arquiteto.
Sentinelas.
Zion.
Economia.
Segurança.
Toda a infraestrutura.
Tudo.
Neo ficou em silêncio.
Depois perguntou:
— Isso é uma missão...
...ou uma sentença?
O Oráculo entrou lentamente.
Olhou para todos.
Sorriu.
E disse:
"Há projetos que fracassam durante a execução. Outros fracassam no instante em que alguém aprova o cronograma."
Bem-vindo ao Death March Project.
O que é um Death March Project?
Um Death March Project (Projeto Marcha da Morte) é um projeto que nasce com metas praticamente impossíveis de cumprir.
Ele normalmente apresenta uma combinação de fatores como:
prazo extremamente curto;
equipe insuficiente;
orçamento limitado;
escopo enorme;
tecnologia nova;
requisitos instáveis;
pressão constante.
Mesmo antes do primeiro código ser escrito, profissionais experientes já percebem que a probabilidade de sucesso é muito baixa.
A origem do termo
O conceito foi popularizado pelo consultor e escritor Edward Yourdon, em seu livro clássico Death March (1997).
Yourdon utilizou a expressão inspirada nas "marchas da morte" históricas para representar projetos onde equipes são levadas ao limite físico e psicológico tentando atingir objetivos praticamente inalcançáveis.
Na Engenharia de Software, a metáfora não se refere à violência histórica, mas ao desgaste extremo causado por projetos mal planejados.
Matrix explica perfeitamente
Imagine se, no primeiro filme, Morpheus dissesse:
— Neo, você terá uma semana para aprender kung fu, pilotar helicópteros, entender a Matrix, derrotar todos os Agentes e libertar a humanidade.
Neo provavelmente responderia:
— Nem carreguei o compilador ainda.
Essa missão seria impossível desde o início.
Como nasce um Death March?
Quase nunca por maldade.
Na maioria das vezes nasce da combinação de:
excesso de otimismo;
desconhecimento técnico;
pressão de mercado;
decisões políticas;
promessas comerciais.
Alguém diz:
"Depois a equipe resolve."
E a equipe paga a conta.
O COBOL conhece muito bem esse cenário
Imagine um banco.
O Banco Central publica uma nova regulamentação.
Prazo legal:
90 dias.
O sistema possui:
12 milhões de linhas COBOL;
centenas de integrações;
dezenas de fornecedores.
A direção pergunta:
— Conseguimos?
Alguém responde:
— Claro.
O projeto começa.
Sem análise.
Sem planejamento.
Sem folga.
O cronograma já nasce comprometido.
Um exemplo inspirado no universo bancário
Objetivo:
Migrar todo o Core Banking.
Prazo:
60 dias.
Equipe:
5 desenvolvedores.
Sistemas envolvidos:
COBOL;
CICS;
Db2;
MQ;
APIs REST;
Mobile;
Open Finance;
PIX;
Cartões;
Internet Banking.
Não importa o quanto a equipe seja talentosa.
O problema é matemático.
Matrix Reloaded
Na conversa entre Neo e o Arquiteto, descobrimos que cada versão da Matrix exigia planejamento, testes e equilíbrio.
Agora imagine o Arquiteto recebendo esta ordem:
— Faça uma nova Matrix.
Prazo:
48 horas.
Sem testes.
Sem Oráculo.
Sem Chaveiro.
Sem equipe.
Essa seria uma verdadeira Death March.
Os sintomas aparecem cedo
Logo nas primeiras semanas surgem sinais claros.
Reuniões intermináveis
Mais tempo discutindo do que construindo.
Horas extras constantes
Viram rotina.
Escopo muda diariamente
Ninguém consegue estabilizar requisitos.
Testes são reduzidos
"Depois testamos."
Documentação desaparece
Não sobra tempo.
Dívida técnica cresce
Tudo vira urgência.
O efeito psicológico
O maior problema não é apenas o cronograma.
É a sensação permanente de fracasso.
Mesmo trabalhando doze horas por dia...
a equipe continua atrasada.
Isso reduz motivação.
Aumenta ansiedade.
Eleva o risco de burnout.
O Programador COBOL Padawan
Imagine seu primeiro projeto.
Você recebe:
cinco sistemas;
três linguagens;
duas semanas;
nenhuma documentação.
Seu líder diz:
— Confio em você.
Confiança é importante.
Planejamento também.
O Agente Smith adora Death March
Porque equipes exaustas:
cometem mais erros;
revisam menos código;
documentam menos;
testam menos;
inovam menos.
Smith não precisa atacar a Matrix.
Basta deixar todos cansados.
Um exemplo COBOL
Projeto:
Adicionar uma nova regra tributária.
Estimativa técnica:
4 meses.
Cronograma aprovado:
30 dias.
Resultado provável:
atalhos;
duplicação de código;
documentação incompleta;
testes reduzidos;
retrabalho posterior.
O custo invisível
Aparentemente o projeto "economizou" tempo.
Na prática criou:
dívida técnica;
manutenção cara;
incidentes;
desgaste da equipe.
O barato saiu caro.
O impacto no Mainframe
Projetos Death March em ambientes IBM Z costumam gerar:
aumento de ABENDs;
regressões;
falhas em lotes batch;
problemas de performance;
incidentes em produção;
retrabalho constante.
Como sistemas críticos raramente podem parar, o risco torna-se ainda maior.
Atenção!
Nem todo projeto difícil é um Death March.
Projetos desafiadores podem ser extremamente saudáveis quando possuem:
planejamento;
recursos compatíveis;
riscos conhecidos;
apoio da gestão.
O problema surge quando as restrições tornam o sucesso improvável desde o início.
A diferença
Projeto Desafiador
Difícil.
Mas possível.
Death March
Praticamente impossível.
Curiosidade
Edward Yourdon observou que muitos Death March Projects terminavam sendo "entregues".
Mas isso não significava sucesso.
Frequentemente eram entregues:
atrasados;
acima do orçamento;
com menos funcionalidades;
com enorme dívida técnica.
Matrix e Zion
Imagine Zion preparando sua defesa.
Necessidade:
construir cem naves.
Prazo:
dois dias.
Recursos:
dez mecânicos.
Mesmo trabalhando sem parar...
a matemática não fecha.
Como evitar?
Negociar escopo
Entregar menos.
Mas entregar bem.
Fazer estimativas realistas
Baseadas em dados.
Não em esperança.
Dividir entregas
Incrementos menores.
Identificar riscos cedo
Não escondê-los.
Reservar tempo para testes
Qualidade faz parte do cronograma.
Comunicar problemas rapidamente
Más notícias pioram quando atrasam.
O papel do Gerente de Projetos
O bom gerente não promete milagres.
Ele protege a equipe.
Negocia prioridades.
Remove impedimentos.
Mantém expectativas realistas.
Seu trabalho não é apenas cobrar prazos.
É tornar o projeto possível.
O papel do Arquiteto
Arquitetos também evitam Death March.
Como?
Reduzindo complexidade.
Reutilizando componentes.
Priorizando soluções simples.
Evitando reinvenções.
O papel da IA
Ferramentas de IA podem acelerar:
geração de código;
documentação;
testes;
análise de impacto.
Mas não transformam um cronograma impossível em um cronograma viável.
A IA aumenta produtividade.
Não altera as leis da física.
Os riscos
Burnout
Equipe esgotada.
Rotatividade
Profissionais pedem demissão.
Incidentes
Pressa gera erros.
Qualidade baixa
Testes sacrificados.
Perda de confiança
Clientes percebem atrasos.
Cultura tóxica
Horas extras tornam-se regra.
Erros clássicos
Prometer antes de estimar.
Ignorar especialistas técnicos.
Aceitar qualquer prazo.
Não reduzir escopo.
Esconder riscos.
Trabalhar continuamente em modo de emergência.
Boas práticas
Planejamento incremental.
Priorização.
Gestão de riscos.
Comunicação transparente.
Métricas objetivas.
Revisões frequentes.
Proteção da qualidade.
Aplicabilidade
Death March pode ocorrer em qualquer contexto:
COBOL;
Java;
Python;
ERP;
Cloud;
IA;
Mobile;
Governo;
Bancos;
Startups.
Sempre que expectativas ultrapassam sistematicamente a capacidade de entrega.
O ensinamento do Oráculo
O Oráculo entrega a Neo um mapa.
Nele existem dois caminhos.
O primeiro.
Curto.
Cheio de precipícios.
O segundo.
Mais longo.
Seguro.
Ela pergunta:
— Qual leva a Zion?
Neo responde:
— Os dois.
Ela sorri.
— Mas apenas um permite que a tripulação chegue viva.
Lições para um Programador COBOL Padawan
No início da carreira você talvez sinta vontade de aceitar qualquer desafio para provar seu valor.
Isso é admirável.
Mas maturidade profissional também significa reconhecer quando um cronograma precisa ser renegociado.
Aprenda a:
estimar com base em fatos;
comunicar riscos sem medo;
dividir entregas;
registrar premissas;
defender tempo para testes;
preservar sua saúde e a de sua equipe.
Grandes profissionais não são aqueles que vivem apagando incêndios.
São aqueles que ajudam a impedir que eles comecem.
Curiosidades
Projetos famosos considerados próximos de Death March incluíram grandes iniciativas de modernização de sistemas governamentais, migrações bancárias e implantações globais de ERP, onde cronogramas excessivamente otimistas acabaram exigindo sucessivas revisões.
Uma característica comum nesses casos foi a subestimação da complexidade de integração e da necessidade de testes.
Conclusão — Nem Mesmo Neo Poderia Vencer um Cronograma Impossível
No universo Matrix, Neo era extraordinário.
Mesmo assim, ele precisou de treinamento, aliados, planejamento e tempo para compreender a realidade antes de enfrentar os Agentes.
Na Engenharia de Software acontece exatamente o mesmo.
O antipadrão Death March Project ensina que talento não substitui planejamento.
Uma equipe excelente, trabalhando em um projeto impossível, continuará enfrentando limites de tempo, qualidade e capacidade humana.
Para um Programador COBOL, especialmente em ambientes IBM Z onde cada alteração pode afetar milhões de clientes, coragem não significa aceitar qualquer prazo.
Coragem significa apresentar estimativas honestas, negociar prioridades e construir soluções sustentáveis.
No universo Bellacosa Mainframe existe uma máxima que Morpheus certamente repetiria antes de iniciar qualquer missão:
"O verdadeiro Escolhido não é aquele que promete fazer o impossível. É aquele que transforma o possível em realidade sem sacrificar a equipe no caminho."
Porque, no fim das contas, um projeto bem-sucedido não é aquele que apenas chega ao destino.
É aquele que chega com um sistema confiável, uma equipe saudável e clientes que continuam acreditando na Matrix que você ajudou a construir.
