BT

A culpa é do gerente de projetos?

por Christopher Goldsbury , traduzido por Giovanni Abner em 04 Nov 2011 |

Os problemas com pessoas, e não com tecnologia, são culpados pelo insucesso de projetos de desenvolvimento de software. Esse é o ponto de vista relatado em um artigo recente do Computerworld. Os gerentes de projetos, em particular, são apontados como sendo a fonte da maioria desses problemas. De acordo com Billie Blair, da Change Strategists Inc., as organizações promovem, a esse papel crítico, pessoas que se destacam como técnicos, apenas para descobrir mais tarde que não têm as habilidades necessárias para desempenhar efetivamente o trabalho. Eles não estão prontos. Diz Blair:

Qualquer coisa que dá errado em uma empresa sempre pode ser rastreada até o gerente.

Técnicos podem assumir com sucesso papéis de gerenciamento? Muitas organizações reconhecem a divergência extrema entre as aptidões exigidas por esses dois papéis, e implementam algum tipo de carreira dupla. A carreira técnica normalmente recompensa conhecimento e habilidades técnicas, com pouca exigência de talentos no gerenciamento de pessoas. A carreira gerencial, pelo contrário, conduz o candidato a responsabilidades cada vez maiores em gestão de pessoas, supervisão financeira e visão estratégica.

A decisão sobre qual carreira seguir pode ser difícil para qualquer pessoa. Pawel Brodzinski escreveu um post sobre essa escolha e como, na sua opinião, ela é mutuamente exclusiva:

Uma qualidade que faz de você um grande engenheiro normalmente o torna ao mesmo tempo um gerente ruim.

Haveria exemplos indicando que uma pessoa pode navegar por papéis técnicos e gerenciais ao mesmo tempo? Na web existem muitas discussões sobre se essas habilidades devem ser cultivadas em paralelo. Seguem trechos de uma dessas discussões (cada um por um autor diferente):

 

Depende da quantidade e do tipo de programação que são exigidos, e da quantidade de obrigações gerenciais.  

 

Participei de uma equipe de desenvolvedores onde um dos programadores era também nosso gerente. Isso conduziu a um colapso total de tudo que lembrasse a produtividade. Em resumo, todas as decisões eram tomadas por ele, e ele era um completo microgerente.

Embora seja possível na maioria dos cenários, na minha opinião não é bom. Há diversos artigos sobre como desenvolvedores excelentes são levados para um papel de gerente de equipe, mesmo que essa não seja sua habilidade específica ou a posição desejada. Eles têm dificuldade para manter o foco no 'gerenciamento' porque consideram como 'trabalho' desenvolver, e não criar relatórios ou ir a reuniões.

Um elemento que está modificando essa discussão é o papel das metodologias ágeis. Visto que elas alteram e minimizam o papel tradicional de gerente de projetos, ao mesmo tempo em que aumentam a responsabilidade dos desenvolvedores, há quem argumente que isso diminui a possibilidade de haver um ponto único de falha nos papéis da equipe.

Outro ponto de vista nesse debate é apresentado por CA Atreya. Ele cita um estudo de 2005 sobre motivos de falhas de projetos, que mostrou que o maior problema são definições de requisitos inadequadas.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Pessoas são... Pessoas by Victor Tales

Gostaria de deixar claro que pessoas são pessoas, como desenvolvimento de software é uma parte da engenharia personalidades diferentes e capacidades diferentes são muitas vezes colocadas em segundo plano. E esse é o maior problema e não o Gerente de Projetos, o maior problema é a falta de respeito, amizade e empatia. Empatia é a palavra nesse caso, pois nós desenvolvemos máquinas, mas não somos uma e muitos engenheiros de software tem empatia zero ou pior fazem de conta que tem o que torna os relacionamentos inter-pessoais superficiais.

Em suma, o Gerente de Projetos não é culpado, a culpa são de todos. Se um projeto falha o time todo FALHOU. É por isso que temos retros ao final de uma Sprint para avaliar o que deu certo e errado e NÃO quem deu certo e errado. Enquanto as pessoas agirem fora do time para demonstrar suas capacidades técnica ou pessoais para se destacar dentro de um modelo piramidal (Diretor, Gerente, Arquiteto, Líder e etc) vamos ter projetos de software falhando a todos os lados.

Re: Pessoas são... Pessoas by Robson de Almeida

Discordo um pouco de você.

