☕ 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

Mostrar mensagens com a etiqueta backlog. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta backlog. Mostrar todas as mensagens

domingo, 28 de junho de 2026

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

 

Bellacosa Mainframe e o conceito do backlog na stack mainframe

☕ Um Café no Bellacosa Mainframe

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

"No mundo IBM Z, um programa COBOL raramente quebra por causa de uma linha de código. Quase sempre ele quebra porque existe um backlog que ninguém quis enxergar."

Existe uma palavra que todo profissional de TI escuta diariamente: Backlog.

Ela aparece em reuniões ágeis, em SCRUM, em Kanban, nos relatórios do gerente, nos dashboards do Jira e até em apresentações do CIO.

Mas curiosamente, poucos programadores COBOL entendem o verdadeiro significado do backlog.

Para um Padawan Mainframe, backlog costuma parecer apenas uma lista enorme de tarefas.

Na realidade, backlog é muito mais parecido com um dataset VSAM KSDS.

Ele armazena tudo que ainda precisa ser processado.

Se ele estiver organizado, o sistema flui.

Se estiver corrompido...

Você acabou de criar o próximo ABEND da equipe.


Imagine um Batch Noturno

Pense em um JOB executando durante a madrugada.

Ele possui:

  • milhares de registros

  • prioridades

  • dependências

  • checkpoints

  • reprocessamentos

Agora substitua os registros por atividades.

Pronto.

Você acabou de entender o backlog.

O backlog é simplesmente o conjunto de trabalho que ainda será executado.

Mas existe uma diferença enorme entre:

muito trabalho

e

backlog saudável.


O Backlog Não É o Problema

O backlog é inevitável.

Todo sistema vivo possui backlog.

Até o z/OS trabalha com filas.

JES2 possui filas.

CICS possui filas.

MQ possui filas.

IMS possui filas.

DB2 possui locks esperando.

Tudo funciona através de filas.

O problema nunca foi possuir backlog.

O problema é possuir um backlog que ninguém entende.


Como Nasce um Backlog

Imagine um sistema bancário.

Hoje o gerente pede:

Criar PIX.

Depois:

alterar TED.

Depois:

corrigir boleto.

Depois:

adequação ao Banco Central.

Depois:

LGPD.

Depois:

Open Finance.

Depois:

PIX Automático.

Depois:

IA.

Depois:

APIs REST.

Cada solicitação entra.

Nem todas saem.

O resultado?

Um backlog crescente.


O Backlog Invisível

O pior backlog é o invisível.

Ele mora em frases como:

"Depois a gente vê."

"Na próxima Sprint."

"Isso fica para outro momento."

"É uma melhoria."

"Não é urgente."

Meses depois...

Existem centenas delas.


Backlog Técnico

Nem todo backlog é funcional.

Existe também:

  • melhoria de performance

  • reorganização de programas

  • limpeza de código

  • documentação

  • atualização de COPYBOOKS

  • reorganização DB2

  • índices

  • compressão VSAM

  • testes

Tudo isso entra no backlog.


Como Identificar um Backlog Doente

Um backlog começa a adoecer quando aparecem sintomas.

Sintoma 1

Todo mundo pergunta:

"O que devemos fazer agora?"

Isso significa ausência de prioridade.


Sintoma 2

Existem tarefas de três anos atrás.

Se ninguém fez em três anos...

Talvez nunca devesse existir.


Sintoma 3

Existem tarefas duplicadas.

Muito comum.

Um analista abre:

"Corrigir cálculo."

Outro abre:

"Ajustar juros."

Outro:

"Problema financeiro."

São o mesmo erro.


Sintoma 4

Ninguém sabe explicar a tarefa.

Descrição:

"Verificar erro."

Qual erro?

Onde?

Quando?

Por quê?


Sintoma 5

Todo item é prioridade máxima.

Quando tudo é urgente...

Nada é urgente.


Como um Programador COBOL Deve Ler um Backlog

Nunca leia apenas o título.

Leia:

  • requisito

  • regra de negócio

  • programas envolvidos

  • COPYBOOKS

  • arquivos

  • tabelas DB2

  • transações CICS

  • JCL

  • impacto

A tarefa começa muito antes do código.


O Erro do Padawan

O Padawan pensa:

"Recebi uma tarefa."

O profissional experiente pensa:

"Recebi um problema de negócio."

Isso muda tudo.


Como Evoluir um Backlog

Existe uma prática chamada:

Backlog Refinement

Ou refinamento.

No Mainframe isso seria parecido com preparar um JOB antes da produção.

Você elimina ambiguidades.


Durante o refinamento fazemos perguntas.

O usuário realmente quer isso?

Existe impacto financeiro?

Existe impacto jurídico?

Existe cálculo?

Existe histórico?

Existe rollback?

Existe auditoria?

Existe logging?

Existe batch?

Existe online?

Existe integração?


Quanto mais perguntas...

Menor o risco.


Um Backlog Não Deve Crescer Para Sempre

Imagine um dataset.

Se ninguém fizer housekeeping...

Ele cresce.

Depois cresce.

Depois cresce.

Depois o volume explode.

Depois aparece:

SPACE ABEND

O backlog também.


Como Priorizar

Uma técnica simples.

Divida em quatro grupos.

Incêndio

Sistema parado.


Financeiro

Pode gerar prejuízo.


Cliente

Afeta usuários.


Melhoria

Pode esperar.


A maioria dos times mistura tudo.


Backlog e COBOL

Um programa COBOL raramente possui apenas uma alteração.

Quando você abre um fonte...

Encontra:

Alteração 2003

Alteração 2006

Alteração 2009

Alteração 2014

Alteração 2018

Alteração 2021

Alteração 2025

Cada comentário representa um backlog encerrado.

O código conta a história da empresa.


O Backlog Bom

Possui:

✔ descrição

✔ prioridade

✔ responsável

✔ impacto

✔ dependência

✔ prazo

✔ critério de aceite

✔ documentação


O Backlog Ruim

Descrição:

"Ajustar."

Boa sorte.


A Grande Diferença Entre Backlog e Dívida Técnica

Muita gente mistura.

Mas são conceitos completamente diferentes.

Backlog

É trabalho conhecido.

Sabemos que precisa ser feito.

Está registrado.

Está visível.

Pode ser priorizado.


Dívida Técnica

É trabalho escondido.

Você decidiu fazer algo mais rápido.

Agora pagará juros.


Imagine um empréstimo.

Você compra uma casa.

Ainda deve dinheiro.

A casa existe.

Mas existe dívida.

No software é igual.


Exemplo.

Você precisava entregar uma alteração.

O correto seria:

  • modularizar

  • criar testes

  • atualizar documentação

Mas o prazo era curto.

Você fez um IF gigantesco.

Funcionou.

Pronto.

Nasceu uma dívida técnica.


Backlog Pode Não Ser Dívida

Exemplo.

Nova funcionalidade PIX.

Ela nunca existiu.

Está no backlog.

Não existe dívida.

É apenas trabalho futuro.


Dívida Técnica Pode Não Estar no Backlog

Muito comum.

Todo mundo sabe que existe.

Ninguém registra.

Ninguém fala.

Até o dia em que explode.


Como Identificar Dívida Técnica

Pergunte:

"Se eu tivesse mais tempo...

faria diferente?"

Se a resposta for SIM...

Existe dívida técnica.


Os Juros da Dívida Técnica

Assim como um banco cobra juros...

O software também.

Cada alteração demora mais.

Cada teste demora mais.

Cada deploy gera medo.

Cada manutenção aumenta.


Dívida Técnica no Mainframe

Exemplos.

Programa COBOL com:

12000 linhas.

Sem PERFORM.

GO TO para todos os lados.

COPYBOOK repetido.

Campos duplicados.

Comentários de 1998.

Variáveis mortas.

Parágrafos nunca chamados.

SQL repetido.

MOVE desnecessário.

PERFORM THROUGH gigantesco.

Tudo isso gera dívida.


Como Corrigir

Nunca tente pagar toda a dívida de uma vez.

Faça igual um financiamento.

Pague parcelas.

Sempre que alterar um programa:

melhore um pouco.

Renomeie variáveis.

Remova código morto.

Atualize comentários.

Crie testes.

Melhore SQL.

Refatore pequenos blocos.


A Regra do Escoteiro

Robert C. Martin criou uma regra famosa.

Deixe o código melhor do que encontrou.

No Mainframe ela é perfeita.


Backlog Funcional

Pedido do negócio.


Backlog Técnico

Pedido da TI.


Backlog Arquitetural

Mudanças estruturais.

Exemplos.

Migrar VSAM.

Migrar CICS.

Atualizar COBOL.

Atualizar compilador.

Migrar DB2.

Atualizar RACF.


O Backlog Nunca Acaba

Isso assusta iniciantes.

Mas é normal.

Software vivo nunca termina.

Ele evolui.


Curiosidade Mainframe nº 1

Nos anos 70 ninguém dizia "Backlog".

Chamavam de:

Pending Requests

Programming Queue

Change Queue

Maintenance Queue

A palavra backlog ficou popular muito depois com métodos ágeis.


Curiosidade nº 2

Em muitos bancos brasileiros ainda existem planilhas Excel paralelas ao Jira.

Sim.

O backlog oficial nem sempre é o verdadeiro.


Curiosidade nº 3

Algumas empresas possuem backlog maior que o código.

Há milhares de demandas abertas.

Mas apenas algumas centenas realmente serão desenvolvidas.


Curiosidade nº 4

O maior inimigo do backlog não é a falta de programadores.

É a falta de decisão.


Curiosidade nº 5

Muitos ABENDs históricos aconteceram porque uma melhoria pequena ficou anos esquecida.

Quando finalmente foi feita...

Ninguém mais entendia o motivo original.


Easter Egg IBM Z

Você já percebeu?

O JES2 organiza trabalhos.

O MQ organiza mensagens.

O CICS organiza transações.

O DB2 organiza dados.

O RACF organiza permissões.

O backlog organiza pessoas.

No fundo...

Todo o ecossistema IBM Z é baseado em gerenciamento de filas.


Easter Egg COBOL

O comando:

NEXT SENTENCE

parece simples.

Mas ele simboliza exatamente muitos backlogs.

Você pula para frente sem realmente resolver o problema.

Funciona.

Até deixar de funcionar.


Easter Egg DB2

Um índice mal planejado gera consultas lentas.

Um backlog mal priorizado gera equipes lentas.

Os dois possuem exatamente o mesmo problema:

falta de organização.


Easter Egg CICS

Em CICS existe o conceito de resposta rápida.

O usuário não pode esperar.

No backlog também.

Quanto mais tempo uma tarefa fica parada...

Maior a chance de perder contexto.


Easter Egg JCL

Imagine um JOB.

STEP010

STEP020

STEP030

STEP040

Existe ordem.

Existe dependência.

Existe fluxo.

Um backlog deveria funcionar exatamente assim.


Easter Egg VSAM

Um KSDS desorganizado sofre mais splits.

Uma equipe desorganizada sofre mais interrupções.


Easter Egg RACF

No RACF, tudo segue o princípio do menor privilégio.

No backlog, vale um princípio parecido:

o menor item possível.

Histórias pequenas fluem melhor do que demandas gigantescas.


O Conselho Final para Todo Padawan COBOL

Quando você entrar em um projeto Mainframe, não olhe apenas para o código-fonte. Observe a saúde do backlog. Um programa de 30 anos pode ser surpreendentemente fácil de manter se houver um backlog bem organizado, prioridades claras e comunicação constante entre negócio e tecnologia. Por outro lado, um sistema moderno pode se tornar um pesadelo quando acumula tarefas mal descritas, prioridades conflitantes e dívida técnica ignorada.

Aprenda a fazer perguntas antes de programar. Entenda a regra de negócio antes de abrir o editor COBOL. Documente suas descobertas, refine as histórias, questione requisitos ambíguos e aproveite cada manutenção para deixar o código um pouco melhor do que estava. Essa disciplina, repetida diariamente, transforma um Padawan em um verdadeiro Mestre Mainframe.

No universo IBM Z, backlog é o mapa da jornada, enquanto a dívida técnica é o peso que você carrega na mochila. O mapa pode crescer à medida que novos caminhos surgem, mas o peso só aumenta quando atalhos mal planejados são tomados. Os melhores profissionais aprendem a equilibrar os dois: mantêm um backlog claro, vivo e priorizado, enquanto pagam pequenas parcelas da dívida técnica a cada entrega.

No fim das contas, a maior lição é simples: software não é apenas código; é uma fila contínua de decisões. Assim como o JES2 coordena jobs, o CICS gerencia transações e o DB2 organiza dados, um bom desenvolvedor organiza seu trabalho, seu conhecimento e sua evolução. É essa capacidade de transformar caos em ordem que diferencia um programador que apenas entrega tarefas de um engenheiro que constrói sistemas capazes de sobreviver por décadas — exatamente como os grandes ambientes IBM Z que continuam sustentando bancos, seguradoras, governos e empresas em todo o mundo.


quarta-feira, 3 de junho de 2026

☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

 

Bellacosa Mainframe como pagar dividas tecnicas em mainframe



☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

Existe uma frase muito conhecida no mercado de tecnologia:

"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."

Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.

Mas a verdade é muito mais divertida.

Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.

Toda vez que alguém dizia:

"Depois a gente arruma."

Nascia uma nova parcela.

E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.

Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.


O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.

Imagine um programa COBOL.

Você precisa entregar uma alteração urgente.

O correto seria:

  • Revisar arquitetura

  • Atualizar documentação

  • Criar testes

  • Refatorar módulos

Mas o prazo é amanhã.

Então alguém faz:

IF CLIENTE = '999999'
    GO TO TRATAMENTO-ESPECIAL.

Entrega.

Produção funciona.

Cliente feliz.

Projeto encerrado.

Mas daqui a dois anos ninguém lembra por que aquele IF existe.

A dívida nasceu.


O MAIOR MITO DO MAINFRAME

Muita gente acredita que:

"Código antigo é dívida técnica."

Errado.

Código antigo pode ser excelente.

Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.

Por outro lado, existem programas escritos há seis meses que já nasceram endividados.

A idade do código não importa.

O que importa é:

  • Complexidade

  • Manutenibilidade

  • Clareza

  • Testabilidade

  • Documentação


COMO IDENTIFICAR DÍVIDA TÉCNICA

O primeiro passo é aprender a enxergá-la.

Alguns sintomas clássicos:

Programa que ninguém quer alterar

Quando uma demanda chega e todos falam:

"Tomara que não seja naquele programa..."

Existe dívida.


Alteração simples demora dias

Mudança:

Trocar 20 para 25.

Tempo gasto:

3 dias

Existe dívida.


Muitos abends

Se o mesmo módulo gera incidentes frequentemente:

  • S0C7

  • S0C4

  • SQLCODE negativos

  • Arquivos inconsistentes

Existe dívida.


Dependência de especialistas

Quando apenas uma pessoa entende o sistema.

Isso é uma dívida técnica humana.

Extremamente perigosa.


A METÁFORA DO CARTÃO DE CRÉDITO

A IBM utiliza uma analogia excelente.

Imagine um cartão.

Você compra algo hoje.

O benefício é imediato.

O pagamento fica para depois.

Dívida técnica funciona igual.

Benefício imediato:

Entreguei no prazo

Pagamento futuro:

Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho

O problema não é usar o cartão.

O problema é esquecer da fatura.


COMO MAPEAR A DÍVIDA TÉCNICA

A primeira atividade prática é criar um inventário.

Monte uma planilha contendo:

SistemaProblemaImpactoPrioridade
CadastroGO TO excessivoMédioMédia
CobrançaSem documentaçãoAltoAlta
FaturamentoAlta complexidadeAltoAlta

Você não consegue corrigir aquilo que não consegue enxergar.


MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA

Uma das métricas mais famosas.

Ela mede quantos caminhos lógicos existem em um programa.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Pouca complexidade.

Agora imagine:

IF A
 IF B
  IF C
   IF D

A complexidade explode.

Quanto maior a complexidade:

  • Mais difícil testar

  • Mais difícil manter

  • Maior risco de erro

Regra prática:

ValorSituação
1 a 10Boa
11 a 20Atenção
Acima de 20Risco

MÉTRICA 2 – TEMPO DE MANUTENÇÃO

Métrica simples.

Quanto tempo leva para implementar uma mudança?

Exemplo:

Alteração simples:

4 horas

Virou:

3 dias

A dívida está cobrando juros.


MÉTRICA 3 – QUANTIDADE DE INCIDENTES

Monitore:

  • Chamados

  • Tickets

  • Problemas recorrentes

Se determinado programa gera:

20% dos incidentes

Ele deve entrar imediatamente no backlog técnico.


MÉTRICA 4 – COBERTURA DE TESTES

Quanto do sistema possui testes?

Exemplo:

10%

Muito arriscado.

80%

Muito saudável.

No mundo COBOL isso pode envolver:

  • Unit Test

  • Testes automatizados

  • Batch Validation


MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO

MTTR

Mean Time To Recovery.

Quanto tempo leva para resolver um problema?

Exemplo:

10 minutos

Excelente.

8 horas

Existe forte dívida técnica.


A REGRA DOS 20%

Uma prática muito utilizada é reservar:

80% desenvolvimento
20% redução de dívida técnica

Isso impede que a dívida cresça infinitamente.


TÉCNICA 1 – REFATORAÇÃO CONTÍNUA

Refatorar significa melhorar sem alterar comportamento.

Exemplo:

Antes:

GO TO ERRO.
GO TO ERRO.
GO TO ERRO.

Depois:

PERFORM TRATA-ERRO.

Mesmo resultado.

Código mais limpo.


TÉCNICA 2 – MODULARIZAÇÃO

Programas gigantes são fábricas de dívida.

Já encontrei programas com:

80.000 linhas

Divida responsabilidades.

Crie módulos menores.

Mais simples de entender.

Mais simples de testar.


TÉCNICA 3 – DOCUMENTAÇÃO VIVA

Documentação morta é inútil.

Documentação viva é atualizada junto com o sistema.

Documente:

  • Fluxos

  • Arquivos

  • Tabelas

  • Regras de negócio


TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO

Existe um cemitério escondido em todo sistema.

Trechos como:

IF FLAG = 'X'

Que nunca mais executam.

Remover código morto reduz:

  • Complexidade

  • Risco

  • Tempo de manutenção


TÉCNICA 5 – BACKLOG TÉCNICO

Crie um backlog específico.

Exemplo:

Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto

A dívida precisa aparecer oficialmente.

Caso contrário ela nunca será priorizada.


FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME

IBM Application Discovery

Mapeia dependências.

Mostra:

  • Programas

  • Arquivos

  • CICS

  • DB2

Excelente para arqueologia de sistemas.


IBM ADDI

Application Discovery and Delivery Intelligence.

Permite visualizar relacionamentos invisíveis.

Muito útil para sistemas legados.


SonarQube

Mesmo para COBOL.

Detecta:

  • Complexidade

  • Duplicação

  • Código suspeito


IBM Developer for z/OS

Auxilia:

  • Navegação

  • Análise

  • Refatoração


Jira

Controle de backlog técnico.

Muitas empresas utilizam para registrar dívida técnica.


EASTER EGG MAINFRAME

Quer descobrir rapidamente onde existe dívida?

Procure:

GO TO
ALTER
NEXT SENTENCE

Ou:

STEP099
STEP100
STEP101

Sem documentação.

Você provavelmente encontrou um sítio arqueológico corporativo.


O ERRO MAIS COMUM DOS JUNIORES

Pensar:

"Vou reescrever tudo."

Não.

Esse é o caminho para o desastre.

A melhor estratégia quase sempre é:

Pequenas melhorias contínuas.

Todo dia.

Toda sprint.

Todo projeto.

Toda manutenção.


COMO EVOLUIR COMO PROFISSIONAL

Programadores experientes não são aqueles que escrevem mais código.

São aqueles que reduzem complexidade.

Quando você consegue olhar para um sistema e dizer:

"Esse trecho vai gerar problema daqui a dois anos."

Você começou a pensar como arquiteto.


O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS

Eles não combatem apenas bugs.

Eles combatem as causas dos bugs.

Essa é a diferença entre apagar incêndios e construir sistemas duradouros.


CONCLUSÃO

Dívida técnica não é um defeito.

Ela é uma ferramenta.

Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.

O problema surge quando ninguém controla o saldo.

O programador COBOL júnior que aprender a:

  • Identificar dívida

  • Medir dívida

  • Priorizar dívida

  • Reduzir dívida

  • Monitorar dívida

Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.

Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.

É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.



terça-feira, 2 de junho de 2026

☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

 

Bellacosa Mainframe divida tecnica decisões erradas que pagamos até hoje


☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

Existe uma lenda antiga nos CPDs.

Ela diz que, em algum lugar do ambiente de produção, existe um programa COBOL que ninguém entende.

Ninguém sabe quem escreveu.

Ninguém sabe por que funciona.

Ninguém sabe o que acontece se ele parar.

Mas todos sabem de uma coisa:

ninguém tem coragem de mexer nele.

Se você trabalha em Mainframe há algum tempo, provavelmente já encontrou um desses.

Talvez ele tenha 30 mil linhas.

Talvez possua 700 GO TO.

Talvez utilize arquivos VSAM que nem aparecem mais na documentação.

Talvez tenha comentários escritos por alguém que já se aposentou há vinte anos.

E talvez ele continue processando milhões de reais por dia.

Parabéns.

Você acabou de encontrar um dos sintomas mais clássicos da dívida técnica.


O QUE É DÍVIDA TÉCNICA?

O termo foi criado por Ward Cunningham.

A ideia é simples.

Você faz uma escolha rápida hoje para ganhar velocidade.

Em troca, aceita que precisará corrigir aquilo futuramente.

É exatamente igual a um empréstimo bancário.

Você recebe um benefício imediato.

Mas depois paga juros.

No software, os juros aparecem na forma de:

  • retrabalho;

  • manutenção mais lenta;

  • defeitos;

  • incidentes;

  • dificuldade de evolução;

  • dependência de especialistas.

O problema é que muitas empresas pegam esse empréstimo todos os dias.

E quase nunca pagam.


O DIA EM QUE O SISTEMA COMEÇA A COBRAR JUROS

Imagine um programador COBOL júnior.

Recebe uma demanda urgente.

Precisa incluir um novo código de operação.

O correto seria:

  • revisar regras;

  • criar módulo reutilizável;

  • atualizar documentação;

  • executar testes.

Mas o prazo está apertado.

Então ele faz:

IF COD-OPER = '99'
   MOVE 'S' TO FLAG-ESPECIAL
END-IF.

Entrega.

Funciona.

Todos ficam felizes.

Seis meses depois surge:

Operação 98.

Depois 97.

Depois 96.

Quando alguém percebe, existe:

IF COD-OPER = '99'
OR COD-OPER = '98'
OR COD-OPER = '97'
OR COD-OPER = '96'

O programa continua funcionando.

Mas ficou pior.

Essa diferença entre funcionar e ser saudável é onde mora a dívida técnica.


COMO IDENTIFICAR DÍVIDA TÉCNICA

Os sinais são sempre parecidos.

1. Programas gigantes

Quando um COBOL possui:

  • 10 mil linhas;

  • 20 mil linhas;

  • 50 mil linhas;

ninguém consegue compreender tudo.

Complexidade gera risco.


2. Dependência de uma única pessoa

Quando você ouve:

"Somente o João conhece esse sistema."

Acenda o alerta vermelho.

O João pode tirar férias.

O João pode mudar de empresa.

O João pode se aposentar.

O sistema precisa sobreviver sem heróis.


3. Medo de alterar

Se toda mudança gera receio:

"Vamos torcer para não derrubar produção."

Existe dívida técnica.


4. Muitas correções

Quando a equipe passa mais tempo corrigindo do que evoluindo.

O sistema está pagando juros elevados.


AS PRINCIPAIS MÉTRICAS

Métricas transformam sensação em informação.

Sem métricas ninguém sabe se está melhorando.


1. LEAD TIME

Tempo entre solicitação e entrega.

Exemplo:

Pedido feito em:

01/06

Produção:

10/06

Lead Time = 9 dias

Quanto menor melhor.


2. CYCLE TIME

Tempo efetivamente gasto desenvolvendo.

Exemplo:

Demanda recebida.

Ficou parada cinco dias.

Desenvolvimento levou dois dias.

Cycle Time = 2 dias.


3. CHANGE FAILURE RATE

Percentual de mudanças que causam problemas.

Exemplo:

100 implantações.

10 causaram incidentes.

Taxa:

10%

Quanto menor melhor.


4. MTTR

Mean Time To Recovery.

Tempo médio para recuperar produção.

Exemplo:

ABEND às 10h.

Sistema normal às 11h.

MTTR = 1 hora.


5. REWORK

Retrabalho.

Mede quanto esforço foi gasto corrigindo erros.

Imagine:

100 horas trabalhadas.

25 horas corrigindo problemas.

Rework:

25%

Muito alto.


6. REFATORAÇÃO

Esforço dedicado a melhorar código existente.

Uma equipe saudável normalmente reserva tempo para:

  • limpeza;

  • reorganização;

  • modularização.


ENTENDENDO O GRÁFICO DA LINEARB

Imagine:

59% Novo Trabalho

17% Refatoração

24% Retrabalho

Significa:

A cada 100 horas:

59 horas criam valor.

17 horas melhoram qualidade.

24 horas apagam incêndios.

Quase um quarto da energia da equipe foi desperdiçada.


COMO REDUZIR DÍVIDA TÉCNICA

Agora chegamos ao ponto mais importante.


PASSO 1 — MAPEAR O PROBLEMA

Não tente resolver tudo.

Primeiro descubra:

  • quais programas mudam mais;

  • quais causam mais incidentes;

  • quais possuem maior complexidade.

Faça uma planilha simples.

ProgramaAlteraçõesIncidentes
FIN00112015
FIN002100
FIN0039512

Comece pelos maiores problemas.


PASSO 2 — CRIAR BACKLOG TÉCNICO

Muitas empresas possuem backlog funcional.

Poucas possuem backlog técnico.

Crie itens como:

  • remover código morto;

  • modularizar rotina;

  • eliminar duplicação;

  • documentar interfaces.

Essas atividades precisam ser visíveis.


PASSO 3 — REFATORAR PEQUENO

Erro clássico:

"Vamos reescrever tudo."

Não faça isso.

Melhore gradualmente.

Hoje:

  • extrair um parágrafo.

Amanhã:

  • eliminar duplicação.

Depois:

  • criar módulo reutilizável.

Pequenas vitórias acumulam grandes resultados.


PASSO 4 — DOCUMENTAR

Documentação não precisa ser um livro.

Basta responder:

  • o que faz;

  • entradas;

  • saídas;

  • dependências.

Já ajuda enormemente.


PASSO 5 — REVISÃO DE CÓDIGO

Mesmo no Mainframe.

Principalmente no Mainframe.

Checklist simples:

✓ Nome adequado

✓ Lógica clara

✓ Tratamento de erro

✓ Performance

✓ Documentação

✓ Testes


PASSO 6 — TESTES

O segredo dos sistemas modernos.

Sem testes:

refatorar é perigoso.

Com testes:

refatorar é seguro.

Mesmo em COBOL.

Ferramentas como:

  • IBM Debug Tool

  • IBM Application Discovery

  • IBM ZUnit

  • Micro Focus Unit Testing

ajudam muito.


PASSO 7 — REDUZIR COMPLEXIDADE

Pergunta mágica:

"Existe uma forma mais simples?"

Sempre existe.

Quanto mais simples:

  • menor risco;

  • menor manutenção;

  • menor custo.


FERRAMENTAS ÚTEIS

IBM Application Discovery

Mapeia dependências.

Mostra:

  • programas;

  • copybooks;

  • arquivos;

  • fluxos.

Excelente para arqueologia de sistemas.


SonarQube

Analisa qualidade.

Detecta:

  • duplicação;

  • complexidade;

  • vulnerabilidades.


Git

Mesmo para Mainframe.

Ajuda a controlar mudanças.


Jira

Controle de backlog técnico.


ServiceNow

Correlação entre incidentes e sistemas.


O SEGREDO QUE NINGUÉM CONTA

A maioria das dívidas técnicas não nasce do código.

Nasce da organização.

Promessas irreais.

Prazos impossíveis.

Mudanças constantes.

Prioridades conflitantes.

O código apenas reflete o ambiente em que foi criado.


EASTER EGG MAINFRAME

Existe um teste simples.

Abra um programa COBOL.

Role até o final.

Se encontrar:

GO TO FIM-PROGRAMA

não se assuste.

Se encontrar:

GO TO INICIO

fique atento.

Se encontrar:

GO TO PARAGRAFO-XYZ

que chama outro GO TO que chama outro GO TO...

Parabéns.

Você encontrou uma relíquia arqueológica do período Jurássico dos sistemas corporativos.


O CAMINHO DE EVOLUÇÃO DO PROGRAMADOR JÚNIOR

Nível 1:

Faz funcionar.

Nível 2:

Faz funcionar corretamente.

Nível 3:

Faz funcionar de forma simples.

Nível 4:

Faz funcionar de forma sustentável.

Nível 5:

Melhora o sistema toda vez que toca nele.

É nesse último estágio que nasce o verdadeiro arquiteto de sistemas.


A GRANDE LIÇÃO

O programador iniciante acredita que seu trabalho é escrever código.

O programador experiente descobre que seu trabalho é reduzir complexidade.

Código novo gera valor.

Mas código limpo preserva valor.

A dívida técnica não explode como um ABEND.

Ela cresce silenciosamente.

Linha após linha.

Workaround após workaround.

Correção após correção.

Até o dia em que uma mudança de cinco minutos passa a exigir três semanas.

Nesse momento os juros finalmente chegaram.

E como qualquer empréstimo antigo, quanto mais tempo você esperar para pagar, mais caro ficará.


quinta-feira, 22 de maio de 2025

O Scheduler da Curiosidade: IA, Backlogs e o Dia em que Tínhamos 30 Assuntos em Paralelo e Nenhum Queria Dar $HASP395

Bellacosa Mainframe e o scheduler da curiosidade 

☕ Um Café no Bellacosa Mainframe

O Scheduler da Curiosidade: IA, Backlogs e o Dia em que Tínhamos 30 Assuntos em Paralelo e Nenhum Queria Dar $HASP395

Por Vagner Bellacosa

Existe um problema novo acontecendo na minha mesa.

Não é falta de documentação.

Não é falta de livros.

Não é falta de cursos.

Não é falta de acesso à informação.

Também não é exatamente falta de tempo — embora os boletos continuem insistindo que o dia tenha apenas 24 horas.

O problema é quase o contrário.

Há conhecimento demais ao alcance das mãos.

E então chegou a Inteligência Artificial.

Agora existe uma criatura disponível praticamente a qualquer momento que aceita perguntas sobre COBOL, filosofia, economia, anime, história, mainframe, arqueologia, inteligência artificial, acidentes aéreos, linguística, segurança, psicologia, grafos, bancos, YAML, XML, Atari e aquela dúvida completamente absurda que apareceu às duas da manhã e que você jamais perguntaria numa reunião de trabalho.

Você pergunta.

Ela responde.

A resposta produz outra pergunta.

Essa produz três.

Uma delas parece muito mais interessante do que a pergunta original.

Você segue por ali.

Duas horas depois está lendo sobre uma tabuinha de argila babilônica de milhares de anos atrás e já não consegue explicar exatamente como uma conversa sobre COBOL terminou na Mesopotâmia.

Bem-vindo ao problema.

Ou talvez...

bem-vindo à solução.

Coloque café na xícara.

Hoje não vamos falar exatamente sobre COBOL.

Vamos falar sobre o programa mais complexo que provavelmente executaremos durante toda a nossa vida:

a nossa própria curiosidade.

E aparentemente o scheduler está tendo problemas.


$HASP100: JOB CURIOSIDADE ON READER

Outro dia olhei para minha lista de conversas fixadas no ChatGPT.

Ali estavam coisas como:

Anime Another Resumo
Memórias Vagnerianas
JSON no COBOL Mainframe
Manias Econômicas Históricas
Curso Lógica Programação
YAML para Programadores
Inuyasha Anime e Legado
Impacto de Conan no Anime
Análise de Erros XML
Homenagem ao Atari

Olhei aquilo e comecei a rir.

Não porque fossem assuntos ruins.

Justamente o contrário.

Todos eram interessantes.

Esse era o problema.

Cada conversa havia começado por alguma razão perfeitamente legítima. Algumas estavam virando artigos. Outras eram investigações técnicas. Algumas eram memórias. Outras tinham começado simplesmente porque alguma coisa despertara curiosidade.

Nenhuma havia realmente terminado.

E então percebi algo.

Minha lista de conversas estava começando a parecer:

SDSF STATUS DISPLAY

Só que em vez de JOBs havia ideias.

JOBNAME     STATUS
COBOLJSON   ACTIVE
YAML001     HELD
ATARI001    WAITING
INUYASHA    ACTIVE
MEMORIA     ACTIVE
ECONHIST    HELD
XMLERROR    ACTIVE
CONAN001    WAITING
LOGICA15    ACTIVE

E em algum lugar do sistema:

30 JOBS ACTIVE
47 JOBS WAITING
123 JOBS DISCOVERED

Nenhum querendo emitir:

$HASP395 JOB ENDED

Foi quando percebi que talvez tivéssemos inventado acidentalmente uma espécie de JES2 da curiosidade intelectual.

E o ChatGPT estava funcionando como uma mistura perigosa de READER, CONVERTER, EXECUTOR e operador da console.


A escola ensinou conhecimento como uma fila

Durante muito tempo fomos educados segundo uma estrutura predominantemente linear.

Capítulo 1.

Depois capítulo 2.

Depois capítulo 3.

Prova.

Próxima matéria.

A própria estrutura física dos livros reforçava isso.

Página 1 → página 2 → página 3.

Claro que sempre existiram notas de rodapé, referências e bibliografias. Mas havia um custo para abandonar a estrada principal.

Imagine estudar alguma coisa em 1985.

Você encontra uma referência interessante:

"Esse conceito deriva dos trabalhos de Fulano publicados em 1967."

Interessante.

Mas você não possui o livro de Fulano.

Talvez exista na biblioteca.

Talvez precise pedir emprestado.

Talvez nem esteja traduzido.

Então você faz uma anotação:

Pesquisar Fulano depois.

E continua lendo.

A escassez de informação produzia involuntariamente uma coisa extremamente valiosa:

foco.

Não porque as pessoas fossem necessariamente mais disciplinadas.

Mas porque perseguir cada ramificação era caro.

Hoje o custo marginal de abrir outra porta intelectual aproxima-se perigosamente de zero.

Estou lendo sobre COBOL.

Encontro "JSON GENERATE".

Pesquiso.

Descubro JSON PARSE.

Pergunto ao ChatGPT.

Aparece uma discussão sobre interoperabilidade.

Interoperabilidade lembra APIs.

APIs levam ao z/OS Connect.

z/OS Connect leva a REST.

REST leva a OpenAPI.

OpenAPI leva a YAML.

YAML lembra pipelines.

Pipelines levam a Jenkins.

Jenkins leva a DevOps.

DevOps leva a agentes de IA.

Agentes levam a sistemas autônomos.

Sistemas autônomos levam a governança.

Governança leva a acidentes.

Acidentes levam à aviação.

Aviação leva a Crew Resource Management.

CRM leva a psicologia organizacional.

Psicologia leva a vieses cognitivos.

E de repente...

onde está o JSON?

Ele continua lá.

Cinco níveis acima no stack trace da curiosidade.


Talvez estejamos pensando errado sobre conhecimento

Aqui aparece algo fascinante.

Talvez o problema seja esperar que conhecimento verdadeiro tenha estrutura linear.

Porque ele não tem.

Conhecimento parece muito mais um grafo.

Para quem passou recentemente pelo Neo4j, a analogia é irresistível.

Imagine:

(:Pessoa)-[:ESTUDA]->(:COBOL)

(:COBOL)-[:EXECUTA_EM]->(:Mainframe)

(:Mainframe)-[:UTILIZA]->(:zOS)

(:zOS)-[:POSSUI]->(:JES2)

(:JES2)-[:GERENCIA]->(:Jobs)

(:Jobs)-[:PODEM_FALHAR_COM]->(:ABEND)

(:ABEND)-[:EXIGE]->(:Diagnostico)

(:Diagnostico)-[:USA]->(:Raciocinio)

(:Raciocinio)-[:SOFRE_COM]->(:ViesCognitivo)

(:ViesCognitivo)-[:APARECE_EM]->(:Aviacao)

(:ViesCognitivo)-[:APARECE_EM]->(:Medicina)

(:ViesCognitivo)-[:APARECE_EM]->(:MercadoFinanceiro)

Agora faça uma pergunta aparentemente inocente:

"Como diagnosticar melhor um problema em produção?"

Podemos começar no COBOL e terminar estudando Sherlock Holmes, House, Patrick Jane, Kahneman, acidentes aéreos e medicina diagnóstica.

E isso não é necessariamente desvio.

Pode ser travessia do grafo.


O ChatGPT virou uma máquina de criar arestas

Essa talvez seja uma das transformações intelectuais mais interessantes provocadas pelos grandes modelos de linguagem.

Google tradicionalmente é extraordinário para encontrar nós.

Você pergunta:

IBM COBOL JSON GENERATE

e recebe documentos relacionados ao assunto.

Mas numa conversa podemos fazer algo diferente:

"Isso me lembrou o problema de comunicação entre pilotos em acidentes aéreos. Existe alguma relação conceitual?"

Agora estamos procurando uma aresta.

COBOL → operação → incidente → comunicação → aviação

Ou:

"Essa arquitetura de agentes lembra CICS?"

Outra aresta.

"O problema de memória de agentes lembra checkpoint/restart?"

Outra.

"Essa ideia econômica existia na Roma antiga?"

Outra.

"Esse comportamento de IA lembra alguma coisa da psicologia cognitiva?"

Outra.

É como se tivéssemos colocado diante do grafo uma máquina especializada em sugerir:

MATCH (ideia)-[r:?]->(outra_ideia)
RETURN outra_ideia

Só existe um pequeno problema.

O MATCH não termina.


O Rabbit Hole virou feature

Existe uma expressão inglesa maravilhosa:

rabbit hole.

A toca do coelho.

Alice vê o coelho, entra atrás dele e descobre que aquilo era apenas a entrada para um universo inteiro.

A Internet já havia industrializado rabbit holes.

A IA generativa colocou elevadores dentro deles.

Você pergunta:

"Por que isso acontece?"

Recebe resposta.

Pergunta:

"Mas de onde veio?"

Resposta.

"Existe precedente histórico?"

Resposta.

"Quem discordava?"

Resposta.

"Isso ainda é válido?"

Resposta.

"E se aplicarmos ao mainframe?"

Resposta.

"E ao mercado financeiro?"

Resposta.

"E aos agentes de IA?"

Resposta.

Às 03:17 da manhã:

"Então precisamos voltar aos babilônios."

Parabéns.

Você começou querendo entender um parâmetro do JCL.


A diferença entre distração e exploração

