Renovar a força de trabalho em COBOL pode ser mais difícil do que parece

A percepção do mercado de TI sobre os desafios enfrentados por grandes instalações que dependem fortemente do COBOL muitas vezes é marcada por equívocos tanto de análise quanto de solução.

Um deles, por exemplo, está associado à ideia de que é difícil ensinar uma linguagem procedural não orientada a objetos a uma geração que se formou com outro paradigma.

Mas o problema não é a linguagem

Como vivo repetindo por aqui, o COBOL não é difícil; tem suas particularidades, como a forma como os dados são estruturados e sua forma de interagir com o ambiente externo, mas qualquer programador consegue entender rapidamente que “a coisa tal tem que ser declarada na divisão tal” e “como funciona o comando EVALUATE”.

O desafio é fazer com que ele domine o stack, que assim como em outras plataformas, raramente é o mesmo em todas as organizações e todos os projetos.

Por stack, estou me referindo a TSO, ISPF/PDF, CICS, IMS/DB, IMS/DC, DB2, QMF, SPUFI, JCL, JES, VSAM, NATURAL, ADABAS, COMPLETE, EASYTRIEVE e tudo o mais que costumamos encontrar na plataforma Z da IBM… e também MCP, WFL, DMSII e outros, para não esquecer da plataforma Unisys.

Não dá para testar um programa teclando numa seta verde na barra de ferramenta do IDE. Você tem que alterar ou escrever um job, submeter esse job, aguardar alguns segundos para que o resultado esteja disponível, entrar no JES e buscar um dos “n” relatórios que o job gerou para ver se deu certo.

Mainframes são máquinas construídas com um propósito diferente dos tradicionais servidores x86. A maneira como seus diversos componentes conversam entre si é bem particular. No canal de Teoria, deste blog, tem um livrinho que explica como essas máquinas funcionam, quais são essas particularidades e para que servem cada uma das siglas que mencionei no parágrafo anterior.

O Linux é uma opção

Hoje existem soluções open source excelentes, como o GnuCOBOL, que viabilizam projetos de rehost com muita eficiência. Você pode migrar todo ou parte do seu portfólio de aplicações de um mainframe para um servidor Linux na núvem e reduzir significativamente o desafio-da-capacitação-da-nova-geração-ao-stack-dos-mainframes, com algumas vantagens:

• Uso de ferramentas com as quais a equipe está mais familiarizada, como Eclipse, VSCode, Git, Jenkins etc
• Ajustes da arquitetura monolítica original a novas abordagens que aumentam a agilidade do processo de desenvolvimento e manutenção, como containerização, CD/CI e DevOps…
• Integração mais fácil (e consequentemente mais barata) com outros protocolos de comunicação, como XML e JSON…

E tudo isso preservando boa parte do que se gastou, nas últimas décadas, com funcionalidade e regras de negócio, num processo muitas vezes menos arriscado que o redesign total da aplicação.

Mas essa solução, naturalmente, não é para todos. Em muitos casos (e isso explica boa parte da permanência dos sistemas legados por tanto tempo), segurança, disponibilidade, responsividade, performance e estabilidade são fatores que as grandes corporações simplesmente não podem arriscar, por mais encantadoras que sejam as promessas das novas tecnologias.

Como então formar toda uma nova geração de desenvolvedores do dia para a noite?

Primeiramente precisamos aceitar que não será do dia para a noite.

Houve um tempo, muitos se lembram, em que o aspirante a programador fazia um curso livre no CEOP ou no DataMeyer, por exemplo, e saía de lá com uma noção de codificação COBOL em papel (porque a fartura de computadores não era grande) e tendo ouvido falar sobre JCL e VSAM.

Quando conseguia um estágio, descobria que ele só tinha lido a capa e a contra-capa da bíblia, e entre as duas havia mais de 900 páginas que ainda precisavam ser lidas.

Sem o Google, esse aprendizado passava por três caminhos: (1) leitura obcecada de manuais do fabricante; (2) horas de tentativa e erro na frente do terminal; e (3) mentorização pelos profissionais mais experientes. E com isso um dia, quem sabe, nos dávamos conta de que já podíamos ser considerados “experientes”.

