Translate

sábado, 8 de agosto de 2026

Quanto Custa um Programador? Salário, custo de oportunidade, conhecimento tácito e o valor invisível de 30 anos de carreira

Bellacosa Mainframe quanto custa um programador

☕ Um Café no Bellacosa Mainframe

Quanto Custa um Programador?

Salário, custo de oportunidade, conhecimento tácito e o valor invisível de 30 anos de carreira

🔴🔵 Matrix, COBOL e a estranha economia onde sabemos o preço da hora, mas quase nunca sabemos o valor do conhecimento

Por Vagner Bellacosa


Existe uma pergunta aparentemente simples que empresas fazem todos os dias:

Quanto custa esse programador?

RH responde.

Procurement responde.

A consultoria responde.

O gerente responde.

O Excel responde.

Todo mundo parece conhecer a resposta.

R$ 50 por hora.

R$ 80.

R$ 120.

R$ 200.

R$ 300.

Depende da tecnologia, senioridade, contrato, localização, especialização e de uma dúzia de outras variáveis.

Simples.

Ou talvez não.

Pegue seu café.

Hoje Morpheus está esperando no CPD.

Sobre a mesa estão novamente duas pílulas.

🔵 A pílula azul pergunta:

Quanto custa contratar um programador por uma hora?

🔴 A vermelha pergunta:

Quanto custou produzir o profissional capaz de entregar aquela hora?

Parece a mesma pergunta.

Não é.

E talvez exista uma Matrix inteira escondida entre as duas respostas.


💊 A primeira Matrix: preço não é valor

Imagine um profissional COBOL com trinta anos de carreira.

Alguém olha sua contratação e escreve:

RESOURCE: COBOL DEVELOPER
LEVEL: SENIOR
RATE: R$ 100/H

Pronto.

Transformamos três décadas de vida numa linha de planilha.

Existe algo errado?

Não necessariamente.

Empresas precisam transformar coisas complexas em números.

Orçamentos precisam existir.

Projetos precisam ser estimados.

Contratos precisam estabelecer preços.

Não conseguimos escrever no procurement:

VALOR: DEPENDE DA HISTÓRIA DE VIDA DO CARLOS

O problema começa quando esquecemos que o preço utilizado para contratar alguma coisa não necessariamente representa seu valor total.

Preço é uma informação.

Valor é outra.

E conhecimento possui uma característica particularmente desagradável para planilhas:

ele é invisível.


🧑‍💻 Quanto custa fabricar um programador?

Vamos fazer um experimento.

Precisamos de um especialista.

COBOL.

JCL.

Db2.

CICS.

VSAM.

MQ.

Batch.

TSO/ISPF.

Um pouco de RACF.

Conhecimento de produção.

Experiência com sistemas financeiros.

Capacidade de diagnosticar incidentes.

Precisamos dele segunda-feira.

Onde compramos?

Não existe fábrica.

Não existe:

AMAZON
  ↓
COBOL SENIOR
  ↓
ENTREGA PRIME
  ↓
AMANHÃ ATÉ 22H

Aquele profissional precisou ser construído.

E sua fabricação talvez tenha começado décadas atrás.

Primeiro curso.

Primeiro emprego.

Primeiro programa.

Primeiro erro.

Primeiro abend.

Primeira madrugada.

Primeiro sistema crítico.

Primeira alteração que deu errado.

Primeira alteração que deu certo por um motivo que ele ainda não compreendia completamente.

Primeiro incidente sério.

Primeiro:

"Não mexa nisso."

Depois:

"Por quê?"

E finalmente, anos depois:

"Agora entendi por que ninguém mexia nisso."

Isso também é formação.


📚 O curso de R$ 1.000 que custou muito mais

Imagine que determinado treinamento custe R$ 1.000.

É tentador registrar:

CUSTO DO CONHECIMENTO = R$ 1.000

Mas talvez o profissional tenha estudado cem horas.

À noite.

Depois do trabalho.

Nos sábados.

Nos domingos.

Enquanto outras pessoas estavam viajando.

Assistindo televisão.

Namorando.

Brincando com os filhos.

Dormindo.

Vivendo.

Essas cem horas possuem valor.

Economistas chamam isso de custo de oportunidade.

Toda escolha implica abrir mão de outra possibilidade.

Quando escolhemos estudar, não sacrificamos apenas dinheiro.

Sacrificamos alternativas.

Agora multiplique isso por trinta anos.

Quantas noites?

Quantos finais de semana?

Quantos livros?

Quantos laboratórios?

Quantos cursos?

Quantas certificações?

Quantos experimentos?

Quantos programas escritos apenas para entender alguma coisa?

Quantos:

"Só mais meia hora..."

que viraram duas da manhã?

Existe uma linha que nunca aparece no currículo:

TEMPO INVESTIDO PARA ME TORNAR QUEM SOU: ????? HORAS

Talvez seja a linha mais cara de todas.


🧪 Você é seu próprio laboratório de P&D

Empresas investem em pesquisa e desenvolvimento.

Testam produtos.

Experimentam tecnologias.

Algumas dão certo.

Outras fracassam.

O profissional de tecnologia faz exatamente a mesma coisa consigo próprio.

Aprende uma linguagem.

Aprende um framework.

Compra um livro.

Monta um laboratório.

Estuda uma certificação.

Experimenta uma ferramenta.

Só que existe um pequeno detalhe.

Ele não sabe se aquele investimento dará retorno.

Em 1998 alguém diz:

"Aprenda X. É o futuro."

Você aprende.

Em 2001:

"Esqueça X. Agora todo mundo quer Y."

Você aprende Y.

Em 2008:

"Y morreu. O futuro é Z."

Lá vamos nós novamente.

Quem absorveu o custo das tecnologias que você estudou e nunca utilizou?

Você.

Quem pagou pelas noites?

Você.

Quem assumiu o risco de obsolescência?

Você.

Portanto, quando alguém diz que apenas a empresa assume risco, talvez devêssemos acrescentar uma pequena observação:

existem diferentes tipos de risco.

A empresa assume risco empresarial.

O profissional assume risco de carreira.

E carreira não possui UNDO.


⏳ Trinta anos não cabem em um currículo de duas páginas

Aqui começa algo fascinante.

Depois de algumas décadas, o profissional já não sabe apenas aquilo que consegue explicar.

Ele sabe coisas que simplesmente reconhece.

Olha um log.

Alguma coisa incomoda.

Olha uma sequência de jobs.

— Tem algo errado aqui.

O júnior pergunta:

— Onde?

O veterano responde:

— Ainda não sei.

Isso parece magia.

Não é.

É experiência acumulada.

Centenas de incidentes anteriores construíram padrões mentais.

O cérebro compara aquilo que está vendo com milhares de situações armazenadas.

É conhecimento tácito.


🧠 Conhecimento tácito: o arquivo que não está no SharePoint

Existe conhecimento explícito.

Manual.

Runbook.

Documentação.

Wiki.

Fluxograma.

JCL comentado.

Diagrama.

E existe conhecimento tácito.

É aquilo que alguém sabe porque viveu.

Por exemplo:

"Esse job pode atrasar vinte minutos normalmente. Se atrasar depois das 03:40, aí temos problema."

Onde está documentado?

Talvez em lugar nenhum.

"Esse campo parece inútil, mas o sistema da contabilidade ainda lê."

Documentado?

Talvez.

Atualizado?

Boa sorte.

"Nunca reinicie essa etapa sem verificar aquele arquivo."

Por quê?

— Em 2007 fizemos isso.

O que aconteceu?

— Melhor não repetir.

😂

Isso é conhecimento organizacional.

E frequentemente está armazenado na pior mídia de backup possível:

HUMAN BRAIN
SINGLE COPY
NO MIRROR
NO REPLICATION
NO DISASTER RECOVERY

Quando o profissional sai:

DELETE USER
REVOKE ACCESS
REMOVE EMAIL
RETURN NOTEBOOK

Perfeito.

Só esqueceram:

BACKUP EXPERIENCE

Comando inexistente.


💰 Então quanto custa aquela hora?

Agora podemos voltar ao nosso profissional.

O cliente paga hipoteticamente R$ 200/h.

Depois das camadas contratuais, o profissional talvez receba R$ 55/h.

Os números são ilustrativos.

Não estamos acusando ninguém.

Consultorias possuem custos.

Vendemm.

Recrutam.

Administram.

Gerenciam.

Assumem riscos.

Possuem impostos.

Mantêm estruturas.

Podem responder contratualmente pela entrega.

Tudo isso possui valor.

Mas nossa pergunta permanece:

Quanto dos R$ 200 representa acesso ao conhecimento acumulado do profissional e quanto desse valor chega a quem acumulou esse conhecimento?

Talvez a resposta seja perfeitamente razoável.

Talvez não.

Mas seria interessante conhecê-la.

Chamamos anteriormente essa diferença de:

Spread do Conhecimento

O cliente conhece quanto paga.

Cada intermediário conhece sua margem.

O profissional conhece quanto recebe.

Pouquíssimas pessoas conhecem a cadeia inteira.

CLIENTE
  │
  │ R$ 200/h
  ▼
CONSULTORIA
  │
  ▼
SUBCONTRATADA
  │
  ▼
FORNECEDOR
  │
  │ R$ 55/h
  ▼
PROFISSIONAL

Agora coloque atrás desse profissional:

30 ANOS DE EXPERIÊNCIA
MILHARES DE HORAS DE ESTUDO
DEZENAS DE PROJETOS
CENTENAS DE INCIDENTES
ERROS
ACERTOS
MADRUGADAS
CONHECIMENTO DE NEGÓCIO
CONHECIMENTO TÁCITO

R$ 55 continua sendo apenas preço.

A discussão sobre valor ficou bem mais complicada.


🏛️ E existe mais um participante na Matrix

Também precisamos lembrar do Estado.

CLT.

Contribuições.

Imposto de renda.

Previdência.

Tributos.

Benefícios.

Proteções.

Direitos.

Tudo isso faz parte da equação.

Novamente, duas pílulas.

🔵 A azul lembra corretamente:

direitos trabalhistas, previdência e proteção social possuem custos e benefícios reais.

🔴 A vermelha pergunta:

quanto da segurança futura de um trabalhador deveria depender de regras que podem mudar várias vezes durante uma carreira de quarenta ou cinquenta anos?

Não existe resposta simples.

A demografia muda.

A expectativa de vida muda.

A quantidade de contribuintes muda.

As contas públicas precisam fechar.

Reformas tornam-se necessárias.

Mas existe também a perspectiva humana.

A pessoa começou a trabalhar acreditando em determinada linha de chegada.

Décadas depois, pode encontrar outra regra.

É como executar:

PERFORM TRABALHAR
   UNTIL APOSENTADORIA.

e descobrir no meio da execução:

*** PROGRAM UPDATED ***
*** NEW CONDITIONS APPLIED ***

O sistema precisa sobreviver.

Mas o trabalhador também.


⌛ O ativo que ninguém consegue devolver

Dinheiro perdido pode ser recuperado.

Emprego perdido pode ser substituído.

Servidor quebrado pode ser trocado.

Dataset pode ser restaurado.

Programa pode voltar de backup.

Existe apenas um ativo sem restore:

TIME

Não existe:

RESTORE MY-LIFE
FROM BACKUP
WHERE YEAR BETWEEN 1995 AND 2010.

Os melhores anos profissionais também são anos de vida.

E frequentemente construímos uma promessa silenciosa:

"Depois eu faço."

Depois eu viajo.

Depois escrevo.

Depois estudo aquilo por prazer.

Depois vou conhecer aquele lugar.

Depois descanso.

Depois aproveito.

Depois da aposentadoria.

Talvez dê certo.

Tomara que dê.

Mas ninguém possui SLA sobre o futuro.

Essa talvez seja uma das pílulas vermelhas mais desconfortáveis de todas.


🕯️ O Sr. Dornelles e o valor que não aparece no extrato

E aqui preciso fazer uma pausa.

Não para falar de uma multinacional.

Nem de um CEO.

Nem de algum bilionário da tecnologia.

Quero falar simplesmente do Sr. Dornelles.

Durante muitos anos, uma página dedicada ao COBOL tornou-se parte da memória afetiva e técnica de muita gente da comunidade.

CADCOBOL.

Quem viveu determinadas épocas da Internet técnica brasileira sabe exatamente o que significavam páginas assim.

Não existia necessariamente uma grande equipe editorial.

Não havia uma máquina gigantesca de marketing.

