☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

quinta-feira, 3 de abril de 2025

Inspetor Clouseau Entra no Dashboard IBM Z — O Caso dos 400 Advocates, dos 100 Mil Membros e do Denominador Desaparecido

 

Bellacosa Mainframe e advocates 

☕ Um Café no Bellacosa Mainframe

Inspetor Clouseau Entra no Dashboard IBM Z — O Caso dos 400 Advocates, dos 100 Mil Membros e do Denominador Desaparecido

Ou: por que 50 mil seguidores não são 50 mil especialistas, por que 400 pessoas também não são “o ecossistema”, e como ensinar mainframe em português pode ser mais importante do que outro foguete no PowerPoint

“Chefe, temos uma grande notícia!”, disse o agente da comunidade, entrando apressado na sala.

O Inspetor Clouseau levantou os olhos da xícara de café, que por algum motivo estava equilibrada sobre um manual de RACF.

“Ah, sim. Encontraram o assassino?”

“Melhor: conseguimos 400 Advocates! E mais de mil atos de advocacy no trimestre!”

Clouseau bateu palmas, tropeçou na cadeira, derrubou a pasta de relatórios, quase prendeu a mão na gaveta e, depois de alguns segundos fingindo que aquilo era parte da investigação, perguntou:

“Magnífico. E quatrocentos… de quantos?”

Silêncio.

Um silêncio de data center às três da manhã depois de alguém dizer: “mas eu só alterei um parâmetro”.

É aí que começa o caso.

Não é um caso sobre pessoas ruins, programas inúteis, Champions sem mérito ou estudantes que não deveriam celebrar certificados. É um caso sobre uma criatura perigosa, muito comum em apresentações corporativas, relatórios de comunidade e dashboards coloridos:

o número absoluto que foi solto na rua sem seu denominador.

Para um programador COBOL iniciante, isso pode parecer conversa de estatístico de gravata borboleta. Mas é assunto de sobrevivência profissional. Afinal, no mainframe nós aprendemos cedo que um número sozinho nunca explica a história.

CPU média de 30% parece ótima. Até você descobrir que, no fechamento, a CPU bate 100%, o batch estoura a janela, o CICS começa a sofrer e alguém pergunta por que o relatório mensal não mencionou o detalhe.

Um job terminou com RC=0. Excelente. Mas processou todos os registros? Atualizou o Db2? Gerou o arquivo de remessa? Ou simplesmente não encontrou nada para fazer e saiu feliz como um gato que derrubou um copo e fingiu que não foi ele?

O número não mente necessariamente. Mas pode estar respondendo a uma pergunta diferente daquela que a apresentação quer que você faça.



1. O primeiro suspeito: “Temos 400 Advocates!”

Vamos começar pela matemática que o Inspetor Clouseau encontrou atrás da cortina.

A IBM divulgou, em seus próprios materiais, que a comunidade IBM Z possui mais de 100 mil membros. Depois, em relatórios de advocacy, celebrou números como 197 participantes no lançamento, mais de 400 Advocates em um trimestre e mais de mil “atos de advocacy”.

Todos esses números podem ser verdadeiros.

Mas a pergunta é: o que eles provam?

Se houver 400 Advocates em uma comunidade declarada de 100 mil pessoas, temos:

400100.000=0,4%\frac{400}{100.000} = 0,4\%

Isso equivale a uma pessoa em cada 250.

Imagine uma cidade com 100 mil habitantes. Quatrocentas pessoas se encontram no auditório de uma escola. Há entusiasmo, palestras, café, networking, gente talentosa e talvez um banner azul muito bonito no fundo.

A reunião é válida? Claro.

Mas se alguém disser que aquela plateia prova que “a cidade inteira está mobilizada”, o Inspetor Clouseau deveria levantar a lupa e perguntar onde estão os outros 99.600 moradores.

No mainframe, seria como dizer que um único LPAR representa toda a empresa. Ele pode ser importante, crítico, cheio de aplicações relevantes e com carga monstruosa. Ainda assim, não é automaticamente o retrato do data center inteiro.

A crítica, portanto, não é: “400 é pouco”.

