Analistas são frequentemente questionados pelos seus gerentes sobre as suas decisões e tem por frequência a necessidade de expor a estes conceitos técnicos. Muitas destas apresentações se tornam desastrosas por desconhecimento do modelo mental dos gerentes. Adapto (e estendo) aqui um belo trabalho realizado por Gerrit Mulller, que discute aspectos importantes em apresentações técnicas para não-técnicos (gerentes).

1. Compreenda como gerentes funcionam. Gerentes são orientadas por ações, são normalmente impacientes, ocupados, trabalham com fatos e não com crenças, operam em contextos essencialmente políticos e buscam elementos financeiros e mercadológicos todo o tempo.

2. Apresente um material profissional, com uso moderado de imagens e animações e textos curtos. Longos textos e uma aparência pobre distraem gerentes e dificultam a venda de idéias técnicas.

3. Não apresente crenças e filosofias sobre métodos e técnicas explicitamente. Deixe que os fatos conduzam os gerentes sobre uma técnica ou um método que você deseje demonstrar.

4. Não subestime o conhecimento técnico dos gerentes. Ao mesmo tempo, nunca corrija um gerente desinformado caso ele diga uma “asneira” técnica no meio da sua apresentação. Lembre-se que gerentes possuem autoridade formal e analistas normalmente somente autoridade moral.

5. Não deixe que um gerente conduza e domine a reunião. Lembre-se que você é o “maestro”.

6. Organize o conteúdo sobre quatro elementos centrais (uma definição clara do problema, uma exploração da solução, opções e recomendações e uma lista de ações e decisões). Lembre-se, entretanto, de usar fatos e figuras para conduzir estes elementos.

7. Esteja confiante, mas aberto a ouvir. Esteja bem-vestido, mas permaneça autêntico ao seu estilo.

8. Gerencie as expectativas desde o começo da reunião. Diga o que irá fazer, faça o que disse que iria fazer e lembre a todos no final da reunião o que você disse.

9. Endereçe as preocupações gerenciais típicas. Traduza os requisitos técnicos em consequências de negócio (esforço e pessoas envolvidas nas ações, tempo, custos, riscos, investimentos necessários e lucro sobre este investimento).

10. Se atenha as princípios fundamentais das “Idéias que Colam” do irmãos Heath e do seu livro homônimo. Os seis princípios fundamentais são: Simplicidade, Concretude, Credibilidade das Idéias, Surpresa, Emoções e Histórias.

Depois de um longo e pesado Setembro, estamos de volta ao nosso bom hábito de escrever. Desta vez gostaria de falar sobre uma habilidade cada vez mais valorizada pela empresas de TI, que são os “soft skills˜, ou habilidade suaves, em uma tradução literal. Estas habilidades são muito enfatizadas pelos agilistas e escolas ágeis e tem a ver com habilidade de comunicação, compreensão, liderança moral e a capacidade de unir e organizar times de trabalho. Um artigo muito interessante de Gary Pollice, da IBM, está disponível aqui.

Li recentemente trechos da filosofia estóica, que tem similiaridade com o Budismo, e que por incrível que pareça podem nos ajudar na TI a sermos pessoas melhores e ganhar autoridade moral sobre times. Parece que filosofia e TI tem pouco em comum, mas o oposto é verdade. As frases abaixo nos mostram como a nossa atitude correta importa muito na saúde de projetos.

“As coisas que nos afetam estão fora de nós. Mude sua atitude e então, como um navio entrando num porto seguro, você encontrará a calma.”

“Quando contrariado, recue e considere se às vezes você não é culpado exatamente pela mesma coisa.”

“Antes de cada ação pense: eu não teria nenhuma razão para me arrepender depois?”

“A felicidade daqueles que querem ser populares depende dos outros; a felicidade daqueles que buscam prazer flutua com humores fora do seu controle; mas a felicidade do sábio nasce dos seus próprios atos livres.”

A virtude e a maldade existem, não como emoções e pensamentos, mas como ações.”

