 |
| Bellacosa Mainframe e o ronin e o castelo |
☕ Um Café no Bellacosa Mainframe
O Ronin e o Castelo: por que todos enxergam a falta de COBOLzeiros, mas ninguém é dono da causa raiz
🔴🔵 Silos, incentivos, procurement, turnover e o paradoxo das organizações onde todos batem suas metas enquanto o sistema inteiro perde conhecimento
Por Vagner Bellacosa
Existe uma reunião acontecendo no último andar do Castelo.
Uma grande mesa.
Telas enormes.
Dashboards.
Indicadores.
PowerPoint.
Café provavelmente melhor que o nosso.
Na parede aparece:
CRITICAL SKILLS REPORT
COBOL ................. SHORTAGE
CICS .................. SHORTAGE
DB2 ................... SHORTAGE
IMS ................... SHORTAGE
MAINFRAME ............. SHORTAGE
RISK LEVEL ............ HIGH
Todos concordam.
Existe um problema.
Faltam profissionais.
O representante de RH levanta a mão:
— Precisamos contratar mais.
O responsável por treinamento:
— Precisamos formar mais.
Procurement:
— Precisamos contratar fornecedores capazes de entregar profissionais.
Financeiro:
— Precisamos controlar o custo dessas contratações.
Projetos:
— Precisamos dessas pessoas ontem.
Vendor Management:
— Precisamos aumentar a competição entre fornecedores.
Todos estão certos.
Essa é justamente a parte assustadora.
Morpheus aparece discretamente no fundo da sala.
Olha para Neo.
Neo não está sentado à mesa.
Ele está alguns andares abaixo.
Provavelmente diante de um terminal.
Morpheus pergunta:
— Você percebeu?
Neo responde:
— O quê?
Morpheus aponta para a sala.
Todos estão resolvendo o problema.
Neo olha novamente.
— Então por que ele continua piorando?
Morpheus sorri.
Pegue seu café.
Hoje vamos falar sobre sistemas nos quais ninguém precisa estar errado para que o resultado esteja errado.
🏯 Bem-vindo ao Castelo
Toda grande organização precisa dividir responsabilidades.
Isso não é defeito.
É necessidade.
Imagine uma empresa com dezenas de milhares de pessoas sem departamentos, papéis, responsabilidades ou hierarquia.
Seria impossível administrar.
Então construímos torres.
CASTELO
CEO
│
┌────────────┼────────────┐
│ │ │
RH FINANCEIRO TI
│ │ │
│ PROCUREMENT │
│ │ │
└──── VENDOR MGMT ────────┘
│
FORNECEDORES
│
PROFISSIONAIS
Cada torre possui sua missão.
Cada torre possui seus indicadores.
Cada torre possui seus samurais.
E cada samurai tenta fazer bem seu trabalho.
Até aqui, perfeito.
🥷 O Ronin
Do lado de fora existe outra figura.
O Ronin.
Ele não pertence permanentemente a nenhum Castelo.
Passou por vários.
Banco A.
Banco B.
Seguradora.
Indústria.
Consultoria.
Fornecedor.
Projeto.
Migração.
Incidente.
Fusão.
Outsourcing.
Insourcing.
Downsizing.
Rightsizing.
Transformação digital.
Agile Transformation.
Cloud Transformation.
AI Transformation.
Ele já sobreviveu a tantas transformações que começa a desconfiar quando alguém coloca “Transformation” no nome.
🤣
O Ronin possui uma característica interessante.
Ele consegue comparar Castelos.
👀 Quem está dentro vê profundidade. Quem está fora vê padrões.
O samurai conhece profundamente sua torre.
O Ronin conhece superficialmente muitas torres.
Essas perspectivas produzem conhecimentos diferentes.
O samurai sabe:
COMO FUNCIONA ESTE CASTELO
O Ronin começa a perceber:
O QUE SE REPETE
EM TODOS OS CASTELOS
Isso é extremamente valioso.
Porque problemas sistêmicos frequentemente parecem locais para quem está dentro deles.
🧠 O conhecimento de segunda ordem
Existe conhecimento técnico.
Sei COBOL.
Existe conhecimento de negócio.
Sei como funciona pagamento.
Existe conhecimento organizacional.
Sei como esta empresa trabalha.
E existe outra categoria:
Já vi organizações tentarem isso antes.
Esse é conhecimento de segunda ordem.
O veterano não conhece apenas soluções.
Conhece padrões.
DECISÃO A
↓
EFEITO B
DECISÃO C
↓
EFEITO D
DECISÃO A NOVAMENTE
↓
"HUM... JÁ VI ESSE FILME."
Esse talvez seja um dos maiores valores do profissional experiente.
Não prever o futuro.
Reconhecer o passado chegando novamente usando outra gravata.
💊 A pílula azul
A explicação tradicional para o shortage de mainframe é bastante razoável.
Muitos profissionais estão envelhecendo.
Durante determinados períodos entraram menos jovens.
Universidades reduziram exposição a COBOL e mainframe.
Tecnologias distribuídas ganharam enorme atenção.
Cloud atraiu novas gerações.
Empresas possuem sistemas que permaneceram por décadas.
Tudo isso contribui.
Seria absurdo negar.
Mas Morpheus levanta a outra mão.
🔴 A pílula vermelha
Talvez parte da escassez seja produzida também pelo próprio modelo de trabalho.
Pergunta:
Quantos profissionais entraram?
Ótimo.
Agora:
Quantos ficaram?
Depois:
Quantos poderiam continuar, mas escolheram sair?
E finalmente:
Por quê?
Essa última pergunta é perigosa.
Porque talvez a resposta não esteja no mercado.
Talvez esteja no Castelo.
🧑💼 Torre do RH
RH olha para o dashboard.
OPEN POSITIONS ........ 73
TIME TO HIRE .......... HIGH
COBOL CANDIDATES ...... LOW
Diagnóstico:
Precisamos aumentar o pipeline.
Soluções:
bootcamp,
universidade,
recrutamento,
programas júnior,
reskilling,
campanhas,
employer branding.
Tudo perfeitamente racional.
KPI melhora.
NEW HIRES ↑
RC=00.
💰 Torre do Procurement
Procurement olha para outro dashboard.
VENDOR COST ........... HIGH
CONTRACT VALUE ........ HIGH
SAVINGS TARGET ........ 12%
Missão:
negociar.
Competição.
RFP.
Benchmark.
Renegociação.
Novo fornecedor.
Resultado:
CONTRACT COST -12%
Excelente.
RC=00.
💵 Torre Financeira
Financeiro observa:
OPEX ↑
MARGIN PRESSURE ↑
Determina:
controle de despesas,
redução de custos,
melhoria de produtividade.
Correto.
Uma empresa que ignora custos não permanece empresa durante muito tempo.
Resultado:
BUDGET = TARGET
RC=00.
📅 Torre de Projetos
Project Management olha:
PROJECTS ............... 47
DEADLINES .............. FIXED
DEPENDENCIES ........... 183
RESOURCES .............. INSUFFICIENT
Resposta:
mais capacidade.
Mais fornecedores.
Mais profissionais.
Mais velocidade.
Mais acompanhamento.
Entrega.
RC=00.
🤝 Vendor Management
Vendor Management precisa evitar dependência excessiva.
Diversifica fornecedores.
Compara desempenho.
Renegocia contratos.
Troca empresas quando necessário.
Excelente governança.
VENDOR CONCENTRATION ↓
COMPETITION ↑
RC=00.
👨💻 E no porão...
Neo olha para seu dashboard particular.
SALÁRIO RELATIVO ........ ↓
PRESSÃO ................. ↑
BUROCRACIA .............. ↑
AUTONOMIA ............... ↓
CONTRATO ................ 12 MESES
RENOVAÇÃO ............... ?
CARREIRA ................ ?
PLANTÃO ................. SIM
RESPONSABILIDADE ........ ALTA
Ele recebe uma proposta para continuar.
Menor.
Olha.
Pensa.
Aceita porque precisa.
Depois abre:
OPEN TO WORK = Y
Três meses depois:
EMPLOYEE STATUS = LEFT
🚨 RH recebe um alerta
CRITICAL SKILL LOST
Resposta:
Precisamos contratar outro COBOLzeiro.
E o ciclo reinicia.
🔁 O loop corporativo
Agora conseguimos enxergar o sistema completo.
FALTA PROFISSIONAL
↓
RH CONTRATA
↓
PROJETOS ALOCAM
↓
CUSTO AUMENTA
↓
FINANCEIRO PRESSIONA
↓
PROCUREMENT REDUZ
↓
FORNECEDORES COMPRIMEM
↓
PROFISSIONAL PERCEBE MENOR VALOR
↓
TURNOVER AUMENTA
↓
CONHECIMENTO SAI
↓
FALTA PROFISSIONAL
Olhe novamente.
Existe algum vilão?
Talvez não.
Isso é que torna o problema tão interessante.
🎯 Todos bateram suas metas
RH:
HIRES TARGET = ACHIEVED
Procurement:
SAVINGS TARGET = ACHIEVED
Financeiro:
BUDGET TARGET = ACHIEVED
Projetos:
DELIVERY TARGET = ACHIEVED
Vendor Management:
COMPETITION TARGET = ACHIEVED
Parabéns.
Agora olhamos para o sistema:
TURNOVER ............... ↑
KNOWLEDGE .............. ↓
SENIORITY .............. ↓
HIRING DIFFICULTY ...... ↑
Como isso é possível?
Bem-vindo à:
Otimização Local
🖥️ O mainframe já nos ensinou isso
Imagine um programa que consome muita CPU.
O desenvolvedor otimiza.
CPU cai 20%.
Excelente.
Mas para conseguir isso ele aumenta brutalmente chamadas ao Db2.
Agora:
PROGRAM CPU ........... -20%
DB2 LOAD .............. +40%
ELAPSED TIME .......... +15%
O programa ficou melhor.
O sistema ficou pior.
Se você medir apenas CPU:
RC=00.
Se medir o workload:
RC=12.
Organizações podem cometer exatamente o mesmo erro.
📏 O problema das métricas
Existe uma ideia famosa em gestão:
Quando uma medida vira alvo, ela pode deixar de ser uma boa medida.
A organização quer eficiência.
Escolhe uma métrica:
VENDOR COST
Então todos otimizam:
VENDOR COST ↓
Mas eficiência organizacional não é apenas vendor cost.
Talvez seja algo mais parecido com:
TOTAL VALUE
---------------------
TOTAL LIFECYCLE COST
E aí entram coisas muito mais difíceis de medir.
🧮 O custo que ninguém recebe numa fatura
Imagine que Procurement economizou:
R$ 2.000.000
Esse número aparece lindamente.
Agora o turnover aumenta.
Custos surgem.
RH:
RECRUITMENT +300K
Treinamento:
TRAINING +200K
Projetos:
DELAY +400K
Operações:
INCIDENTS +?
Sêniores:
MENTORING HOURS +?
Produtividade:
RAMP-UP LOSS +?
Conhecimento:
TACIT KNOWLEDGE LOSS = ???
Talvez o total ultrapasse os dois milhões.
Talvez não.
O ponto é:
alguém calculou?
👻 O custo fantasma
Custos diretos são fáceis.
Possuem nota fiscal.
Centro de custo.
Contrato.
PO.
Invoice.
Custos sistêmicos são fantasmas.
Eles aparecem espalhados.
R$ 80K aqui
R$ 120K ali
3 meses acolá
2 incidentes depois
500 horas de onboarding
Ninguém recebe:
NOTA FISCAL
FORNECEDOR:
PERDA DE CONHECIMENTO S/A
SERVIÇO:
SAÍDA DO CARA QUE SABIA
POR QUE AQUELA PROC
NÃO PODE RODAR ÀS 04:10
VALOR:
R$ 487.391,72
🤣
Se existisse, talvez administrássemos conhecimento de maneira diferente.
⏳ E existe latência
Esse talvez seja o ponto mais perverso.
Decisão:
2026:
REDUCE CONTRACT COST 15%
Resultado imediato:
SAVING = SUCCESS
Consequências possíveis:
2027:
TURNOVER ↑
2028:
SENIORITY ↓
2029:
KNOWLEDGE GAP ↑
2030:
INCIDENT RISK ↑
Agora alguém pergunta:
— Por que temos esse problema?
Quem lembrará da decisão de quatro anos atrás?
Talvez ninguém.
Sistemas complexos possuem memória.
Organogramas nem sempre.
🦋 Causa aqui, efeito lá
Mainframeiros entendem isso.
Um pequeno parâmetro alterado hoje pode produzir comportamento estranho muito depois.
Organizações também possuem dependências invisíveis.
PROCUREMENT DECISION
↓
SALARY PRESSURE
↓
ENGAGEMENT
↓
TURNOVER
↓
KNOWLEDGE LOSS
↓
INCIDENT RISK
Mas cada seta pode levar meses.
Isso dificulta perceber causalidade.
🥷 Por que o Ronin percebe?
Não porque seja necessariamente mais inteligente.
Isso é importante.
Ele possui outra posição de observação.
Passou por:
CASTELO A
CASTELO B
CASTELO C
CASTELO D
E viu:
PADRÃO A
PADRÃO A
PADRÃO A
PADRÃO A
Então pensa:
Talvez não seja coincidência.
A experiência transversal permite reconhecer padrões que estruturas verticais escondem.
🏯 O samurai conhece profundamente uma torre
Ele talvez passe quinze anos em Procurement.
Conhece negociação como ninguém.
Outro passa quinze anos em RH.
Outro em Finance.
Outro em TI.
Todos especialistas.
Mas o problema mora:
entre as torres.
E problemas que vivem entre departamentos possuem uma característica perigosa:
ninguém é completamente dono deles.
👤 Quem é o owner do turnover sistêmico?
RH?
Talvez.
Mas RH não controla procurement.
Procurement?
Não controla carreira.
TI?
Não controla contratos comerciais.
Financeiro?
Não controla motivação.
Vendor Management?
Não controla mercado.
Então:
PROBLEM OWNER = NULL
E todo programador sabe que NULL pode gerar resultados interessantes.
🧠 Talvez este seja o verdadeiro problema
Não falta inteligência.
Falta ownership sistêmico.
Cada área possui:
LOCAL OWNER = YES
Mas:
END-TO-END OWNER = ???
Quem responde pela pergunta:
Estamos preservando conhecimento crítico ao longo de dez anos?
Talvez ninguém.
Porque dez anos não cabem confortavelmente num trimestre.
📆 O trimestre contra a década
Esse conflito merece atenção.
Sistemas mainframe podem durar:
30,
40,
50 anos.
Contratos:
12 meses.
Metas:
trimestrais.
Orçamentos:
anuais.
Carreiras:
talvez décadas.
Temos escalas temporais completamente diferentes.
MAINFRAME ............. 40 ANOS
CARREIRA .............. 30 ANOS
ESTRATÉGIA ............. 5 ANOS
CONTRATO ............... 1 ANO
BUDGET ................. 1 ANO
KPI .................... 3 MESES
Agora tente otimizar tudo isso simultaneamente.
Boa sorte.
🏃 O curto prazo sempre corre mais rápido
Economizar R$ 1 milhão este ano é concreto.
Evitar perder conhecimento daqui a cinco anos é abstrato.
Então:
BENEFÍCIO PRESENTE
>
RISCO FUTURO PERCEBIDO
Até o futuro virar presente.
Aí abrimos um projeto chamado:
CRITICAL SKILLS
TRANSFORMATION PROGRAM
🤣
Contratamos consultoria.
Criamos steering committee.
Fazemos workshops.
E tentamos reconstruir aquilo que talvez tivéssemos conseguido preservar.
💰 O paradoxo econômico
Podemos gastar:
R$ X
para evitar dar:
R$ Y
de incentivo de retenção.
Porque X está em:
TRANSFORMATION BUDGET
e Y estava em:
PAYROLL
São caixas diferentes.
O dinheiro não sabe disso.
Mas o organograma sabe.
🧱 Silos não são apenas departamentos
Existem silos de:
informação,
tempo,
incentivo,
orçamento,
responsabilidade,
métrica.
O problema pode atravessar todos eles.
Por isso parece invisível.
Cada pessoa enxerga uma parte verdadeira.
Ninguém enxerga necessariamente a verdade completa.
🧩 É o elefante corporativo
RH toca a tromba:
Falta recrutamento.
Procurement toca a perna:
Custo alto.
TI toca a barriga:
Falta capacidade.
Finance toca a orelha:
OPEX.
Neo olha o elefante inteiro:
Talvez tenhamos um problema de retenção e proposta de valor.
Todos podem estar parcialmente certos.
🎯 Goodhart entra no CPD
Imagine que estabelecemos:
KPI:
REDUCE CONTRACTOR COST 10%
A organização conseguirá.
Pessoas são extraordinariamente criativas quando bônus dependem disso.
Mas talvez precisássemos de:
KPI:
REDUCE TOTAL COST
WHILE PRESERVING
CRITICAL KNOWLEDGE
AND SERVICE QUALITY
Muito melhor.
Também muito mais difícil de medir.
E exatamente aí mora o problema.
📊 O que é fácil medir vence
Preço/hora:
fácil.
Número de profissionais:
fácil.
Quantidade de vagas:
fácil.
Turnover:
razoavelmente fácil.
Agora:
valor do conhecimento tácito?
Difícil.
Confiança?
Difícil.
Custo de contexto perdido?
Difícil.
Capacidade de diagnóstico?
Difícil.
Valor de alguém que evita um incidente que nunca aconteceu?
Quase impossível.
Então nossa planilha possui precisão extraordinária sobre as coisas menos interessantes.
👴 Quanto vale o incidente que não aconteceu?
O veterano olha para uma mudança e diz:
— Não façam isso.
Perguntam:
— Por quê?
— Já vi dar problema.
Mudam a abordagem.
Nada acontece.
Resultado:
INCIDENTS = 0
Quanto dinheiro ele economizou?
Zero?
Talvez milhões.
Mas como o incidente nunca aconteceu, não existe número.
Esse é o paradoxo da prevenção.
O sucesso apaga a evidência do próprio valor.
🧑🏫 E quando ele sai...
Seis meses depois alguém repete a ideia.
Desta vez ninguém diz:
— Não façam isso.
Executam.
Produção cai.
War Room.
Executivos.
Fornecedores.
Post-mortem.
Consultoria.
Plano de ação.
Agora temos números!
INCIDENT COST:
R$ 4.700.000
Finalmente conseguimos medir o valor daquele conhecimento.
Só precisávamos perdê-lo primeiro.
🔴 Red Pill Management
Talvez precisemos de perguntas diferentes.
Não apenas:
Quantas pessoas contratamos?
Mas:
Quantas perdemos?
Não apenas:
Quanto reduzimos o contrato?
Mas:
Quanto aumentamos o custo total?
Não apenas:
Quantos profissionais temos?
Mas:
Onde está o conhecimento crítico?
Não apenas:
Quem executa?
Mas:
Quem sabe por que fazemos assim?
Não apenas:
Qual fornecedor possui o contrato?
Mas:
Quem continuará sabendo isso depois que o fornecedor sair?
Essas perguntas atravessam torres.
🧠 O WLM humano
Mainframe possui uma ideia maravilhosa.
WLM não deveria simplesmente perguntar:
Qual tarefa está consumindo CPU?
Ele pensa em:
objetivos de serviço.
O sistema tenta administrar recursos olhando para prioridades e resultados.
Talvez organizações precisem de algo semelhante.
Um:
Enterprise Knowledge WLM
Objetivo:
CRITICAL KNOWLEDGE
MUST REMAIN AVAILABLE
Agora RH, Procurement, Finance, TI e fornecedores deixam de otimizar isoladamente.
Precisam negociar recursos em torno de um objetivo comum.
🏯 O problema não é destruir as torres
Silos possuem função.
Especialização importa.
Não queremos RH fazendo tuning de Db2.
Nem queremos o DBA negociando plano odontológico.
🤣
A solução não é eliminar departamentos.
É construir mecanismos que enxerguem:
END-TO-END
Porque alguns problemas não pertencem a nenhuma torre.
Pertencem ao Castelo.
👑 Quem deveria ser dono?
Talvez a resposta varie.
CTO.
CIO.
CHRO.
Knowledge Management.
Workforce Strategy.
Um comitê transversal.
Não importa tanto o título.
Importa existir alguém capaz de perguntar:
Qual é o efeito conjunto das nossas decisões sobre a capacidade técnica daqui a cinco anos?
Essa pergunta raramente cabe num KPI trimestral.
Justamente por isso alguém precisa fazê-la.
🔵 A pílula azul novamente
Grandes empresas não são burras.
Executivos não ignoram necessariamente esses problemas.
Muitas organizações possuem excelentes programas de:
sucessão,
talentos,
retenção,
formação,
knowledge management,
workforce planning.
Além disso, shortages podem realmente resultar de demografia, tecnologia, mercado e mudanças educacionais.
Seria simplista culpar procurement ou terceirização.
Não é essa nossa tese.
🔴 A pílula vermelha novamente
Mas seria igualmente simplista acreditar que políticas internas não participam da equação.
Se profissionais:
ganham relativamente menos,
possuem contratos menores,
veem menos carreira,
enfrentam mais camadas,
recebem mais pressão,
possuem menos autonomia,
e encontram alternativas...
alguns sairão.
Depois disso, chamar todo o fenômeno simplesmente de:
SKILLS SHORTAGE
pode esconder parte da história.
Talvez seja também:
RETENTION SHORTAGE
ou até:
INCENTIVE DESIGN PROBLEM
🥷 O Ronin volta ao Castelo
Um dia convidam Neo para uma reunião.
Ele entra.
Olha os dashboards.
O slide diz:
MAINFRAME TALENT CRISIS
Perguntam:
— O que você acha que deveríamos fazer?
Neo olha para RH.
Depois Procurement.
Financeiro.
Projetos.
Vendor Management.
Respira.
E pergunta:
Quantos COBOLzeiros vocês formaram nos últimos cinco anos?
Alguém responde.
Quantos contrataram?
Resposta.
Quantos ainda estão aqui?
Silêncio.
Quantos saíram?
Mais silêncio.
Então vem a última:
Por que saíram?
A sala fica muito quieta.
Morpheus sorri no fundo.
☕ Cambio final, Torre de Controle
Talvez a pergunta:
“Por que faltam COBOLzeiros?”
seja grande demais para qualquer departamento responder sozinho.
RH enxerga recrutamento.
Procurement enxerga custo.
Financeiro enxerga orçamento.
Projetos enxergam capacidade.
TI enxerga tecnologia.
Vendor Management enxerga fornecedores.
Todos enxergam partes verdadeiras.
Mas sistemas complexos possuem uma característica inconveniente:
o comportamento do todo não é simplesmente a soma das intenções das partes.
Podemos ter:
bons profissionais,
bons gestores,
bons compradores,
bons recrutadores,
bons fornecedores,
bons processos.
E ainda assim produzir um resultado ruim.
Isso não exige conspiração.
Não exige incompetência.
Não exige maldade.
Talvez seja justamente o contrário.
Todos podem estar fazendo exatamente aquilo que foram incentivados a fazer.
Na última tela da reunião aparece:
CORPORATE WLM
HR ..................... RC=00
PROCUREMENT ............ RC=00
FINANCE ................. RC=00
PROJECT MANAGEMENT ...... RC=00
VENDOR MANAGEMENT ....... RC=00
---------------------------------
ENTERPRISE .............. RC=12
ROOT CAUSE:
LOCAL OPTIMIZATION
O executivo olha.
— Como todas as áreas podem estar verdes e a empresa vermelha?
Neo responde:
— Porque vocês mediram as áreas.
— E não a empresa?
Neo balança a cabeça.
— Exatamente.
Morpheus coloca duas pílulas sobre a mesa.
🔵 A azul:
TRAIN MORE PEOPLE
🔴 A vermelha:
FIND OUT WHY
THEY DON'T STAY
Talvez precisemos das duas.
Mas durante décadas prestamos muito mais atenção à primeira.
E essa talvez seja a conclusão mais inquietante de toda esta Matrix.
O problema pode não estar nos samurais.
Pode não estar no Ronin.
Pode não estar no COBOL.
Pode nem estar na terceirização isoladamente.
Pode estar na arquitetura que conecta tudo isso.
Porque sistemas fazem exatamente aquilo para que foram desenhados e incentivados — inclusive quando ninguém pretendia conscientemente produzir aquele resultado.
Então, antes de procurar culpados, talvez devêssemos fazer aquilo que todo velho mainframeiro aprende depois de sobreviver a alguns incidentes:
STOP BLAMING COMPONENTS.
TRACE THE FLOW.
FOLLOW THE DEPENDENCIES.
CHECK THE INCENTIVES.
MEASURE END-TO-END.
FIND THE ROOT CAUSE.
E se depois de tudo isso descobrirmos:
ROOT CAUSE:
CASTLE DESIGN
não adianta demitir o samurai.
Outro ocupará seu lugar.
Receberá os mesmos KPIs.
Responderá aos mesmos incentivos.
Tomará decisões semelhantes.
E alguns anos depois estaremos novamente naquela sala perguntando:
“Onde estão todos os COBOLzeiros?”
Enquanto, do lado de fora do Castelo, o Ronin toma seu café, olha para a estrada e talvez pense:
“Vocês continuam procurando pessoas para alimentar um sistema sem perguntar por que tantas pessoas querem sair dele.”
🔴🔵
Wake up, Neo.
Às vezes o problema não está em quem executa o programa.
Está no programa.
E, às vezes, nem mesmo no programa.
Está na arquitetura que decidiu como todos os programas deveriam trabalhar juntos.
☕ Cambio final, Torre de Controle.
☕ Um Café no Bellacosa Mainframe // IT JOB MARKET RADAR
Mercado de Trabalho em TI: Quando Conhecimento Vira Commodity, Poder e Risco
Cinco leituras sobre salário, memória técnica, conhecimento legado, leilão reverso de profissionais e o êxodo de especialistas COBOL. Um pequeno mapa de um mercado em que experiência vale muito — até alguém tentar transformá-la em desconto.
STATUS=KNOWLEDGE_CRITICAL
SALARY_PRESSURE=HIGH
LEGACY_SKILLS=SCARCE
CORPORATE_MEMORY=VOLATILE
ACTION=READ_THE_EVIDENCE
O Spread do Conhecimento: Matrix, COBOL e o Valor do Saber
Quando conhecimento raro deixa de ser apenas competência técnica e passa a funcionar como ativo econômico dentro das organizações.
Knowledge EconomicsQuanto Custa um Programador? Salário, Valor e Mercado
O preço de um profissional de tecnologia não é simplesmente salário: envolve experiência, escassez, produtividade, conhecimento acumulado e risco operacional.
Salary EconomicsDELETE USER Não Apaga Memória: O Conhecimento que Sai da Empresa
Demitir ou perder um especialista é simples no RH. Recuperar décadas de contexto operacional depois pode ser impossível.
Corporate MemoryO Leilão Reverso do Conhecimento
Quando empresas tentam comprar cada vez mais experiência por cada vez menos dinheiro, o mercado pode transformar contratação em um leilão reverso de conhecimento.
Reverse AuctionO Êxodo dos COBOLzeiros
O que acontece quando profissionais que conhecem sistemas críticos descobrem que permanecer onde estão pode valer menos do que sair?
COBOL Exodus🧠 O problema não é COBOL. É economia do conhecimento.
Empresas costumam tratar conhecimento técnico como se fosse um recurso facilmente substituível. Entretanto, sistemas corporativos acumulam décadas de regras de negócio, exceções, interfaces, decisões históricas e conhecimento informal que raramente aparece integralmente na documentação.
Quando o profissional sai, o USERID pode ser apagado imediatamente. O contexto que ele carregava não possui um comando equivalente.
📚 Leituras sobre mercado de trabalho, COBOL e conhecimento em TI
- O Spread do Conhecimento: Matrix, COBOL e o valor econômico da experiência técnica
- Quanto Custa um Programador? Salário, experiência e valor profissional em tecnologia
- DELETE USER Não Apaga Memória: conhecimento corporativo e perda de especialistas
- O Leilão Reverso do Conhecimento: contratação, salários e desvalorização técnica
- O Êxodo dos COBOLzeiros: escassez de profissionais, salários e sistemas legados