A crítica correta é:

“400 pode ser um excelente resultado para um programa especializado; não é evidência suficiente, por si só, de engajamento amplo de um ecossistema com mais de 100 mil pessoas.”

Essa diferença parece pequena. Mas muda toda a investigação.



2. O denominador não é inimigo da celebração

Há quem ouça essa discussão e pense: “Então não podemos comemorar nada?”

Podemos e devemos.

Se um programa reuniu 400 pessoas dispostas a ensinar, escrever, falar, testar produtos, mentorar alunos e promover conhecimento técnico, isso merece reconhecimento. Existem comunidades menores que fazem milagres com dez pessoas e uma cafeteira que só funciona quando o ar-condicionado está desligado.

O problema aparece quando a comemoração troca de tamanho no meio da frase.

Veja a diferença:

  • “Temos 400 Advocates ativos em nosso Hub.”

  • “Temos 400 Advocates, portanto o ecossistema IBM Z está fortemente engajado.”

A primeira frase informa um fato.

A segunda exige prova de representatividade.

É como medir a temperatura de uma sala de CPD e concluir que o clima do Brasil inteiro está controlado. Pode estar fresquinho perto do mainframe; do lado de fora, o termômetro pode estar fritando ovo no asfalto.

3. A sala pode encolher — mas o discurso também precisa encolher

Talvez 100 mil seja um denominador amplo demais. Afinal, “comunidade” pode incluir estudantes, pessoas que assistiram a um evento, perfis inativos, curiosos, parceiros, professores, clientes, ex-clientes e pessoas que se cadastraram numa época em que ainda usávamos CD-ROM para instalar software.

Se usarmos um grupo IBM Z mais específico, com aproximadamente 26.900 membros, 197 Advocates representariam perto de 0,73%.

Ainda não chega a 1%.

Se reduzirmos a sala até um Hub especializado de cerca de 1.500 pessoas, então 400 Advocates equivaleriam a quase 27%.

Aí sim temos uma adoção bastante bonita.

Só que há uma regra de ouro que Clouseau escreveria com caneta azul, erraria a grafia de “denominador” e pisaria no próprio casaco:

Você pode usar o denominador pequeno ou a missão enorme. Não pode usar o pequeno para fazer a porcentagem parecer gigante e o enorme para fazer o programa parecer representativo.

Um Hub de fãs e multiplicadores pode ser uma excelente ferramenta de advocacy. Mas não deve ser apresentado, sem ressalvas, como espelho completo de todos os especialistas que mantêm bancos, seguradoras, governos, indústrias, companhias aéreas e varejistas funcionando.

Porque muita gente essencial simplesmente não aparece nesse tipo de fotografia.

4. O especialista invisível também existe

O Champion, o Advocate e o criador de conteúdo geralmente são pessoas visíveis. Falam em eventos, escrevem, produzem vídeos, participam de comunidades, respondem dúvidas e compartilham conhecimento.

Isso é ótimo. É trabalho real. É generosidade profissional.

Mas o ecossistema mainframe também é formado por pessoas que nunca serão vistas em um palco.

Existe a especialista RACF de um banco que não pode falar publicamente sobre o ambiente. Existe o operador que conhece os sintomas de um incidente antes de o dashboard perceber. Existe a pessoa de storage que carrega na cabeça quarenta anos de decisões estranhas, datasets críticos e procedimentos de recovery que ninguém ousa testar numa segunda-feira.

Existe o programador COBOL que não publica artigo, não participa de rede social e talvez nem tenha foto no LinkedIn — mas sabe que alterar uma definição de copybook sem mapear os programas consumidores pode criar um pequeno apocalipse de produção.

Um processo de Champion seleciona muito bem quem demonstra advocacy visível. Não foi feito para ser um censo da força de trabalho técnica.

É como fazer uma seleção de grandes cozinheiros observando quem posta receitas no Instagram. Você encontrará gente excelente. Mas talvez nunca encontre a tia que alimenta 200 pessoas numa festa de família e sabe exatamente quando o feijão vai queimar sem olhar a panela.

A vitrine pode ser bonita. Mas não é o estoque inteiro.