Existia alguém compartilhando conhecimento.

Exemplos.

Explicações.

Material técnico.

COBOL.

Experiência.

E do outro lado existiam estudantes e profissionais procurando respostas.

ALGUÉM TEM UMA DÚVIDA
        ↓
PESQUISA
        ↓
ENCONTRA CADCOBOL
        ↓
LÊ
        ↓
ENTENDE
        ↓
RESOLVE
        ↓
SEGUE A VIDA

Talvez consiga emprego.

Talvez resolva um incidente.

Talvez ensine outra pessoa.

Talvez aquele conhecimento entre num programa.

Talvez esse programa permaneça anos em produção.

Uma pequena pedra cai no lago.

As ondas continuam muito depois de perdermos a pedra de vista.


🌊 Quanto vale uma página que ensinou milhares?

Essa pergunta é quase impossível.

Imagine milhares de acessos.

Cada pessoa economizando dez minutos.

Uma hora.

Um dia.

Imagine alguém conseguindo compreender COBOL graças a um exemplo.

Imagine alguém usando aquele aprendizado numa entrevista.

Imagine outro professor utilizando a explicação para preparar uma aula.

Outro profissional compartilhando o link.

Outro resolvendo um problema de produção.

Qual foi o valor econômico total?

Não sabemos.

Provavelmente jamais saberemos.

Mas sabemos uma coisa:

não foi zero.

Agora vem o paradoxo.

Para quem acessou:

CUSTO DO CONTEÚDO = R$ 0,00

Mas para quem produziu:

TEMPO
CONHECIMENTO
HOSPEDAGEM
DOMÍNIO
MANUTENÇÃO
ESTUDO
VIDA

Gratuito nunca significou sem custo.

Significava apenas que alguém do outro lado estava pagando a conta.


❤️ Quando a seta muda de direção

Durante anos:

SR. DORNELLES
       ↓
    CADCOBOL
       ↓
   COMUNIDADE

Conhecimento saindo.

Compartilhamento.

Ajuda.

Memória.

Experiência.

Então chega um momento difícil da vida.

E aquela seta precisa inverter:

SR. DORNELLES
       ↑
   COMUNIDADE

A comunidade ajuda.

Pessoas anônimas ajudam.

Colegas ajudam.

Isso é extraordinariamente bonito.

É humanidade funcionando.

Mas também deveria nos fazer pensar.

Não sobre uma pessoa específica.

Sobre nosso modelo de valorização do conhecimento.

Como alguém pode produzir durante décadas algo útil para milhares de pessoas e esse valor social acumulado não necessariamente se transformar em proteção econômica para seu próprio criador?

Não estou dizendo que alguém lhe devia royalties.

Não estou dizendo que cada pessoa que consultou uma página deveria ter pago.

Não estou procurando culpados.

Estou fazendo uma pergunta.

Morpheus também fazia perguntas.


🔴 A pílula vermelha do conhecimento gratuito

Nós adoramos conhecimento gratuito.

Eu adoro.

Você provavelmente também.

Software livre.

Documentação.

Blogs.

Vídeos.

Tutoriais.

Fóruns.

Stack Overflow.

GitHub.

Listas de discussão.

Páginas pessoais.

Quantas vezes nossa carreira foi salva por alguém que resolveu publicar gratuitamente aquilo que sabia?

Talvez centenas.

Mas raramente pensamos:

quem está pagando para esse conhecimento continuar existindo?

Existe uma economia invisível sustentando a Internet técnica.

Milhares de pessoas entregaram milhões de horas sem receber diretamente por elas.

E a sociedade tecnológica ficou extraordinariamente mais rica.

Só que os autores não ficaram necessariamente mais ricos junto com ela.

Essa é uma gigantesca externalidade positiva.

O conhecimento escapa.

Espalha-se.

Multiplica-se.

Produz valor em lugares que seu criador jamais conhecerá.

É maravilhoso.

E economicamente estranho.


🤖 Então chegou a IA

Agora a pergunta ficou ainda maior.

Durante décadas nós colocamos conhecimento na Internet.

Código.

Tutoriais.

Artigos.

Perguntas.

Respostas.

Livros.

Documentação.

Fóruns.

Repositórios.

Hoje construímos sistemas capazes de trabalhar sobre quantidades gigantescas de conhecimento humano.

Isso abre discussões jurídicas e econômicas enormes.

Mas existe uma pergunta filosófica anterior:

quanto da inteligência digital moderna nasceu de pessoas que simplesmente decidiram compartilhar aquilo que sabiam?

Não existe IA moderna sem uma história anterior de produção humana de conhecimento.

Não existe programador moderno isolado de tudo aquilo que outros programadores escreveram.

Somos todos, de alguma maneira, nós de uma enorme rede.

O conhecimento que recebi ontem entra naquilo que ensino amanhã.


🧓 Quanto vale um profissional de 30 anos?

Agora podemos finalmente responder à pergunta do título.

Quanto custa um programador com trinta anos de experiência?

Resposta:

não sabemos.

Sabemos quanto custa contratá-lo.

Isso é diferente.

Podemos calcular seu salário.

Sua hora.

Encargos.

Benefícios.

Margem.

Contrato.

Mas como colocamos preço em:

30 anos de decisões?

30 anos de erros?

30 anos de padrões reconhecidos?

30 anos de contatos profissionais?

30 anos de sistemas conhecidos?

30 anos de regras de negócio?

30 anos sabendo o que não fazer?

Essa última talvez seja uma das coisas mais valiosas.

O júnior sabe fazer.

O sênior sabe fazer melhor.

O veterano frequentemente sabe:

quando não fazer.

E evitar um erro pode valer muito mais do que escrever mil linhas de código.


🚨 O profissional de R$ 55 que vale R$ 50.000 às 03:17

Produção cai.

03:17.

War Room.

Executivos.

Operação.

DBA.

Sysprog.

Desenvolvimento.

Ninguém encontra a causa.

Até alguém perguntar:

— Quem conhecia isso?

Silêncio.

— O antigo analista.

— Chamem ele.

— O contrato acabou.

— Quando?

— Há dois anos.

Nesse momento ocorre uma transformação fascinante.

O mesmo conhecimento que procurement classificava como:

RATE = R$ 55/H

pode subitamente valer:

PRODUÇÃO PARADA = R$ ??????/MINUTO

Nada mudou na cabeça daquele profissional.

Mudou nossa percepção.

Talvez valor sempre estivesse ali.

Apenas não aparecia no Excel.


🕶️ Wake up, Neo

Talvez Thomas Anderson nunca tenha sido apenas um programador preso numa realidade simulada.

Talvez ele seja uma metáfora perfeita para o profissional moderno.

Durante o dia:

EMPLOYEE_ID
SALARY
JOB_TITLE
RATE
COST_CENTER

A organização sabe exatamente quanto Anderson custa.

Mas Neo começa a fazer outra pergunta:

Quanto vale aquilo que Anderson sabe?

Essa é a verdadeira pílula vermelha.

Não significa pedir demissão.

Não significa odiar empresas.

Não significa atacar bancos.

Não significa demonizar consultorias.

Não significa abandonar a CLT.

Não significa rejeitar previdência.

Não significa cobrar por cada tutorial que você publicou.

Significa apenas:

entender a arquitetura.


🔴🔵 As duas pílulas continuam sobre a mesa

🔵 Pílula azul

Seu salário é o preço acordado pelo seu trabalho.

Empresas assumem riscos.

Consultorias adicionam serviços.

Intermediários possuem custos.

O Estado oferece proteção e cobra por ela.

Contratos existem porque organizações precisam funcionar.

Tudo isso é verdade.

🔴 Pílula vermelha

Seu salário não mede necessariamente todo o valor do seu conhecimento.

Sua formação possui custos invisíveis.

Seu tempo possui custo de oportunidade.

Sua carreira contém risco.

Seu conhecimento tácito pode desaparecer quando você sair.

As regras podem mudar durante décadas.

Conhecimento gratuito possui custo.

E talvez aquilo que você sabe seja economicamente muito mais valioso do que aquilo que aparece no seu contracheque.

Isso também pode ser verdade.

As pílulas não precisam destruir uma à outra.

Talvez maturidade seja conseguir enxergar as duas.


☕ Cambio final, Torre de Controle

Depois de trinta anos, talvez a pergunta errada seja:

"Quanto ganha um programador?"

A pergunta interessante é:

"Quanto custou construir aquele programador?"

Cursos.

Livros.

Computadores.

Certificações.

Horas.

Noites.

Sábados.

Domingos.

Projetos.

Fracassos.

Sucessos.

Abends.

Produção.

Incidentes.

Amigos.

Mentores.

Professores.

Páginas como CADCOBOL.

Pessoas como o Sr. Dornelles.

Milhares de pequenos fragmentos de conhecimento emprestados por pessoas que vieram antes.

Tudo isso está sentado naquela cadeira.

Então alguém abre uma planilha.

Olha para o profissional.

E escreve:

RESOURCE COST = R$ 55/H

Talvez esteja correto.

Como preço.

Mas nunca confunda isso com a resposta para:

VALUE OF KNOWLEDGE = ?

Essa variável continua sem PIC.

Talvez seja grande demais.

E se algum dia você encontrar uma página antiga, um tutorial esquecido, um vídeo com poucas visualizações ou um veterano explicando gratuitamente algo que levou trinta anos para aprender...

pare um instante.

Leia.

Aprenda.

Compartilhe.

Agradeça.

Se puder, ajude a preservar.

Porque talvez você esteja diante de uma coisa que nossa Matrix ainda não aprendeu a contabilizar:

patrimônio humano.

E patrimônio humano possui uma característica curiosa.

Quando uma máquina antiga desaparece, podemos procurar outra no museu.

Quando um manual desaparece, talvez exista uma cópia.

Quando um dataset desaparece, talvez exista backup.

Quando uma pessoa que carregava décadas de conhecimento desaparece...

IEC999I KNOWLEDGE NOT FOUND
BACKUP DATASET DOES NOT EXIST
RETURN CODE = 12

Não existe restore.

Não existe rollback.

Não existe UNDO.

Só resta aquilo que ela conseguiu transmitir.

Por isso talvez nossa maior responsabilidade como comunidade não seja apenas aprender.

É preservar quem ensina, reconhecer quem compartilha e transmitir adiante aquilo que recebemos.

Sr. Dornelles:

esta xícara é para o senhor.

Não como caridade.

Não como dívida.

Mas como reconhecimento.

Porque em algum ponto da carreira de milhares de profissionais existe uma linha invisível de código que talvez tenha começado numa página chamada CADCOBOL.

E nenhuma folha de pagamento jamais será capaz de calcular completamente o valor disso.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. KNOWLEDGE-VALUE.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-SALARY              PIC 9(09)V99.
       01 WS-HOURLY-RATE         PIC 9(07)V99.
       01 WS-KNOWLEDGE-VALUE     PIC X(30)
                                 VALUE 'IMPOSSIBLE TO CALCULATE'.

       PROCEDURE DIVISION.

           DISPLAY 'PRICE CAN BE MEASURED'.
           DISPLAY 'KNOWLEDGE CANNOT.'.

           DISPLAY 'REMEMBER WHO TAUGHT YOU.'.
           DISPLAY 'TEACH THE NEXT GENERATION.'.

           STOP RUN.

🔴🔵

Wake up, Neo.

Seu crachá sabe quanto você custa.

Seu contracheque sabe quanto você recebe.

O procurement sabe quanto sua hora custa.

A consultoria sabe sua margem.

O Estado sabe quanto você deve.

Os boletos sabem exatamente onde encontrá-lo.

Mas talvez ninguém saiba realmente...

quanto vale tudo aquilo que existe entre suas orelhas.

Cambio final, Torre de Controle.

sexta-feira, 7 de agosto de 2026

O Spread do Conhecimento: Matrix, COBOL e o Profissional de R$ 200/h que Recebe R$ 55

Bellacosa Mainframe e o spread do conhecimento por que $200/h não é igual $50/h

☕ Um Café no Bellacosa Mainframe

O Spread do Conhecimento: Matrix, COBOL e o Profissional de R$ 200/h que Recebe R$ 55

🔴🔵 Uma viagem pela Matrix corporativa para entender quanto custa o conhecimento, quem assume o risco e por que o profissional que faz o trabalho pode receber apenas uma pequena parcela do valor cobrado por ele

Por Vagner Bellacosa


Há uma cena de Matrix que sempre me chamou atenção.

Thomas Anderson trabalha em uma grande empresa de software.