Frases do imperador romano e filósofo estóico Marcus Aurelius Antoninus

O modelo de “fábricas de software” está em franca expansão na TI Brasileira. Com a premissa de maior produtividade e redução de custos para contratantes, este modelo originalmente nasceu do belo conceito de “Software Product Lines”, muito bem documentado em corpos de conhecimento do SEI e outros institutos mundo afora.

Infelizmente, algumas “fábricas de software” não são exatamente “Product Lines”, mas instrumentos de lucratividade apenas de seus sócios.

Coloco abaixo um teste lúdico para que um desenvolvedor possa avaliar a qualidade do ambiente que ele trabalha. Quanto maior a pontuação, melhor.

Horas Extras

• Horas extras são uma exceção e você é pago com um valor de hora extra conforme legislação CLT. (SOME 1 PONTO)
• Horas extras são uma constante e você é pago com incentivos morais, tapinhas nas costas e elogios oportunistas. Normalmente você trabalha mais de 200 horas por mês. (SOME -1 PONTO)
• Você não tem finais de semana. (SOME -2 PONTOS)

Treinamento e Aprendizado

• Existe um programa de treinamento formal na sua empresa e você é normalmente capacitado em novas tecnologias e novos domínios de negócio. (SOME 1 PONTO)
• O seu programa de treinamento é feito por conta própria por você de madrugada e nos finais de semana. (SOME -1 PONTO)

Participação em Projetos

• Você é normalmente convidado para opinar e propor soluções técnicas no seu projeto. (SOME 1 PONTO)
• Você recebe ordens e deve executá-las sem discutir. (SOME -1 PONTO)

Apoio Gerencial

• O seu gerente é um facilitador para os seus problemas. (SOME 1 PONTO)
• O seu gerente somente sabe cobrar o % de completude do caso de uso. “E aí, tá pronto?”. (SOME -1 PONTO)

Apoio Técnico

• A sua empresa possui uma área de frameworks e técnicos especialistas para resolução de problemas. (SOME 1 PONTO)
• O seu suporte técnico é o Google. (SOME -1 PONTO)
• Você não tem acesso ao Google no trabalho. (SOME -2 PONTOS)

Tratamento na empresa

• O seu RH o trata pelo nome. (SOME 1 PONTO)
• O seu RH o chama de recurso ou colaborador nos emails. (SOME -1 PONTO)

O resultado da sua fábrica…

Se você marcou mais que 3 pontos, isso é uma excelente notícia. O seu ambiente é saudável e você tem uma boa qualidade no desenvolvimento diário dos seus sistemas. Conte a sua história aqui.

Se você marcou entre 0 e 3 pontos, você provavelmente trabalha em uma fábrica de recursos. Você é uma mais uma peça da engrenagem fabril. Recomendo que você assista ao clássico filme chamado “Tempos Modernos”, com o Charles Chaplin.

Se você marcou pontuação negativa, você trabalha em um presídio de software. Recomendo que você assista ao clássico filme “Fuga de Alcatraz”, com Clint Eastwood.

Estive em uma interessante e instigante apresentação de um arquiteto chamado Jan Bosch no último evento do SBQS. Comento aqui alguns dados interessantes sobre a organização de times da Amazon e do Google.

• 3 homens mês x 3 meses. Todo e qualquer projeto tem no máximo 3 pessoas em um tempo não maior que 3 meses.
• A regra das 2 pizzas. O tamanho máximo de um time deve ser limitado pela quantidade de comida presente em 2 pizzas grandes. Fiz rápidas contas e acredito que um o tamanho máximo não deve exceder 6 ou 7 pessoas para que ninguém fique com fome.

Aparentemente, a premissa é colocar como regra corporativa que o ciclo de vida de um produto deva ser guiado por projetos curtos com poucas pessoas e portanto com pouco overhead gerencial. Em times deste porte, podemos ter gerentes técnicos ou mesmo arquitetos que possam conduzir as atividades necessárias a geração de um produto.