5. “Atos de advocacy”: quando uma unidade mede muitas coisas diferentes

Agora vamos ao segundo suspeito: o contador de “atos”.

Um programa pode registrar como advocacy:

  • criar um perfil;

  • compartilhar uma publicação;

  • divulgar um evento;

  • assistir ou participar de uma sessão;

  • escrever um artigo;

  • publicar vídeo;

  • dar palestra;

  • mentorar alguém;

  • testar beta;

  • participar de conselho técnico;

  • contribuir para open source;

  • produzir material educacional.

Tudo isso pode ter valor. Mas não é a mesma coisa.

Não se mede o mesmo impacto quando alguém:

  1. preenche o perfil;

  2. compartilha o convite para um evento;

  3. escreve um tutorial que ajuda 500 iniciantes a entender JCL;

  4. testa uma função de produto e encontra um problema antes de ele chegar ao cliente;

  5. orienta um aluno que depois consegue seu primeiro emprego na área.

Misturar tudo em um contador único é útil para gamificação. Ajuda a motivar participação, distribuir badges e criar uma sensação de movimento.

Mas não basta para afirmar que a capacidade técnica do ecossistema aumentou.

No jargão Bellacosa, é como somar SUBMIT, RC=0, RC=8, ABEND, RESTART, CANCEL e PURGE em uma métrica chamada “eventos do batch” e depois concluir: “A produção foi muito ativa esta semana.”

Foi ativa? Possivelmente.

Foi saudável? Ninguém sabe.

Foi útil? Depende.

Foi melhor do que a semana anterior? Cadê os dados?

6. Alcance, participação, contribuição e impacto não são sinônimos

Esta é uma das lições mais importantes para qualquer pessoa que trabalha com comunidade, educação ou tecnologia.

CamadaPergunta certa
AlcanceQuantas pessoas tiveram contato com o conteúdo?
ParticipaçãoQuantas voltaram e interagiram?
ContribuiçãoQuantas produziram algo útil para outras pessoas?
AprendizagemQuantas desenvolveram conhecimento verificável?
ResultadoQuantas aplicaram isso no trabalho, carreira ou produto?
ImpactoO que melhorou de forma mensurável no ecossistema?

Uma live com 50 mil visualizações é alcance.

Um grupo com 1.500 membros é comunidade potencial.

400 pessoas registrando atividades é participação.

Um artigo técnico, uma palestra ou uma mentoria podem ser contribuição.

Uma pessoa que conclui uma trilha e entende o assunto demonstra aprendizagem.

Uma pessoa que entra em uma função, ajuda a manter um ambiente, reduz um incidente ou substitui conhecimento que estava indo embora com uma aposentadoria demonstra resultado.

O “skills gap” não é fechado no momento em que alguém ganha um badge. Ele começa a ser fechado quando uma organização ganha capacidade técnica sustentável.

E isso é difícil de medir. Muito mais difícil do que contar visualizações ou pontos.

7. O caso Bellacosa: aqui a fotografia muda

Agora entra uma evidência prática de como advocacy pode ser mais profundo do que uma campanha trimestral.

Um educador técnico que mantém aproximadamente 50 mil seguidores somados em LinkedIn, YouTube, X/Twitter, Instagram, Blogspot, WhatsApp, Telegram e Facebook possui alcance potencial. Isso, sozinho, não significa 50 mil especialistas IBM Z — e seria desonesto dizer que significa.

Mas o alcance não está sozinho.

Há milhares de postagens, dezenas de vídeos, um blog com conteúdo técnico acessível a qualquer hora, histórias de CPD, explicações de COBOL, CICS, Db2, JCL, VSAM, RACF e z/OS, além de uma narrativa que não trata o mainframe como relíquia empoeirada nem como panfleto corporativo.

Há também ensino formal.

Desde 2022, mais de 500 alunos passaram por aulas de pós-graduação e cursos livres no INEFE. Como SME em um programa IBM Brasil, há atuação direta com um público estimado em aproximadamente 100 profissionais e clientes — estimativa honesta, pois o consolidado oficial não foi disponibilizado pela IBM.

