Acabo de ler “Please, don’t just do what I tell you! Do what needs to be done” e recomendo.

Como profissional eu sempre tento ser pró-ativo, procuro me envolver em projetos complicados que ninguém tem interesse e procuro dar o máximo de mim em todas as situações. Até o momento tenho sido bem sucedido com essa abordagem, mas pela primeira vez achei um livro que reflete exatamente como me comporto. E aparentemente estou no caminho certo.

Não sei a experiência de vocês, mas algo que me incomoda muito é ver uma coisa sendo feita de um jeito defeituoso, complicado,  caro, complexo ou demorado demais só porque sempre foi feito daquela forma. E ninguém nunca toma a iniciativa de resolver aquele problema.

Ah, meu amigo… Na minha mão essas coisas não duram não.

Eu gosto muito de aprender pelo exemplo dos outros e caso alguém ai também goste vão aqui dois exemplos de coisas simples que eu fiz no  passado que fizeram uma imensa diferença profissional no futuro.

A primeira foi num banco onde trabalhei. No meu segundo dia lá o sujeito que eu estava substituindo apareceu para assinar uns papéis no RH e veio conversar comigo. Falou que o principal sistema do banco (Java-based) rodava em um servidor lá num canto do CPD e que ele caia pelo menos 2 vezes por dia. Minha principal responsabilidade na empresa seria ficar de ouvido e assim que alguém gritar que o sistema caiu sair correndo, entrar na sala dos servidores e rodar uma série de uns 10 comandos no shell para restaurar o sistema.

Dito e feito, naquele mesmo dia antes do final do expediente caiu o maldito e toca eu correr pra arrumar. Eu nem sabia o que estava fazendo, só sei que tinha uma série de comandos a serem executados. Mas ali mesmo já fiz uma melhoria. O cara digitava todos os comandos, demorando uns 2 ou 3 minutos para recuperar o sistema. Eu comecei só apertando flecha pra cima e usando o history. Já abaixei pra um minuto, mas ainda não tinha idéia do que rolava. Nem sabia que raios era aquilo.

Depois de um mês mais ou menos de casa (e muitas corridas minhas e dos meus colegas pra dentro do CPD) eu comecei a entender. A aplicação feita em Java rodava em um container proprietário. Um container que o banco pagou uma fortuna para ter. E era uma versão com uns 4 ou 5 anos de idade, cheio de bug.

Comecei a fazer amizade com o pessoal de desenvolvimento e descobri que como ambiente de desenvolvimento cada um rodava uma instância de Tomcat no seu próprio desktop e que nenhum deles tinha os problemas que apareciam em produção.

Lógico que cheguei pro meu chefe e sugeri migrar para Tomcat. E lógico que a resposta foi não.

Bom… ai entrei no modo black-ops e sorrateiramente instalei o Tomcat no servidor, mas numa porta alternativa e deixei rodando, sem ninguém acessando, por uns 2 ou 3 dias. Depois conversei com uns usuários que trabalhavam no meu andar e alterei o bookmark deles para acessar a minha instância do Tomcat por padrão ao invés do default. E eles rodaram felizes e sem quedas por mais de semana.

Nisso eu já me preparei, arrumei uns scripts num canto e numa segunda-feira assim que o sistema default caiu eu subi o Tomcat no lugar dele. Sem dó nem piedade.

Ao invés de cair 2 vezes por dia o sistema passou a cair só 2 vezes por semana. Rodando mais rápido e bem mais confiável. E eu quieto.

Com quase um mês com a coisa rodando eu chego pro meu chefe e falo: Reparou que o sistema parou de cair? Viu como está mais rápido? (Alguns usuários tinham até elogiado). Pois é. Instalei o Tomcat.

Fui elogiado e reconhecido apesar de ter desobedecido ordens pois resolvi um problema enorme da empresa sem nenhum custo e excelente resultado. Fiz o que precisava ser feito no melhor interesse da empresa e de mim mesmo, afinal não sou bombeiro para sair apagando incêndio.

Quase um ano depois acabei também descobrindo porque raios o sistema ainda caia uma ou duas vezes por semana: O servidor era um hardware RISC cuja última versão de Java disponível era 1.3 e os programadores estavam desenvolvendo o sistema em Java 1.4. Quando algumas rotinas eram chamadas elas simplesmente abendavam o container. (Não lembro ao certo os números das versões, mas era algo assim).

A segunda história foi quando eu trabalhava no meu primeiro emprego numa mega-empresa sendo recurso dedicado para um cliente que era outra mega-empresa.

Nosso time de brasileiros foi contratado para substituir um time de americanos. A gente custava menos de 1/4 do que eles custavam então rolou um outsource.

Parte de nossas atividades era uma vez por mês fazer um relatório de capacity planning para as localidades pelas quais éramos responsáveis e apresentar para os administradores dessas localidades.

Para fazer isso tínhamos uma planilha excel onde importávamos gráficos do Orion de cada localidade. Eram uns 4 ou 6 gráficos para cada localidade, umas 20 ou mais localidades para cada um dos 10 membros do time.  Eram umas 4 horas de trabalho gerar a planilha. Um total de 40 horas-homem cada mês só pra preparar o relatório.

Depois de uns 3 ou 4 meses fazendo esse treco eu cansei. Trabalho duro e chato demais. Não é possível que não tivesse um forma melhor de fazer aquilo.

Gastei então 2 dias inteiros (16 horas/homem) aprendendo como fazer macros em Excel e fiz um script que era capaz de gerar todos os gráficos sozinho, conectando no Orion e puxando o que fosse necessário. Arrumando fontes, cores, tudo do jeito que o povo estava acostumado.

Joguei na mão do meu time e todo mundo adorou. Criar o report então passou a ser uma atividade de 15 minutos (2.5 horas-homem/mês).

Isso, juntamente com outras inovações que o time trouxe em relação ao que os americanos faziam, nos renderam um prêmio e mais tarde eu consegui ser transferido para um outro departamento para onde eu sempre quis ir, exclusivamente dedicado a projetos.

Em nenhum dos dois casos ninguém me pediu para fazer nada. Não fazia parte das minhas atividades normais e, potencialmente poderiam até me prejudicar (quem sabe demitido no primeiro por desobedecer o chefe ou despedido no segundo por não ser mais necessário).

Eu já trabalhei com pessoas que pensam que não devem automatizar procedimentos pois não poderão mais justificar sua presença “se não tiverem o que fazer”. Outras não criam documentação nem procedimentos na esperança de se tornarem insubstituíveis.

Na minha humilde opinião qualquer trabalho que possa ser automatizado não vale a pena ser feito manualmente logo de cara. Se seu trabalho constitui-se apenas de coisas de um script poderia fazer melhor e mais rápido do que você faz seria uma boa idéia começar a procurar um novo emprego. Eu já fiz isso e não me arrependi. Automatizei todas as minha tarefas e pedi demissão. Todo mundo ficou feliz. Meu ex-chefe e eu.

E no segundo caso comento duas coisas:

  • Ninguém é insubstituível.
  • Quem é quase insubstituível é 100% impromovível.

Se você não tem uma atitude profissional do tipo “faça o que tem que ser feito” leia o livro e pense na sua carreira.