Mas precisamos tomar cuidado para não diagnosticar toda ramificação como déficit de atenção.

Há uma diferença enorme entre:

COBOL
 ↓
Instagram
 ↓
meme
 ↓
vídeo
 ↓
notícia
 ↓
WhatsApp
 ↓
esqueci o COBOL

e:

COBOL
 ↓
Mainframe
 ↓
Sistemas críticos
 ↓
Resiliência
 ↓
Falhas
 ↓
Fator humano
 ↓
Psicologia cognitiva
 ↓
Gestão de incidentes

O primeiro fluxo provavelmente representa distração.

O segundo pode representar exploração intelectual.

Existe coerência semântica.

O problema é que ambos consomem o mesmo recurso físico:

tempo.

Seu cérebro pode ter descoberto a conexão intelectual mais extraordinária da semana.

O relógio continuará dizendo:

03:42.


O verdadeiro recurso escasso mudou

Durante séculos o recurso escasso foi informação.

Hoje, para grande parte de nós, não é mais.

Temos Wikipedia.

Livros digitais.

Papers.

Vídeos.

Cursos.

Podcasts.

Blogs.

GitHub.

Documentação.

Fóruns.

Reddit.

Stack Overflow.

ChatGPT.

Outras IAs.

E bilhões de páginas indexadas.

O recurso escasso passou a ser:

atenção.

E logo atrás:

capacidade de seleção.

A pergunta intelectual moderna não é apenas:

"O que devo aprender?"

É também:

"O que deliberadamente não vou aprender agora?"

Essa segunda pergunta é muito mais cruel.

Porque dizer "não" para algo desinteressante é fácil.

O verdadeiro problema é dizer:

"Isso é fascinante. Mas ficará para depois."


Surge o backlog intelectual

É exatamente aí que nasce nossa lista.

JSON no COBOL
YAML
XML
Atari
Anime
Economia
Memórias
IA
Segurança
História

Ela não é necessariamente um cemitério de projetos abandonados.

Talvez seja algo mais interessante:

um buffer intelectual.

Uma área de spool.

A ideia chegou.

Foi registrada.

Ainda não existem recursos disponíveis para executá-la.

Então:

JOB STATUS = HELD

Isso é infinitamente melhor do que perder a ideia.

O problema começa quando confundimos:

HELD

com:

FAILED

Uma investigação estacionada não fracassou.

Ela apenas perdeu prioridade para outra.


Precisamos de WLM para a cabeça

Quem trabalha com mainframe imediatamente perceberá o próximo problema.

Se existem dezenas de workloads competindo pelos mesmos recursos, alguém precisa estabelecer prioridades.

No z/OS temos Workload Manager.

Na cabeça temos...

Bem...

Café.

Talvez seja justamente aí que precisamos melhorar.

Imagine um WLM intelectual:

SERVICE CLASS: PRODUCAO
-----------------------
Curso atual
Trabalho
Artigo com prazo
Aula da semana

SERVICE CLASS: ALTA
-------------------
Pesquisa diretamente relacionada
Projeto em andamento

SERVICE CLASS: DISCRETIONARY
----------------------------
Anime obscuro de 1987
História do Atari
Origem de palavra suméria
Tecnologia soviética esquecida

SERVICE CLASS: SYSOTHER
-----------------------
"Por que os romanos não inventaram..."

😂

O objetivo não seria matar SYSOTHER.

Aliás, algumas das descobertas mais deliciosas provavelmente estão lá.

O objetivo seria impedir SYSOTHER de consumir toda a capacidade enquanto PRODUCAO está atrasada.


A IA não eliminou a necessidade de disciplina

Esse é um ponto importante.

Existe uma fantasia contemporânea segundo a qual IA permitirá aprender tudo.

Não permitirá.

Pode reduzir brutalmente o custo de explicação.

Pode resumir.

Pode traduzir.

Pode comparar.

Pode produzir exemplos.

Pode adaptar a linguagem.

Pode ajudar a encontrar relações.

Pode responder perguntas imediatamente.

Mas existe uma coisa que ela ainda não consegue aumentar:

24 horas = 24 horas

Podemos aumentar nossa eficiência.

Não podemos aumentar indefinidamente nosso throughput humano.

E pior:

compreender continua custando tempo.

Ler uma explicação não significa incorporá-la.

Reconhecer um conceito não significa dominá-lo.

Assistir a uma demonstração não significa conseguir reproduzi-la.

Receber código funcionando não significa compreender sua arquitetura.

Esse talvez seja um dos perigos da aprendizagem com IA:

confundir velocidade de obtenção da resposta com velocidade de aquisição do conhecimento.

São coisas diferentes.

Muito diferentes.


Conhecimento não é download

Se conhecimento fosse simplesmente transferência de bytes, poderíamos fazer:

//LEARN EXEC PGM=UPLOAD
//SYSIN DD *
  COBOL
  NEO4J
  PYTHON
  QUANTUM
  JAPANESE
