Empresas Brasileiras de TI! Abram os olhos (se ainda não o fizeram) !

Quase 1 mês desde de o último post! Queria ter postado algo no Carnaval, mas simplesmente precisava descansar.

Os últimos dias foram bastante estressantes, quebrando todo o meu ideal de qualidade (de vida, de trabalho e de produto) e também de ritmo sustentável. Na verdade, sou total defensor de valores que parecem ser verdadeiras "ofensas" para alguns tipos de profissionais de TI que ainda não vieram para 2008. Este profissionais, que baseam seus parâmetros de produção de Software em Taylor e Ford, acreditam que trabalhar muito é trabalhar 14 horas por dia. Minha definição de trabalhar muito é: "Entregar o máximo possível em menos tempo". Ou seja, trabalhar muito para mim, é ser produtivo! É ter produtividade! É ser direto e resolver o problema sem enrolação e ainda sobrar tempo para estudar, e se aperfeiçoar.

Voltando ao assunto do post, sempre tenho dito e visto que no Brasil acontece alguns "fenômenos" interessantes!

1. Os professores de algumas faculdades insistem que ter sucesso na carreira é se tornar gerente de projetos!
2. O profissional nem tirou as fraldas da faculdade então sai procurando vagas de gerente... (alias foram 5 anos de "lavagem celebral")
3. O profissional que resolve codificar, trabalha dois anos e diz: "Não quero mais isto! Vou virar gerente ou analista, mas não coloco mais a mão em código fonte"
4. O estudante já entra na faculdade falando que não vai passar o resto da vida trabalhando com TI (Pelo amor de Deus, né ? Larga a faculdade então, meu filho!)
5. "Analistas de sistemas" que nunca escreveram uma linha de código, especificando sistemas usando os templates do RUP
6. Por falar em RUP, existem as "empresas" de TI que dizem que usam o RUP, mas na verdade apenas estão usando o velho "desenvolvimento em cascata"

Já disse anteriormente que acreditava que as causas dos fenômenos 1, 2 e 3 é que infelizmente no Brasil, as empresas pagam mais para os Gerentes de Projeto apenas porquê o possuidor deste perfil é responsável por "fazer valer" alguns dos princípios de Fayol:

1. Autoridade e Responsabilidade - Poder de dar ordens e poder de se fazer obedecer; Obrigação de prestar contas
2. Disciplina - Tornar as expectativas claras e punir as violações;
3. Unidade de Comando - Se reportar à um único chefe/gerente;
4. Unidade de Direção - Garantir que os esforços dos empregados devem focar na realização dos objetivos organizacionais;
5. Subordinados a seu comando
6. Centralização - Um único núcleo de comando centralizado, atuando de forma similar ao cérebro, que comanda o organismo. Considera que centralizar é aumentar a importância da carga de trabalho do chefe e que descentralizar é distribuir de forma mais homogênea as atribuições e tarefas;
7. Hierarquia - Ou também cadeia de comando
8. Ordem - Ordenar as tarefas
9. Iniciativa - Estimular em seus liderados a inciativa para solução dos problemas

Claro que pessoas com todas estas características devem ser devidamente remuneradas. Entretanto, passados 90 anos da publicação destes princípios; após a globalização; após o "boom" da Internet; após toda a melhoria na educação dos profissionais e principalmente depois de se falar muito de trabalho em equipe; será que apenas 1 pessoa na equipe (o Gerente) é o cara ?!?! Todos sabemos que hoje em dia isto não é mais realidade!

Nossa área de TI é composta "quase que obrigatoriamente" de pessoas muito bem qualificadas, que estudaram (e ainda continuam a estudar) anos de informações, técnicas e metodologias que nos obrigam a acompanhar uma área sempre em rápida evolução. Cada um em sua área de formação (e afinidade) - Gerência de Projetos, Banco de Dados (DBA e AD), Desenvolvedores (Front-End e Back-end), Arquiteto, Infraestrutura (Application Servers e Rede) é responsável por um produto de Software que pode ser desde um Cadastro de Locadora até um Sistema de Bankline com centenas de milhares de acesso simultâneo. Em um sistema crítico você poderia responder quem foi o ÚNICO responsável pelo sucesso do sistema ? Acredito que não!

