Marco Mendes´s Blog

O mercado de TI no Brasil, apesar da crise que se anuncia, está muito aquecido. Este aquecimento, como qualquer processo econômico, gera problemas de oferta e demanda. Uma alta oferta gera problemas diversos de déficit na demanda. A Gazeta Mercantil, em uma pesquisa de 2006, apontou um déficit de 50 mil profissionais no mercado de TI. Uma outra pesquisa, do portal Convergência Digital da Terra, diz que o Brasil acumulará um déficit de 150 mil profissionais até 2011. A Business Week, renomada revista americana, mostra que a profissão de Engenheiro de Software é a segunda posição do mercado de trabalho dentre as 20 profissões à prova de recessão.

Neste aquecido mercado, começamos a observar um estranho fenômeno, que é da presumida senioridade de profissionais de TI. Em termos mais simples, observamos profissionais que sem nenhuma ou pouquíssima experiência se assumem a seus gerentes e pares como plenos ou mesmos sêniores. Um padrão típico que já observei várias vezes poderia ser resumido da seguinte forma:

• O profissional faz um estágio em uma empresa de TI. No estágio ele “aprende” um framework como por exemplo o Hibernate e “domina” uma ferramenta como por exemplo o Visual Studio.
• Após o aprendizado do estágio, o profissional consegue o emprego e trabalha em seu primeiro projeto. Após um ano e algumas experiências vividas com um mesmo framework em um ou dois projetos, o profissional percebe que domina muito bem a ferramenta. Como ele passa a coordenar novos estágiários, que chegam sem nenhum conhecimento, ele de repente se percebe pleno. Pleno de conhecimento, pleno de domínio e pleno de influência. Para tornar a coisa pior, os seus gerentes, ingenuamente, começam a dizer a todos que ele é pleno. E como uma mentira dita em voz alta ao vento dez vezes se torna verdade, o profissional se torna pleno!
• Um profissional pleno almeja novas posições financeiras. Muitas vezes o profissional não encontra isso na empresa que o empregou. É o momento de ir para outra empresa, onde ele já entra como pleno, devido a sua “experiência” de coordenação de estagiários e novatos e do seu domínio sintático de ferramentas.
• No seu trabalho “pleno”, o profissional vive boas experiências em projetos. Ele lida com pressões de tempo, pressões da sua gerência, coordena pessoas que se dizem plenos e aprende novas ferramentas e novos frameworks. E eis que depois de algum tempo e mais projetos, ele percebe que é a pessoa que possui mais conhecimento no seu time. Neste momento, a síndrome do máximo local o atormenta. Ele é o melhor jogador de futebol da sua rua e então decide que é sênior.
• Este novo profissional sênior busca, novamente, posições maiores e maiores posições financeiras. Muitas vezes ele não encontra isso na empresa que o contratou como pleno. Novamente o seu CV está na rua e em breve ele consegue uma nova posição como sênior. Ele tem três ou quatro anos de experiência de mercado! Nos próximos 32 anos anos da sua vida profissional ele será sênior!

Este parece ser um sintoma mais presente na geração Y (pessoas que nasceram depois dos anos 70) do que na geração X (seus antecessores), mas isso é pura especulação minha.

O processo evolutivo da senioridade!

Mas o que é um profissional pleno ou um profissional sênior? Sem dúvida é difícil definir isso e eu claramente não tenho competência para isso. O que percebo, entretanto, é que habilidades e competências diversas devem estar presentes. Uma vasta experiência (medida em milhares de horas de projeto), um grande número de projetos entregues com sucesso (medido em dezenas), uma vasta formação acadêmica (medido no número de pós-graduações e cursos de aperfeiçoamentos), um forte quociente emocional e um reconhecimento sólido do mercado são atributos essenciais. Arrisco-me a dizer, entretanto, que talvez o atributo mais importante seja a humildade, afinal de contas, para reconhecer as próprias limitações e aprender continuamente.