Não parece ser um desempregado.

Não parece ser alguém sem qualificação.

Muito pelo contrário.

Anderson é programador.

Conhece computadores.

Entende sistemas.

E, quando deixa o escritório e assume sua segunda identidade, descobrimos que Neo possui habilidades suficientemente valiosas para existir também em uma pequena economia clandestina.

Mesmo assim, sua vida é surpreendentemente modesta.

Apartamento pequeno.

Pouco luxo.

Noites diante do computador.

Um emprego durante o dia.

Outra vida durante a noite.

E boletos.

Sempre os boletos.

Talvez os verdadeiros Agentes da Matrix nunca tenham usado terno preto.

Talvez venham impressos com código de barras.

Porque existe uma característica extraordinária nos boletos:

RECEITA: EVENTUAL
EMPREGO: INSTÁVEL
PROJETO: TEMPORÁRIO
BOLETO: 24x7

Você pode perder o emprego.

Pode terminar o projeto.

Pode ficar alguns meses procurando uma nova oportunidade.

Mas tente explicar isso para a conta de energia.

Ela não demonstra muita empatia.

Foi pensando nisso que comecei a observar uma das contradições mais curiosas da indústria de tecnologia.

Um banco pode movimentar bilhões.

Um sistema pode processar milhões de transações.

Uma aplicação pode permanecer funcionando durante vinte ou trinta anos.

Mas o profissional que ajudou a construir tudo aquilo pode terminar o projeto numa sexta-feira e começar a segunda-feira seguinte procurando emprego.

Não estou dizendo que existe necessariamente algo errado nisso.

Também não estou dizendo que o programador deveria ser proprietário do banco.

Muito menos que consultorias são parasitas ou que empresas não assumem riscos.

A realidade é muito mais interessante.

E justamente por isso merece uma conversa.

Morpheus está esperando.

Sobre a mesa existem duas pílulas.

🔵 A azul diz:

"Você foi contratado para fazer um trabalho. Recebeu por ele. O contrato terminou. Vida que segue."

🔴 A vermelha pergunta:

"Quanto realmente custou produzir o conhecimento que tornou aquele trabalho possível — e quem capturou o valor produzido por ele?"

Pegue seu café.

Vamos descobrir até onde vai essa toca do coelho.


💊 A pílula azul: você recebeu pelo trabalho

Vamos começar pelo argumento mais óbvio.

Uma empresa contrata alguém.

Esse profissional aceita determinadas condições.

Executa o serviço.

Recebe aquilo que foi combinado.

Fim.

Existe algo errado nisso?

Em princípio, não.

A empresa possui capital.

Possui infraestrutura.

Consegue clientes.

Assume riscos.

Paga impostos.

Mantém departamentos jurídicos, comerciais, administrativos e técnicos.

Pode investir milhões em um projeto que fracassa completamente.

Se houver prejuízo, normalmente ninguém telefona para o programador dizendo:

— João, aquele sistema que você ajudou a desenvolver perdeu R$ 30 milhões. Poderia depositar sua parte do prejuízo?

Naturalmente não.

Portanto, existe um argumento perfeitamente razoável:

quem assume maior risco econômico também espera capturar parte maior do retorno econômico.

Isso é capitalismo básico.

Mas...

Sempre existe um BUT escondido em algum lugar do código.

IF ARGUMENTO = "SIMPLES"
   PERFORM OLHAR-MAIS-DE-PERTO
END-IF.

Porque existe outro risco que raramente aparece nessa conta.

O risco do profissional.


🔴 Quanto custou você aprender aquilo que sabe?

Imagine um programador COBOL experiente.

Quando uma empresa o contrata, ela não está comprando apenas oito horas daquele dia.

Está acessando algo que levou talvez vinte anos para ser construído.

COBOL.

JCL.

Db2.

CICS.

VSAM.

MQ.

IMS.

RACF.

Git.

APIs.

Regras de negócio.

Experiência em produção.

Incidentes.

Madrugadas.

Erros.

Livros.

Cursos.

Certificações.

Laboratórios.

Documentação.

Projetos anteriores.

E milhares de pequenas experiências que nunca aparecerão no currículo.

Quanto custou isso?

Normalmente calculamos assim:

Curso .................... R$ 500
Livro .................... R$ 150
Certificação ............. R$ 800

Mas existe uma linha invisível nessa planilha:

TEMPO .................... ???

Suponha que você tenha estudado 100 horas para aprender determinada tecnologia.

Foram 100 horas que poderiam ter sido usadas para trabalhar.

Ou dormir.

Ou viajar.

Ou brincar com os filhos.

Ou assistir Matrix pela 37ª vez procurando Easter Eggs.

Ou simplesmente ficar olhando para o teto.

O ócio também possui valor.

Economistas chamam isso de custo de oportunidade.

Você escolheu estudar.

Logo, abriu mão de alguma outra coisa.

Agora multiplique isso por dez, vinte ou trinta anos de carreira.

De repente percebemos algo curioso:

o profissional é uma empresa que investe continuamente em P&D sobre si próprio.

E geralmente faz isso com capital próprio.


🧪 O laboratório chamado "você"

Existe ainda outro problema.

Nem todo conhecimento adquirido dará retorno.

Você pode passar seis meses aprendendo uma tecnologia porque todo mundo garante:

"Isso é o futuro!"

Seis meses depois:

"Aquilo morreu. Agora o futuro é outra coisa."

Bem-vindo à tecnologia.

Você assumiu o risco.

Comprou o curso.

Gastou noites.

Montou laboratório.

Leu documentação.

Talvez tenha pago certificação.

E descobriu que o mercado mudou.

Quem indeniza esse investimento?

Ninguém.

Você escolheu a pílula errada.

Tente novamente.

Isso significa que empresas não assumem riscos?

Claro que não.

Elas assumem enormes riscos.

Mas precisamos abandonar uma simplificação:

"A empresa assume o risco e o trabalhador recebe salário."

Existem diferentes tipos de risco.

A empresa possui risco empresarial e de capital.

O profissional possui risco de empregabilidade, renda, formação e obsolescência.

São riscos diferentes.

E podem coexistir.


🏦 Bem-vindo ao banco

Agora nosso Neo consegue um projeto.

Parabéns!

Existe um grande banco precisando de alguém com seus conhecimentos.

O banco possui dinheiro para contratar especialistas.

Digamos, apenas para construir um exemplo hipotético, que esteja disposto a pagar:

R$ 200 por hora.

Mas grandes organizações raramente contratam cada especialista diretamente.

Então aparece uma consultoria.

BANCO
  │
  │ R$ 200/h
  ▼
CONSULTORIA A

A consultoria possui contrato.

Conhece procurement.

Atende requisitos de compliance.

Mantém estrutura comercial.

Possui seguros.

Gerencia contratos.

Assume responsabilidades.

Isso possui valor.

Portanto:

BANCO
  │ R$ 200/h
  ▼
CONSULTORIA A
  │ R$ 160/h
  ▼

Até aqui, perfeitamente compreensível.

Mas talvez a Consultoria A também não possua aquele especialista.

Ela procura um parceiro.

BANCO
  │ R$ 200
  ▼
CONSULTORIA A
  │ R$ 160
  ▼
CONSULTORIA B
  │ R$ 120
  ▼

A Consultoria B encontra outro fornecedor.

BANCO
  │ R$ 200
  ▼
CONSULTORIA A
  │ R$ 160
  ▼
CONSULTORIA B
  │ R$ 120
  ▼
FORNECEDOR C
  │ R$ 85
  ▼
PROFISSIONAL
    R$ 55

ATENÇÃO.

Esses valores são deliberadamente ilustrativos.

Não estou afirmando que essa seja a margem real de qualquer empresa ou setor.

A pergunta é conceitual.

O banco desembolsa R$ 200 por uma hora de determinada capacidade técnica.

O profissional que efetivamente possui essa capacidade recebe R$ 55.

Entre os dois existem R$ 145.

Esse dinheiro não desapareceu.

Ele remunerou alguma coisa.

Administração.

Comercial.

Risco.

Impostos.

Gestão.

Compliance.

Recrutamento.

Lucro.

Infraestrutura.

E margens intermediárias.

Talvez tudo seja perfeitamente justificável.

Mas Morpheus coloca novamente as duas pílulas sobre a mesa.

🔵 Quanto custa contratar esse profissional?

🔴 Quanto valor cada camada realmente adicionou até ele chegar ao teclado?

São perguntas diferentes.


💰 O Spread do Conhecimento

Quem trabalha em banco conhece muito bem uma palavra:

spread.

Simplificando bastante, existe uma diferença entre o custo de determinado recurso financeiro e o preço pelo qual ele é disponibilizado.

Então pensei:

talvez exista algo semelhante na indústria de conhecimento.

Chamo isso, provocativamente, de:

Spread do Conhecimento

Podemos representar assim:

VALOR PAGO PELO CONHECIMENTO
              -
VALOR RECEBIDO POR QUEM POSSUI O CONHECIMENTO
              =
SPREAD DO CONHECIMENTO

Cuidado.

O spread não é automaticamente lucro.

Existem custos legítimos no meio.

A provocação é outra:

quanto maior a cadeia de intermediação, maior pode se tornar a distância entre o valor pago pelo cliente e o valor recebido pelo especialista.

E aparece uma pergunta fascinante:

O profissional sabe quanto sua hora custa na outra ponta?

Frequentemente, não.

E talvez o banco também não saiba quanto chega efetivamente ao profissional.

Essa opacidade interessa a quem?

Boa pergunta.

Pílula vermelha ou azul?

Você decide.


🧑‍💻 O paradoxo do profissional indispensável e descartável

Durante o projeto:

— Precisamos urgentemente de alguém com COBOL, CICS, Db2, VSAM, MQ, RACF, APIs, Git e experiência no mercado financeiro!

Depois do projeto:

— Obrigado. Seu acesso será desativado às 18h.

Três meses depois:

— Alguém sabe por que o programa XPTO possui esse IF?

Silêncio.

— Quem escreveu isso?

— Era um terceiro.

— Onde ele está?

— O contrato terminou.

— Temos documentação?

...

Houston, temos um problema.

Ou melhor:

Morpheus, temos um problema.

Existe conhecimento que pode ser documentado.

E existe conhecimento tácito.

É aquilo que o profissional aprendeu convivendo com o sistema.

Ele sabe que determinada rotina precisa rodar antes de outra.

Sabe que aquele campo aparentemente inútil existe porque um sistema externo ainda o utiliza.

Sabe que aquele IF estranho foi colocado ali depois de um incidente ocorrido quinze anos atrás.

Na documentação existe:

CAMPO-STATUS PIC X.

Na cabeça do veterano existe:

"Não coloque '9' nisso entre 23:55 e 00:10 porque o sistema Y ainda está fechando o movimento e você vai acordar metade da operação."

Boa sorte colocando isso no inventário patrimonial.


🧠 O ativo que não aparece no balanço

Hardware aparece.

Software aparece.

Licenças aparecem.

Contratos aparecem.

Cloud aparece.

Datacenter aparece.

Mas uma parte enorme do conhecimento organizacional vive em pessoas.

E pessoas possuem uma característica inconveniente:

elas vão embora.

Principalmente quando são tratadas exclusivamente como:

RESOURCE_ID = 92731
STATUS      = CONTRACTOR
END_DATE    = 30/09/2026

A empresa pode ser proprietária do código.

Mas isso não significa que seja proprietária de todas as conexões mentais utilizadas para construí-lo.

Essa diferença só costuma ficar evidente quando alguma coisa quebra.


🚨 03:17 da manhã

Produção parou.

War Room aberta.

Executivos entrando.

Operação olhando logs.

DBA olhando banco.

Sysprog olhando sistema.

Desenvolvimento olhando código.

Até alguém dizer:

— Chamem o Carlos.

— Carlos?

— Sim. Ele trabalhou nisso.

— Ele ainda está aqui?

— Não.

— Quando saiu?

— Dois anos atrás.

— Para onde foi?

...

Nesse momento acontece um milagre contábil.

Um profissional que aparentemente valia R$ 55/h às 17h de sexta-feira pode adquirir valor extraordinário às 03:17 da terça-feira.

O código não mudou.

O conhecimento não mudou.

Mudou apenas nossa percepção sobre seu valor.


💊 Mas existe outra pílula azul importante

Seria intelectualmente desonesto transformar essa discussão em:

"programador bom, empresa má."

Não funciona assim.

Uma aplicação bancária não produz bilhões simplesmente porque alguém escreveu COBOL.

Existem milhares de pessoas envolvidas.

Arquitetura.

Operações.

Segurança.

Auditoria.

Compliance.

Jurídico.

Produto.

Negócio.

Infraestrutura.

Atendimento.

Gestão.

Regulação.

Executivos.

Investidores.

Clientes.

E décadas de capital acumulado.

O programador não criou sozinho aquele valor.

Da mesma forma, movimentar R$ 10 bilhões através de um programa não significa que o programador produziu R$ 10 bilhões.

Essa distinção é essencial.

Caso contrário nossa pílula vermelha vira apenas outra ilusão.


🔴 Então qual é a verdadeira pergunta?

Talvez seja esta:

A maneira como remuneramos conhecimento especializado representa adequadamente o investimento, o risco e o valor econômico desse conhecimento?

Não sei.

E desconfio de qualquer pessoa que tenha uma resposta simples.

Mas sei que vale perguntar.

Principalmente quando terceirização vira quarteirização.

E quarteirização vira uma cadeia tão grande que o profissional que efetivamente faz o trabalho sequer conhece quem originalmente está pagando por ele.


📚 "Mas você aceitou o contrato"

Sim.

Esse argumento também é válido.

Neo poderia continuar na MetaCortex.

Anderson poderia chegar no horário.

O profissional pode recusar determinado valor.

Em teoria.

Mas mercados reais possuem assimetria de poder e informação.

O banco sabe quanto paga.

A primeira consultoria sabe quanto recebe.

A segunda conhece sua margem.

O fornecedor conhece sua margem.

O profissional normalmente conhece apenas:

R$ 55/h
ACEITA?
SIM / NÃO

Ele pode negociar.

Mas negocia conhecendo toda a cadeia?

Provavelmente não.

Isso torna o contrato inválido?

Não.

Mas torna o mercado perfeitamente transparente?

Também não.

Duas coisas podem ser verdade ao mesmo tempo.

Bem-vindo à Matrix.


👔 Os agentes não precisam ser vilões

Talvez essa seja a parte mais importante deste café.

Não precisamos procurar vilões.

O gerente da consultoria provavelmente também possui metas.

O recrutador possui metas.

O procurement possui metas.

O executivo precisa reduzir custos.

O banco precisa gerar retorno.

O profissional precisa pagar boletos.

Cada pessoa está executando racionalmente sua pequena parte do sistema.

E o resultado agregado pode produzir algo que nenhuma delas planejou individualmente.

Isso é muito mais interessante do que uma conspiração.

Sistemas não precisam de vilões para produzir resultados estranhos.

Às vezes basta cada agente seguir suas próprias regras.

Quem trabalha com mainframe deveria entender isso melhor do que ninguém.


🐇 Follow the white rabbit

Talvez abrir os olhos da comunidade não signifique dizer:

"Vocês estão sendo explorados."

Isso seria simplista.

Talvez signifique ensinar cada profissional a perguntar:

Quanto investi na minha formação?

Quanto vale minha experiência?

Quanto custa substituir meu conhecimento?

Quanto minha hora custa para o cliente?

Quantas camadas existem entre mim e ele?

Que riscos a empresa assume?

Que riscos eu assumo?

Que valor cada intermediário adiciona?

Estou sendo remunerado apenas pelo meu tempo ou também pela raridade do meu conhecimento?

Estou construindo conhecimento transferível para minha próxima oportunidade?

Minha dependência deste contrato é maior do que a dependência da empresa em relação a mim?

E principalmente:

eu conheço meu próprio valor econômico ou apenas conheço meu salário?

Essa última pergunta pode ser desconfortável.

Talvez seja justamente por isso que vale fazê-la.


🤖 E então chegou a Inteligência Artificial

Agora coloque IA generativa dentro dessa equação.

Ficou interessante, não?

Durante décadas, profissionais produziram:

código,

documentação,

livros,

artigos,

perguntas,

respostas,

exemplos,

tutoriais,

fóruns,

manuais,

experiência coletiva.

Agora construímos máquinas capazes de transformar grandes quantidades de conhecimento em novas respostas e novos códigos.

E as antigas perguntas retornam maiores:

Quem produziu o conhecimento original?

Quem financiou sua produção?

Quem possui o resultado?

Quem captura o ganho de produtividade?

Se um desenvolvedor com IA produz aquilo que antes exigia três profissionais, quem captura essa diferença?

O desenvolvedor?

O cliente?

A consultoria?

O fornecedor da IA?

Todos?

Em quais proporções?

A toca do coelho ficou muito mais funda.


🏦 Juros compostos do conhecimento

Existe uma última ironia que adoro.

Bancos compreendem perfeitamente juros compostos.

Um capital aplicado hoje pode produzir valor durante anos.

Conhecimento funciona de maneira semelhante.

Você aprende COBOL.

Depois aprende CICS.

CICS ajuda a compreender transações.

Transações ajudam a entender sistemas distribuídos.

Depois chegam APIs.

Depois cloud.

Depois DevOps.

Depois IA.

O conhecimento novo não simplesmente substitui o anterior.

Frequentemente ele se conecta.

EXPERIÊNCIA
     +
ESTUDO
     +
ERROS
     +
PROJETOS
     +
TEMPO
     =
CAPITAL INTELECTUAL

São os juros compostos da carreira.

Só existe uma diferença curiosa.

O banco sabe calcular perfeitamente os juros compostos do dinheiro.

Nós, profissionais, frequentemente somos péssimos em calcular os juros compostos do nosso próprio conhecimento.


🏛️ Espera... faltou alguém na Matrix

Até agora nossa arquitetura tinha esta aparência:

BANCO
  ↓
CONSULTORIA A
  ↓
CONSULTORIA B
  ↓
FORNECEDOR
  ↓
PROFISSIONAL

Mas está faltando uma entidade importante.

Muito importante.

                    ESTADO
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       TRIBUTOS    TRABALHO    PREVIDÊNCIA
          │           │           │
          └───────────┼───────────┘
                      ↓
BANCO → CONSULTORIA → PROFISSIONAL

Agora nossa Matrix ficou um pouco mais completa.

Porque o valor que chega ao profissional também não corresponde necessariamente ao dinheiro que estará disponível para ele consumir, poupar ou investir.

Existem impostos.

Existem contribuições.

Existe previdência.

Existem diferentes regimes de contratação.

Existe CLT.

Existe PJ.

Existe autônomo.

Existe terceirizado.

Existe quarteirizado.

E existe uma pergunta que acompanha o trabalhador brasileiro durante décadas:

quanto daquilo que estou entregando hoje está realmente construindo minha segurança amanhã?

Essa pergunta merece outra xícara de café.


☕ O salário bruto é outra Matrix

Existe uma pequena experiência filosófica que todo trabalhador conhece.

Alguém pergunta:

— Quanto você ganha?

Existe uma resposta.

Depois chega o demonstrativo de pagamento.

E existe outra resposta.

SALÁRIO BRUTO
      ↓
DESCONTOS
      ↓
CONTRIBUIÇÕES
      ↓
IMPOSTOS
      ↓
SALÁRIO LÍQUIDO
      ↓
ALUGUEL
      ↓
ENERGIA
      ↓
ÁGUA
      ↓
ALIMENTAÇÃO
      ↓
TRANSPORTE
      ↓
BOLETOS
      ↓
"PARABÉNS! VOCÊ SOBREVIVEU AO MÊS."

Naturalmente, imposto não é simplesmente dinheiro desaparecendo em um buraco negro.

O Estado financia serviços públicos, infraestrutura, saúde, educação, segurança, previdência e inúmeras estruturas necessárias para a sociedade funcionar.

Da mesma maneira que seria intelectualmente desonesto dizer que toda margem de uma consultoria é lucro, seria igualmente simplista tratar toda tributação como dinheiro confiscado sem contrapartida.

A questão interessante continua sendo outra:

qual é a relação entre aquilo que entregamos, aquilo que contribuímos e a segurança que esperamos receber no futuro?

E aqui entramos numa das salas mais desconfortáveis da Matrix brasileira.


👴 A promessa chamada aposentadoria

Quando alguém começa a trabalhar jovem, aposentadoria parece uma abstração.

Aos vinte anos, sessenta parece pertencer a outra civilização.

Você pensa:

"Um dia."

E continua trabalhando.

Ano após ano.

Projeto após projeto.

Segunda-feira após segunda-feira.

20 anos
   ↓
25
   ↓
30
   ↓
35
   ↓
40
   ↓
45
   ↓
50
   ↓
...

Durante esse percurso existe uma espécie de contrato social implícito:

trabalhe, contribua e, no futuro, haverá proteção.

Não é uma conta de investimento individual simples. Sistemas previdenciários são muito mais complexos, envolvem solidariedade entre gerações, regras contributivas, demografia, financiamento e políticas públicas.

Mas, para o trabalhador olhando de dentro da cabine, a percepção pode ser muito mais simples:

"Estou entregando parte da minha renda e décadas da minha vida em troca de alguma segurança futura."

E então as regras mudam.


🐇 A linha de chegada que se movimenta

Aqui precisamos tomar cuidado com números simplificados.

Não podemos dizer literalmente:

COMEÇOU EM 1980 → TRABALHA 35 ANOS
COMEÇOU EM 1990 → TRABALHA 40 ANOS
COMEÇOU EM 2000 → TRABALHA 50 ANOS
COMEÇOU EM 2010 → TRABALHA 60 ANOS

A legislação brasileira nunca funcionou segundo essa progressão matemática.

Existem regras diferentes, reformas, idades, tempos de contribuição, categorias e sistemas de transição.

Mas como metáfora geracional, existe algo poderosíssimo aí.

Imagine uma esteira.

Você começa a correr.

No horizonte existe uma placa:

APOSENTADORIA
       10 KM

Você corre.

Corre.

Corre.

Quando finalmente se aproxima:

ATUALIZAÇÃO DO SISTEMA...

NOVAS REGRAS APLICADAS.

A placa parece um pouco mais distante.

Continue correndo.

Isso não significa necessariamente que exista alguém maliciosamente movimentando a placa.

Existe uma questão demográfica real por trás disso.

As pessoas vivem mais.

A proporção entre trabalhadores ativos e beneficiários muda.

A natalidade cai.

O sistema precisa continuar financiável.

Existem contas que precisam fechar.

Essa é a pílula azul.

Mas existe também a vermelha.


🔴 Quanto da vida cabe numa planilha atuarial?

Um sistema previdenciário olha para:

EXPECTATIVA DE VIDA
NÚMERO DE CONTRIBUINTES
NÚMERO DE BENEFICIÁRIOS
IDADE
CONTRIBUIÇÕES
RECEITAS
DESPESAS
PROJEÇÕES

Tudo perfeitamente racional.

Mas existe uma variável difícil de colocar na planilha:

MELHORES ANOS DA VIDA

Dos vinte aos trinta.

Dos trinta aos quarenta.

Dos quarenta aos cinquenta.

Dos cinquenta aos sessenta.

Existe uma coisa que nenhum sistema previdenciário consegue devolver:

tempo.

Dinheiro pode ser compensado.

Salário pode aumentar.

Investimento pode render.

Patrimônio pode valorizar.

Tempo não possui ROLLBACK.


💾 TIME-USED PIC 9(02)

Imagine nosso programa COBOL da existência:

01  WS-IDADE                 PIC 9(03).
01  WS-TEMPO-TRABALHADO      PIC 9(03).
01  WS-TEMPO-DISPONIVEL      PIC 9(03).
01  WS-APOSENTADORIA         PIC X(10).

PROCEDURE DIVISION.

    PERFORM TRABALHAR
       UNTIL WS-APOSENTADORIA = 'LIBERADA'.

    PERFORM APROVEITAR-VIDA.

Parece razoável.

Só existe um pequeno problema de arquitetura.

Quanto mais tarde executamos:

PERFORM APROVEITAR-VIDA

menos sabemos sobre as condições em que essa rotina será executada.

Essa talvez seja uma das maiores ilusões modernas:

"Quando eu me aposentar, faço."

Quando me aposentar, viajo.

Quando me aposentar, estudo aquilo.

Quando me aposentar, vou morar naquele lugar.

Quando me aposentar, caminho por aquele país.

Quando me aposentar, escrevo meu livro.

Quando me aposentar, finalmente terei tempo.

Existe apenas uma variável que ninguém conhece:

FUTURO AVAILABLE? Y/N

🔵 Mas Morpheus precisa mostrar a outra pílula

