 |
| Bellacosa Mainframe bem vindo a guilda do mainframe |
☕ Um Café no Bellacosa Mainframe
🛡️ GUILD GIRL E A GUILDA DOS TALENTOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE PESSOAS NÃO SÃO RECURSOS DE CPU
Qualidade, produtividade, trabalhadores intelectuais, liderança, conhecimento, criatividade, descentralização, retenção, Bus Factor, IA — e o dia em que a Guild Girl descobriu que administrar uma equipe de informática era muito mais complicado do que distribuir quests.
🎬 PRÓLOGO — BEM-VINDO À GUILDA
A porta abriu.
Um jovem programador COBOL entrou carregando aquilo que todo iniciante costuma carregar: dúvidas, alguns JCLs impressos, meia dúzia de mensagens de compilação que não entendia e a certeza perigosíssima de que administrar uma equipe de informática deveria ser relativamente simples.
Atrás do balcão estava Guild Girl.
Ela organizava fichas de aventureiros.
Guerreiros.
Magos.
Sacerdotisas.
Arqueiros.
Batedores.
Cada um possuía habilidades diferentes.
O programador aproximou-se.
— Guild Girl, preciso aprender sobre gerenciamento de talentos em empresas de informática.
Ela levantou os olhos.
— Então primeiro esqueça uma coisa.
— O quê?
— Pessoas não são recursos computacionais.
Silêncio.
Em algum lugar distante, um gerente tentou executar:
//HUMANO EXEC PGM=PROGRAMADOR,
// PARM='PRODUTIVIDADE=MAX'
e recebeu:
ABEND S0C4
Guild Girl sorriu.
— Vamos começar.
🏰 CAPÍTULO 1 — A EMPRESA É UMA GUILDA
Uma empresa de informática parece muito mais com a Guilda de Goblin Slayer do que inicialmente imaginamos.
Na Guilda existem diferentes profissionais.
Um guerreiro possui determinadas capacidades.
Um mago possui outras.
Uma sacerdotisa possui conhecimentos completamente diferentes.
Goblin Slayer é absurdamente especializado em uma categoria particular de problema.
A Guild Girl conhece aventureiros, missões, recompensas, riscos e necessidades das comunidades.
Ninguém possui exatamente as mesmas capacidades.
Uma empresa de informática funciona de maneira semelhante.
Podemos encontrar:
Programadores COBOL
Analistas de Sistemas
DBAs
Especialistas CICS
Especialistas IMS
Administradores z/OS
Segurança/RACF
Arquitetos
Analistas de negócio
DevOps
SRE
Cloud Engineers
Especialistas em redes
Suporte
Gestores
A primeira grande lição é justamente esta:
administrar talentos não significa administrar pessoas como se fossem unidades intercambiáveis.
Um programador COBOL com vinte anos de experiência em cartões de crédito não pode simplesmente ser substituído por qualquer outro programador COBOL.
Por quê?
Porque existem pelo menos três camadas de conhecimento.
CONHECIMENTO DA TECNOLOGIA
+
CONHECIMENTO DO SISTEMA
+
CONHECIMENTO DO NEGÓCIO
Ele pode conhecer COBOL.
Mas também conhece aquele sistema específico.
E, além disso, pode conhecer as regras de negócio acumuladas durante décadas.
Esse terceiro conhecimento costuma ser perigosamente subestimado.
🎯 CAPÍTULO 2 — A PRIMEIRA QUEST: QUALIDADE
Guild Girl colocou uma ficha sobre o balcão.
Nela estava escrito:
QUEST:
ENTREGAR SOFTWARE COM QUALIDADE
O programador perguntou:
— O que significa qualidade?
Guild Girl respondeu:
— Depende.
Essa resposta incomoda engenheiros porque gostamos de valores objetivos.
Mas qualidade é contextual.
Um martelo excelente é péssimo para apertar um parafuso.
Da mesma forma, software tecnicamente sofisticado pode ser inadequado para aquilo que o cliente realmente precisa.
Podemos pensar:
QUALIDADE =
ADEQUAÇÃO AO PROPÓSITO
+
REQUISITOS
+
EXPECTATIVAS
+
CONTEXTO
Imagine um sistema bancário.
O usuário solicita:
“Quero consultar meu saldo.”
Podemos construir uma arquitetura maravilhosa, usando dezenas de tecnologias.
Mas se a consulta demora quinze segundos, o cliente provavelmente não ficará impressionado com o diagrama arquitetural.
Qualidade precisa ser percebida por quem utiliza o produto.
🧭 CAPÍTULO 3 — QUALIDADE COMEÇA ANTES DO COBOL
O programador iniciante frequentemente pensa:
qualidade = código bom
Não.
Código bom é apenas uma parte.
Antes de escrever:
IDENTIFICATION DIVISION.
PROGRAM-ID. SALDO001.
alguém deveria compreender:
Qual problema estamos resolvendo?
Quem utilizará?
Quais regras existem?
Qual volume?
Qual disponibilidade necessária?
Qual latência aceitável?
Quais requisitos de segurança?
O que acontece quando alguma coisa falha?
Imagine que alguém peça:
“Precisamos melhorar a performance do programa COBOL.”
Você otimiza o programa.
Ele passa de:
40 ms
para:
20 ms
Fantástico.
Mas a transação completa leva:
2,4 segundos
porque existe:
Aplicação
↓
API
↓
Rede
↓
Gateway
↓
CICS
↓
COBOL
↓
Db2
↓
Serviço externo
Você reduziu 20 milissegundos enquanto outro componente consome dois segundos.
Tecnicamente houve melhoria.
Para o cliente, praticamente nada mudou.
Guild Girl anotaria:
QUEST CONCLUÍDA?
[ ] SIM
[X] NÃO
📦 CAPÍTULO 4 — PRODUTO + SERVIÇO
Existe outra ideia importante:
qualidade envolve produto e serviço.
Considere um programa COBOL impecável.
Ele possui excelente tratamento de erros.
É rápido.
Está bem estruturado.
Foi testado.
Porém ninguém criou:
Quando ocorre um problema às 03:17 da manhã...
Sim, 03:17.
Os frequentadores antigos da Guilda Bellacosa sabem que incidentes importantes possuem uma estranha tendência de aparecer nesse horário.
O operador encontra:
DFHAC2206
TRANSACTION ABCD FAILED
E ninguém sabe o que fazer.
Temos bom software e péssimo serviço.
Portanto:
QUALIDADE REAL
=
SOFTWARE
+
OPERAÇÃO
+
SUPORTE
+
DOCUMENTAÇÃO
+
EXPERIÊNCIA
📈 CAPÍTULO 5 — PRODUTIVIDADE É CONSEQUÊNCIA
Guild Girl apresentou outra quest:
AUMENTAR PRODUTIVIDADE
O gerente tradicional poderia interpretar:
mais código
mais horas
mais tarefas
menos pessoas
Essa estratégia frequentemente cria um ciclo perigoso:
PRESSÃO
↓
PRESSA
↓
ATALHOS
↓
ERROS
↓
RETRABALHO
↓
INCIDENTES
↓
PRESSÃO
Parece familiar?
Agora fazemos o contrário.
Melhoramos:
requisitos
documentação
testes
automação
ferramentas
arquitetura
processos
comunicação
treinamento
Então:
QUALIDADE
↓
MENOS DEFEITOS
↓
MENOS RETRABALHO
↓
MENOS INCIDENTES
↓
MAIOR PREVISIBILIDADE
↓
MAIOR PRODUTIVIDADE
Essa é a razão para dizer que produtividade pode ser um subproduto da qualidade.
🧙 CAPÍTULO 6 — O TRABALHADOR INTELECTUAL
Agora chegamos ao personagem principal.
Não é o gerente.
Não é o computador.
É o trabalhador intelectual.
Em informática, grande parte do valor produzido vem de conhecimento.
A organização gostaria que esse profissional fosse:
cooperativo
generalista
criativo
flexível
interessado
comprometido
sensível
responsável
proativo
tecnicamente competente
Guild Girl olhou a lista.
— Querem contratar um aventureiro ou montar um grupo inteiro dentro de uma pessoa?
Boa pergunta.
Empresas frequentemente descrevem um profissional ideal impossível.
Querem alguém:
especialista
+
generalista
+
líder
+
criativo
+
disciplinado
+
comunicativo
+
autônomo
+
colaborativo
+
inovador
E, naturalmente:
“com disponibilidade imediata”.
🗡️ CAPÍTULO 7 — ESPECIALISTA OU GENERALISTA?
Imagine Goblin Slayer.
Ele possui conhecimento extremamente profundo sobre goblins.
Ele conhece:
comportamento;
esconderijos;
armas;
armadilhas;
estratégias;
padrões de ataque;
pontos fracos.
Isso é especialização.
Mas ele precisa compreender também cavernas, magia, venenos, logística, combate e comportamento de outros aventureiros.
Isso é visão generalista.
Em TI precisamos das duas coisas.
Um programador pode possuir conhecimento profundo em:
COBOL
CICS
JCL
VSAM
Db2
e conhecimento suficiente para conversar sobre:
MQ
APIs
Cloud
Linux
DevOps
Segurança
Observabilidade
IA
Podemos representar isso pelo modelo T:
────────────────────────────────
conhecimento abrangente
│
│
│
│
│
especialização profunda
O objetivo não é saber tudo.
É conseguir entender onde sua especialidade encaixa-se no todo.
🧠 CAPÍTULO 8 — CRIATIVIDADE NÃO É JCL
Aqui existe uma diferença fundamental entre computadores e pessoas.
Você consegue escrever:
//STEP01 EXEC PGM=CRIATIVO
Mas não consegue executar criatividade por comando.
Uma empresa pode dizer:
“Queremos inovação.”
Então alguém apresenta uma ideia.
O gerente responde:
“Nunca fizemos assim.”
Segunda ideia:
“Muito arriscado.”
Terceira:
“Não temos tempo.”
Depois de algumas tentativas, o profissional aprende:
IDEIA = RISCO
Então passa a fazer:
SILÊNCIO = SEGURANÇA
Meses depois a organização pergunta:
“Por que ninguém inova?”
Porque o sistema organizacional treinou as pessoas a não inovarem.
🛡️ CAPÍTULO 9 — SEGURANÇA PSICOLÓGICA
Equipes técnicas precisam conseguir dizer:
“Eu não sei.”
“Acho que isso está errado.”
“Cometi um erro.”
“Não concordo com essa arquitetura.”
“Existe risco nessa implementação.”
Isso é particularmente importante em tecnologia.
Imagine um programador percebendo que determinado processamento financeiro pode duplicar uma transação.
Mas o gerente é conhecido por destruir publicamente quem aponta problemas.
O programador pode permanecer calado.
Agora temos:
PROBLEMA TÉCNICO
+
PROBLEMA CULTURAL
=
RISCO OPERACIONAL
A cultura organizacional pode afetar diretamente a confiabilidade tecnológica.
⚔️ CAPÍTULO 10 — FLEXIBILIDADE NÃO É ACÚMULO DE FUNÇÃO
Guild Girl entregou outra ficha:
REQUISITO:
PROFISSIONAL FLEXÍVEL
Flexibilidade saudável:
“Sou programador COBOL e vou aprender como nossa aplicação participa de APIs REST.”
Excelente.
Flexibilidade doentia:
“Você programa COBOL, configura CICS, administra Db2, resolve incidente, faz pipeline, documenta, testa, atende usuário e amanhã precisa aprender Kubernetes.”
Isso não é necessariamente flexibilidade.
Pode ser simplesmente:
SOBRECARGA
Gestores precisam distinguir adaptabilidade de exploração da capacidade disponível.
👑 CAPÍTULO 11 — A GERÊNCIA PELO EXEMPLO
Agora Guild Girl virou a placa sobre o balcão:
GERÊNCIA PELO EXEMPLO
Imagine um gerente dizendo:
“Documentação é obrigatória.”
Mas ele próprio toma decisões críticas verbalmente e nunca registra nada.
Qual regra a equipe aprenderá?
A escrita?
Ou a praticada?
Outro exemplo:
“Qualidade vem primeiro.”
Chega sexta-feira.
O projeto está atrasado.
— Podemos pular os testes?
— Pode.
A equipe acaba de aprender:
QUALIDADE VEM PRIMEIRO
EXCETO QUANDO ATRAPALHA
Liderança não é apenas aquilo que alguém comunica.
É principalmente aquilo que faz, recompensa e tolera.
⚙️ CAPÍTULO 12 — GERENCIAR O PROCESSO
Empresas tradicionais frequentemente administram recursos.
Por exemplo:
8 programadores
2 DBAs
3 analistas
1 arquiteto
Mas existe outra pergunta:
Como uma necessidade torna-se software funcionando?
Observe:
REQUISITO
↓
ANÁLISE
↓
DESENVOLVIMENTO
↓
TESTES
↓
HOMOLOGAÇÃO
↓
CHANGE
↓
PRODUÇÃO
↓
MONITORAMENTO
Agora descobrimos algo curioso.
O COBOL foi alterado em quatro horas.
Porém:
espera DBA 3 dias
espera testes 4 dias
homologação 5 dias
change 3 dias
Alteração:
4 HORAS
Entrega:
15 DIAS
Perguntar apenas se o programador está ocupado não resolverá nada.
Precisamos analisar fluxo.
🚀 CAPÍTULO 13 — FAZER ACONTECER NÃO É FAZER TUDO
Um excelente programador é promovido.
Agora é gerente.
Surge um problema.
Ele diz:
“Deixa comigo.”
Resolve.
Segundo problema:
“Deixa comigo.”
Resolve novamente.
Depois de seis meses:
GERENTE
/ | | \
/ | | \
problema problema problema
Ele virou gargalo.
O objetivo da liderança deveria evoluir de:
EU CONSIGO RESOLVER
para:
MINHA EQUIPE CONSEGUE RESOLVER
Isso exige ensinar, delegar, orientar e permitir aprendizado.
🧝 CAPÍTULO 14 — CADA AVENTUREIRO É DIFERENTE
Na Guilda ninguém mandaria um mago fazer exatamente aquilo que um arqueiro faz melhor.
Por que empresas tentam fazer isso?
Pessoas possuem combinações diferentes de capacidades.
Um profissional pode ser excelente em:
incidentes
Outro:
arquitetura
Outro:
comunicação
Outro:
documentação
Outro:
negócio
Outro:
ensino
Administrar talentos significa identificar essas diferenças e aproveitá-las.
🧙♂️ CAPÍTULO 15 — O MAGO COBOL DE 1989
Guild Girl encontrou uma ficha antiga.
Nome:
ALFREDO
Experiência:
32 ANOS
Conhecimentos:
COBOL
CICS
VSAM
JCL
DB2
FATURAMENTO
FECHAMENTO
ARQUIVOS
INTERFACES
Quando alguma coisa quebra:
“Chama o Alfredo.”
Alfredo olha o dump.
— Já vi isso em 1998.
Cinco minutos depois:
RESOLVIDO
A empresa pensa:
“Temos um grande ativo.”
Correto.
Mas também existe risco.
Porque:
ALFREDO
/ | \
COBOL JCL NEGÓCIO
| | |
CICS BATCH REGRAS
Se Alfredo sai, aposenta-se ou muda de área:
ABEND ORGANIZACIONAL
🚌 CAPÍTULO 16 — BUS FACTOR
Existe um conceito famoso em engenharia chamado Bus Factor.
A pergunta é deliberadamente mórbida:
Quantas pessoas precisam desaparecer inesperadamente para o projeto entrar em grave dificuldade?
Não precisa existir ônibus algum.
Pode ser:
férias
demissão
aposentadoria
promoção
transferência
doença
mudança de projeto
Se somente Alfredo conhece determinado sistema:
BUS FACTOR = 1
Perigo.
O conhecimento precisa circular:
ALFREDO
↓
MENTORIA
↓
PAIR PROGRAMMING
↓
DOCUMENTAÇÃO
↓
RUNBOOK
↓
TREINAMENTO
↓
OUTROS PROFISSIONAIS
Isso não diminui Alfredo.
Pelo contrário.
Transforma sua experiência individual em patrimônio organizacional.
📚 CAPÍTULO 17 — CONHECIMENTO TÁCITO E EXPLÍCITO
Aqui podemos aprofundar ainda mais.
Existe conhecimento explícito.
É aquilo que conseguimos registrar:
manual
documentação
código
diagrama
procedimento
runbook
E existe conhecimento tácito.
É aquele:
“Quando aparece essa mensagem junto daquela outra, verifica primeiro o arquivo X.”
Onde está documentado?
Em lugar nenhum.
Está na cabeça do veterano.
Essa informação pode ter surgido depois de vinte incidentes ao longo de quinze anos.
É extremamente valiosa.
Um dos trabalhos da administração de talentos é converter, quando possível:
CONHECIMENTO TÁCITO
↓
COMPARTILHAMENTO
↓
CONHECIMENTO ORGANIZACIONAL
🏰 CAPÍTULO 18 — DESCENTRALIZAR SEM CRIAR ANARQUIA
Participação não significa:
“Todo mundo decide tudo.”
Guild Girl não coloca todas as quests em votação entre todos os aventureiros.
Existem responsabilidades.
A descentralização saudável significa levar decisões até onde existe conhecimento suficiente para tomá-las.
Imagine:
Programador
↓
Tech Lead
↓
Coordenador
↓
Gerente
↓
Diretor
Se uma decisão operacional simples precisa percorrer tudo isso, criamos latência administrativa.
O equivalente humano de uma aplicação fazendo vinte chamadas síncronas desnecessárias.
Uma boa organização define:
EQUIPE decide A, B e C.
GERÊNCIA decide D e E.
DIRETORIA decide F.
Isso é:
autonomia com governança.
💰 CAPÍTULO 19 — TALENTOS TAMBÉM FAZEM BENCHMARK
Chegamos aos salários e condições de trabalho.
No passado, uma empresa poderia competir principalmente com organizações próximas.
Hoje, em várias especialidades de tecnologia, o profissional pode comparar oportunidades nacionais e internacionais.
Logo, retenção depende de múltiplos fatores:
REMUNERAÇÃO
+
DESENVOLVIMENTO
+
AMBIENTE
+
AUTONOMIA
+
RECONHECIMENTO
+
FLEXIBILIDADE
+
PROPÓSITO
+
OPORTUNIDADES
Dinheiro importa.
Mas raramente é a única variável.
💎 CAPÍTULO 20 — O MILAGRE DO ORÇAMENTO DA CONTRAPROPOSTA
Existe uma antiga criatura das cavernas corporativas.
Seu nome:
Orçamento de Retenção Emergencial.
Funciona assim.
Profissional:
“Gostaria de discutir minha remuneração.”
Empresa:
“Infelizmente não temos orçamento.”
Três meses depois:
“Recebi proposta de outra empresa.”
Repentinamente:
+20%
PROMOÇÃO
BÔNUS
CURSO
HOME OFFICE
Guild Girl perguntaria:
— De onde surgiu esse tesouro?
Boa pergunta.
Uma política madura de talentos tenta reconhecer discrepâncias antes da carta de demissão.
📊 CAPÍTULO 21 — CONSTRUINDO UM MAPA DE TALENTOS
Agora vamos fazer algo prático.
Primeiro identificamos competências relevantes.
Exemplo:
COBOL
CICS
Db2
VSAM
JCL
MQ
APIs
Cloud
Negócio
Segurança
Liderança
Comunicação
Depois mapeamos conhecimentos.
Por exemplo:
| Profissional | COBOL | CICS | Db2 | Negócio | Cloud |
|---|
| Ana | 5 | 4 | 3 | 5 | 1 |
| Bruno | 3 | 3 | 5 | 4 | 2 |
| Carla | 2 | 2 | 3 | 3 | 5 |
O objetivo não é criar um ranking de pessoas.
É descobrir situações como:
IMS:
Alfredo █████
Ana █
Bruno █
Carla -
Temos concentração de conhecimento.
Precisamos criar sucessão.
🗺️ CAPÍTULO 22 — PASSO A PASSO PARA ADMINISTRAR TALENTOS
Guild Girl finalmente entrega nossa quest principal.
PASSO 1 — Descubra quais competências realmente importam
Não copie uma lista genérica da internet.
Observe seus sistemas.
PASSO 2 — Mapeie conhecimento
Descubra quem conhece:
tecnologia
sistemas
processos
negócio
história
operações
PASSO 3 — Localize SPOFs humanos
Pergunte:
“Se essa pessoa ficar três meses fora, o que acontece?”
PASSO 4 — Crie compartilhamento
Utilize:
mentoria
shadowing
pair programming
documentação
workshops
rotação
code review
runbooks
PASSO 5 — Descubra interesses
Pergunte também:
“O que você quer aprender?”
Não apenas:
“O que você já sabe?”
PASSO 6 — Crie oportunidades reais
Curso sem oportunidade de aplicação evapora.
PASSO 7 — Reconheça contribuição
Inclusive contribuições invisíveis:
ensinar
documentar
ajudar
prevenir incidentes
melhorar processos
PASSO 8 — Revise periodicamente
Conhecimento muda.
Tecnologia muda.
Pessoas mudam.
O mapa precisa acompanhar isso.
🤖 CAPÍTULO 23 — ENTRA A INTELIGÊNCIA ARTIFICIAL NA GUILDA
Então a porta abriu novamente.
Entrou uma nova aventureira.
Nome:
IA GENERATIVA
Ela consegue:
explicar código
gerar documentação
sugerir testes
resumir programas
produzir exemplos
analisar logs
ajudar no aprendizado
Alguém gritou:
“Agora não precisamos mais dos veteranos!”
Guild Girl quase derrubou o café.
Porque existe diferença entre:
CONHECER SINTAXE
e
CONHECER CONTEXTO
A IA pode analisar:
IF WS-STATUS = 'A'
PERFORM 3000-PROCESSAR
END-IF
Mas talvez não saiba que WS-STATUS = 'A' existe porque uma decisão tomada em 2003 precisava compatibilidade com uma interface que ainda alimenta determinado parceiro comercial.
O código mostra o que existe.
A história organizacional explica frequentemente por que existe.
🧠 CAPÍTULO 24 — O PROFISSIONAL DO FUTURO
A IA muda a definição de talento.
Saber respostas continua importante.
Mas outras capacidades tornam-se ainda mais relevantes:
formular perguntas
validar respostas
entender contexto
relacionar conhecimentos
detectar inconsistências
tomar decisões
ensinar
aprender continuamente
Podemos representar:
CONHECIMENTO
↓
COMPREENSÃO
↓
CONEXÃO
↓
JULGAMENTO
↓
DECISÃO
↓
AÇÃO
↓
APRENDIZADO
↺
A IA pode participar de várias etapas.
Mas responsabilidade e contexto continuam fundamentais.
🐉 CAPÍTULO 25 — O GERENTE NÃO PRECISA MATAR TODOS OS GOBLINS
Nosso jovem programador finalmente percebeu a analogia.
Um gerente não precisa ser o melhor COBOL da equipe.
Nem o melhor DBA.
Nem o melhor arquiteto.
Nem necessariamente aquele que resolve cada incidente.
Assim como Guild Girl não precisa entrar em todas as cavernas.
Seu papel é compreender:
qual missão existe
qual risco existe
quem possui capacidade
quem precisa desenvolver capacidade
quais recursos são necessários
como o conhecimento circula
Uma liderança madura cria condições para que outros tenham sucesso.
🎁 CURIOSIDADE — O PARADOXO DO MELHOR FUNCIONÁRIO
Imagine dois profissionais.
Programador A
Resolve todos os incidentes sozinho.
Nunca documenta.
Ninguém consegue substituí-lo.
Programador B
Resolve incidentes.
Documenta.
Ensina.
Treina dois colegas.
Automatiza procedimentos.
Depois de algum tempo, quase ninguém precisa chamá-lo.
Quem parece mais indispensável?
Provavelmente A.
Quem criou mais capacidade organizacional?
Possivelmente B.
Esse é um paradoxo importante da gestão de talentos.
O profissional que compartilha conhecimento pode parecer menos indispensável justamente porque fez a organização ficar melhor.
Não penalize o aventureiro que ensinou outros aventureiros a sobreviver.
🥚 EASTER EGG — O INCIDENTE DAS 03:17
Guild Girl abriu uma última ficha.
INCIDENTE: 0317
HORÁRIO: 03:17
SISTEMA: LEGACY-PROD
SEVERIDADE: 1
O operador ligou para Alfredo.
Ninguém respondeu.
Alfredo estava de férias.
Tentaram chamar o gerente.
Também não sabia.
Chamaram outro programador.
— Existe documentação?
Silêncio.
Finalmente alguém encontrou um comentário no COBOL:
* ALTERADO 1997 - J.SILVA
* NAO REMOVER ESTA REGRA.
— Por quê?
Ninguém sabia.
Guild Girl fechou a ficha.
— Eis o verdadeiro monstro da dungeon.
Não era COBOL.
Não era CICS.
Não era o mainframe.
Era:
CONHECIMENTO NÃO COMPARTILHADO
☕ EPÍLOGO — PESSOAS NÃO SÃO LPARs
Depois de horas de aula, o jovem programador perguntou:
— Então administrar talentos significa cuidar das pessoas?
Guild Girl pensou alguns segundos.
— Também. Mas é maior que isso.
Ela desenhou:
PESSOAS
+
CONHECIMENTO
+
PROCESSOS
+
CULTURA
+
TECNOLOGIA
↓
CAPACIDADE ORGANIZACIONAL
Uma empresa de informática não produz valor apenas porque possui computadores poderosos.
Um IBM Z pode executar bilhões de instruções.
Mas ele não decide sozinho:
“Qual problema vale a pena resolver?”
Não cria espontaneamente conhecimento institucional.
Não constrói confiança entre equipes.
Não decide ensinar um programador júnior.
Não percebe sozinho que Alfredo conhece uma regra crítica esquecida há vinte anos.
Não transforma experiência em cultura.
Esse é o domínio humano.
Durante a era industrial, administração concentrou enorme atenção em máquinas, materiais, tempo e capacidade.
Na economia do conhecimento, aparece outro recurso muito mais estranho.
Uma pessoa.
Ela aprende.
Esquece.
Ensina.
Questiona.
Discorda.
Inventa.
Erra.
Melhora.
Vai embora.
E leva consigo tudo aquilo que a organização não conseguiu transformar em conhecimento compartilhado.
Por isso administrar talentos em informática não significa simplesmente:
CONTRATAR
↓
DISTRIBUIR TAREFAS
↓
COBRAR RESULTADOS
↓
AVALIAR
É necessário construir:
PROPÓSITO
│
LIDERANÇA
│
┌────────────┴────────────┐
│ │
PESSOAS PROCESSOS
│ │
├── APRENDEM │
├── CRIAM │
├── ENSINAM │
├── QUESTIONAM │
└── COLABORAM │
│ │
└────────────┬────────────┘
│
QUALIDADE
│
PRODUTIVIDADE
│
VALOR
│
CLIENTE
E finalmente chegamos à grande lição da Guild Girl.
Quanto mais intelectual for o trabalho, menos eficiente será tratar profissionais como componentes substituíveis de uma máquina.
Programador não é CPU.
Analista não é memória.
DBA não é DASD.
Especialista não é uma licença de software.
E aquele veterano que sabe por que existe uma rotina COBOL escrita em 1989 definitivamente não é apenas:
RESOURCE-ID=000173
Ele é parte da memória viva da organização.
O desafio do gestor é permitir que esse conhecimento produza resultados, desenvolva outras pessoas e sobreviva ao próprio profissional.
Guild Girl guardou as últimas fichas.
O jovem programador levantou-se.
Antes que chegasse à porta, ela chamou:
— Espere.
— Sim?
Ela entregou outra quest.
QUEST ESPECIAL
OBJETIVO:
CONSTRUIR UMA EQUIPE QUE
NÃO DEPENDA DO GERENTE.
RECOMPENSA:
UMA ORGANIZAÇÃO MADURA.
RISCO:
EGO.
O programador riu.
Guild Girl completou:
— Existe uma última regra.
Se todo incidente precisa do gerente, toda decisão precisa do gerente, toda autorização precisa do gerente e a equipe para quando ele tira férias...
Ela virou a ficha.
Na parte de trás havia apenas:
***************************************
* *
* SPOF DETECTED: MANAGER *
* *
***************************************
E naquele dia nosso jovem programador COBOL descobriu que até uma organização pode sofrer ABEND.
A diferença é que o dump costuma vir em PowerPoint.