/*

Resultado:

IEC999I KNOWLEDGE SUCCESSFULLY INSTALLED

Infelizmente não funciona.

Aprendizagem exige reconstrução interna.

Você precisa errar.

Relacionar.

Esquecer.

Relembrar.

Aplicar.

Comparar.

Explicar para outra pessoa.

Encontrar contradições.

Reformular.

Voltar meses depois e perceber que aquilo que parecia óbvio não era.

A IA pode acompanhar todo esse processo.

Mas não pode simplesmente substituir o processo.


Talvez nossa aparente desorganização esconda alguma coisa valiosa

Aqui entra uma hipótese que me fascina.

E se parte dessas ramificações não for desperdício?

E se estivermos construindo uma espécie de Knowledge Graph pessoal?

Durante décadas de trabalho uma pessoa acumula experiências.

Banco.

Mainframe.

Incidentes.

Programação.

Gestão.

Pessoas.

Viagens.

Livros.

Filmes.

Histórias.

Tecnologias.

Fracassos.

Acertos.

Essas coisas ficam armazenadas como nós aparentemente desconectados.

Então surge uma conversa.

Um assunto ativa outro.

Uma memória conecta-se a um conceito novo.

Uma história profissional antiga encontra uma teoria publicada décadas depois.

De repente:

(:Experiencia1989)
      |
      | [:EXPLICA]
      v
(:Conceito2026)

A experiência sempre esteve lá.

Faltava a aresta.

Talvez uma das funções mais poderosas da IA para alguém que acumulou décadas de experiência não seja simplesmente ensinar fatos novos.

Talvez seja ajudar a indexar intelectualmente a própria vida.

Isso é enorme.


Curiosidade como algoritmo de busca

Uma pessoa curiosa executa continuamente algo parecido com:

while alive:
    observe()
    question()
    connect()
    investigate()
    update_model()

Só existe um pequeno bug:

while alive:

não possui END-IF.

E aparentemente tampouco possui MAX-DEPTH.

😂

Por isso precisamos talvez acrescentar:

IF DEPTH > ACCEPTABLE-LIMIT
   MOVE CURRENT-TOPIC TO BACKLOG
   PERFORM RETURN-TO-MAIN-QUEST
END-IF

Esse talvez seja o algoritmo intelectual necessário para a era da IA.

Não bloquear rabbit holes.

Controlar profundidade.


O conceito de estacionamento intelectual

Imagine que estamos estudando agentes de IA.

Durante a conversa surgem:

[ ] memória vetorial
[ ] MCP
[ ] sistemas multiagentes
[ ] segurança
[ ] prompt injection
[ ] teoria de jogos
[ ] swarm intelligence
[ ] governança
[ ] custos de inferência
[ ] mainframe integration

Não precisamos abrir dez frentes.

Podemos dizer:

CURRENT:
Agentes e memória

PARKED:
MCP
Segurança
Swarm
Governança
Mainframe integration

A curiosidade continua viva.

Mas o scheduler recupera o controle.

Essa simples mudança psicológica é poderosa porque reduz aquela sensação:

"Estou deixando algo importante para trás."

Não.

Você colocou no spool.


O perigo oposto: nunca terminar nada

Agora precisamos tomar a red pill.

Existe uma versão romântica da curiosidade que pode virar desculpa.

"Sou explorador."

"Tenho muitos interesses."

"Estou conectando conhecimentos."

Tudo verdadeiro.

Mas existe um teste brutal:

o que foi concluído?

Porque conhecimento também precisa produzir $HASP395.

Artigo publicado.

Programa funcionando.

Curso concluído.

Experimento documentado.

Livro lido.

Hipótese descartada.

Aula preparada.

Problema resolvido.

Sem isso podemos passar anos em:

$HASP373 JOB STARTED

sem jamais chegar a:

$HASP395 JOB ENDED

E então o backlog não é biblioteca.

É dívida.


Talvez terminar seja uma tecnologia

Essa é outra ideia que merece reflexão.

Somos treinados para começar.

Cursos vendem começos.

Tutoriais ensinam começos.

Plataformas recomendam novos começos.

Algoritmos apresentam novidades.

IA responde imediatamente à próxima curiosidade.

Pouquíssimos sistemas são economicamente incentivados a dizer:

"Não abra nada novo. Termine aquilo."

Porque novidade gera clique.

Descoberta gera dopamina.

Conclusão frequentemente exige a parte menos glamourosa:

revisar.

corrigir.

testar.

reescrever.

organizar.

publicar.

documentar.

É muito mais divertido descobrir outro rabbit hole.

Talvez finalização tenha se tornado uma competência intelectual própria.


O Scheduler da Curiosidade

Chegamos então ao nosso pequeno sistema operacional mental.

Eu o imaginaria assim:

                 ┌───────────────┐
                 │ CURIOSIDADE   │
                 └───────┬───────┘
                         │
                         ▼
                  NOVA PERGUNTA
                         │
               ┌─────────┴─────────┐
               │                   │
         RELEVANTE AGORA?          NÃO
               │                   │
              SIM                  ▼
               │               BACKLOG
               ▼
           EXECUTAR
               │
         ┌─────┴─────┐
         │           │
   NOVO RAMO?       NÃO
         │           │
        SIM          ▼
         │       CONCLUIR
         ▼           │
    REGISTRAR        ▼
         │       $HASP395
         │
         └──────► VOLTAR

Parece trivial.

Mas pense na diferença.

Não estamos dizendo:

"Pare de ser curioso."

Estamos dizendo:

"Faça scheduling da curiosidade."


E onde vamos parar?

Essa talvez seja a pergunta mais divertida.

Provavelmente em lugar nenhum.

E isso não é necessariamente ruim.

Porque conhecimento não possui tela final.

Não existe:

CONGRATULATIONS
YOU HAVE COMPLETED KNOWLEDGE
100%

Quanto mais aprendemos, maior parece o mapa.

É quase cruel.

Quando sabemos pouco, o mundo parece relativamente simples.

Quando aprendemos mais, começamos a enxergar as dependências.

Depois enxergamos as exceções.

Depois as controvérsias.

Depois a história.

Depois as escolas rivais.

Depois descobrimos que algumas certezas eram aproximações.

O mapa aumenta justamente porque aprendemos a enxergá-lo.

Talvez seja esse o paradoxo definitivo da curiosidade:

cada resposta aumenta o território das perguntas.


A IA tornou o universo intelectual navegável — não finito

Esse ponto é fundamental.

ChatGPT e outras ferramentas não transformaram conhecimento em algo que podemos terminar.

Transformaram conhecimento em algo que podemos percorrer com muito menos atrito.

Antes havia oceanos entre os continentes intelectuais.

Agora construímos pontes.

Isso muda completamente a viagem.

Mas não reduz o tamanho do planeta.

Talvez até faça o contrário.

Quando percebemos que COBOL pode conversar com IA, que mainframe pode conversar com cloud, que psicologia pode conversar com segurança, que história pode explicar tecnologia e que experiências de décadas atrás podem iluminar problemas atuais...

o mundo fica intelectualmente maior.

Não menor.


O profissional em T

Durante muito tempo falou-se no profissional em T.

Conhecimento amplo horizontalmente.

Especialização profunda verticalmente.

Talvez a IA esteja favorecendo outro formato.

Algo parecido com um grafo.

Você possui alguns nós extremamente profundos.

Mainframe.

COBOL.

Sistemas financeiros.

E centenas de conexões menos profundas:

        História
           |
Economia--Mainframe--IA
           |
      Segurança
       /      \
 Psicologia  Aviação
      |
  Gestão

O valor não está necessariamente em dominar todos esses campos.

Está também em conseguir perceber:

"Eu já vi esse padrão em outro lugar."

Essa capacidade é extraordinariamente poderosa.

Porque inovação muitas vezes nasce justamente da transferência de modelos entre domínios.


Easter egg: talvez o cérebro seja um mainframe ruim

Antes que algum neurocientista jogue café em mim:

é uma metáfora.

Mas divertida.

Temos memória.

Temos processamento.

Temos prioridades.

Temos interrupções.

Temos cache.

Temos processos esquecidos.

Temos informações que sabemos que estão armazenadas em algum lugar, mas cujo endereço aparentemente foi perdido.

Temos:

"Eu conheço essa pessoa..."

seguido de:

SEARCHING...
SEARCHING...
SEARCHING...

Três horas depois, tomando banho:

HIT!

😂

Temos também algo equivalente a storage leak:

uma música ruim de 1987 permanece perfeitamente armazenada enquanto esquecemos por que entramos na cozinha.

O hardware humano definitivamente possui algumas decisões arquitetônicas curiosas.


O grande desafio não será saber mais

Será governar o que queremos saber.

Isso talvez seja uma das grandes competências da próxima década.

Não apenas prompt engineering.

Não apenas saber perguntar.

Mas saber decidir:

qual pergunta merece continuação?

qual merece estacionamento?

qual merece profundidade?

qual merece abandono?

qual precisa virar projeto?

qual deve permanecer apenas como curiosidade?

Porque podemos perguntar praticamente indefinidamente.

Mas não podemos viver indefinidamente.

Existe aí uma dimensão profundamente humana que nenhuma otimização elimina.

Escolher aprender alguma coisa significa escolher não aprender outras naquele momento.

Escolher escrever um artigo significa deixar três esperando.

Escolher terminar um curso significa ignorar temporariamente cinco tecnologias novas.

Escolher profundidade significa renunciar momentaneamente à novidade.

Esse é o verdadeiro scheduler.


Blue Pill ou Red Pill?

A Blue Pill é confortável:

"Com IA finalmente conseguirei aprender tudo."

Não.

Provavelmente acontecerá exatamente o contrário.

A IA mostrará quanto existe para aprender.

A Red Pill é mais interessante:

"Nunca aprenderei tudo. Então preciso escolher melhor minhas viagens."

Isso muda completamente nossa relação com conhecimento.

Não precisamos conquistar todo o mapa.

Podemos explorá-lo.

Construir caminhos.

Registrar descobertas.

Voltar.

Conectar regiões.

E ocasionalmente colocar uma placa:

TODO:
RETORNAR AQUI

$HASP395: ou talvez não

Chegamos ao fim deste artigo falando sobre...

Deixe-me conferir.

Começamos com conversas abertas no ChatGPT.

Passamos por JES2.

Grafos.

Neo4j.

Rabbit holes.

Psicologia.

WLM.

Aprendizagem.

Gestão de atenção.

IA.

Knowledge Graph.

E terminamos discutindo finitude humana.

Nada mal para uma conversa que começou olhando uma barra lateral cheia de chats inacabados.

Talvez seja exatamente esse o ponto.

A curiosidade intelectual não é uma estrada.

É uma rede.

Cada pergunta é um nó.

Cada associação cria uma aresta.

Cada experiência antiga pode ganhar significado novo quando conectada a alguma coisa aprendida hoje.

ChatGPT não inventou esse comportamento.

Nós sempre fizemos isso.

A diferença é que agora existe uma ferramenta capaz de acompanhar nossa corrida pelo grafo quase na velocidade em que surgem as perguntas.

E isso é maravilhoso.

Também é perigoso.

Porque sempre haverá outra aresta.

Sempre haverá outro nó.

Sempre haverá:

"Só mais uma pergunta..."

O verdadeiro desafio intelectual da era da IA talvez não seja descobrir como começar uma investigação.

Isso ficou absurdamente fácil.

Será aprender quando continuar, quando estacionar e quando terminar.

Precisamos ser simultaneamente exploradores e operadores.

Curiosos e schedulers.

Alice e JES2.

Precisamos permitir:

$HASP373 CURIOSITY STARTED

Mas de vez em quando precisamos olhar para o backlog, escolher alguma coisa e exigir:

$HASP395 CURIOSITY ENDED

Mesmo sabendo que aquilo nunca terminou completamente.

Porque uma boa resposta deixa uma pergunta.

Uma boa pergunta encontra outra área.

Uma experiência encontra uma teoria.

Uma memória encontra significado.

Um artigo encontra outro artigo.

E talvez seja justamente por isso que continuamos estudando depois de décadas.

Não porque estejamos chegando ao fim.

Mas porque finalmente começamos a enxergar o tamanho do grafo.

Então onde vamos parar?

Não faço a menor ideia.

Provavelmente começaremos falando sobre o scheduler da curiosidade, alguém mencionará teoria dos grafos, daí surgirá a história dos sete graus de separação, que levará a redes sociais, que levará a algoritmos de recomendação, que levará a manipulação comportamental, que levará a Skinner, que levará a psicologia, que lembrará inteligência artificial...

...e daqui a pouco estaremos novamente discutindo COBOL.

Talvez exista uma explicação técnica para isso.

Ou talvez seja simplesmente:

//CURIOS EXEC PGM=LIFE
//PARM DD *
   MAXDEPTH=UNLIMITED
   CURIOSITY=YES
   COFFEE=STRONG
   RETURN=OPTIONAL
/*

IEFBR14 provavelmente não resolverá.

☕ Café terminado.

Artigo terminado.

JOB terminado.

Finalmente:

$HASP395 CURIOSITY ENDED

...

Espera.

Se conhecimento funciona como grafo, será que nosso backlog de conversas poderia ser automaticamente transformado em um grafo visual de interesses, mostrando quais assuntos deram origem a quais outros?

Droga.

$HASP100 NEWJOB ON READER

E lá vamos nós outra vez. ☕🖥️

quarta-feira, 15 de janeiro de 2025

☕📋💣 BACKLOG: O ARQUIVO SECRETO QUE SEPARA UM PROGRAMADOR COBOL COMUM DE UM VERDADEIRO ARQUITETO DE SISTEMAS

Bellacosa Mainframe e o backlog mainframe


☕📋💣 BACKLOG: O ARQUIVO SECRETO QUE SEPARA UM PROGRAMADOR COBOL COMUM DE UM VERDADEIRO ARQUITETO DE SISTEMAS

"O sistema não está parado. Ele apenas está esperando na fila."

Existe uma cena que se repete diariamente em praticamente todas as empresas que possuem Mainframe.

O telefone toca.

Um gerente aparece.

Um usuário reclama.

Um diretor pede urgência.

Uma área regulatória exige mudanças.

O banco central publica uma nova norma.

O auditor encontra uma inconsistência.

O operador identifica um erro.

E de repente surgem vinte novas tarefas.

A pergunta é:

quem decide o que será feito primeiro?

É exatamente nesse momento que nasce um dos conceitos mais importantes da engenharia de software moderna:

o Backlog.

Se você é um programador COBOL Mainframe iniciante, entender backlog pode acelerar sua carreira mais do que aprender cinquenta comandos novos de JCL.

Porque programar é importante.

Mas entender como o trabalho é organizado é o que diferencia um executor de um profissional estratégico.

Pegue seu café.

Vamos abrir esse dataset.


O QUE É BACKLOG?

A definição mais simples possível:

Backlog é uma lista organizada de tudo aquilo que precisa ser feito.

Simples assim.

Pode conter:

  • novas funcionalidades;

  • correções de bugs;

  • melhorias;

  • ajustes regulatórios;

  • documentação;

  • refatoração;

  • automação;

  • modernização.

Tudo entra no backlog.

Pense nele como uma fila de JOBs esperando para executar.


O BACKLOG EXPLICADO COMO UM JOB SCHEDULER

Imagine um ambiente de produção.

Você possui:

JOB001 - Fechamento diário
JOB002 - Atualização de clientes
JOB003 - Relatório gerencial
JOB004 - Backup
JOB005 - Auditoria

Todos precisam executar.

Mas existe uma ordem.

Backlog é exatamente isso.

Uma fila organizada de atividades aguardando execução.

A diferença é que em vez de JOBs estamos falando de trabalho humano.


O MAIOR MITO SOBRE BACKLOG

Muitos iniciantes acreditam:

"Backlog é uma lista de novas funcionalidades."

Errado.

Backlog é muito maior que isso.

Um backlog saudável contém:

  • inovação;

  • manutenção;

  • correções;

  • melhorias;

  • dívida técnica.

Quando só existem novas funcionalidades no backlog, algo está errado.

Muito errado.


UM EXEMPLO REAL DE MAINFRAME

Imagine um sistema bancário.

O backlog pode conter:

Criar PIX Internacional
Corrigir cálculo de juros
Atualizar layout FEBRABAN
Refatorar COBCLI01
Documentar JOB FAT0001
Criar testes para módulo de cobrança

Observe.

Nem tudo é desenvolvimento novo.

Parte do trabalho é manutenção.

Parte é prevenção.

Parte é sobrevivência.


ONDE ENTRA A DÍVIDA TÉCNICA?

Agora chegamos ao ponto interessante.

A dívida técnica normalmente vive dentro do backlog.

Por exemplo:

BACKLOG

Criar API de consulta
Novo relatório fiscal
Refatorar COBPAG01
Eliminar COPYBOOK duplicado
Automatizar testes

Os três últimos itens são pagamentos de dívida técnica.

Ou seja:

Todo pagamento de dívida técnica vira backlog.

Mas nem todo backlog é dívida técnica.


COMO A DÍVIDA TÉCNICA APARECE

Imagine que você recebeu uma demanda urgente.

O gerente diz:

"Precisamos colocar isso em produção amanhã."

Você cria uma solução rápida.

Funciona.

Entrega realizada.

Todo mundo feliz.

Meses depois:

  • ninguém entende o código;

  • faltam comentários;

  • surgem bugs;

  • novas alterações ficam lentas.

Pronto.

A dívida nasceu.


O EFEITO BOLA DE NEVE

O primeiro remendo parece inocente.

Depois vem outro.

E mais outro.

Então surge um IF dentro de outro IF.

Depois outro.

Quando você percebe:

IF A
   IF B
      IF C
         IF D
            IF E

O programa ainda funciona.

Mas ninguém mais entende.

Isso é o juros da dívida técnica.


O DIA EM QUE O BACKLOG VIROU UM CEMITÉRIO

Existe uma curiosidade interessante.

Algumas empresas possuem backlog com milhares de itens.

Mas ninguém sabe:

  • quem criou;

  • por que criou;

  • se ainda faz sentido.

Isso não é backlog.

É arqueologia corporativa.


COMO UM JÚNIOR DEVE ENXERGAR O BACKLOG

Não veja o backlog como uma lista de tarefas.

Veja como um mapa.

Ele mostra:

  • para onde o sistema está indo;

  • quais problemas existem;

  • quais riscos precisam ser tratados.

Os melhores analistas costumam estudar o backlog inteiro.

Não apenas sua tarefa.


COMO IDENTIFICAR DÍVIDA TÉCNICA

Existem sinais clássicos.

Programas gigantes

Mais de 10.000 linhas.


COPYBOOKs duplicados

Mesma estrutura espalhada.


JCLs clonados

Copiar e colar virou arquitetura.


Falta de documentação

Conhecimento armazenado apenas na cabeça de alguém.


Dependência de especialistas

Quando você ouve:

"Somente o Carlos entende isso."

A dívida já existe.


COMO MAPEAR DÍVIDA TÉCNICA

Crie uma planilha simples.

Campos:

  • Sistema

  • Programa

  • Problema

  • Risco

  • Complexidade

  • Prioridade

Exemplo:

ProgramaProblema
COBCLI01Sem documentação
COBPAG0215.000 linhas
COBFAT03Sem testes

Agora a dívida ficou visível.

E aquilo que é visível pode ser gerenciado.


MÉTRICAS IMPORTANTES

Os melhores profissionais medem.

Sempre.

Algumas métricas úteis:

Número de ABENDs

Quanto mais ABENDs.

Maior a chance de problemas estruturais.


Tempo médio de correção

Quanto demora para corrigir um incidente?


Quantidade de bugs

Excelente indicador.


Número de programas sem documentação

Métrica simples.

Mas extremamente poderosa.


FERRAMENTAS QUE AJUDAM

Muitos acreditam que Mainframe não possui ferramentas modernas.

Grande erro.


IBM ADDI

Mapeia dependências.

Mostra relações entre:

  • COBOL;

  • JCL;

  • DB2;

  • CICS.


IBM Application Discovery

Excelente para sistemas legados.


IBM Fault Analyzer

Investiga ABENDs.


IBM Debug Tool

Ajuda a entender programas complexos.


SonarQube

Em ambientes integrados.

Ajuda na análise de qualidade.


Git

Sim.

Mainframe moderno usa Git.

E muito.


COMO CONTROLAR O BACKLOG

Regra simples.

Prioridade.

Nem tudo tem o mesmo peso.

Uma técnica muito usada:

Alta prioridade

Produção parada.


Média prioridade

Risco futuro.


Baixa prioridade

Melhorias desejáveis.


O SEGREDO DOS TIMES MADUROS

Times iniciantes fazem:

100% Funcionalidades

Times maduros fazem:

70% Funcionalidades
20% Correções
10% Dívida Técnica

Alguns chegam a reservar uma sprint inteira para limpeza.

E os resultados aparecem rapidamente.


EASTER EGG MAINFRAME

Se você encontrar comentários como:

* NÃO ALTERAR
* FUNCIONA DESDE 1998

Você encontrou um fóssil corporativo.

Parabéns.

Agora investigue antes de tocar.

Porque muitas vezes esse comentário está escondendo uma dívida técnica de milhões de dólares.


A REGRA DOS 15 MINUTOS

Uma dica que poucos ensinam.

Se você gastou mais de 15 minutos para entender um trecho de código:

documente.

Seu "eu do futuro" agradecerá.


COMO EVOLUIR MAIS RÁPIDO NA CARREIRA

O júnior normalmente aprende:

  • COBOL;

  • JCL;

  • DB2;

  • CICS.

Mas os profissionais mais valorizados aprendem também:

  • gestão de backlog;

  • análise de impacto;

  • controle de dívida técnica;

  • arquitetura;

  • observabilidade.

É isso que os transforma em analistas seniores.


O QUE NINGUÉM CONTA SOBRE BACKLOG

O backlog é uma fotografia do estado de saúde do sistema.

Se ele possui:

  • centenas de bugs;

  • dezenas de refatorações pendentes;

  • documentação atrasada;

o sistema está acumulando dívida.

O backlog está contando uma história.

Aprenda a lê-la.


CONCLUSÃO

Backlog não é apenas uma lista de tarefas.

É o painel de controle do futuro do sistema.

E a dívida técnica é uma das passageiras mais perigosas dessa viagem.

Um programador COBOL Mainframe que aprende a:

  • identificar problemas;

  • registrar atividades;

  • priorizar demandas;

  • controlar dívida técnica;

  • documentar descobertas;

deixa de ser apenas alguém que escreve código.

Passa a ser alguém capaz de manter sistemas vivos por décadas.

E no mundo Mainframe, onde muitos programas são mais antigos que seus desenvolvedores, essa habilidade vale ouro.

Porque no final das contas, o verdadeiro segredo não é escrever um programa novo.

É conseguir entender por que aquele programa de 1989 ainda está funcionando perfeitamente em produção.

E sobreviver ao chamado das 03:17 da manhã quando alguém decidir alterá-lo.

 

sábado, 5 de setembro de 2009

📉 Por que o MS Project caiu em desuso nas equipes modernas?

Bellacosa Mainframe apresenta o fim do Ms Project


Ao estilo Bellacosa Mainframe — direto, pragmático e sem romantizar ferramenta legada:


📉 Por que o MS Project caiu em desuso nas equipes modernas?

O MS Project nasceu em um mundo onde planejar era mais importante do que aprender.
Projetos eram previsíveis, lineares e comandados por um Project Manager centralizador.
Esse mundo acabou.

Hoje, projetos mudam toda semana.
E o MS Project não lida bem com mudança constante.


⚙️ O que mudou no jogo

1️⃣ Do Plano Fixo para o Fluxo Contínuo

  • MS Project → cronograma fechado, dependências rígidas

  • Mundo atual → backlog vivo, prioridades dinâmicas

Atualizar um Gantt a cada mudança:

  • consome tempo

  • não gera valor

  • cria falsa sensação de controle


2️⃣ Do Comando e Controle para Times Autônomos

  • MS Project pressupõe:

    • um dono do plano

    • tarefas atribuídas de cima para baixo

  • Agile / DevOps exigem:

    • auto-organização

    • visibilidade compartilhada

    • decisão no nível do time

O MS Project não conversa com times auto-geridos.


3️⃣ Planejamento por Datas vs Planejamento por Valor

  • MS Project pergunta: “quando termina?”

  • Agile pergunta: “qual valor entregamos agora?”

Hoje, valor entregue > cronograma perfeito.


🔁 Quem ocupou o lugar do MS Project?

O MS Project não teve um substituto direto.
Ele foi desmontado em partes.

🔹 Planejamento e Backlog

  • Jira

  • Azure DevOps

  • Rally

👉 substituíram o planejamento detalhado por backlog priorizado


🔹 Fluxo de Trabalho

  • Kanban Boards

  • Trello

  • Jira Boards

👉 substituíram o Gantt por fluxo visual em tempo real


🔹 Roadmap e Visão

  • Product Roadmap

  • Product Vision

  • OKRs

👉 substituíram o cronograma mestre por direção estratégica flexível


🔹 Execução e Métricas

  • Velocity

  • Lead Time

  • Cycle Time

  • Burnup / Burndown

👉 substituíram o % completo do MS Project, que nunca refletiu a realidade


🧠 O verdadeiro motivo do desuso

O MS Project não é ruim.
Ele só resolve um problema que quase não existe mais.

Projetos previsíveis, estáveis, com escopo fechado.

Hoje temos:

  • produto em evolução

  • requisitos emergentes

  • integração contínua

  • entrega contínua

MS Project não acompanha ritmo de pipeline.


🧾 Onde o MS Project ainda sobrevive

Ele não morreu.
Virou ferramenta de exceção:

  • Engenharia pesada

  • Construção civil

  • Infraestrutura tradicional

  • Projetos regulatórios com escopo fechado

👉 Onde mudança é inimiga, não aliada.


🔚 Conclusão Bellacosa

MS Project planeja projetos.
Agile gerencia incerteza.

Quando a incerteza virou regra,
o MS Project virou peça de museu corporativo.


👉 Resumo para ir mais longe

Durante muitos anos, o Microsoft Project (MS Project) foi uma das principais ferramentas de gerenciamento de projetos do mercado. Seu foco em cronogramas detalhados, dependências complexas, diagramas de Gantt e planejamento de longo prazo refletia a realidade de projetos conduzidos por metodologias tradicionais, especialmente o modelo cascata (waterfall).

Com o crescimento das metodologias ágeis, muitas empresas passaram a enxergar limitações nesse modelo. Em ambientes onde requisitos mudam constantemente, criar planejamentos extremamente detalhados para meses ou anos à frente tornou-se cada vez mais difícil. O problema não era necessariamente a ferramenta, mas a mudança na forma como os projetos passaram a ser conduzidos.

Frameworks como Scrum, Kanban e práticas de Agile priorizam adaptação contínua, entregas frequentes e revisão constante das prioridades. Nesse contexto, ferramentas mais leves e colaborativas, como Jira, Trello, Azure DevOps e outras plataformas digitais, ganharam espaço por facilitarem o gerenciamento dinâmico de backlogs, sprints e fluxos de trabalho.

Mesmo assim, o MS Project não desapareceu. Ele continua sendo amplamente utilizado em áreas como engenharia, construção civil, infraestrutura, projetos governamentais e iniciativas que exigem forte controle de cronograma e recursos.

A grande transformação ocorreu na cultura de gestão. O foco deixou de ser apenas prever todo o futuro do projeto e passou a incluir adaptação rápida, colaboração entre equipes e resposta eficiente às mudanças constantes do mercado.


terça-feira, 17 de março de 2009

🧠 Agile de Verdade: Por que Planejar Tudo no Início Falha (e o que Fazer em Vez Disso)

 

Bellacosa Mainframe agile kanbam estouro de prazo

🧠 Agile de Verdade: Por que Planejar Tudo no Início Falha (e o que Fazer em Vez Disso)

Por El Jefe — Estilo Bellacosa Mainframe


Introdução: o som dos prazos passando voando

Douglas Adams resumiu melhor do que qualquer framework:

“Eu amo prazos. Adoro o som que eles fazem quando passam voando. Whoosh!”

Se você trabalha com projetos — especialmente em TI, mainframe, DevOps ou software corporativo — já ouviu esse som.
Planejamos tudo no início, cravamos uma data… e erramos.

A pergunta não é se isso vai acontecer.
A pergunta é: por que insistimos em fazer isso?


O erro clássico: decidir tudo quando você sabe o mínimo

No início de um projeto, sabemos quase nada:

  • Requisitos ainda são hipóteses

  • Sistemas dependentes mudam

  • Patches surgem

  • Prioridades do negócio se ajustam

Mesmo assim, é exatamente nesse momento que:

  • Criamos cronogramas longos

  • Estimamos prazos fixos

  • Prometemos entregas distantes

📌 Bellacosa rule #1

Não decida tudo no ponto em que você sabe menos sobre o problema.


A analogia dos pinguins (e por que ela funciona)

Imagine atravessar um campo cheio de pinguins em movimento.

  • No início, você escolhe os primeiros passos

  • No meio do caminho, o cenário já mudou

  • Quanto mais avança, melhor é sua visão

Agora troque:

  • Pinguins por dependências

  • Campo por projeto

  • Movimento por mudança constante

Isso é desenvolvimento de software.
Isso é modernização de sistemas.
Isso é Agile.


Planejamento iterativo: navegar, não adivinhar

Agile não elimina planejamento.
Ele elimina planejamento ilusório.

A ideia é simples:

  • Planeje o que você conhece agora

  • Avance um pouco

  • Aprenda

  • Ajuste

  • Repita

🎯 Precisão real:

  • Planejar 3 meses à frente → ~50% de acurácia

  • Planejar 2 semanas → quase 100%

📌 Bellacosa rule #2

Agile não tenta ser onisciente. Agile aprende rápido.


O segundo grande erro: trocar cargos sem mudar mentalidade

Quando empresas “viram Agile”, algo perigoso costuma acontecer:

  • Product Manager vira Product Owner

  • Project Manager vira Scrum Master

  • Time de desenvolvimento vira “Scrum Team”

Tudo isso sem treinamento.

Resultado? Fracasso previsível.


Product Manager ≠ Product Owner

  • Product Manager

    • Cargo

    • Foco em orçamento e operação

  • Product Owner

    • Papel do Scrum

    • Visionário

    • Conecta negócio e tecnologia

    • Define valor e experimentos

📌 Podem ser a mesma pessoa? Sim.
📌 Devem ser automaticamente? Não.


Project Manager ≠ Scrum Master

Aqui mora o choque cultural.

Project Manager

  • Controla tarefas

  • Cobra plano

  • Documenta riscos

Scrum Master

  • Atua como coach

  • Remove impedimentos

  • Protege o time

  • Incentiva auto-organização

📌 Diferença brutal
O Project Manager pergunta:

“Como você vai se destravar?”

O Scrum Master diz:

“Deixa comigo. Vai produzir.”


Development Team ≠ Scrum Team

  • Development Team: só desenvolvedores

  • Scrum Team: time cross-functional

Inclui:

  • Dev

  • Teste

  • Ops

  • Segurança

  • Negócio

📌 Agile sem time multidisciplinar é teatro corporativo.


Sem apoio da gestão, Agile não escala

Essa é a verdade que dói.

Gestão tradicional pergunta:

  • “O que você entrega até o fim do ano?”

Gestão ágil pergunta:

  • “O que você entrega nas próximas duas semanas?”

  • “Qual valor chega ao cliente neste sprint?”

📌 Bellacosa rule #3

Agile só funciona quando a liderança muda as perguntas.


Ferramentas não tornam ninguém ágil

Kanban, Jira, ZenHub, GitHub…
Ferramentas não criam mindset.

Elas apenas:

  • Dão visibilidade

  • Sustentam o processo

  • Reduzem ruído

Se o processo é Waterfall, o Kanban vira um Gantt disfarçado.


Kanban sem frescura: simples, visual e honesto

Kanban é só isso:

  • O que preciso fazer

  • O que estou fazendo

  • O que já fiz

Trabalho flui da esquerda para a direita.
Sem mágica. Sem burocracia.


Pipelines: uma visão clara do fluxo

Um Kanban típico tem:

  • New Issues – entrada

  • Icebox – longo prazo

  • Product Backlog – tudo que queremos

  • Sprint Backlog – próximas duas semanas

  • In Progress – trabalho ativo

  • Review / QA – validação

  • Done – concluído

📌 Uma única fonte da verdade.
📌 Atualizada automaticamente onde o dev já trabalha.


Conclusão: Agile não é moda, é sobrevivência

Agile não é sobre:

  • Framework

  • Cerimônia

  • Ferramenta

Agile é sobre:

  • Aprender rápido

  • Planejar melhor

  • Entregar valor continuamente

  • Aceitar que o desconhecido faz parte do jogo

📌 Bellacosa final rule

Quem tenta controlar o futuro perde o presente.
Quem aprende continuamente constrói o futuro.



📌 Resumo para ir mais longe

 Um dos princípios mais importantes do movimento Agile é reconhecer uma realidade que muitos projetos tentam ignorar: é impossível planejar tudo com precisão absoluta. Mercados mudam, clientes alteram prioridades, tecnologias evoluem e novos desafios surgem constantemente. Por isso, metodologias ágeis não eliminam o planejamento; elas transformam o planejamento em um processo contínuo.

Durante décadas, muitas organizações acreditaram que documentos extensos e cronogramas detalhados seriam suficientes para prever todo o futuro de um projeto. Na prática, porém, quanto maior o prazo, maior a probabilidade de mudanças. O Agile surgiu justamente para lidar com essa incerteza de forma estruturada.

Em vez de definir todos os detalhes antecipadamente, equipes ágeis trabalham com objetivos claros e ciclos curtos de entrega. A cada sprint, novas informações são analisadas, permitindo ajustes rápidos e redução de riscos. O aprendizado contínuo passa a ser parte integrante do processo.

Outro conceito fundamental é o feedback constante. Clientes, usuários e equipes colaboram para identificar melhorias antes que pequenos problemas se transformem em grandes falhas. Essa abordagem aumenta a capacidade de adaptação e melhora a qualidade das entregas.

O verdadeiro Agile não promete prever o futuro. Ele oferece mecanismos para responder às mudanças de maneira eficiente, permitindo que pessoas, equipes e organizações evoluam continuamente em um ambiente cada vez mais dinâmico e imprevisível.

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