Há vida lá fora?

Pergunte a qualquer profissional de TI com mais de dois anos de experiência se, em algum momento, sua vida pessoal foi sacrificada em detrimento de seu ofício. Tenho absoluta certeza de que em pelo menos 90% dos casos a resposta será afirmativa. É óbvio que esta situação não é exclusividade de nossa amada profissão, que o digam os médicos, advogados, jogadores de futebol e artistas, entre outros. Mas podemos fazer algo no sentido de minimizar o impacto causado pelas horas extras, viradas de noite e fins de semana gastos em prol do trabalho?

Muitas pessoas, quando idealizam o desejo de trabalhar em TI não têm a real noção de certos sacrifícios inerentes à profissão. Plantões, horas extras e sobre-avisos são atividades requeridas com certa freqüência seja no segmento de suporte/infra-estrutura, operação ou desenvolvimento de sistemas. Algumas pessoas ao se depararem com este cenário desestimulam-se e às vezes perdem até mesmo o encanto com a profissão. Entender as razões que nos levam a estarmos praticamente “full time” disponíveis à nossos cliente pode ser um passo para administrarmos melhor esta situação.

Na sociedade da informação, a TI uma vez utilizada torna-se essencial. Uma falha de rede, um “abend” no processamento noturno ou a indisponibilidade de um site podem representar prejuízos inestimáveis que vão desde o aspecto financeiro até a imagem pública das organizações. A velocidade com que os produtos são criados e disponibilizados (ou “Time to market” - TTM) por uma organização pode ser o grande diferencial de um líder de mercado em seu segmento; e a TI, muitas vezes, é o habilitador deste processo. Neste cenário, somos submetidos, várias vezes, à condições extremas de trabalho visando a redução de impactos ou a maximização do lucro.

Podemos e devemos sugerir ações visando diminuição destas situações extremas. Algumas delas requerem algum investimento por parte das organizações, mas o nosso papel é demonstrar que os benefícios vão além do bem-estar dos profissionais (que por si só é um grande argumento). Para a infra-estrutura, por exemplo, trabalhar com redundância de servidores com parte de um plano de contingência é uma prática que apresenta ótimos resultados. Para o desenvolvimento de produtos, o estabelecimento de um acordo de nível de serviço razoável, um sólido levantamento de requisitos e a priorização do portfólio de projetos pelo cliente, alinhado à capacidade de produção são ações que podem minimizar situações em que a equipe é sobrecarregada.

É claro que as ações aqui citadas passam por decisões do corpo executivo ou gerencial das organizações, porém nossa tarefa é propor mudanças e apresentar os benefícios destas iniciativas. Ser a mola matriz deste processo de mudança de mentalidade e atitude é um papel que cabe à todos os profissionais. Vale ressaltar que a pretensão aqui não é extinguir horas extras, plantões e etc., porém quando estas situações são planejadas e controladas, os impactos são muito menores para todos os envolvidos: profissionais, clientes e organizações.

E o COBOL?

O surgimento do COBOL (COmmon Business Oriented Language) confunde-se com a invenção das linguagens de programação de terceira geração (estruturadas) e, sem dúvidas, sua invenção foi um dos projetos mais bem sucedidos do que se tem notícia, liderado por Grace Murray Hopper (e dizem que mulheres não têm talento para desenvolver software...). Desde o início da década de 90, pelo menos, o fim do COBOL é anunciado pelos arautos da inovação. Porém o COBOL, indiferente e imponente (por que não!?) continua na cena. Firme e forte. Liderando com sobras o segmento de ferramenta de desenvolvimento de software para instituições financeiras em geral. Então, o que faz com que este quase “cinqüentão” tenha tanta longevidade?

Primeiramente, consideremos o cenário que impulsionou a criação deste mito: o COBOL foi idealizado e projetado por um comitê (CODASYL) que envolvia fabricantes de computadores e órgãos governamentais americanos. O propósito do comitê era construir uma linguagem para resolver problemas específicos, “orientada a negócios” como o próprio nome diz. Antes de dar início ao seu desenvolvimento, as linhas gerais do projeto foram traçadas e debatidas pelos envolvidos e este assunto foi esgotado. O tempo de desenvolvimento do projeto foi de 6 meses. Em seguida, analisemos os pilares sobre os quais o COBOL foi construído: confiabilidade, desempenho, escalabilidade, estabilidade e proximidade com a linguagem natural (3GL). O que talvez o torne a ferramenta ideal para o desenvolvimento de softwares voltados ao sistema financeiro é sua capacidade de trabalhar com números extremamente grandes e sua alta performance, frente às outras linguagens disponíveis no mercado. Até os dias atuais o COBOL já viu diversas linguagens de sua geração e de gerações mais recentes como BASIC, Clipper, FORTRAN, VB, Delphi, entre outras nascerem, ficarem obsoletas e cair em desuso. É claro que algumas destas visavam outro segmento de software, porém o absolutismo com o qual o COBOL reina por tanto tempo é algo sem precedentes.

Sendo tão aceito pelo mercado e tendo uma história tão consistente, por que seu fim já foi anunciado tantas vezes? Por que há de profissionais capacitados no mercado? Por que as faculdades não ensinam COBOL hoje em dia? Ora, TI é intrinsecamente ligada à inovação e um quase “cinqüentão” cuja última versão (estruturada) foi especificada em 1985 vai contra tudo isso. Os garotos de hoje se negam a aprender uma linguagem que de repente é dominada por seus pais. Uma linguagem em que é preciso “escrever” o programa ao invés de dar meia dúzia de cliques. Que mal há nisso? Pode ser o costume que nossa geração (anos 80) tem de estar mais inteirado a estes aspectos do que seus pais. Pode ser o interesse das empresas capitalistas em criar “novos produtos” (linguagens de programação) e os lançarem no mercado.

Enfim, o fato é que o COBOL está aí. É uma realidade e enganam-se os que prevêem ou planejam sua extinção. Como muitos profissionais relutam em admitir esta realidade, o mercado continua “pagando o preço” da falta de mão de obra sucumbindo à sua mais antiga lei: a da oferta versus procura. Não quero entrar nos aspectos que tangem à metodologia de desenvolvimento, coeficiente de produtividade, ambiente (sistema operacional) e outros. Tudo isso é periférico. O COBOL pode (e deve) ser adaptado às melhores práticas da engenharia de software. Parafraseando um antigo colega: “E viva o COBOL!”.

É hoje!!!

É hoje, pessoal!
Aproveitando a ociosidade durante um vôo em uma viajem de trabalho, esbocei um texto sobre mais um tema polêmico! Pretendo finalizá-lo e postá-lo ainda hoje.
Agora é um compromisso! Nem mesmo os gêmos (Bia e Caio) que andam me tirando o sono, literalmente, vão ser desculpa.
Teremos um texto novo aqui pelo menos uma vez por mês. Conto com a participação de vocês. Comentários, críticas e sugestões são sempre bem vindos.
Abraço!