Entregar sistemas de software não é uma arte. É uma complexa ciência que requer, dentre vários outros fatores, muito estudo. Para apoiar neste aspecto, compilo artigos que me muito me ajudaram nos últimos anos, escritos por “mestres” na arte de desenvolver sistema e que são uma eterna fonte de inspiração.

1. Processos ágeis - The Seven Habits of Effective Iterative Development
2. Projetos Iterativos - Planning an Iterative Project e Iterative Development
3. Bom planejamento de Projetos - Project planning best practices
4. Gerência de Riscos - Gambling with Success: Software Risk Management
5. Estimativa de Tamanho de Software - Estimating Software Development Effort based on Use Cases - Experiences from Industry
6. Modelagem de Negócios - Effective Business Modeling with UML: Describing Business Use Cases and Realizations
7. Gerência de Requisitos - So You Want to be a Requirements Analyst? e The Five Levels of Requirements Management Maturity
8. Modelagem de Casos de uso - Why Use Cases Are Not Functions, Features, Requirements, Use Cases, Oh My e The Top Ten Ways Project Teams Misuse Use Cases – and How to Correct Them.
9. Escrita Estruturada de Regras de Negócio - Business Rule Overview e Business Rules.
10. Especificação de Glossário de Termos - Glossary Overview.
11. Mapas de Navegação e Prototipação - User experience storyboards: Building better UIs with RUP, UML, and use cases.
12. Análise Robusta e Modelagem de Domínio - Robustness Diagram Overview e Driving Design: The Problem Domain.
13. Modelagem Arquitetural - Reference Architecture: The Best of Best Practices e Capturing Architectural Requirements.
14. Modelagem de Estruturas de Análise e Desenho - Driving Design: The Problem Domain
15. Modelagem Comportamental - Sequence Diagrams: One Step at a Time
16. Mapeamento Objeto Relacional - The Object-Relational Impedance Mismatch.
17. Gerência de Mudanças - Software Change Management.
18. Gerência da Qualidade - Software Quality at Top Speed e Determining Your Project’s Quality Priorities
19. Desenvolvimento Centrado em Testes Generating Test Cases From Use Cases, Test-Driven Development.
20. Refactoring e Testes de Unidade - Refactoring, a first example.

O que deve saber um desenvolvedor Java, .NET ou de outra tecnologia para ter sucesso e crescimento no mercado? O senso comum é que nós, enquanto desenvolvedores, devamos saber apenas programar, conhecer algoritmos, estruturas de dados e APIs.

Infelizmente, o mundo real exige muitas outras coisas não ensinadas na graduação. Coloco abaixo alguns pontos que observo como exigências explícitas e implícitas no nosso dia e dia a partir dos desafios de projetos das nossas empresas e de empresas por todo o Brasil.