Além da baixa remuneração dos desenvolvedores tenho visto atitutes no mínimo questionáveis: Quando o prazo está estourando, quem é que vira a noite implementando algo não devidamente planejado e negociado com o cliente ?

Fora este tão conhecido problema, existe um outro problema não velado: Por incrível que pareça, existem empresas onde os desenvolvedores que mais trabalham são exatamente aqueles que mais sabem. Afinal de contas eles resolvem todos os problemas, possuem baixo índice de defeitos, escrevem os códigos mais legíveis e pensam em todos os possíveis Bugs ou situações durante a implementação. Por outro lado, o desenvolvedor que NÃO QUER se especializar. Repito, NÃO QUER pois existem forums, tutoriais, ebooks, artigos, códigos fontes, google e todo o tipo de informação disponível para as pessoas com iniciativa de correrem atrás. Estes desenvolvedores sem iniciativa não estão na lista de promoção das empresas, mas como fazem o "feijão com arroz" também não estão na lista de cortes da empresa. O que está errado então ?

Muitas vezes ouvimos falar que culturalmente no Brasil "Não faça nada e ganhe muito"! É ai que está o problema: As empresas brasileiras (generalizando) ainda não abriram o olho para a qualidade. A idéia é bastante simples: Reduzir os custos! Como ? Pagando um pouco melhor dois ou três desenvolvedores bem qualificados (DBQ) e entupindo o resto das vagas com desenvolvedores mal qualificados (DMQ). E isto desencadeia uma série de eventos que não afetam o bolso da empresa. Apenas a qualidade, o prazo, os bugs, o tempo de manutenção do código e outras coisas que os empresários ainda não aprenderam a enxergar.

1. Os desenvolvedores bem qualificados (DBQs) são sempre escolhidos para os projetos críticos.
2. Ninguém arrisca colocar os desenvolvedores mal qualificados (DMQs) nos projetos críticos
3. Os DBQs ganham "um pouco" a mais que os DMQs para se sentirem motivados.
4. Os DMQs sentem que ganham quase o mesmo tanto que os DBQs e se dão por satisfeitos.
5. A empresa acha que está fazendo um bom negócio e deixa como está.
6. Quando os DBQs estão cheios de projetos e não conseguem ajudar os DMQs, os problemas começam a aparecer
7. A empresa acredita que o problema é que os DMQs estão perdendo muito tempo na internet e corta INTEGRALMENTE o acesso impedindo assim que os DMQs tenham contato com tutoriais, howtos, etc.
8. Os DBQs então, tem que atrasar seus projetos (em andamento) para "dar suporte" aos DMQs - Trabalho dobrado!
9. Se até agora a empresa não fez nada o DBQ vai sentir que ganha pouco e trabalha muito e vai querer virar gerente ou analista para assistir "este filme" de camarote.
10. A empresa culposa "reconhece" o esforço do DBQ e o promove para gerente!
11. Resultado: A empresa perdeu um excelente técnico e ganhou um péssimo gerente.

Neste exemplo surreal e fictício quem seria o grande vilão ? A empresa que apenas enxergou os lucros e colaborou com este cenário? O Desenvolvedor Mal Qualificado (DMQ) que não teve iniciativa de melhorar profissionalmente? Ou o Desenvolvedor Bem Qualificado (DBQ) que trocou de área apenas pelo dinheiro ? Pensem e respondam...

Empresas de TI, abram seus olhos! Invistam em treinamento. Crie políticas de cargos e salários que possibilitem as pessoas ganharem mais fazendo o que sabem fazer de melhor! Incentivem o uso racional da Internet. No final, o resultado de sua qualidade estará sempre no sorriso de seus clientes.

Se você está começando na área de TI agora, por favor: Não se acomode como o personagem que citei! Leia livros. Pratique. Se informe. Participe de comunidades. Explore. Descubra/Entenda como funciona. Ajude o Brasil a ser cada vez mais concorrente.

E por fim, se você já está na área há algum tempo, faça o que gosta e porquê gosta! Só assim você será Feliz e terá Sucesso e Paixão no que faz!

Apesar deste desabafo, continuo gostando bastante do que faço. Acredito que "nossa" área ainda tem bastante para oferecer afinal fazer CRUD é fácil! Quero ver é quando a aplicação está lenta, caindo ou foi hackeada"