Seria fácil transformar isso em:

"Previdência é uma fraude."

Não.

Seria uma conclusão irresponsável.

Previdência social possui uma função importantíssima.

Sem mecanismos coletivos de proteção, milhões de pessoas chegariam à velhice sem nenhuma fonte de renda.

Nem todo trabalhador consegue investir.

Nem toda carreira permite acumular patrimônio.

Existem doenças, desemprego, crises, acidentes, desigualdade e acontecimentos completamente imprevisíveis.

Proteção social existe justamente porque a vida não executa sempre com:

RETURN-CODE = 00

Às vezes vem:

S0C7

sem aviso.

Portanto, a discussão não deveria ser:

Estado ou indivíduo?

Talvez seja:

quanto da nossa segurança futura deveria depender exclusivamente de uma promessa cuja regra pode mudar ao longo de quarenta anos?

Essa pergunta é muito mais interessante.


🔴 O risco regulatório do trabalhador

Falamos anteriormente sobre risco empresarial.

Depois falamos sobre risco profissional.

Agora aparece outro:

risco regulatório.

Você pode planejar sua carreira considerando determinadas regras existentes aos 25 anos.

Mas possui pouquíssimo controle sobre quais regras existirão quando tiver 55.

Esse risco é particularmente curioso porque o horizonte é gigantesco.

Imagine contratar um serviço cujo prazo de entrega seja:

quarenta anos.

Durante esses quarenta anos:

governos mudarão,

leis mudarão,

moedas poderão mudar,

economias entrarão em crise,

tecnologias desaparecerão,

profissões nascerão,

demografia mudará,

e talvez o próprio conceito de trabalho seja transformado.

Mesmo assim, fazemos planejamento previdenciário atravessando todo esse período.

É quase um projeto mainframe.

Só que o sistema legado é você.


🧑‍💻 E o terceirizado?

Agora voltamos ao nosso profissional de R$ 55/h.

Dependendo da relação contratual, ele pode ter diferentes níveis de proteção.

Pode ser CLT.

Pode ser PJ.

Pode trabalhar por projeto.

Pode passar períodos sem contrato.

Pode precisar financiar sozinho sua formação.

Pode precisar formar sua própria reserva.

Pode ter benefícios diferentes.

Pode contribuir para a previdência de maneiras diferentes.

E talvez exista aqui uma das maiores contradições da chamada flexibilização do trabalho:

quanto mais risco transferimos ao indivíduo, mais necessário se torna que ele compreenda finanças, previdência e seu próprio valor econômico.

O antigo modelo dizia aproximadamente:

TRABALHE
   ↓
RECEBA
   ↓
CONTRIBUA
   ↓
APOSENTE

O novo mundo pode se parecer mais com:

ESTUDE
   ↓
PAGUE O ESTUDO
   ↓
ENCONTRE PROJETO
   ↓
TRABALHE
   ↓
PROJETO TERMINA
   ↓
PROCURE OUTRO
   ↓
ATUALIZE-SE
   ↓
PAGUE SUA PROTEÇÃO
   ↓
FORME RESERVA
   ↓
ACOMPANHE AS REGRAS
   ↓
RECOMECE

Isso é liberdade?

Pode ser.

Isso é precarização?

Também pode ser.

Depende de quem está olhando, das condições oferecidas e principalmente de quanto poder de escolha aquela pessoa realmente possui.

Outra vez:

pílula azul.

Pílula vermelha.


🕶️ Anderson entregou os melhores anos

E finalmente retornamos ao apartamento pequeno.

Talvez seja por isso que Thomas Anderson continue sendo tão reconhecível décadas depois.

Ele não começa como escolhido.

Começa como trabalhador.

Acorda.

Vai trabalhar.

Entrega tempo.

Recebe salário.

Volta para casa.

Tenta construir outra identidade durante as horas que sobraram.

E repete.

A grande provocação de Matrix talvez não seja simplesmente:

"Nossa realidade é falsa?"

Existe outra pergunta muito mais cotidiana:

"Quanto da sua realidade foi escolhido por você?"

Estudar foi escolha?

Trabalhar foi escolha?

Aceitar aquele projeto foi escolha?

Adiar aquela viagem foi escolha?

Trabalhar naquele sábado foi escolha?

Guardar dinheiro foi escolha?

Não guardar porque não sobrava foi escolha?

Esperar pela aposentadoria foi escolha?

Talvez algumas respostas sejam sim.

Outras não.

E muitas provavelmente sejam:

mais ou menos.


⏳ O único ativo não renovável

Dinheiro perdido pode voltar.

Emprego perdido pode ser substituído.

Uma certificação vencida pode ser renovada.

Uma tecnologia esquecida pode ser reaprendida.

Um sistema destruído pode ser restaurado do backup.

Mas existe um recurso sem disaster recovery:

TIME

Não existe:

RESTORE TIME
FROM BACKUP
WHERE YEAR = 1997.

Talvez essa seja a verdadeira pílula vermelha deste artigo.

Não é descobrir que bancos ganham dinheiro.

Sabíamos.

Não é descobrir que consultorias possuem margens.

Sabíamos.

Não é descobrir que o Estado cobra impostos.

Definitivamente sabíamos.

É perceber que, no centro de toda essa arquitetura, existe alguém pagando com uma moeda que nenhum dos outros participantes consegue fabricar:

tempo de vida.

E isso não significa abandonar o trabalho.

Não significa abandonar a CLT.

Não significa abandonar a previdência.

Não significa declarar guerra ao Estado, aos bancos ou às consultorias.

Significa apenas acrescentar uma variável ao nosso planejamento:

IF DINHEIRO > 0
   AND TEMPO = 0
      DISPLAY 'TRANSACTION FAILED'
END-IF.

Porque talvez tenhamos passado gerações ensinando trabalhadores a perguntar:

Quanto vou receber quando me aposentar?

Quando deveríamos também ensinar:

Quanto da minha vida estou disposto a adiar até lá?

Essa pergunta não cabe numa folha de pagamento.

Não aparece no Imposto de Renda.

Não aparece no contrato.

Não aparece no extrato previdenciário.

Mas talvez seja uma das contas mais importantes que faremos.

🔵 A pílula azul diz:

trabalhe agora para viver depois.

🔴 A vermelha pergunta:

e se "depois" não puder entregar aquilo que você adiou?

Nenhuma das duas elimina a necessidade de trabalhar.

Nenhuma elimina os boletos.

Nenhuma resolve a previdência.

Mas uma delas talvez faça você olhar para o relógio de maneira diferente.

E desta vez...

não estou falando do relógio de ponto.

🕶️ Wake up, Neo

Talvez seja isso que mais me fascine em Thomas Anderson.

Durante o dia, alguém dizia quanto ele valia.

Tinha cargo.

Salário.

Horário.

Chefe.

Identificação.

Lugar no organograma.

Na outra vida existia Neo.

Neo começou a descobrir que aquilo que sabia fazer tinha valor fora da estrutura que definia Anderson.

Não precisamos abandonar nossos empregos.

Não precisamos declarar guerra às consultorias.

Não precisamos exigir royalties por cada MOVE A TO B.

Não precisamos enxergar exploração em toda relação comercial.

Mas talvez devêssemos fazer algo muito mais simples.

Entender a Matrix.

Entender quem paga.

Quem recebe.

Quem arrisca.

Quem investe.

Quem aprende.

Quem intermedeia.

Quem mantém.

Quem captura valor.

E quem pode ser descartado quando o projeto termina.

Porque liberdade profissional não começa quando você pede demissão.

Começa quando você entende sua posição dentro do sistema.


☕ Cambio final, Torre de Controle

Da próxima vez que alguém disser:

— Sua hora vale R$ 55.

Talvez a resposta não precise ser:

— Isso é injusto!

Talvez seja simplesmente:

— Interessante. Quanto ela vale para o cliente?

Essa pergunta não acusa ninguém.

Não exige nada.

Não quebra contrato.

Não transforma empresa em inimiga.

Apenas acende uma luz.

E sistemas complexos ficam muito mais interessantes quando conseguimos enxergar suas conexões.

Talvez você descubra que os R$ 55 são perfeitamente razoáveis.

Talvez descubra que existem custos que nunca havia considerado.

Talvez perceba que a consultoria realmente adiciona enorme valor.

Ou talvez descubra cinco camadas entre seu teclado e o cliente, cada uma retirando uma pequena fatia de algo que começou em R$ 200.

Nesse momento você terá uma escolha.

Não entre capitalismo e socialismo.

Não entre empregado e empresário.

Não entre banco e programador.

Uma escolha muito mais simples.

🔵 Continuar olhando apenas para o número que aparece no contrato.

Ou...

🔴 Começar a entender toda a arquitetura econômica que existe atrás dele.

Morpheus provavelmente sorriria.

Porque a pílula vermelha nunca prometeu que aquilo que encontraríamos seria necessariamente injusto.

Prometeu apenas uma coisa:

ver o sistema como ele realmente funciona.

E para um programador COBOL...

convenhamos...

não existe convite mais irresistível do que esse.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. WAKE-UP-NEO.

       PROCEDURE DIVISION.

           PERFORM ENTENDER-O-SISTEMA
              UNTIL FIM-DA-CARREIRA.

           DISPLAY 'KNOWLEDGE HAS VALUE'.
           DISPLAY 'KNOW YOURS.'.

           STOP RUN.

☕🕶️💊

Cambio final, Torre de Controle.

Wake up, Neo.

Os boletos já acordaram.

quinta-feira, 6 de agosto de 2026

O Caso TSB Bank : Como uma migração de mainframe destruiu a reputação de um banco

Bellacosa Mainframe edição especial O Caso TSB Bank

Um café no Bellacosa Mainframe Edição Especial

O Caso TSB Bank

Como uma migração de mainframe destruiu a reputação de um banco

Resumo

Em abril de 2018, o banco britânico TSB Bank realizou uma migração do seu core bancário.

O objetivo era:

  • abandonar a plataforma herdada da Lloyds

  • desligar o ambiente mainframe legado

  • migrar milhões de contas para a plataforma espanhola Proteo4UK, desenvolvida pelo grupo Sabadell.

O resultado foi um desastre.

Durante semanas:

  • clientes ficaram sem acessar contas

  • pagamentos falharam

  • salários não foram creditados

  • pessoas visualizaram contas de terceiros

  • fraudes aumentaram

  • o banco praticamente parou.

Até hoje o episódio é usado em universidades e cursos de gerenciamento de projetos.


Antes da crise

2008

Crise financeira mundial.

O governo britânico salva o Lloyds Banking Group.

Como condição da União Europeia:

Lloyds deveria vender parte de seus ativos.


2013

Nasce o novo TSB.

Entretanto...

O banco não possuía infraestrutura própria.

Continuou utilizando o enorme ambiente tecnológico da Lloyds.

Era praticamente um "inquilino" da infraestrutura do antigo dono.


O problema

Todos os anos o TSB pagava milhões para utilizar:

  • mainframe

  • processamento

  • storage

  • sistemas

  • infraestrutura

Era caro.

Muito caro.


2015

O banco espanhol

Banco Sabadell

compra o TSB por cerca de £1,7 bilhão.

O plano era simples.

"Vamos desligar toda a tecnologia da Lloyds e colocar tudo na plataforma Sabadell."

Nascia o projeto Proteo4UK. (Tsb)


O erro número 1

Uma consultoria estratégica contratada antes da aquisição recomendou justamente o contrário:

permanecer o máximo possível na plataforma Lloyds e, depois, utilizar uma cópia independente ("clone") da plataforma existente, reduzindo riscos de migração. (Tsb)

Mas, após a compra pelo Sabadell, prevaleceu o objetivo de capturar rapidamente as sinergias financeiras da aquisição, acelerando a migração para a plataforma própria. (Tsb)

  • Para saber mais

https://eljefemidnightlunch.blogspot.com/2020/04/o-caso-tsb-bank-como-uma-migracao-de.html

  • House MD investiga quando os dados mentem

https://eljefemidnightlunch.blogspot.com/2021/04/o-paciente-tsb-house-cobol-e-migracao.html


O cronograma

2015

Projeto iniciado


2016

Construção da nova plataforma


2017

Testes

Dress rehearsals

Ensaios

Migrações parciais

Segundo o banco:

  • nove ensaios completos

  • milhares de testes

  • piloto com cerca de 1.600 funcionários

Tudo aparentemente aprovado. (Tsb)


Abril de 2018

Chega o grande fim de semana.