Somam-se 60 horas de webaulas ao vivo, 30 horas de conteúdo gravado e materiais de apoio criados para os alunos.

Isso é uma diferença enorme.

Uma postagem pode ser vista e esquecida.

Uma aula ao vivo permite dúvida, contexto, conversa, correção de rota e aquele momento em que alguém finalmente entende por que DISP=(NEW,CATLG,DELETE) não é feitiçaria, mas também não é coisa para copiar sem pensar.

Uma aula gravada é ainda mais interessante: ela transforma horas de professor em capacidade educacional reutilizável.

O professor deixa de ser apenas uma CPU atendendo uma turma em tempo real e passa a criar uma espécie de “batch educacional”: o conteúdo continua processando novos alunos mesmo quando a aula original já acabou.

Clouseau chamaria isso de “automação pedagógica de alto risco”, derrubaria a câmera e depois ficaria satisfeito com a definição.

8. O poder do português: a porta de entrada que muita gente esquece

A maior vantagem desse modelo está na língua portuguesa.

Para quem está começando, mainframe já chega com uma coleção de barreiras:

  • conceitos antigos e profundamente técnicos;

  • documentação extensa;

  • inglês técnico;

  • siglas em toda frase;

  • ferramentas que parecem menos amigáveis que um terminal de aeroporto dos anos 1980;

  • histórias de produção que assustam mais do que animam;

  • a sensação de que tudo é “para gente que já nasceu sabendo”.

Se o aluno precisa primeiro vencer o inglês técnico para depois descobrir o que é um dataset, o funil fica cruel:

ingleˆs teˊcnicoentendimento da documentac¸a˜oentendimento de mainframe\text{inglês técnico} \rightarrow \text{entendimento da documentação} \rightarrow \text{entendimento de mainframe}

Quando alguém explica em português, com analogias, exemplos, humor e contexto local, o caminho fica mais humano:

entendimento inicial em portugueˆsconfianc¸avocabulaˊrio teˊcnicodocumentac¸a˜o oficial em ingleˆsautonomia\text{entendimento inicial em português} \rightarrow \text{confiança} \rightarrow \text{vocabulário técnico} \rightarrow \text{documentação oficial em inglês} \rightarrow \text{autonomia}

A meta não é substituir a documentação IBM. Ela continua fundamental. Mensagens de erro, manuais, Redbooks, documentação de produto, certificações e debates globais continuarão usando muito inglês.

A meta é evitar que o inglês seja uma catraca na entrada.

Uma pessoa pode começar entendendo em português por que um S0C7 acontece, por que um VSAM tem organização própria, por que um RC=8 não é necessariamente fim do mundo e por que RACF não foi colocado ali apenas para irritar desenvolvedores.

Depois, com confiança, ela lê o manual oficial e reconhece os conceitos. A língua deixa de ser muro e vira ferramenta.

9. Como provar impacto sem cair na própria armadilha do denominador

Aqui vem a parte prática.

Se você quer demonstrar impacto em uma candidatura Champion 2027, não precisa alegar que representa todo o mainframe brasileiro. Nem precisa transformar seguidor em aluno, aluno em profissional e profissional em “caso de sucesso” sem evidência.

O caminho mais forte é montar um dossiê honesto, com números em camadas.

Passo 1 — Registre alcance

Anote os números por canal:

  • seguidores;

  • visualizações;

  • alcance mensal;

  • acessos do blog;

  • vídeos publicados;

  • artigos produzidos;

  • crescimento ao longo do ano.

Mas não pare aí. Alcance é a porta, não a casa.

Passo 2 — Registre participação educacional

Aqui entram os dados que já possuem muito peso:

  • mais de 500 alunos no INEFE desde 2022;

  • aproximadamente 100 participantes e clientes no programa IBM Brasil, como estimativa;

  • 60 horas de aulas ao vivo;

  • 30 horas de aulas gravadas;

  • materiais de apoio produzidos;

  • assuntos cobertos;

  • turmas e períodos de atuação.

Isso já permite dizer algo muito mais sólido que “publiquei bastante”.

Passo 3 — Separe conteúdo de transformação

