Especializar-se ou não?

Conversava em uma roda de amigos outro dia, quando surgiu o tema "especializar-se ou não?". Debatemos por cerca de meia hora e não chegamos a uma resposta à questão. Porém, tiramos algumas conclusões que compartilho aqui com vocês:

Especialização x Retorno financeiro

A especialização normalmente aumenta o retorno financeiro do profissional. Mas isto ocorre à médio-longo prazo. Um cuidado que se deve tomar é estudar o 'teto' de remuneração do segmento. Algumas vezes um especialista no segmento A tem uma remuneração de 'profissional pleno' em um segmento B. O tempo para chegar-se ao 'teto' também deve ser levado em consideração.

Especialização x Empregabilidade

Eis um aspecto que deve ser especialmente estudado: Empregabilidade. Uma opção é avaliar a densidade demográfica da carreira.
Por exemplo:

• Para suportar um grupo hipotético de 20 desenvolvedores, há 1 administrador de banco de dados (DBA), 3 analistas de sistemas, 1 analista de suporte, 3 analistas de testes. Analisando a situação demonstrada, pode-se optar pela carreira de desenvolvimento que garante uma melhor empregabilidade, porém a rentabilidade não é igual à de um DBA

Sendo assim, avaliar a empregabilidade é um aspecto importante a ser considerado na hora de fazer a opção pela especialização.
O estudo 'empregabilidade x especialização' tem dois aspectos distintos:

1. Um especialista está mais preparado para enfrentar os desafios de sua área de atuação. Este fator aumenta a empregabilidade do especialista.
2. Um especialista é mais 'caro' do que um profissional generalista e nem sempre as organizações estão dispostas a pagar pela especialização. Seja pela natureza de seu negócio, urgência ou capacidade financeira. Este fator diminui a empregabilidade do especialista.

Capacitação

Tornar-se especialista em um determinado segmento custa tempo, dinheiro e dedicação. Cada segmento determinará o quanto de cada um destes elementos será necessário. É importante pensar neste aspecto antes da opção.
Uma área A pode exigir apenas 1 ano para que o profissional torne-se especialista, porém os treinamentos querem alta dedicação e custam alto.
Uma área B pode exigir 5 anos para a especialização, porém os custos seriam reduzidos e a dedicação seria diluída ao longo deste tempo.

Plano de contingência

Uma situação à que o especialista estará sujeito é a ausência de mercado. É preciso que o profissional que tenha um plano de contingência para esta situação. Neste plano de contingência o profissional deve considerar:

• Reserva financeira - O especialista deve ter uma reserva financeira para os tempos em que sua rentabilidade não esteja suprindo suas necessidades.
• Áreas afins - Em algumas situações o especialista pode considerar a troca de área de atuação, então é importante conhecer áreas afins, onde seu conhecimento acumulado será aproveitado.
• Localização geográfica - Profissionais especialistas em alguns ramos de negócio. Devem considerar a localização geográfica de seu mercado. Em alguma cidades, há grande concentração de Instituições Financeira em outras, há Telecom, Siderurgia, Metalurgia e por aí vai...

Afinidade com a área escolhida

É preciso que o profissional tenha afinidade com a área em que deseja especializar-se, afinal de contas, a especialização é uma espécie de casamento. Ter prazer em desempenhar certa atividade pode ser um fator de sucesso e um importante diferencial, além de minimizar o risco por um eventual arrependimento.


Bem pessoal, este tema é muito controverso e particular. Vejam que aqui não entramos no mérito do "Vale a pena?". Apenas enumeramos aspectos a serem considerados na hora da decisão pela especialização. Em matéria de especialização, conheço diversos casos de sucesso e alguns de fracasso. É importante frisar que não conheço nenhum fracasso "total". Há sempre uma válvula de escape que permite que o profissional não vá ao fundo do poço. Também é importante ressaltar que nenhuma história de sucesso foi construída sem talento, dedicação, suor e aquela pitada de sorte...

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!”.