Atualizado: pequenas mudanças no texto da conclusão
Um post bem divertido do Jeremy Miller, Anti-Team, apresenta o seria o pior time do mundo, descrevendo alguns tipos bem caricaturatos, mas com fundo de verdade. Sinceramente acredito que muitas vezes é o ambiente que leva o profissional a esta situação. A empresa, um gerente, as vezes até um cliente, acabam forçando o profissional a fazer tarefas inutéis, se preocupar com outras coisas a não desenvolver boas soluções para os clientes.
Vou aproveitar e adicionar um personagem típico aqui no Brasil, o Analista de sistemas documentador. A carreira em uma empresa (ou departamento) de desenvolvimento no Brasil costumava ser: programador -> analista de sistemas -> coordenador de projetos. (Acho que isto finalmente está mudando aos poucos)
O programador, que realmente coloca a mão no código, é o nível de entrada. Um bom programador que se destaca em pouco tempo é promovido a Analista de sistemas! Então a função dele passa ser entender os requisitos e transformá-los em documentação que o programador possa entender. Pode ser um DFD, um modelo UML ou até um texto mais "técnico".
Isto significa que alguém que se destaca como desenvolvedor pára de desenvolver código e passa a desenhar figurinhas que representam código! Percebem a ironia? O pior de tudo é que a função do analista de sistema é entender o que o cliente disse e traduzir para o programador...alguém já brincou de telefone mudo? Pois é, o analista de sistemas torna-se uma camada inútil de abstração, um ruído na comunicação entre quem sabe o que deve ser feito e quem vai fazer.
De novo, não acho que o profissional é o culpado, ele simplesmente está buscando seu lugar ao sol, aceitando uma promoção e botando mais dinheiro no bolso no final do mês.
Eu já atuei neste papel por bastante tempo. Durante algum tempo eu acreditava que minha atuação era importante no processo. Depois eu já duvidava disto, mas demorou mais um pouco para que eu mudasse radicalmente de opinião.
Atualmente acredito fortemente em eliminar desperdício (ver Lean Software Development) e, neste caso, parte da atividade do Analista é exatamente isto. Um atravessador de informações, que agrega muito pouco valor neste processo.
Para mim o desenvolvedor deve ter mais responsabilidades: deve ler a especificação funcional, conversar com o cliente e desenhar e implementar a sua solução. Não acredito em qualquer processo que delega implementação para os membros menos qualificados e/ou mais jovens da equipe. No final das contas, código-fonte é o que entregamos para o cliente, o resto é papel...