Toda migração foi planejada para ocorrer entre

20 e 22 de abril.


Sexta-feira

20/04/2018

Os sistemas entram em manutenção.

Clientes avisados.


Domingo

22/04

Às 18h

Os serviços deveriam voltar.

Não voltaram normalmente.

Começaram os primeiros relatos:

  • erro de login

  • saldo incorreto

  • aplicativos travando

E o mais assustador...

Algumas pessoas conseguiam visualizar dados bancários de outros clientes. (The Guardian)


Segunda-feira

23 abril

O banco dizia:

"Há apenas problemas de acesso."

Nas redes sociais a situação parecia muito pior.

Milhares de reclamações.

Curiosamente, a própria Sabadell chegou a publicar uma nota comemorando o "sucesso" da migração antes de retirar o comunicado. (The Guardian)


Terça-feira

24 abril

O caos.

Até 1,9 milhão de clientes de internet banking e aplicativo foram afetados. (The Guardian)


O que aconteceu tecnicamente?

Durante muito tempo imaginou-se que:

"os dados foram perdidos."

Na realidade...

Não.

Os dados principais foram migrados corretamente.

Todas as contas chegaram.

O problema estava na infraestrutura.

Segundo as análises posteriores:

  • inconsistências entre os dois data centers

  • diferenças de configuração entre ambientes que deveriam ser idênticos

  • problemas de capacidade

  • defeitos de software

  • gargalos inesperados

  • canais digitais instáveis

  • explosão de acessos dos clientes tentando verificar suas contas, sobrecarregando ainda mais call centers e agências. (Tsb)

Ou seja...

Os registros bancários foram preservados.

A plataforma ao redor deles não conseguiu operar de forma estável.


IBM entra em cena

Dias depois, o CEO Paul Pester anunciou que especialistas da IBM haviam sido chamados para ajudar na estabilização da plataforma. O objetivo era recuperar o ambiente, e não conduzir a migração original. (The Guardian)

É importante destacar:

A IBM não foi responsável pelo projeto de migração.

Ela entrou posteriormente para auxiliar na recuperação.


As consequências

Durante semanas ocorreram:

  • salários atrasados

  • hipotecas afetadas

  • cartões recusados

  • pagamentos perdidos

  • transferências bloqueadas

  • empresas incapazes de pagar funcionários

Houve também aumento nas tentativas de fraude contra clientes durante o período de instabilidade. (Grupo Banc Sabadell)


O Parlamento britânico

O CEO Paul Pester foi convocado diversas vezes para prestar esclarecimentos ao Comitê do Tesouro da Câmara dos Comuns.

As audiências foram bastante críticas e questionaram planejamento, governança, comunicação e avaliação de riscos. (The Guardian)


O relatório independente

Em 2019, o conselho do TSB publicou uma revisão independente conduzida pelo escritório de advocacia Slaughter and May.

Entre as conclusões estavam:

  • cronograma excessivamente agressivo

  • supervisão insuficiente de fornecedores

  • falhas na governança

  • testes que não reproduziram adequadamente o ambiente real

  • excesso de confiança nos indicadores de prontidão antes do "go live". (Tsb)


Quanto custou?

As estimativas variam conforme o critério contábil, mas o impacto financeiro foi enorme.

Os custos incluíram:

  • compensações a clientes

  • recuperação operacional

  • perda de clientes

  • reforço da infraestrutura

  • consultorias

  • suporte emergencial

  • investigações regulatórias

O Grupo Sabadell informou centenas de milhões de libras em impactos relacionados ao incidente ao longo do tempo, considerando custos diretos e indiretos. (Grupo Banc Sabadell)


Houve multa?

Sim.

Em dezembro de 2022, os reguladores britânicos (Financial Conduct Authority – FCA e Prudential Regulation Authority – PRA) anunciaram um acordo com o TSB.

As multas somadas chegaram a aproximadamente £48,65 milhões, relacionadas às deficiências na gestão dos riscos operacionais e da migração tecnológica. (Tsb)


O CEO caiu?

Sim.

Paul Pester renunciou em setembro de 2018.

A pressão política e pública tornou sua permanência praticamente inviável. (The Guardian)


O TSB quebrou?

Curiosamente...

Não.

O banco continuou existindo.

Hoje opera normalmente utilizando a nova plataforma.

Após anos de estabilização, o próprio TSB afirma que os incidentes de TI voltaram a níveis comparáveis aos de outros bancos do mercado e que internalizou parte relevante da gestão de TI. (Tsb)


As principais lições para quem trabalha com mainframe

Este caso costuma ser resumido em algumas lições clássicas:

  1. O problema não era o mainframe. A motivação principal era reduzir dependências e custos do ambiente legado, não substituir uma plataforma que estivesse falhando.

  2. Migrações de core bancário são projetos de transformação organizacional, não apenas de tecnologia.

  3. Testes de laboratório não garantem comportamento em produção. Carga real, usuários simultâneos e cenários extremos podem revelar problemas invisíveis.

  4. Cronogramas definidos por metas de negócio podem aumentar o risco técnico. O relatório independente critica explicitamente o calendário considerado otimista demais. (Tsb)

  5. Planos de rollback e contingência precisam ser extremamente robustos. Em sistemas financeiros, recuperar a operação rapidamente é tão importante quanto migrar.


Links para as principais fontes históricas

Na minha opinião técnica, o caso TSB é um dos melhores estudos para profissionais de mainframe porque desmonta um mito recorrente: a falha não ocorreu porque o banco usava mainframe, mas porque uma transformação extremamente complexa foi conduzida sob um cronograma agressivo e encontrou problemas de arquitetura, implantação, governança e operação. A própria migração preservou os dados dos clientes; o colapso aconteceu na infraestrutura e nos serviços que deveriam disponibilizar esses dados de forma confiável. É por isso que o episódio continua sendo citado em discussões sobre modernização de sistemas críticos, muito mais como uma lição de engenharia e gestão do que como uma crítica à tecnologia de origem.

quarta-feira, 5 de agosto de 2026

NÃO ENTRE EM PÂNICO: Doctor Who, Doomwatch, COBOL e o Guia do Programador Mainframe para Sobreviver ao Futuro

Bellacosa Mainframe e o nao entre em panico como os britanicos e suas series viam o futuro

☕ Um Café no Bellacosa Mainframe

NÃO ENTRE EM PÂNICO: Doctor Who, Doomwatch, COBOL e o Guia do Programador Mainframe para Sobreviver ao Futuro

Ou: como a ficção científica britânica dos anos 1970 descobriu AI Governance, resiliência, pandemias, vigilância e incidentes cinquenta anos antes de inventarmos os nomes bonitos

Por Vagner Bellacosa


Existe uma regra fundamental para sobreviver no universo.

Douglas Adams resumiria isso em letras grandes e amigáveis:

NÃO ENTRE EM PÂNICO.

No mundo mainframe, entretanto, convém acrescentar algumas observações:

NÃO ENTRE EM PÂNICO.

Não cancele o job sem saber o que ele está fazendo.

Não dê PURGE apenas porque alguém importante está gritando ao telefone.

Não altere produção diretamente porque “é só uma coisinha”.

E, pelo amor de todos os compiladores COBOL existentes na galáxia, descubra primeiro por que o sistema funciona antes de decidir modernizá-lo.

Pegue sua toalha.

Pegue seu café.

Abra o SDSF.

Nossa nave está prestes a sair da órbita.

Destino:

Reino Unido, década de 1970.

Porque, escondidas entre cenários de papelão, monstros de borracha, computadores cheios de luzes piscantes e naves construídas em miniatura, algumas séries britânicas estavam fazendo perguntas que continuam assustadoramente atuais.

A matéria que serviu de ponto de partida para esta viagem considera os anos 1970 uma espécie de “era de ouro” da ficção científica televisiva britânica. A principal razão não era simplesmente a quantidade de alienígenas apresentados na televisão, mas a profundidade dos temas: problemas políticos, sociais, ambientais e tecnológicos começaram a ocupar o centro das histórias.

Eis a primeira coisa que um jovem programador COBOL precisa entender:

ficção científica de verdade raramente fala sobre o futuro.

Ela fala sobre o presente usando o futuro como máscara.


1. O planeta Reino Unido estava com problemas

Antes de encontrarmos Daleks, Cybermen, vírus mortais e governos totalitários, precisamos verificar o log do sistema operacional chamado Reino Unido.

Nos anos 1970, a situação estava longe de ser tranquila.

O país enfrentava problemas econômicos, greves, restrições de investimento e crise energética. Entre 1973 e 1974, a situação chegou ao ponto de haver restrições na operação das emissoras BBC e ITV durante a noite.

Agora imagine um roteirista sentado diante da televisão.

Ele vê:

greves;

desemprego;

problemas energéticos;

desconfiança política;

ameaças da Guerra Fria;

poluição;

crescimento tecnológico;

medo nuclear.

E pergunta:

“E se isso piorar?”

Pronto.

Temos ficção científica.

Uma das grandes virtudes dos britânicos foi transformar problemas concretos em experimentos narrativos.

As diferenças entre classes sociais, o totalitarismo e as preocupações ambientais tornaram-se temas recorrentes dessas produções.

O roteiro deixou de ser apenas:

ALIENÍGENA CHEGA
      ↓
HERÓI DESCOBRE
      ↓
HERÓI LUTA
      ↓
ALIENÍGENA EXPLODE
      ↓
FIM

e começou a ser algo parecido com:

SOCIEDADE CRIA TECNOLOGIA
          ↓
TECNOLOGIA CRIA BENEFÍCIOS
          ↓
ALGUÉM IGNORA OS RISCOS
          ↓
INCENTIVOS POLÍTICOS INTERFEREM
          ↓
SISTEMA SAI DO CONTROLE
          ↓
PESSOAS DESCOBREM QUE DEPENDIAM DELE
          ↓
PROBLEMA

Se você trabalha com tecnologia há alguns anos, isso provavelmente lhe parece menos ficção científica do que deveria.


2. Antes de Doctor Who havia Quatermass

Voltemos um pouco no tempo.

Em 1953 a BBC exibiu The Quatermass Experiment.

A história mostrava astronautas contaminados por uma forma de vida alienígena após uma missão espacial. O material que analisamos identifica a produção como uma das experiências da BBC que misturavam drama, terror, fantasia e ciência antes do nascimento de Doctor Who.

Observe a arquitetura da história.

O perigo não aparece simplesmente porque “alienígenas são maus”.

O problema surge porque:

HOMEM
 ↓
EXPLORA
 ↓
DESCONHECIDO
 ↓
TRAZ ALGO DE VOLTA
 ↓
NÃO ENTENDE O QUE TROUXE

Isso é uma estrutura importantíssima da ficção científica moderna.

E também da segurança da informação.

Se substituirmos “organismo extraterrestre” por:

biblioteca desconhecida
pacote npm
imagem Docker
modelo de IA
arquivo recebido
dependência open source

a história continua funcionando.

O monstro muda.

O problema permanece.


3. 1955: surge concorrência no datacenter televisivo

Durante muitos anos, a BBC dominou praticamente sozinha a televisão britânica.

Então surgiu a ITV.

De repente, existia competição.

A ITV trouxe programação mais popular e produções estrangeiras. A BBC precisou reagir aumentando sua capacidade de oferecer entretenimento sem abandonar sua tradição educacional e cultural.

Aqui encontramos uma lição de arquitetura empresarial.

Um sistema raramente evolui sozinho.

Ele evolui porque o ambiente muda.

Concorrência muda produto.

Regulação muda produto.

Usuários mudam produto.

Tecnologia muda produto.

Custo muda produto.

Até COBOL muda.

O COBOL que você encontra hoje em um IBM Z moderno não é simplesmente uma peça arqueológica que alguém esqueceu ligada desde 1968.

É resultado de décadas de evolução.

Da mesma forma, a BBC precisava preservar aquilo que funcionava e adaptar aquilo que já não respondia ao ambiente.

Guarde essa ideia.

Ela voltará quando falarmos de modernização mainframe.


4. 1963: chega Doctor Who

Então entra Sydney Newman.

A missão era quase impossível:

manter o conteúdo inteligente da BBC e, ao mesmo tempo, torná-lo popular.

A resposta foi uma série chamada:

Doctor Who.

A concepção original tinha forte propósito educacional. História, ciência, tecnologia, espaço e viagens temporais seriam apresentados aos jovens através de aventuras.

Parece simples hoje.

Mas pense na elegância da arquitetura.

