quinta-feira, 19 de março de 2009

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

sexta-feira, 12 de dezembro de 2008

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.

terça-feira, 1 de julho de 2008

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

segunda-feira, 30 de junho de 2008

É 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!

domingo, 19 de agosto de 2007

Cultura organizacional - um processo chave para a Terceirização dos serviços de TI

Quando a Tecnologia da Informação (TI) não é a atividade fim de uma organização, ou seja, não gera lucro direto por si só, surgem algumas questões: o valor gasto em recursos e serviços de TI é justo? Existem meios para a diminuição do gasto em TI sem perda da qualidade dos serviços oferecidos? O quanto é vantajoso ou importante para a organização deter todo o "know-how" dos serviços de TI? Atualmente muitas organizações adotam a terceirização (de todos ou parte dos serviços) como meio para reduzir os gastos em recursos e serviços de TI. O que pretendemos refletir aqui é: a terceirização dos serviços de TI por si só diminui o custo total de posse (TCO)?

Analisar os fatores que fazem parte deste cenário não é simples e por isto mesmo, uma organização não pode optar por esta solução apenas por ser uma tendência de mercado ou porque é o comportamento adotado por seus concorrentes ou organizações do mesmo segmento. É preciso que se faça uma análise complexa e profunda do papel da TI na organização, dos riscos associados à terceirização, da existência de fornecedores competentes no mercado e de um fator determinante: da cultura organizacional.

Na era da informação, já é sabido e aceito que o maior ativo de uma organização é o conhecimento. Um dos riscos inerentes à terceirização é justamente a capacidade de retenção de conhecimento da organização. Muitos processos de terceirização fracassam quando uma organização torna-se "refém" de um fornecedor por falta de conhecimento sobre o próprio negócio. É uma questão delicada e que tem uma linha tênue como fronteira. De um lado, o fornecedor precisa conhecer os negócios, processos e produtos de seu cliente para que o serviço prestado tenha a qualidade acordada. De outro, o cliente precisa saber passar as informações necessárias para seu fornecedor sem trasnferir, por exemplo, o processo decisório (em qualquer nível) ao seu fornecedor.

A falta desta consciência na organização (em todos os setores e, principalmente, nos que estarão em contato direto com os fornecedores) é um dos fatores que podem levar um processo de terceirização ao fracasso. É muito importante que as pessoas não enxerguem o fornecedor como uma ameaça à sua estabilidade ou ao seu emprego e sim como um parceiro que o ajudará a fornecer um determinado serviço aos seus clientes internos. Também é muito importante que o fornecedor saiba ganhar a confiança de seus clientes portando-se como um parceiro, efetivamente. Entre a opção pela terceirização e a contratação dos fornecedores é preciso que a organização passe por um processo de alinhamento de expectativas e de papéis/responsabilidades. As pessoas que estarão em contato com fornecedores precisam saber como elas se encaixarão no novo modelo de trabalho, até onde elas devem atuar, a partir de quando devem delegar, como fazer uma solicitação e como cobrar os resultados.

O fator "cultura organizacional" é chave para o sucesso de um processo de terceirização. Caso a organização não esteja pronta para lidar com a terceirização, o efeito pode ser exatamente o oposto do desejado. Por outro lado, organizações devidamente preparadas para lidar com a terceirização aumentam consideravelmente suas chances de alcançar os objetivos determinados. Desta forma, a terceirização, por si só não dimunui o TCO. Para isto, é preciso que o processo seja bem desenhado e que as pessoas envolvidas diretamente nele estejam conscientes dos benefícios esperados e comprometidas com as metas estabelecidas.

O tema Terceirização tem diversos prismas e com certeza os abordaremos furamente

terça-feira, 13 de fevereiro de 2007

A SOX e a ânsia dos administradores

Ultimamente, presenciamos um grande movimento de empresas investindo em governança corporativa e em aderência à lei americana Sabanes-Oxley (SOX). Nós, da tecnologia da informação, somos afetados diretamente, tendo em vista que algumas das medidas necessitam do suporte da TI para saírem do papel. O grande problema está na ânsia dos administradores que não querem fazer da aderência à SOX um projeto planejado e cuidadosamente articulado (como deve ser). O que vemos é a pressa em obter o selo "empresa aderente à SOX" do dia para a noite e o caos sendo instaurado nos processos internos das organizações.

É importante lembrar que o principal motivador da criação da SOX foi o mercado de capitais norte-americano, que sofreu um grande baque com as fraudes nas demonstrações financeiras de enormes empresas. Porém, o principal foco da SOX não é garantir uma vantagem competitiva aos acionistas e sim garantir controle total sobre os processos administrativos das empresas, garantir números reais e confiáveis a respeito da saúde da empresa como um todo (não apenas a saúde financeira) e garantir que todos os acionistas, independentemente do tamanho de sua participação no capital da empresa, tenham acesso às mesmas informações, entre outros. As exigências da Sarbanes-Oxley, além de garantirem a estabilidade da bolsa de NY e da economia americana como um todo, acabavam por garantir a estabilidade das empresas também. Por este prisma, podemos perceber que governo, sociedade, empresas e, principalmente, investidores são beneficiados.

