Gestores de projetos e área de atuação

Um Gestor de Projetos tem que ter conhecimento técnico na área em que vai atuar?

A resposta deveria ser: preferencialmente, sim !

E caso esta resposta gerasse uma nova pergunta, do tipo : “mas por que?”, a resposta seria : simples; porque este profissional deve ter um mínimo de conhecimento técnico na área em que vai atuar.

Soou meio redundante e evasivo, não é mesmo? Mas nisto mora um grande perigo.

Imagine a seguinte situação: Uma grupo de 11 desenvolvedores, 3 analistas de negócios, 2 analistas de vendas.

O grupo de desenvolvedores foi dividido em 3 equipes : os mais antigos e experientes, mantendo o framework e os módulos de alta complexidade, um segundo grupo com profissionais de média experiência, para módulos de média complexidade, e um terceiro grupo para emergências e módulos de baixa complexidade.

Em cada equipe, um líder, e um dos líderes coordenando todo o grupo.

Todos os colaboradores tem seu grau de excelência dentro de suas qualificação, e procuram melhoria constante.

Então é contratado um Gestor de Projetos que não tem a mínima ideia de como funciona o desenvolvimento de software.

Mesmo contando com uma equipe excepcional, este gestor passará por algumas dificuldades se não possuir um mínimo de conhecimento na área como, por exemplo, perceber o comportamento dos desenvolvedores, o timing de cada um, a diferenteça de complexidade entre um módulo e outro, onde está realmente o “gargalo” do desenvolvimento, além de inúmeros outros problemas.

Claro que existem muitos gerentes generalistas que possuem um feeling muito grande, mas que, ainda assim, podem acabar cometendo erros no planejamento, na execução, no acompanhamento, na mitigação de erros, na gestão de riscos.

Continuando o exemplo acima, imagine agora uma pessoa totalmente despresparada, que não faz a mínima noção de como funciona o desenvolvimento de software (sua complexidade, relacionamentos entre classes e tabelas, graus de dificuldades), se contratada e nomeada como Coordenadora desta equipe.

Os problemas de comunicação serão enormes. Se algum problema for direcionado à este gestor, ele não terá condições de entender a causa, as formas de tratamento, as possíveis soluções.

No caso de um prazo, ele não terá condições de “negociar” com os desenvolvedores.

Se o problema for uma duplicação de dados, onde o registro de um campo está sendo duplicado exponencialmente (1 registro gera 1 duplicata; 2 registros geram 4 duplicatas, 3 registros geram 9 duplicatas, e assim por diante), ele tentará conversar, inicialmente, com o DBA e pedir uma solução.

Mesmo que o DBA afirme categoricamente que este é um problema gerado pelo aplicativo, o gestor ainda assim insistirá para que o DBA corrija o erro.

Após alguns  transtornos, finalmente o gestor procura o desenvolvedor de relatórios, e pede para o mesmo consertar o programa.

O desenvolvedor analisa e garante que o problema não é o relatório. Para não prolongar, só nestas interações, já se perderam 2 dias, e o problema persiste.

Finalmente este gestor se curva à primeira informação e redireciona o problema para um desenvolvedor que, numa análise simples do problema apresentado, concorda com o DBA de que se trata de um loop que está duplicando estas informações.

Este caso retrata uma situação real, ocorrida em uma empresa real.

Este gestor teve uma série de problemas de relacionamento com a equipe, tendo que ser afastado desta função.

Eu, o autor deste artigo, não conheço absolutamente nada em matéria de construção civil e jamais aceitaria trabalhar como Gestor de Projetos de construção.

Claro que, após alguns erros e um tempo de vivência, o conhecimento chega. Mas a empresa, muitas vezes, não pode pagar o preço da espera.

O melhor a se fazer, exatamente como reza a maioria das metodologias de Gestão de Projetos, é aproveitar as lições aprendidas, muitas vezes chamadas de experiências pessoais, de profissionais que já vivenciaram várias situações na sua área de atuação.

Sobre o Colunista: Carlos Amaral tem formação em Gestão da Produção Industrial, especialização em Gestão da T.I. e certificação PRINCE2. Trabalha com desenvolvimento de software desde 1989, tendo atuado em praticamente todas as funções dentro de seu ciclo de vida, e participando de projetos ERP e CRM para os mais diversos segmentos de mercado. Entusiasta de software livre, acredita que liberdade é respeitar, também, os entusiastas de software proprietário. Consultor em Projetos de Software, VLogger e autor de artigos na sua área de atuação, não se prende à uma determinada metodologia, procurando extrair o melhor de cada mundo, conforme o cenário.

E-mail de contato: chayimamaral@gmail.com – Site : www.carlosamaral.eti.br

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.