Você quer ensinar história?

Leve os personagens para o passado.

Quer falar sobre tecnologia?

Viaje para o futuro.

Quer discutir ética?

Crie uma civilização alienígena.

Quer discutir racismo?

Crie duas espécies que se odeiam.

Quer falar sobre autoritarismo?

Invente um governo galáctico.

Quer discutir guerra?

Crie Daleks.

Doctor Who transformou ficção científica em uma espécie de laboratório moral portátil.

A TARDIS podia levar o espectador para qualquer problema.


5. O sistema quase foi cancelado

A primeira aventura de Doctor Who não provocou o sucesso esperado.

Então apareceram os Daleks.

A audiência aumentou dramaticamente, chegando a aproximadamente nove milhões de espectadores segundo o material analisado.

Ironicamente:

os Daleks salvaram Doctor Who.

Isso também contém uma pequena aula de engenharia de produtos.

Você pode criar uma solução tecnicamente brilhante.

Mas se ninguém quiser utilizá-la, temos um problema.

O criador pensa:

“Mas minha arquitetura está perfeita!”

O usuário responde:

“Tá. Mas onde está o botão que resolve meu problema?”

A BBC descobriu algo parecido.

A ideia educacional era boa.

Mas os Daleks forneceram:

ameaça;

identidade;

conflito;

memória;

símbolo.

Em linguagem de produto:

engajamento.


6. 1970: Doomwatch entra na sala

Agora chegamos a uma das partes mais interessantes desta viagem.

Em 1970 estreia Doomwatch.

A série foi criada por Kit Pedler e Gerry Davis. Pedler era cientista e atuava como consultor das situações apresentadas. Segundo o artigo analisado, a produção teve três temporadas e 38 episódios.

Mas observe a premissa.

Existe um departamento chamado:

Department for the Observation and Measurement of Scientific Work.

Missão:

acompanhar pesquisas científicas e verificar se elas poderiam representar ameaça às pessoas ou ao meio ambiente.

Caro viajante galáctico...

Estamos em 1970.

Agora troque:

Scientific Work

por:

Artificial Intelligence.

Temos imediatamente:

DEPARTMENT FOR THE OBSERVATION
AND MEASUREMENT OF
ARTIFICIAL INTELLIGENCE

Parabéns.

Você acabou de reinventar:

AI Governance.


7. A pergunta de Doomwatch

A pergunta fundamental de Doomwatch é maravilhosa:

se podemos fazer alguma coisa, devemos fazê-la?

Na tecnologia normalmente somos treinados para responder:

“Funciona?”

Mas sistemas críticos exigem outras perguntas:

“Devemos fazer?”

“Quem será afetado?”

“Qual é o risco?”

“Como detectaremos erro?”

“Quem pode interromper?”

“Existe rollback?”

“Quem autorizou?”

“Existe evidência?”

“Existe auditoria?”

“Qual é o blast radius?”

Esse é exatamente o ponto em que engenharia deixa de ser simplesmente programação.


8. O programador COBOL encontra Doomwatch

Imagine que alguém lhe entregue uma mudança:

IF CLIENTE-VIP
    MOVE ZERO TO TAXA
END-IF.

Funciona?

Provavelmente.

Compila?

Talvez.

Resolve a solicitação?

Aparentemente.

Mas o programador experiente pergunta:

Quem definiu CLIENTE-VIP?

Essa taxa pode legalmente ser zerada?

Quem autorizou?

Existe trilha de auditoria?

Isso afeta cálculo tributário?

Existem outros programas utilizando esse campo?

É aqui que surge uma regra fantástica:

código correto pode produzir um sistema errado.

Doomwatch já estava discutindo, metaforicamente, exatamente esse problema.


9. 1975: Survivors e o planeta sem produção

Então Terry Nation criou algo muito mais sombrio.

Survivors.

Uma praga provocada por vírus cultivado em laboratório destrói aproximadamente 99% da população mundial. Os sobreviventes precisam reconstruir comunidades praticamente sem infraestrutura moderna.

A produção existiu entre 1975 e 1977 e acumulou 38 episódios.

Hoje, depois de uma pandemia global real, assistir a essa premissa produz outra sensação.

Mas existe uma camada ainda mais interessante.

Survivors não é apenas sobre vírus.

É sobre:

dependência sistêmica.


10. Civilization.exe parou de responder

Imagine que amanhã desapareçam:

energia;

telecomunicações;

sistema bancário;

logística;

produção industrial;

governo;

hospitais;

internet;

combustíveis;

cadeias de suprimento.

Em poucas horas descobriremos algo curioso.

Nossa civilização é uma gigantesca aplicação distribuída.

Ela possui milhares de serviços.

Alguns críticos.

Alguns aparentemente insignificantes.

E todos possuem dependências.

Por exemplo:

SUPERMERCADO
     ↓
LOGÍSTICA
     ↓
COMBUSTÍVEL
     ↓
PAGAMENTO
     ↓
BANCO
     ↓
DATACENTER
     ↓
ENERGIA
     ↓
TELECOM

Agora faça o caminho inverso.

Telecom depende de energia.

Energia depende de sistemas informatizados.

Sistemas informatizados dependem de redes.

Redes dependem de telecom.

Bem-vindo ao maravilhoso universo das:

dependências circulares.


11. O batch das 04:37

Um jovem desenvolvedor pode olhar para determinado processamento mainframe e pensar:

“É apenas um job.”

Não.

Pode ser:

liquidação;

folha de pagamento;

posição contábil;

cartões;

compensação;

arrecadação;

seguros;

reservas;

crédito;

tributação.

O job pode terminar às 04:37.

Ninguém vê.

Ninguém aplaude.

Nenhuma animação aparece.

Não existem luzes azuis cinematográficas.

Mas talvez milhões de pessoas acordem de manhã esperando que o resultado daquele processamento exista.

Essa é uma das grandes lições de Survivors.

Infraestrutura só parece invisível enquanto funciona.


12. Resiliência antes de chamarmos de resiliência

Hoje utilizamos termos sofisticados:

Business Continuity.

Disaster Recovery.

Cyber Resilience.

High Availability.

Fault Tolerance.

Redundancy.

RTO.

RPO.

Survivors coloca tudo isso em uma única pergunta:

“O que acontece quando quase tudo deixa de funcionar?”

O exercício parece extremo.

Mas arquitetos fazem versões menores dessa pergunta todos os dias.

Se o Db2 cair?

Se o CICS parar?

Se perdermos um LPAR?

Se perdermos o datacenter?

Se a rede cair?

Se o fornecedor desaparecer?

Se o backup estiver corrompido?

Se o operador errar?

Se o ransomware atingir infraestrutura crítica?

Ficção científica e engenharia compartilham uma ferramenta intelectual maravilhosa:

cenários hipotéticos.


13. 1978: Blake's 7

Chegamos então a Blake's 7.

Também criada por Terry Nation.

A série apresenta um futuro onde uma organização chamada Terran Federation governa diversos mundos através de mecanismos políticos, religiosos, tecnológicos e até genéticos.

Agora mudamos de ameaça.

Em Survivors:

o sistema desapareceu.

Em Blake's 7:

o sistema ficou poderoso demais.

Excelente contraponto.

Um extremo:

SEM CONTROLE

Outro:

CONTROLE TOTAL

A humanidade vive entre os dois.


14. A tecnologia também pode controlar

Na Federação, tecnologia não é apenas ferramenta.

Ela é instrumento de poder.

Essa discussão cresceu enormemente no século XXI.

Quem possui os dados?

Quem controla algoritmos?

Quem define recomendações?

Quem observa usuários?

Quem decide quais informações aparecem?

Quem pode desligar uma conta?

Quem controla sistemas de identidade?

Quem controla a infraestrutura?

Não precisamos imaginar uma Federação Galáctica.

Podemos estudar simplesmente a concentração de infraestrutura digital.


15. Blake não é Luke Skywalker

Outro aspecto interessante é que Blake's 7 não transforma automaticamente a resistência em grupo moralmente perfeito.

Os próprios personagens questionam Blake.

Nem todos compartilham sua ideologia.

A série chega a apresentar acusações de fanatismo contra ele.

Isso é muito importante.

Porque sistemas complexos raramente apresentam:

MOCINHO = CERTO
VILÃO   = ERRADO

Normalmente encontramos:

pressões;

interesses;

incentivos;

erros;

interpretações;

riscos;

informação incompleta.

Quem trabalha em incidentes conhece isso.

Depois que tudo termina, é fácil dizer:

“Era óbvio.”

Antes do incidente?

Nem sempre.


16. Zen, o computador

A nave Liberator possui um computador chamado Zen.

Por décadas a ficção científica imaginou computadores que:

conversam;

aconselham;

controlam;

decidem;

questionam;

enganam;

ajudam.

Durante muito tempo isso parecia apenas recurso narrativo.

Agora chegamos à era dos modelos generativos e agentes.

A fronteira começou a mudar.

Antes:

HOMEM
 ↓
COMANDO
 ↓
COMPUTADOR
 ↓
RESULTADO

Hoje podemos ter:

HOMEM
 ↓
OBJETIVO
 ↓
AGENTE
 ↓
PLANO
 ↓
FERRAMENTA
 ↓
AÇÃO
 ↓
AVALIAÇÃO
 ↓
NOVA AÇÃO

A diferença é gigantesca.

Quanto maior a autonomia, maior a importância de controle, observabilidade e validação.

Doomwatch volta à sala.


17. UFO: a burocracia encontra os alienígenas

Outra produção importante foi UFO, de Gerry e Sylvia Anderson, também mencionada entre as séries relevantes daquele período.

Existe algo particularmente divertido em UFO.

A defesa da Terra não depende simplesmente de um herói com uma arma.

Existe uma organização.

Existem procedimentos.

Bases.

Monitoramento.

Satélites.

Computadores.

Comando.

Comunicação.

Ou seja:

até para combater alienígenas os britânicos imaginaram uma estrutura operacional.

Quase conseguimos ouvir alguém dizendo:

“Antes de interceptar a nave alienígena, abra o ticket.”

Isso talvez seja a coisa mais britânica possível.


18. Espaço: 1999 e o problema chamado consequência

Espaço: 1999 apresenta uma ideia completamente absurda do ponto de vista da física:

uma explosão gigantesca lança a Lua para fora da órbita terrestre.

Tudo bem.

Não entre em pânico.

Ficção não precisa necessariamente funcionar como artigo científico.

O interessante é a causa.

Resíduos nucleares.

Outra vez encontramos:

tecnologia + irresponsabilidade + consequência.

Os anos 1970 estavam profundamente preocupados com energia, poluição e tecnologia nuclear.

A Lua simplesmente serviu como cenário.


19. O detalhe mais importante das Eagles

As naves Eagle tornaram-se talvez um dos designs mais memoráveis da série.

Mas existe uma curiosidade de engenharia escondida nelas.

Elas parecem máquinas.

Não parecem “magia espacial”.

É possível observar:

módulos;

estrutura;

propulsores;

cockpit;

componentes.

Isso produz plausibilidade visual.

A mesma regra vale para software.

Quando mostramos arquitetura como caixas mágicas:

APP → CLOUD → IA → RESULTADO

não explicamos nada.

Um bom arquiteto precisa desmontar a Eagle.

APLICAÇÃO
    ↓
API
    ↓
AUTENTICAÇÃO
    ↓
SERVIÇO
    ↓
BANCO
    ↓
MENSAGERIA
    ↓
MAINFRAME

Agora podemos discutir risco.


20. O impacto no Brasil

A influência dessas produções no Brasil aconteceu de maneira diferente da experiência britânica.

Nem todas as séries tiveram aqui a mesma visibilidade.

Isso significa que memória cultural não depende apenas da qualidade de uma obra.

Depende também de:

distribuição;

emissora;

horário;

dublagem;

reprises;

licenciamento;

alcance.

No Reino Unido, Doctor Who tornou-se parte profunda da cultura popular.

No Brasil, para muitas gerações, outras produções britânicas como UFO, produções de Gerry Anderson e Espaço: 1999 foram referências muito mais imediatamente reconhecíveis.

Essa diferença ensina algo curioso.

Tecnologia também possui distribuição cultural.

Uma invenção pode existir.

Mas se não chega às pessoas, seu impacto é limitado.

Software é igual.


21. O código que ninguém conhece não existe

Imagine criar uma biblioteca fantástica.

Documentação inexistente.

Ninguém sabe utilizá-la.

Ela praticamente não existe.