No Brasil, esta mentalidade está em fase inicial e, por isto, a coisa ainda está um tanto deturpada. Algumas empresas perceberam a real essência das práticas de governança e estão usufruindo de um balanço superavitário há alguns anos, apesar de terem passado por um árduo caminho até um bom nível de maturidade na governança corporativa. Outras empresas viram o sucesso das primeiras e estão tentando remar na mesma direção. O grande perigo é que estas só estão querendo "copiar" os benefícios obtidos e não os processos que as levaram ao sucesso na implantação da governança corporativa. A implantação da governança não deve ser vista apenas como meio de aumentar a liquidez de seu capital. As empresas devem enxergar, também, a oportunidade de crescimento que está por trás disto tudo: otimização de processos internos, racionalização de investimentos, transparência na administração e valorização do capital humano, entre outros.

Como muitas modas já vistas aqui no Brasil, muitas empresas estão remando para uma direção sem saberem ao certo aonde querem chegar. Muitas não sabem os reais benefícios trazidos pela SOX e nem estão interessadas em os aproveitarem. Estão enxergando apenas o benefício imediato: participar do "Novo Mercado" da Bovespa, visando aumentar a liquidez em suas ações.

É como querer ter um físico de atleta e, para isto, tomar anabolizantes ao invés de fazer ginástica.

segunda-feira, 12 de fevereiro de 2007

POG x MDS

Há alguns anos, o movimento pró-metodologias de desenvolvimento de sistemas (MDS) cresceu bastante entre os acadêmicos, porém não parece sensibilizar o mercado e muito menos uma grande fatia de desenvolvedores que ainda insistem praticar a "programação orientada a gambiarras" (POG). Tanto a indústria quanto a academia já comprovaram em diversos estudos e até mesmo na prática que os resultados, quando se utiliza uma MDS no processo de desenvolvimento de sistemas, são infinitamente superiores aos resultados obtidos em um ambiente, digamos, "desordenado". Então, apresento-lhes a grande pergunta: por que os investimentos em metodologias de desenvolvimento de sistemas ainda são relativamente pequenos?

Vamos começar pelo fator que mais interessa às empresas: o fator financeiro. É claro que a utilização de uma MDS tem um custo de implantação, um custo de manutenção e, geralmente, gera um "delay" que afeta diretamente o "time to market" (TTC) dos produtos. Porém, é necessário lembrar que um sistema desenvolvido segundo uma MDS tem um grau de escalabilidade muito superior aos outros e esta característica, muitas vezes, acaba por determinar o tempo de vida útil de um sistema. Por mais que o projeto tenha sido bem feito, um sistema sempre será customizado para adequar-se aos usuários, aos negócios, à legislação ou ao mercado. Sistemas engessados, instáveis e com baixa escalabilidade geralmente são os produtos entregues por equipes de desenvolvimento de sistemas que trabalham desordenadamente.

Nos últimos anos, a academia não mede esforços a fim de comprovar os benefícios agregados pela utilização de uma MDS. O tema é exaustivamente debatido em workshops, simpósios e grupos de discussão. Os analistas de sistemas formados pelas universidades, apesar de conhecerem o assunto ainda são minoria frente os milhares de "coboleiros", "clipeiros" e outros desenvolvedores que não estão dispostos a mudar a forma de fazer sistemas. E talvez aí esteja o maior desafio: MUDAR. O tema "resistência à mudanças" é base para teses e mais teses nas diversas áreas de conhecimento. E mais: é fato. O "modo antigo" de se fazer sistemas, além de gerar sistemas instáveis e pouco escaláveis, gera uma outra figura que é inimiga das empresas: o "dono do sistema". Não é raro nos depararmos com a situação em que apenas uma pessoa (ou grupo) é capaz de manter um determinado sistema (talvez isto explique a "indisposição" em usar uma metodologia). O uso de metodologias inverte os papéis e transfere a propriedade do conhecimento para a organização.

Os profissionais envolvidos neste cenário também poderiam adotar um outro ponto de vista. A consolidação do uso de metodologias pelo mercado, diminuirá consideravelmente a dificuldade de adequação em um novo emprego. Sem procedimentos formais é muito mais difícil encaixar um novo membro na equipe, otimizar o "modus operanti" e até mesmo sair de férias. Isto mesmo: sair de férias. Todos os analistas de sistemas com mais de 5 anos de estrada já devem ter passado pela situação em que não podiam sair de férias porque no período desejável iria acontecer "aquela migração" ou o "fechamento anual". Para não nos tornarmos escravos de nossos empregos, é imperativo que tornemos nosso ambiente de trabalho impessoal.

Enumeremos as vantagens que vimos até o momento:
  • Para as empresas: aumento do tempo de vida útil de um sistema, tornando-o mais barato em longo prazo; transfere a propriedade dos conhecimentos para a organização.
  • Para os profissionais: impessoalidade; maior abertura para os bons profissionais (acaba com os "donos dos sistemas").
  • Para os clientes: sistemas mais estáveis e escaláveis; aumento da qualidade dos sistemas.

Vistos todos estes fatores, a pergunta inicial continua sem resposta.

Ah... Já ia esquecendo! Os profissionais tem resistência à mudanças...

Talvez este deva ser o foco das academias e das pessoas que gostariam de ver esta mudança nos rumos da nossa profissão: mostrar para as pessoas que mudar não é ruim, e que, neste caso, a mudança tem tudo para ser positiva para todos os envolvidos. Como em todas as quebras de paradigma, o desafio não é fácil.