Primeiro discordo desta visão de desenvolvimento de software como "uma parte da engenharia". Para eu, fazer software e construir prédios, máquinas, etc, são coisas bem diferentes hoje em dia.

Concordo que projetos de software dão muito mais errado por causa das pessoas do que por outros motivos. Porém, não vejo, atualmente, como o GP (que deveria ser o responsável pelo projeto) possa modificar esta situação. A idéia de um líder que motiva, desempede e faz parte da equipe, me parece muito mais eficiente. A responsabilidade do projeto é da equipe. O líder ajuda a equipe a alcançar seus objetivos. Quanto a aspectos financeiros e outros que fazem parte de um projeto de software mas que, ao meu ver, não devem estar nas mãos da equipe, devem estar nas mãos de quem sabe conduzí-los. Pessoas que sabem como cuidar de finanças, etc.

Re: Pessoas são... Pessoas by Vinicius Serpa

Não sei não, pra mim engenharias tradicionais e desenvolvimento de software são coisas bem semelhantes, exceto pela característica "adaptativa", que faz com que os sistemas de software sofram mudanças constantes.

Re: Pessoas são... Pessoas by Vinicius Serpa

... e, lógico, pela questão "imaterial".

Re: Pessoas são... Pessoas by Robson de Almeida

... adaptativa, imaterial, em desenvolvimento de software você não precisa ficar meses calculando, medindo, planejando e etc, para ter seu produto final. Em desenvolvimento de software, um defeito pode ser corrigido em 2h a uma semana, sem que um prédio ou avião tenham que cair, sem que um acidente tenha que ocorrer, sem a necessidade de um recall, etc (veja bem, estamos falando de aplicações empresariais). Quanto custa para uma montadora fazer recall por defeito de fabricação? Quanto custa para uma aplicação web/mobile/desktop fazer uma atualização? Quanta infraestrutura é necessária para construir um prédio ou um avião ou um automóvel? Quanta infraestrutura é necessária para se desenvolver software?

Por estas e outras questões acredito que esta analogia entre engenharia (prédios e tudo mais) e desenvolvimento de software, está ultrapassada.

.. apenas opinião. Mas acho que este assunto já está saindo do foco do artigo.

Voltando ao foco, para eu, projetos de software não precisam de um papel explícito de gerente. Projetos de software precisam de um líder e uma boa equipe.

Re: Pessoas são... Pessoas by Vinicius Serpa

Oi Robson,

Respeito muito a sua opinião, mas eu mudei muito o meu conceito depois que passei a trabalhar em uma empresa de engenharia tradicional (mecânica/civil/química). Vi que na prática existem as diferenças, mas existem muitas semelhanças. E tudo o que vc comentou depende muito do contexto do software. Exemplo:

- desenvolvimento de software você não precisa ficar meses calculando (depende do tamanho do software e do valor a ser investido, o cliente não vai querer gastar 1 centavo antes de se ter uma idéia completa da viabilidade)

- um defeito pode ser corrigido em 2h a uma semana, sem que um prédio ou avião tenham que cair (um software complexo pode receber uma correção que pode demorar semanas para ser projetada, e quando colocada em produção pode injetar erro no sistema que acaba comprometendo o faturamento da empresa - dependendendo da situação pode sair tão caro qto um avião).

- os demais argumentos sobre infraestrutura e recal caem na questão do "imaterial" do software. Ele não possui custo porque não envolve matéria prima, mas nem por isso não deva ser projetado.

De qualquer maneira essa é a minha forma de entender sobra a área, claro que posso estar redondamente enganado e a sua visão estar correta. Mas prefiro pensar dessa forma, que software é uma engenharia, diferente das tradicionais, mas não deixa de ser engenharia. Que o IEEE formulou o SWEBOOK (Software Engineer Body of Knowledge) porque faz sentido a área ter essa denominação e ficar sob "tutela" de um órgão de engenharia e que o Brasil está investindo na graduação em Engenharia de Software porquê entende que a área precisa ter um certo nível de maturidade para prosperar.

Enfim, peço desculpa tanto a você bem como aos demais que lêem o artigo por ter saído completamente do escopo.

Re: Pessoas são... Pessoas by Luiz Henrique Ferreira

Colocar a culpa no Gerente de Projetos é a mesma coisa que "pedir a cabeça" de alguém da equipe quando algum projeto falha.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

7 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT