Gerenciando e motivando desenvolvedores

Um novo artigo sobre o tema gerenciamento e motivação de desenvolvedores foi publicado no site CIO.com, nesse text a autora Esther Schindler apresenta uma pesquisa feita com vários desenvolvores de lista de discussões, fórums e outros canais na internet. Não é uma pesquisa com embasamento científico, mas contém algumas respostas interessantes sobre o que os próprios desenvolvedores esperam de seus gestores.

Embora o texto não tenha teor científico e nem uma análise profunda sobre os dados coletados a leitura é válida, pois quem já teve oportunidade de coordenar ou gerenciar equipes de desenvolvimento encontrará muitas características inerentes aos desenvolvedores.

As respostas dos desenvolvedores trazem algumas dicas sobre como trabalhar com eles:

• Confie nos desenvolvedores, deixe que eles façam seu trabalho
• Se quiser que seus desenvolvedores sejam criativos, dê tempo e espaço para que eles pensem e criem.
• Desenvolvedores, no geral, são altamente competentes individualmente.
• Não diga aos desenvolvedores como fazer ( é uma crítica as metodologias que visam transformar o desenvolvimento em um modelo de “fábrica” )
• Nada acaba tão rápído com o espírito de um desenvolvedor quanto receber uma tarefa em conjunto com instruções de como completá-la ( também referente ao ítem acima )
• Não peça aos desenvolvedores para fazerem tarefas que não sejam de desenvolvimento. ( ler item abaixo )
• Desenvolvedores vêem seus gerentes como “protetores” dos serviços burocráticos da organização, como reuniões, papeladas e etc.
• Gestores não devem ficar perguntando todos os dias sobre suas atividades e nem relembrando os desenvolvedores dos seus prazos.
• Gestores devem saber ouvir, responder e elogiar os seus desenvolvedores.
• Seja direto ao falar com os desenvolvedores, muitos deles não entenderão indiretas.
• Enfim, quando as pessoas, aprenda a dar feedback.

Esses são alguns dos ítens comentados ao longo do texto, claro que fui muito direto e conciso aqui, vale a pena a leitura do texto para ver as idéias a autora e a sua explicação/explanação sobre esses ítens. Um assunto que não coloquei na lista mas que deixou um ar de espanto foi o do dinheiro, muitos desenvolvedores comentaram simplesmente que o dinheiro é o que os motiva, reclamando dos seus salários. Claro que o dinheiro é um fator crucial para muitos, principalmente para quem possui família, contudo, ser colocado como fator principal é assustador, pois desenvolver sempre foi uma atividade feita por pessoas que gostam do que fazem, sendo o dinheiro a consequência, e não o fator motivacional.

É difícil para muitos gerentes de projeto mensurar o tempo e a qualidade do trabalho feito por desenvolvedores, e a forma como se dará esse laço de envolvimento entre o gerente e seus desenvolvedores é muito importante para diminuir erros e imprevistos no projeto.

IMHO, o desenvolvedor tem que ser muito versátil e saber trabalhar com dois tipos de atividades, a primeira é uma atividade de desenvolvimento menos intelectual, mas ainda importante, e a outra atividade é o desenvolvimento, envolvendo criação.  O gerente deve saber identificar essas atividades, a primeira é mais comum e repetitiva, é fácil prever e acertar um prazo enquanto a segunda é mais desafiadora e mais complexa a definição de prazo. Para exemplificar, a atividade menos intelectual seria a criação de formulários, inserção/alteração e remoção de registros enquanto a segunda seria a criação de um software  ou recurso ainda não existente no mercado ou que esteja fora do know how da equipe, como por exemplo um softphone para televisão HDTV.

O comentário feito a cima não parece pertinente ao texto, mas ao lê-lo é perceptível que as opiniões apresentadas no texto são de desenvolvedores que estão acostumados a trabalhar com inovação e com projetos não triviais e desafiadores, mas que com certeza devem também trabalhar com atividades menos intelectuais, mas necessárias para a organização e/ou projeto. Acredito que o gerente deve identificar o perfil dos seus colaboradores e  saber mesclar as atividades para deixar o desenvolvedor motivado obter os resultados para organização.

No âmbito do PMI o gerente deve conhecer bem a área de Recursos Humanos e Comunicações, não sou um especialista mas segundo meus estudos e leituras as boas práticas do PMBOK auxiliam na identificação e na forma de trabalho com os colaboradores de um projeto.

Simplicidade

Estou aproveitando as férias(yeah!), enquanto aproveitava a oportunidade para colocar minha leitura dos RSS em dia me deparei com um pequeno artigo que fala sobre “simplicidade”. O “textículo” ou pequeno texto (como preferir) foi escrito por Joel Spolsky (desenvolvedor de software).

Na minha opinião o texto é uma crítica e ao mesmo tempo um aviso sobre o mal uso do termo simplicidade, muitas vezes generalizado em várias áreas como desenvolvimento de software ou produtos (comentado pelo Luiz de Paiva).

A leitura do artigo com a mente aberta, isto é, captando a essência das idéias, permite abrir novas discussões e pensamentos interessantes acerca de como nós vemos, entendemos e aplicamos a simplicidade.

Na minha opinião a simplicidade é sempre a melhor alternativa desde que não deixemos de fazer o melhor, não acredito que esse conceito seja fácil de entender e aplicar, mas é algo que muitas pessoas devem se acostumar a lidar.

Uma parte muito interessante do texto diz o seguinte: “Uma grande parte dos desenvolvedores de software são seduzidos pela velha regra do ‘80/20′” (fazem 20% das funcionalidades pois 80% das pessoas usam apenas 20%) “[...]Infelizmente, as pessoas nunca usam o mesmo conjunto de 20% das funcionalidades“.

Especificamente na parte de projetos de software é muito comum ouvirmos dizer “o simples é o melhor”, contudo este texto nos alerta sobre essa armadilha e nos traz algumas dúvidas, simples é o produto fácil de usar ou o que tem menos funcionalidades? A quantidade de funcionalidades e simplicidade de uso são relativas entre si (+ funcionalidades = + complexidade)?

Para os que têm interesse no assunto vale a pena a leitura. Encontrei o artigo no blog stakeholder mantido por Luiz de Paiva, e o artigo pode ser lido aqui.