Me recordo que certa vez, em uma aula do MBA em Gestão de Projetos no qual me formei, discutíamos sobre as metodologias, padrões e melhores práticas e qual seria a mais adequada a determinado tipo de projeto e/ou indústria. Lembro que a discussão não coube em uma aula porque, como vocês sabem, o brasileiro nos últimos 5 anos, estranhamente, entrou em um “modo divisão” no qual qualquer discussão põe as pessoas em lados opostos e assuntos amenos tornaram-se briga de torcida organizada. E não foi diferente nessa aula, gente culpando o Scrum, outros culpando o PMBOK, sobrou até para o ITIL (lol).

O bom de já estar há muito tempo nessa área é que você consegue ver esse tipo de discussão e ter a certeza de que ainda há muito o que as pessoas aprenderem, principalmente fora da ementa dos MBAs ofertados pelo país. Eu sou de uma época em que o gerenciamento de projetos era ensinado como algo focado em processos e não em pessoas e isso realmente era um problema porque acreditávamos (inocentemente) que os métodos precisavam de ajustes. E aí começou toda a discussão sobre o que seria melhor para gerenciar projetos: as práticas do PMI, o método Prince2, o padrão ISO/IEC 21500, o Scrum, o RUP, o GoHorse (só pra descontrair), etc.

Eu não quero nem entrar na discussão sobre o Scrum ser melhor para projetos de desenvolvimento de software, o PMBOK e Prince2 serem melhores para projetos de infraestrutura, seja ela qual for. Acho bem inútil essa discussão porque, no frigir dos ovos, o Scrum não resolve os problemas causados pela ação (ou pena inação) das pessoas em projetos de software, o PMBOK idem.

Na minha opinião não há dúvidas que o melhor padrão/metodologia/melhor prática para gerenciar projetos não existe. Ficou frustrado? Não fica não, isso não é uma verdade absoluta, é apenas a minha opinião. Não importa que escolha você ou sua empresa faça pelo método, o segredo não está nos processos, está nas pessoas. O que nós, como profissionais em gerenciamento de projetos, fazemos durante toda a nossa carreira é tentar adequar as pessoas aos processos e não os processos às pessoas.

Por esses dias me enviaram um artigo (que agora eu não vou me recordar a autoria) falando sobre o fracasso do PMBOK e do Scrum na gestão de projetos e eu honestamente achei até demoraram muito para reconhecer isso, porém, mais uma vez, culpar o método é sempre o caminho mais fácil. O primeiro grande erro é o entendimento equivocado do que é gerenciar projetos e quem deve ser o responsável por isso. Geralmente, quando um projeto é iniciado, as pessoas envolvidas (independentemente do nível de envolvimento) não têm uma expectativa correta do que se espera como resultado desse projeto e isso acontece simplesmente porque os responsáveis pela gestão do projeto não engajam corretamente essas pessoas.

Quer um exemplo?

Um projeto para construir uma estrada usa as melhores práticas preconizadas pelo PMBOK como método de gestão. Abstrai se o cliente é iniciativa privada ou governo tá? No PMBOK, quem são os principais atores para coleta de requisitos e identificação dos riscos? As partes interessadas: cliente, fornecedores, sociedade civil e por aí vai. Como é feito o engajamento dessas partes no projeto? Se esse projeto seguir as melhores práticas (processos, ferramentas e técnicas) quais as chances de dar errado? Eu entendo que mínimas né, você entende diferente? O processinho tá ali ó… entrada, processamento e saída, tudo bonitinho, certo? Por que esses projetos estouram orçamentos e prazos? Por que parte dessas obras serão embargadas? Tá todo mundo pensando esse projeto dentro da mesma expectativa? Será que um gerenciamento 360º, com todos os lados contribuindo com inputs relevantes, não reduziria a probabilidade de estouro?

Quer outro exemplo?

Agora usando o Scrum. Uma empresa está construindo um software de gestão de ativos para um cliente XPTO. A gestão de ativos desse cliente era feita anteriormente usando planilhas do Excel. O Product Owner (o “dono do produto”) está alocado dentro do cliente e é o responsável por entender a necessidade dele, determinar quais as prioridades e quais os critérios que farão com que o cliente aceite aquilo que foi produzido. Apesar da proximidade, o PO só tem reuniões com os gerentes de TI da empresa contratante. São esses caras que vão utilizar a ferramenta? Não… Quem está faltando ser engajado nesse projeto? Quem pode fornecer inputs essenciais para entrega do produto? Se você já participou de um projeto de desenvolvimento de software, me fala um que não houve necessidade do time fazer hora extra para entregar uma demanda que estava atrasada por falta de definição funcional? Mas tá lá, estamos trabalhando com o Scrum, do jeito que o Guia diz que é para trabalhar.

Resumindo: será que realmente a culpa é do método? Alguém já pensou em focar a gestão do projeto nas pessoas ao invés dos processos?

Gente, um projeto é um grande acontecimento, independente do tamanho ou valor que empregado nele. Não é algo para ser feito à 2 ou 4 mãos… tem que jogar com instinto de centopeia mesmo, os processos sem as pessoas são só caixas vazias com setas coladas nas arestas. As pessoas não devem se adequar aos métodos, tem que ser feito exatamente o contrário.

Novamente: culpar o método é sempre o caminho mais fácil, mas nem sempre é o correto.

Wagner Borba
Articulista / Manager 3.0