É verdade que o Google não oferece tanto conteúdo para o stack do mainframe quanto oferece para outras plataformas, mas manter 12 manuais abertos em cima da mesa não é mais necessário. Disposição para passar horas em tentativa e erro e sentir orgulho quando se consegue dar um pequeno passo adiante é um traço comum a qualquer desenvolvedor.

O que talvez esteja faltando é a mentorização correta.

E mentorização pode significar muita coisa

A solução para muitas empresas é simplesmente terceirizar o problema e acreditar que a empresas terceira terá mais facilidade do que ela própria para superar essas dificuldades. Uma questão muitas vezes mais de fé do que de planejamento estratégico.

Outras empresas, ainda, vêem o processo de mentorização como uma atividade de 30 dias ou menos, onde um profissional experiente apresentará alguns slides do PowerPoint para uma turma de programadores juniores.

Esses slides falam sobre princípios básicos da programação COBOL, apresentam uma rápida introdução sobre as demais ferramentas disponíveis e como são usadas na instalação e talvez alguns exercícios práticos em “laboratório” para que os mentorizados apliquem alguns dos conceitos adquiridos.

E na sequência, começa a expectativa mal disfarçada de que eles andarão com as próprias pernas e rapidamente terão a produtividade que o projeto espera.

Tem algo errado na premissa.

Outros caminhos

Talvez o caminho não seja acreditar num processo fast-track de formação de profissionais, e sim num processo contínuo orientado a pequenos desafios do dia a dia. Não ensinar como programar em COBOL, JCL, NATURAL ou EASYTRIEVE; não ensinar para que serve e como usar CICS, VSAM, e JES; mas possivelmente ensinar como o “sistema” como um todo funciona, tanto na sua dimensão funcional quanto na sua dimensão técnica.

Quem sabe (para usar uma expressão que entrou na moda) um squad fixo formado por um ou mais profissionais experientes que dominem (de verdade) o sistema e o stack sobre o qual foi ele foi construído somado a um grupo de desenvolvedores que vão aprender ao longo do tempo com pequenos desafios do dia a dia.

O “jovem programador X” não teve oportunidade de mexer com o CICS nesse minor-enhancement que concluímos esse mês, mas o “jovem programador Y” sim, e fez isso com o profissional experiente ao seu lado dizendo que comandos executar e explicando o que estava acontecendo.

Os desafios são principalmente dois, como você já percebeu:

1. Seria um modelo muito parecido com o que nos anos 1980 e 1990 chamávamos de “igrejinha”, onde cada equipe tomava conta só da sua própria paróquia.
2. Quem serão os mentores? Numa realidade onde provavelmente o seu profissional mais experiente não teve oportunidade de se aprofundar na plataforma, quem vai ser a pessoa que vai sentar ao lado do junior para mostrar-lhe como calcular um off-set com base no DITTO? Ou explicar porque o programa que ele acabou de submeter derrubou o CICS?

Seguramente a área de atuação desses squads teria que ser expandida, para que eles possam atingir o equilíbrio entre conhecimento e sinergia.

Mas o mais importante é garantir a “disponibilidade da experiência” para a equipe em formação. Ter um só profissional especialista em VSAM para dar consultoria para toda a instalação é praticamente deixar os squads por conta própria. Só vai funcionar se os especialistas forem os responsáveis técnicos pela entrega de cada enhancement e puderem participar de todas as decisões, discussões e dificuldades enfrentadas pela equipe.

Conclusão

Deixar tudo como está e esperar (de novo) que em mais vinte anos esse problema não existirá não me parece a melhor solução. Deu errado no final dos anos 1990, e tem grande chance de não dar certo de novo.

As ações de modernização radical, reescrevendo tudo em outra plataforma, já demonstraram que podem dar bons resultados com sistemas satélites, mas trazem custos e riscos preocupantes quando falamos de sistemas core.

Por outro lado, sabemos que não é possível voltar à era das “igrejinhas”. Não dá para pagar conhecimento e produtividade com a moeda da capacidade ociosa. TI é um negócio como outro qualquer. Precisa dar lucro para alguns e reduzir o custo para outros. E não tem nada de errado nisso.

A solução, seguramente, está em algum caminho do meio.

---