Capítulo 4 de 7
Automatizar antes de a palavra virar moda
Nos anos 1990, muitas tarefas administrativas em computadores e redes exigiam repetir os mesmos passos: copiar arquivos, preparar diretórios, iniciar programas, mapear recursos compartilhados e executar rotinas de manutenção. Eram atividades necessárias, mas que consumiam tempo e atenção de quem as realizava.
Foi nesse contexto que comecei a utilizar scripts BATCH, levando para o trabalho os conhecimentos de programação adquiridos no curso de COBOL e nos estudos de processamento de dados. Aquela formação me ajudava a olhar para uma tarefa, entender sua lógica e organizar os passos necessários para executá-la.
Antes de escrever os comandos, era preciso compreender o problema. Quais informações seriam utilizadas? O que deveria acontecer primeiro? Que condições poderiam mudar o resultado? Esse raciocínio dava sentido ao código e ajudava a transformar uma necessidade do dia a dia em uma solução prática.
Uma base construída com estudo e prática
Os livros de programação e algoritmos também fizeram parte desse aprendizado. Entre as referências estavam Algoritmos e Estruturas de Dados, de Angelo Moura e Newton Castilho, e a obra de Valdemar W. Setzer, ligada ao ensino de programação e aos fundamentos da computação.
Esses estudos ajudaram a desenvolver uma maneira de pensar: dividir problemas em partes menores, organizar informações, estabelecer uma sequência lógica e conferir se o resultado correspondia ao que se esperava.
Ao aplicar essa base aos scripts BATCH, eu conseguia aproximar o conhecimento de programação das necessidades de quem utilizava os computadores. Uma sequência de comandos podia facilitar uma configuração, reduzir tarefas manuais e tornar mais simples uma rotina que precisava ser repetida em várias máquinas.
O valor estava na solução
Um arquivo BAT não precisava ser sofisticado para ser útil. Muitas vezes, seu valor estava em executar de maneira previsível uma tarefa que antes dependia de alguém lembrar cada etapa.
O script registrava a sequência, reduzia esquecimentos e ajudava a padronizar o trabalho. Para quem precisava preparar uma estação ou prestar um atendimento, isso significava menos retrabalho e mais tempo para cuidar de outros problemas.
Era uma aplicação direta do que eu havia aprendido: observar uma necessidade, organizar uma solução e verificar se ela funcionava nas condições reais de uso.
Automação de estações e rotinas de rede
Com o crescimento dos ambientes, os scripts passaram a apoiar tarefas como preparação de estações, cópia de arquivos, inicialização de aplicações, rotinas de backup e acesso a recursos compartilhados.
As limitações das ferramentas exigiam cuidado. Um diretório inexistente, um arquivo ausente ou um recurso de rede indisponível podia interromper a sequência ou produzir um resultado diferente do esperado.
Por isso, automatizar também envolvia pensar nas situações em que alguma coisa poderia dar errado. A lógica aprendida nos estudos de programação ajudava justamente nesse ponto: considerar as condições de execução, prever desvios e conferir os resultados.
Sistemas começaram a conversar entre si
Com a expansão da web e das interfaces de integração, essa lógica ganhou novas possibilidades. A automação passou a conectar aplicações e a acompanhar etapas inteiras de uma operação.
As APIs permitiram que um sistema consultasse ou atualizasse informações em outro. Os webhooks trouxeram a possibilidade de reagir a acontecimentos, como a aprovação de um pagamento ou o recebimento de uma solicitação, sem depender de alguém verificar tudo manualmente.
Tecnologias como PHP e Node.js passaram a fazer parte desses cenários. As ferramentas mudaram, mas a base continuou familiar: compreender o processo, organizar suas etapas e tratar as informações com cuidado.
Automação sem controle também automatiza erros
Quanto maior o alcance de uma automação, maior a responsabilidade de quem a desenvolve. Uma falha pode se repetir rapidamente e afetar diferentes sistemas.
É preciso controlar acessos, validar dados, registrar o que aconteceu e definir como agir quando um serviço externo demora ou deixa de responder. Também é necessário evitar que uma mesma solicitação, recebida mais de uma vez, gere operações duplicadas.
A distância tecnológica entre esses processos e um arquivo BAT dos anos 1990 é grande. Ainda assim, permanece uma preocupação que acompanha meu trabalho desde aquela época: fazer a sequência funcionar corretamente e conseguir entender o que aconteceu quando o resultado não é o esperado.
Do comando repetido ao fluxo de negócio
Hoje, automatizar pode envolver a integração de sistemas, a geração de documentos, a sincronização de cadastros ou a eliminação da redigitação de informações.
Quando olho para esse caminho, reconheço a contribuição daquela formação em COBOL e processamento de dados, dos livros e da experiência prática. Essa base continua presente na maneira como analiso problemas e construo soluções.
Para mim, automatizar é transformar conhecimento sobre uma rotina em um processo consistente, que possa ser acompanhado e melhorado. Dos scripts BATCH às APIs e aos webhooks, o propósito permanece: aliviar o trabalho repetitivo e permitir que as pessoas dediquem mais tempo ao que exige atenção, análise e decisão.