Tente guardar mensagens e evidências, sempre respeitando a privacidade dos alunos, de pessoas que digam coisas como:

  • “Comecei a estudar COBOL depois do seu artigo.”

  • “Entendi JCL depois da sua aula.”

  • “Usei seu material para me preparar para uma entrevista.”

  • “Consegui concluir uma trilha.”

  • “Entrei em estágio, projeto ou função relacionada.”

  • “Passei a entender melhor o ambiente da empresa.”

Não é preciso fabricar grandes histórias heroicas. Cinco depoimentos concretos e autorizados podem valer mais que cem frases genéricas de “conteúdo incrível”.

Passo 4 — Mostre permanência

O conteúdo público, especialmente no blog, possui uma qualidade que a campanha momentânea não tem: ele permanece.

Um artigo sobre Db2 publicado hoje pode ser encontrado por alguém daqui a dois anos. Uma explicação sobre GDG pode salvar uma tarde de estudo. Uma história sobre CPD pode fazer o estudante perceber que mainframe não é uma tecnologia morta, mas uma infraestrutura com memória, responsabilidade e consequências reais.

O seu acervo é patrimônio educacional em construção.

Passo 5 — Conte a história com precisão

Uma apresentação forte para Champion 2026 poderia dizer:

Desde 2022, atuo na formação de profissionais em mainframe e tecnologias IBM, alcançando mais de 500 alunos em programas de pós-graduação e cursos livres no INEFE. Como Subject Matter Expert em iniciativa da IBM Brasil, contribuí com aproximadamente 60 horas de webaulas ao vivo, 30 horas de conteúdo gravado e materiais de apoio para um público estimado em cerca de 100 profissionais e clientes.

Paralelamente, mantenho uma presença educacional independente em português, com aproximadamente 50 mil seguidores somados em múltiplos canais, milhares de publicações e dezenas de vídeos. Meu trabalho reduz a barreira inicial do inglês técnico e torna conceitos de IBM Z, COBOL, z/OS, CICS, Db2, JCL, RACF, VSAM e operação mais acessíveis a estudantes e profissionais brasileiros.

Meu objetivo é criar uma ponte sustentável entre a experiência prática acumulada no mainframe e a próxima geração de profissionais que precisará manter, modernizar e evoluir essas plataformas.

Isso não é fumaça de marketing. É um caso documentável.

10. Easter egg: a pergunta que Clouseau finalmente acertou

No final da investigação, o Inspetor Clouseau encontra uma sala cheia de dashboards, badges e gráficos com setas apontando para cima.

Ele olha para o responsável e pergunta:

“Então vocês têm 1.000 atos de advocacy?”

“Sim, inspetor!”

“E quantas pessoas aprenderam algo que conseguem usar?”

“Bem…”

“E quantas entraram no mercado?”

“Bem…”

“E quantas continuam na área um ano depois?”

Silêncio.

Clouseau sorri, esbarra no cabo do projetor, apaga a apresentação inteira e diz:

“Aha! O criminoso não era o número. Era a conclusão que ele estava tentando esconder.”

É essa a lição.

Advocacy não é quantidade de posts, badges ou palmas. É capacidade de abrir portas, explicar o que parecia impossível, dar contexto, criar confiança e ajudar alguém a avançar.

Quando isso acontece em português, com conteúdo público, ensino estruturado, experiência prática e continuidade, o impacto deixa de caber em um leaderboard.

Ele aparece no aluno que entende.

E, anos depois, talvez apareça no profissional que está diante de uma tela verde às duas da manhã, vê um RC=8, respira fundo e pensa:

“Calma. Eu sei por onde começar.”

Nesse momento, sem foguete, sem confete e sem precisar de outra medalha digital, o ecossistema ficou um pouco mais forte.




☕ Gostou deste café?
Siga o Bellacosa Mainframe e acompanhe os próximos artigos.
SEGUIR O BLOG

Sem comentários:

Enviar um comentário

De Fã para Fã. Conteúdo não oficial produzido como homenagem, comentário, análise ou paródia. Personagens, marcas e obras eventualmente mencionados pertencem aos seus respectivos titulares.
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...