• Conhecimentos sólidos de escrita de código. Martin Fowler, autor de renome na nossa área, tem uma frase interessante: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”. Para termos conhecimento sólidos de desenvolvimento, devemos dominar, obviamente, estruturas de dados e algoritmos e APIs de programação. Além disso, devemos conhecer também “idioms”, testes de unidade e técnicas de refatoração. Um excelente livro, que recomendo fortemente para quem aumentar o seu conhecimento em escrita de código, é o livro Code Complete do autor Steve McConnell. Outro excelente livro nesta área é: Refactoring: Improving the Design of Existing Code, de Martin Fowler.
• Conhecimento de Padrões. Quase nenhum problema que vivemos no dia a dia é realmente inédito. A chance deste problema ter sido enfretado e resolvido por outra pessoa no mundo é alta. Existe uma chance boa também de uma boa solução para os seus problemas terem sido documentados em padrões. Temos diversos tipos de padrões, tais como padrões de arquitetura, padrões de desenho, padrões de análise, padrões de implementação (idioms) e padrões de testes. Somente os padrões de desenho essenciais do clássico livro do Gamma (Design Patterns: Element of Reusable Object Oriented Software) somam 23. Temos mais de uma centena de padrões de arquitetura apenas nos livros (obrigatórios): Patterns Oriented Software Architecture vol. 4 (Bushman et al.), Enterprise Integration Patterns (Gregor Hohpe) e Enterprise Applications Architectures (Martin Fowler).
• Conhecimentos de Processo de Software. Você domina algum processo de software? Dominar um processo é conhecer suas nuances, bases filosóficas e aplicá-lo na prática. Ouço com frequência pessoas que dizem usar “processos ágeis” mas desconhecem TDD (Test Driven Development) ou Agile Modeling. Também ouço pessoas que dizer usar o RUP mas ainda confundem elaboração com análise. Em verdade vejo que muitos desenvolvedores, por desconhecimento, usam o famoso processo “conserta e remenda” no seu dia a dia. Como desenvolvedores, devemos aumentar o nosso conhecimento de engenharia de software e de processos de software. Livros chave nesta área incluem: The Rational Unified Process: An Introduction, Philipe Kruchten e XP Explained, Kent Beck.
• Conhecimentos Laterais. Conhecer profundamente de implementação e de uma linguagem é bom. Entretanto, um bom desenvolvedor deve conhecer e aplicar técnicas laterais de outras disciplinas. Exemplos incluem: requisitos funcionais e não-funcionais, modelagem de casos de uso, modelagem de dados, UML, arquitetura de software, gerência de configuração, testes funcionais, testes não-funcionais, técnicas e métricas de qualidade de software, práticas de gerência de projeto, ferramentas de desenvolvimento, técnicas de integração de sistemas, modelagem de processos de negócio, produtos para verticais tais como ERP, CRM ou HRMS; liderança técnica e práticas de gerência.
• Pró-atividade. É importante possuir e aplicar um atitude crítica sobre as decisões do projeto. Questionar e debater as escolhas gerenciais e criar acordos ganha ganha com todo o time é a essência do desenvolvimento em time praticado e enfatizado por qualquer metodologia ágil. O papel do desenvolvedor não é apenas escrever código, mas ser uma peça central no sucesso do projeto. Com tal responsabilidade, ele não pode simplesmente reclamar de uma decisão inadequada de sua gerência e fazer as tarefas por que foi comandado para isso. Um desenvolvedor não pode se vitimizar e criar uma espiral descendente de desânimo e apatia com o o seu time. Ao invés, ele deve (junto do time) fazer o trabalho necessário e possível para o sucesso do projeto. Criar sinergia com seus pares, ambientes saudáveis e estratégias ganha ganha é fundamental para qualquer trabalho de time, especialmente o pesado trabalho de desenvolvimento de software. Como aprendi há algum tempo, o problema não são os eventos (positivos ou negativos) que ocorrem no seu projeto. A verdadeira pró-atividade vem de como reagimos e respondemos a estes eventos..
• Comunicação. A clássica idéia do desenvolvedor que vai para o escritório, senta em sua cadeira, coloca o seu fone de ouvido e fica o dia inteiro escrevendo código como um autista é filme de ficção científica. Desenvolvedores devem se comunicar o tempo todo. Eles devem conversar diariamente com os analistas, com os gerentes e com os testadores. Eles devem conversar diariamente com os seus pares e somente após isso então conversar com a máquina. A maior parte dos problemas de projetos nascem de questões de comunicação e requisitos. Compreender profundamente o ambiente e os requisitos de projeto é papel chave para todo desenvolvedor.
• Formação Acadêmica. Infelizmente os tempos mudaram. Uma graduação em computação significava muita coisa há 25 anos atrás. Hoje isso é apenas o começo. Um bom desenvolvedor deve investir continuamente na sua formação. Cursos de especialização, pós-graduação lato sensu em engenharia de software, arquitetura de software, redes e outros tópicos bem como mestrados profissionais, mestrados strict sensu e doutorados devem ser perseguidos todo o tempo. Além disso, certificações específicas de Java (SCJP, SCWCD, SCEA) e .NET (MCAD, MCSD, MCTS) devem ser alcançadas. Finalmente, assinar e ler revistas específicas, podcasts, newsletters e webzines bem como participar de eventos específicas e ser membro de comunidades como por exemplo o MGJUG e os .NET Raptors, entre várias outras, é fundamental para manter a empregabilidade.
• Humildade. A nossa carreira dura em média 35 anos. A ansiedade, entretanto, nos prega peças. Devemos tomar cuidado, portanto, antes de dizermos que somos sêniores em algum assunto ou buscar atalhos profissionais. Para nos tornarmos sênior em alguma coisa, precisamos de anos e talvez décadas de trabalho em um tópico específico. Precisamos de um vasto portfólio de projetos vividos e dezenas de milhares de horas de trabalho em nosso currículo. O nosso aprendizado é lento e somente vem com o tempo, muitos erros e com a experiência acumulada. Devemos saber ter paciência e humildade para criamos uma carreira sólida enquanto desenvolvedores.
• Foco e persistência. Ser desenvolvedor é uma carreira de longo prazo. Trocá-la por uma carreira de gerente ou analista simplesmente por uma questão monetária ou status é um erro, a não ser que a sua voz esteja em outra carreira. Felizmente, desenvolvedores agora tem a chance de serem bem remunerados por seu trabalho. Cada vez mais as empresas valorizam o desenvolvedor pelo valor agregado que ele produz ao projeto. Isso é fato e observo vários desenvolvedores que ganham mais que gerentes ou analistas. Não existe nada de errado com isso, nem existiria com o contrário. O retorno financeiro deve ser proporcional ao valor agregado trazido por cada membro do time.
• Ética. Este talvez seja o atributo mais importante. Um desenvolvedor deve ser implacável com qualquer desvio de conduta praticado por qualquer membro de um projeto. Um desvio de conduta não é apenas desviar dinheiro. Ao invés, um desvio de conduta é entregar um produto com qualidade inadequada, mascarar um produto para ganhar tempo, trabalhar com má vontade, manipular pessoas ou simplesmente dizer “mentiras brancas” sobre a situação do projeto para um colega do time ou cliente.