Este conceito também traz implicações interessantes. Produtos devem ser gerados incrementalmente respeitando as enormes pressões de tempo de mercado e ao mesmo incentivando a criatividade dos técnicos envolvidos. A técnica clara para que isto opere é uma forte priorização de requisitos e um adiamento dos requisitos menos importantes para futuros ciclos e novas versões dos produtos.

Podemos ver também uma forte influência de culturas ágeis, com a geração de valor (produto operável na mesa dos usuários) como a regra número 01.

Em resumo, o que vemos nestas empresas talvez seja também uma forma humilde de reconhecer que a TI não deve operar como um fim em si mesma mas como uma forma de gerar maior valor de negócios. Projetos pequenos e rápidas liberações parece ser uma estratégia interessante, o que pode explicar uma parte do sucesso da Amazon e da Google.

Pensamento do dia: “Divide et impera”, ditado latino.

Vemos muitos projetos que falham por problemas gerenciais. Um destes problemas é a distância entre o gerente de projeto e a sua equipe. Times que não se sentem orientados e aconselhados diariamente perdem o seu foco e se dispersam. Para combater esta distância, devemos fomentar e incentivar a figura do líder técnico de desenvolvimento (que em muitas empresas também é o arquiteto de sistemas).

O líder técnico de desenvolvimento mantém o time unido e coeso. Ele mantém a consistência técnica do produto de software sendo construído e atua como um coach para todo o time para os problemas técnicos e de ausência de motivação, que são comuns em projetos complexos e com prazos desafiadores.

O líder técnico/arquiteto é o contraponto musical do gerente de projeto. O líder técnico e o gerente de projeto atuam como um par-alfa de lobos em uma alcatéia na caçada pelo sucesso do projeto.

As fronteiras entre o Gerente de Projeto e o Líder Técnico de Desenvolvimento

Adapto abaixo um trecho do livro Applied Software Architecture, de Christine Hofmeister, Robert Nord e Dilipe Soni, que explicita a fronteira entre a gerência de projeto e a liderança técnica de projetos.

Pensamento do dia - Eclesiastes 4:9 Melhor é serem dois do que um, porque tem melhor paga do seu trabalho. 4:10 Porque se um cair, o outro levanta o seu companheiro.

A comunicação talvez seja o princípio mais importante das escolas ágeis mas é infelizmente muito mal compreendido por técnicos de TI. Exploro aqui duas rápidas questões sobre princípios de comunicação efetiva.

O princípio da comunicação quente
A paleta de cores abaixo mostra algumas formas de comunicação em projetos. Quanto mais quente (à direita), mais rico e efetivo é o mecanismo de comunicação.

Surpreendemente, analistas gostam de email e documentação (mesmo com o colega a dez metros de distância), que são formas frias de comunicação. Ao invés, comunicações quentes (conversas) devem ser usadas para estabelecer sinergia e transmitir idéias entre times. Este princípio, explorado anteriormente por Alistair Cockburn e revisitado por Scott Ambler, é descrito em mais detalhes aqui.

O princípio SUCESSO
Idéias que colam e sào lembradas por pessoas são simples, inesperadas, concretas, transmitem crença imediata, remetem a emoções e são baseadas em histórias. Cito como um exemplo um assunto aparentemente árido - a instrumentação de alarmes em sistemas telefônicos, que foi transmitido com sucesso através da metáfora arquitetural Clínica médica por um grupo de técnicos do nosso convívio.

O caso completo é descrito em mais detalhes aqui.

O livro Idéias que Colam, escrito por Chip Heath e Dan Heath, endereça estes princípios e fornece dezenas de exemplos de como comunicar efetivamente idéias para outras pessoas.É um livro brilhante e leitura indispensável a bons comunicadores.

Pensamento do dia: “True interactivity is not about clicking on icons or downloading files, it’s about encouraging communication.”, Edwin Schlossberg.