Agora imagine um programa COBOL de 1989.

Executa todos os dias.

Possui milhares de regras.

Resolve dezenas de exceções.

Pouquíssimas pessoas entendem completamente aquilo.

O código existe.

O conhecimento talvez esteja desaparecendo.

É o problema inverso.

Em um caso:

produto sem distribuição.

No outro:

sistema sem conhecimento distribuído.

Ambos são risco.


22. O que a ficção britânica fez de diferente

Existe uma generalização interessante.

Muita ficção científica americana tradicional perguntou:

“O que encontraremos no futuro?”

A tradição britânica frequentemente perguntou:

“O que o futuro fará conosco?”

Não é uma regra absoluta.

Mas ajuda a compreender essas produções.

Doctor Who pergunta:

como usamos conhecimento?

Doomwatch pergunta:

quem controla ciência?

Survivors pergunta:

o que acontece quando infraestrutura desaparece?

Blake's 7 pergunta:

o que acontece quando controle tecnológico se torna excessivo?

Space: 1999 pergunta:

quais consequências deixamos para o futuro?

Essas perguntas continuam abertas.


23. De 1970 para 2026

Podemos montar uma pequena tradução temporal.

DOOMWATCH
1970: risco científico
2026: AI Governance
SURVIVORS
1975: pandemia e colapso
2026: resiliência sistêmica
BLAKE'S 7
1978: Estado tecnológico
2026: vigilância algorítmica
UFO
1970: infraestrutura de defesa
2026: sistemas distribuídos
SPACE: 1999
1975: lixo nuclear
2026: sustentabilidade tecnológica
DOCTOR WHO
1963+
ciência + ética + história
2026:
inovação responsável

Isso não significa que os roteiristas “previram” exatamente nosso mundo.

Significa algo mais interessante.

Eles identificaram padrões.


24. E padrões sobrevivem

Tecnologias mudam.

Padrões humanos nem tanto.

Temos:

pressa;

ambição;

medo;

competição;

custo;

ego;

autoridade;

conformismo;

pressão por prazo;

excesso de confiança.

Agora misture isso com tecnologia.

Resultado:

incidentes.

É exatamente aqui que nossas discussões sobre Plan Continuation Bias entram na TARDIS.

Um plano começa fazendo sentido.

O ambiente muda.

Surgem sinais de problema.

Mas pessoas continuam seguindo o plano porque já investiram nele.

“Já estamos quase terminando.”

“Não vamos voltar agora.”

“Diretoria já anunciou.”

“O cutover é hoje.”

“Todo mundo está mobilizado.”

Enquanto isso:

alerta.

alerta.

alerta.

alerta.

E ninguém reage.

Bem-vindo à Alarm Fatigue.


25. O episódio perdido de Doomwatch

Imagine.

Doomwatch — episódio 39.

Título:

The Legacy System.

Um grande banco decide substituir um sistema COBOL criado décadas antes.

Uma consultoria garante:

“Dezoito meses.”

Um jovem executivo pergunta:

“Quantas linhas?”

Alguém responde:

“Oito milhões.”

Executivo:

“Então é fácil. Colocamos cinquenta programadores.”

No fundo da sala existe um senhor com cinquenta anos de mainframe.

Ele levanta a mão.

Silêncio.

Pergunta:

“Vocês sabem o que ele faz?”

Executivo:

“Claro. Processa contas.”

O veterano:

“Não. Isso é o que vocês acham que ele faz.”

Música dramática.

Corta para propaganda.


26. A arqueologia do legado

Aqui está outra lição fundamental para quem começa em COBOL.

Sistema legado não significa necessariamente:

sistema ruim.

Significa principalmente:

sistema herdado.

Ele acumulou decisões.

Regras.

Correções.

Mudanças legais.

Tratamentos especiais.

Exceções.

Integrações.

Um programa pode conter algo assim:

IF DATA-MOVIMENTO < WS-DATA-1997
   PERFORM CALCULO-ANTIGO
ELSE
   PERFORM CALCULO-NOVO
END-IF.

O jovem pergunta:

“Por que 1997?”

Resposta:

“Ninguém sabe.”

Cuidado.

Isso não significa automaticamente que podemos apagar.

Talvez exista legislação.

Conversão histórica.

Contrato antigo.

Migração.

Compatibilidade.

A primeira ferramenta do mantenedor não é DELETE.

É:

curiosidade.


27. Guia galáctico para mexer em COBOL antigo

Antes de modificar código crítico:

Passo 1 — Descubra quem chama

JCL?

CICS?

IMS?

Outro programa?

Scheduler?

MQ?

API?

Passo 2 — Descubra o que entra

Arquivo?

VSAM?

Db2?

COMMAREA?

Fila?

Passo 3 — Descubra o que sai

Outro arquivo?

Tabela?

Relatório?

Transação?

Passo 4 — Procure dependências

COPYBOOKS.

CALLs.

PROCs.

SORTs.

Utilitários.

Passo 5 — Entenda a regra de negócio

Não pergunte apenas:

“O que esse IF faz?”

Pergunte:

“Por que o negócio precisa desse IF?”

Passo 6 — Teste o cenário feliz

Depois teste justamente o contrário.

Passo 7 — Crie rollback

Porque:

MOVE PROD TO TEST

é ficção científica.

MOVE TEST TO PROD

sem controle é terror.


28. O verdadeiro vilão quase nunca é o computador

Essa talvez seja a grande síntese.

Nas boas histórias de ficção científica, a máquina raramente é o problema inteiro.

Normalmente existe:

TECNOLOGIA
     +
DECISÃO HUMANA
     +
CONTEXTO
     +
INCENTIVO
     +
FALHA DE CONTROLE

= desastre.

Isso vale para:

IA;

mainframe;

aviação;

energia;

medicina;

bancos;

redes sociais;

automação.


29. Curiosidade: Daleks e Cybermen são diferentes

Para um iniciante em Doctor Who, existe uma diferença filosófica divertida.

Daleks representam uma espécie de pureza ideológica extrema.

Cybermen representam transformação tecnológica que elimina progressivamente características humanas.

Ou seja:

um teme o “outro”.

O outro elimina o “humano”.

Em tecnologia moderna isso permite uma metáfora interessante.

Um sistema pode falhar porque rejeita diversidade.

Ou pode falhar porque automatiza tudo sem preservar julgamento humano.

Qualquer semelhança com debates contemporâneos sobre IA é bastante conveniente.


30. Easter egg COBOL galáctico

Se Arthur Dent fosse programador COBOL, provavelmente seu código começaria assim:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DONT-PANIC.

       PROCEDURE DIVISION.

       0000-MAIN.

           PERFORM UNTIL UNIVERSE-END
               DISPLAY "DON'T PANIC"
               PERFORM CHECK-BATCH
               PERFORM DRINK-COFFEE
           END-PERFORM.

           STOP RUN.

O problema está em:

UNIVERSE-END

porque ninguém documentou o formato da variável.

Há rumores de que seja PIC 9(8).

Outros afirmam que é PIC X(42).

Naturalmente, 42.


31. Segunda curiosidade: a resposta não serve sem a pergunta

Em O Guia do Mochileiro das Galáxias, 42 é apresentado como resposta à Grande Questão da Vida, do Universo e de Tudo.

Mas existe um detalhe genial:

ninguém sabe exatamente qual era a pergunta.

Isso é uma metáfora perfeita para tecnologia.

Quantas vezes alguém aparece com uma solução?

“Cloud!”

“Blockchain!”

“Microserviços!”

“IA!”

“Kubernetes!”

“Agentes!”

Você pergunta:

“Qual problema estamos resolvendo?”

Silêncio.

Temos a resposta.

Esquecemos a pergunta.

Arquitetura boa começa pelo problema.


32. O mainframe é a TARDIS da computação empresarial

Exteriormente, alguém olha e diz:

“Isso ainda existe?”

Por dentro encontramos:

processamento massivo;

virtualização;

criptografia;

bancos de dados;

mensageria;

Linux;

APIs;

Java;

Python;

COBOL;

containers;

automação;

IA;

DevOps.

Talvez não seja literalmente maior por dentro.

Mas é suficientemente grande para assustar qualquer desenvolvedor que achava que “mainframe = COBOL + tela verde”.


33. O que realmente aprendemos

Depois de atravessar Quatermass, Doctor Who, Doomwatch, Survivors, Blake's 7, UFO e Espaço: 1999, podemos finalmente voltar para nosso café.

Essas séries ensinaram algo essencial.

Tecnologia não existe isolada.

Ela existe dentro de:

sociedade;

economia;

política;

organizações;

pessoas;

valores.

Portanto, nenhuma discussão tecnológica séria deveria terminar em:

“Funcionou.”

Precisamos perguntar também:

Funcionou para quem?

Com qual risco?

Sob qual controle?

Quem observa?

Quem audita?

Quem interrompe?

Quem responde?

Quem entende?


34. A pergunta que o jovem programador deve aprender

Quando receber sua primeira alteração em um sistema COBOL crítico, talvez você queira mostrar serviço.

Excelente.

Mas existe uma pergunta extremamente poderosa:

“O que pode dar errado?”

Depois:

“Como saberemos que deu errado?”

Depois:

“O que faremos se der errado?”

Essas três perguntas transformam um programador em engenheiro.


35. Não entre em pânico

Um ABEND acontece.

Não entre em pânico.

Veja o código.

Uma transação CICS falha.

Não entre em pânico.

Veja o contexto.

Um job fica preso.

Não entre em pânico.

Veja dependências.

Um usuário liga gritando.

Principalmente:

não entre em pânico.

O pânico reduz investigação.

E incidentes exigem investigação.


36. Observe antes de agir

Talvez Doomwatch pudesse ter como lema:

observar antes de intervir.

Isso é fantástico para produção.

Primeiro:

colete evidência.

Depois:

forme hipótese.

Depois:

valide.

Depois:

aja.

Em pseudo-COBOL:

PERFORM OBSERVE
PERFORM UNDERSTAND
PERFORM VALIDATE
PERFORM AUTHORIZE
PERFORM CHANGE
PERFORM VERIFY

Jamais:

PERFORM CHANGE
PERFORM PRAY

Embora esse segundo modelo tenha sido utilizado com surpreendente frequência na história da informática.


37. A grande lição da ficção científica britânica

Não foram as naves.

Não foram os monstros.

Não foram os figurinos.

Não foram os computadores piscantes.

A grande contribuição foi perceber que o problema fundamental do futuro seria:

como viver com as consequências das tecnologias que criamos.

Essa discussão aparece repetidamente nas obras analisadas: a matéria destaca explicitamente que essas produções dos anos 1970 utilizaram ficção científica para discutir questões sociais, políticas, ambientais e de poder.

Isso continua conosco.

IA.

Biotecnologia.

Computação quântica.

Cybersecurity.

Automação.

Redes sociais.

Mainframes.

Cloud.

Agentes autônomos.

A tecnologia continua avançando.

A pergunta continua praticamente a mesma.


38. Epílogo: o último operador do universo

Imagine o fim do universo.

As estrelas apagaram.

Os planetas desapareceram.

Os Daleks foram embora.

A Federação caiu.

A Lua finalmente encontrou uma órbita decente.

Arthur Dent terminou seu chá.

Restou apenas um datacenter IBM Z perdido no vazio cósmico.

Uma luz verde pisca.

No console aparece:

IEF404I JOB DAILY42 ENDED

Um velho operador olha para o relógio.

04:37.

Sorri.

O batch terminou.

O universo pode acabar tranquilo.

Porque em algum lugar nos últimos registros da civilização existe uma linha dizendo:

MAXCC=0000

E talvez essa seja a maior definição possível de sucesso operacional.

Não evitar todo problema.

Não possuir tecnologia perfeita.

Não prever exatamente o futuro.

Mas construir sistemas suficientemente compreendidos, observáveis, resilientes e responsáveis para continuar funcionando quando o inesperado finalmente aparecer.

Os britânicos descobriram isso enquanto colocavam monstros de borracha diante das câmeras.

Nós descobrimos novamente em cada war room.

Então, jovem programador COBOL, quando alguém aparecer diante de sua mesa dizendo:

“É só uma alteraçãozinha...”

segure sua toalha.

Beba seu café.

Abra o código.

Pergunte quem autorizou.

Descubra as dependências.

Prepare o rollback.

E lembre-se das palavras mais importantes já impressas em qualquer guia realmente útil para sobreviver à tecnologia:

NÃO ENTRE EM PÂNICO.

Principalmente em produção.

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