Em resumo, apesar de todas as dificuldades e pressões do dia a dia, a carreira de desenvolvedor é empolgante e pode ser bastante valorosa para os que nela acreditam e investem. Recomendo os livros citados aqui (a maior parte deles traduzidos para o português) como ponto de partida de desenvolvimento técnico e as inúmeras redes sociais na Web sobre Java e .NET para aprendermos continuamente com as pessoas ao nosso redor.

Recentemente escrevemos um artigo para a Rational Buzz (revista on-line da IBM Rational no Brasil), sobre aspectos motivacionais para o desenvolvimento de recursos humanos na área de software. O artigo apresenta também ferramentas para suporte a este desenvolvimento como o IBM Rational Portfolio Manager e o IBM Rational Unified Process.

O resumo do artigo está aqui:

A volatilidade dos negócios, a globalização e a necessidade de contínuas inovações tecnológicas nas empresas tornam a TI uma peça fundamental para o correto alinhamento estratégico dessas empresas às suas visões. Esses novos paradigmas tornam ainda mais desafiante a implementação de projetos, que dependem, para o seu sucesso, do uso adequado de pessoas competentes e motivadas, processos ágeis e ferramentas integradas. Nesse contexto, este artigo apresenta como a questão do capital intelectual é crítica para a execução de projetos e propõe um pequeno conjunto de práticas-chave ancoradas em ferramentas de produtividade como o IBM RPM e o IBM RUP para promover uma maior previsibilidade nos resultados de projetos e a gestão de competências e desenvolvimento de recursos humanos em organizações.

O artigo completo pode ser encontrado aqui.