Você provavelmente conhece muitas analistas e desenvolvedores “ocupados”. Pessoas muito “ocupadas” almoçam em quinze minutos, não tem tempo de conversar cinco minutos no café, ler um bom blog na Internet ou fazer qualquer outra atividade de TI que não seja escrever, desenhar, codificar e testar casos de uso. O senso de urgência é tão grande que estas pessoas também não tempo de estudar ou pensar sobre estratégias para serem mais eficazes e eficientes no seu trabalho. Nos casos mais graves, eles também não tem tempo de dormir oito horas por dia ou dar atenção à sua família. Afinal, existem defeitos para consertar, sistemas para implantar ou ligações do trabalho para atender.

O Equilíbro P/CP

Este tipo de analista, consciente ou inconscientemente, somente enxerga a produção (P), em detrimento da sua capacidade produtiva (CP). A relação P/CP determina, como na fábula da galinha dos ovos de ouro, a relação entre a produção (P) e a capacidade necessária para a produção (CP). Queremos ovos de ouro, mas se não alimentarmos a galinha ou, ainda pior, matarmos a galinha, não teremos mais ovos.

É verdade que muitos analistas trabalham desta forma pois são guiados por gerências ou empresas que focam apenas na produção sem fornecer a infra-estrutura e meios para que o analista se recicle e seja um aprendiz constante (CP). Independente da razão, entretanto, o destino deste analista é um dos seguintes: a obsolescência ou um crônico problema de saúde. Analistas obsoletos ou doentes não produzem mais ovos atrativos e entram numa espiral descendente de produção inadequada e baixa capacidade produtiva. São galinhas velhas que param de botar ovos e se tornam canja para a sopa da rotatividade corporativa. No fim, estes analistas são substituídos por outros profissionais de mercado, que possuem um maior P e um maior CP. Eles formam a maior parte da massa de analistas demitidos e que tem grande dificuldade em se reposicionar no mercado.

Idealmente, as empresas deveriam fornecer espaço para que os seus profissionais trabalhem o CP. Programas de treinamento formais e espaços livres na agenda semanal para atividades de aprendizado constante de seus funcionários são exemplos de ações nesta linhas. Cito dois bons exemplos de empresas assim no Brasil:

• Uma multi-nacional no Rio de Janeiro que impede que gerentes aloquem mais do que 6 horas diárias ou 30 horas semanais de cada analista ou desenvolvedor.
• Uma empresa de pesquisa aplicada em Belo Horizonte que fornece às tardes de Sexta-Feira para os funcionários estudarem.

Profissionais que não trabalhem em empresas que priviligiem o CP, entretanto, não podem se lamentar. Ao invés, eles devem buscar o aprendizado constante e obviamente lutar para que as suas empresas implementem estes programas. Cursos de especialização, assinatura de revistas ou participação em comunidades técnicas são exemplos pessoais de aumentar o seu CP.

Não devemos, também, mirar no outro extremo e ficar apenas na “teoria”. Resultados contam e são muito importantes. Você provavelmente também deve conhecer algum analista “desocupado”. Ele passa o dia no MSN, no Orkut, Facebook, LinkedIn, Twitter e responde quase todos os emails em listas de discussão. Este profissional também não conclui projetos, pois ele está sempre mudando de empresas ao sabor dos modismos tecnológicos que ele ouviu falar ontem. Muitas vezes ele também é conhecido pela aplicação da técnica chamada “Resumèe-Driven-Design”, que é aplicar apenas o seu último framework “predileto” em todos os seus projetos. Sem o P, a equação P/CP se torna desiquilibrada. A sabedoria se encontra no equilíbrio ou como dizem os Budistas, no “Caminho do Meio”.

Por fim, lamento apenas que os “analistas ocupados” não poderão ler este post. Eles estarão muito atarefados na produção de ovos nas granjas de TI de todo o Brasil.

Pensamento do dia: “Os analfabetos do século XXI não serão aqueles que não sabem ler e escrever; mas os que não sabem aprender, desaprender e reaprender continuamente”, Alvin Toffler.

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.