Bem, este vai ser um post polêmico (e longo). Mas eu preciso botar isso pra fora.
Primeiramente, antes que você me acuse de não saber do que estou falando, é importante mencionar que eu, além de possuir a certificação de PMP, já dei inúmeros treinamentos e implantei vários escritórios de projeto Brasil afora nos meus sete anos de consultoria. Mas durante este tempo todo eu ficava com um incômodo estranho, uma sensação de que havia algo errado com o gerenciamento de projetos aos modos do Project Management Institute – o famoso PMI – e de sua “bíblia”, o PMBOK, até então o “estado da arte” em GP. Tudo era complexo demais, as pessoas se perdiam no método e gastavam mais tempo montando documentação e estudando cronogramas do que efetivamente entregando os projetos. Pra piorar, eu fui trabalhar numa agência e quando cheguei, achei inúmeros projetos, a maioria com prazos ridículos para acontecer, sem documentação formal, sem tratamento de riscos, tocados por gerentes de projeto sem nenhum treinamento… e que ficavam prontos, às dezenas.
E foi então que a ficha caiu e consegui identificar a razão do meu incômodo. Ela é meio complicada de explicar, mas vamos lá.
Problema número 1: As práticas do PMI foram concebidas com foco nos meios, e não nos fins.
A impressão que dá é que o PMI atacou o problema de “como gerenciar um projeto” como bons engenheiros: dividiram o problema em partes menores – escopo, tempo, custo, etc. – e se enfiaram numa análise minuciosa de tudo que precisa ser feito em cada uma dessas partes – o que resultou nas mais de 450 páginas cheias de fluxogramas aracnídeos do PMBOK.
O PMBOK já está em sua quarta edição e até agora ninguém se tocou que ele foi feito em cima da pergunta errada. A certa deveria ser: “O que é que faz um projeto dar errado?”. Porque, apesar de cada projeto ser único, eu aposto que uma boa pesquisa encontraria vários problemas iguais ocorrendo em projetos de mercados e/ou produtos diferentes. Aí você analisaria estes problemas, detectaria suas causas e só então estabeleceria um jeito padronizado de agir.
Se você não sabe o que quer resolver, acaba sendo genérico demais para cobrir todas as possibilidades ou minucioso demais tentando tapar todos os possíveis furos. É como se você tivesse que instruir alguém a fazer uma longa viagem a pé e, sem saber nada sobre o caminho por onde a pessoa vai passar, você fala que a pessoa pode levar roupas de calor, de frio, de chuva, uma bóia pra se tiver um rio, um esqui pra se tiver neve, etc., etc., e ela passa dias decidindo e sai com 150 quilos de bagagem e não consegue chegar ao destino porque não aguenta arrastar toda aquela traquitana.
Só que, infelizmente, a galera que montou o PMBOK fez um belo trabalho e concebeu um framework de gestão que, apesar de complexo, é muito bem amarrado, tanto que chega a ser fascinante. O que nos leva ao…
Problema número 2: As pessoas se deslumbram com o framework do PMBOK
Imagine que você é um daqueles caras formado em alguma ciência exata, como engenharia ou computação. Você naturalmente gosta de um desafio intelectual, então acaba se dando bem na sua profissão e, algumas promoções depois, acaba caindo num cargo de gerente de projeto (porque todos os concorrentes da sua empresa também tem um). De repente todo aquele seu conhecimento técnico passa a não valer de nada, porque seu trabalho mudou da água pro vinho e você tem que lidar com pessoas, processos e políticas ao invés de diagramas e softwares. Seus dias de trabalho ficam bem desconfortáveis.
Aí você, como bom engenheiro, vai buscar um “manual” que te explique como lidar com aquilo tudo. E você quer logo o melhor que existe. Então não demora muito até você chegar ao PMBOK.
Já na primeira leitura você começa a ver todas aquelas coisas que está tendo problemas para lidar, todas elas rotuladas, descritas e categorizadas. Aquela bagunça de gente onde você não sabe quem manda em quem no projeto vira uma “estrutura matricial balanceada”. Aqueles momentos onde você não sabe se deve mandar um email ou ligar para a pessoa viram “comunicações formais escritas” ou “horizontais formais orais” ou “verticais informais escritas”. Aquele livro mágico te dá um prisma para você entender esse mundo novo todo – e ainda por cima te dá todo o processo para lidar com seus projetos. É como o Player’s Handbook para projetos.
E pra completar, te dizem que, se você aprender direitinho o que tem no PMBOK, pode fazer uma prova super difícil, de 400 perguntas, que vai te certificar como um disputadíssimo Project Management Professional. Pronto: está lançado o teu novo desafio intelectual.
E pronto, você foi convertido.
Só que, como eu disse ali em cima no problema 1, todo esse framework é montado em cima de uma premissa errada. Mas ao invés da pessoa perceber isto, ela acaba enfiando a cabeça mais e mais nele. Pior, ela adota o mesmo modelo mental usado pelo PMI para conceber o PMBOK como seu próprio modelo mental para tocar os projetos. Assim, ao invés de focar em resolver os problemas do projeto, o gerente acaba achando que a solução está em novos fluxos, formulários, categorizações, modelos de priorização, etc, etc, “ensimesmando-se” no método cada vez mais ao invés de focar nos resultados desejados e estruturar seu plano de ação a partir deles.
Durante a minha carreira eu cansei de ver gerentes de projeto com PMPs, MSCs, PHDs e o escambau, conhecedores de tudo que existe por aí em termos de metodologias, processos, frameworks, softwares e o escambau… todos eles incapazes de gerenciar um projeto. Uns eram muito bunda-moles, outros tinham problemas sérios de relacionamento… um deles, que conheci recentemente, quando questionado por que seu projeto ia mal, respondia, indignado, que “não estão me dando condições de cumprir todos os ritos da metodologia”.
“Puxa, mas não é possível que ninguém se toca disso no mercado”, você deve estar pensando. Acontece que, quando você olha por aí pra ver o que os “grandes especialistas” do assunto estão dizendo, fica horrorizado porque ELES não somente são os maiores punheteiros de metodologia que existe, como também estão usando esta ilusão coletiva para ganhar dinheiro. O que nos leva ao…
Problema número 3: A comunidade de gerenciamento de projetos em torno do PMI é repleta de picaretas.
OK, sei que esta é uma acusação séria, mas ela fica mais fácil de entender à luz dos problemas 1 e 2 que eu expus anteriormente.
Sob a ótica que estou defendendo neste texto, o bom profissional de gerenciamento de projetos deveria ser aquele que entrega resultados. Aquele que pega projetos de risco e consegue concluí-los, aquele que tem uma consistência de entregas bem-sucedidas ao longo de sua carreira, aquele que consegue mobilizar bem as equipes, aquele que garante o ROI do capital investido. Acontece que, em todos os meus anos trabalhando com gerenciamento de projetos, eu nunca vi nenhum dos tais fodões do GP falando em resultados dos seus projetos. Na verdade eu nunca vi nenhum desses fodões dando detalhes de NENHUM projeto que tenha entregue. Mas vejo esses caras o tempo todo punhetando metodologia com cara de deslumbrados.
A maior autoridade do Gerenciamento de Projetos no Brasil hoje em dia é Ricardo Vargas. No site tem a biografia dele. Diz lá que ele foi responsável por mais de 80 “major projects” compondo um portifólio de investimentos de “over 18 billion dollars”. Mas foi ele quem tocou os projetos? E qual foi o ROI destes 18 bilhões investidos? Por essa mesma ótica eu posso falar que, com nove meses de agência, sou responsável por centenas de projetos (são meus GPs quem tocam, mas em última instância eu sou o responsável), compondo um portifólio de investimento de vários milhões de reais (valor pago pelos clientes, somado). Ou seja, sem falar em ROI é fácil ficar expondo números grandes por aí. Mas ao invés de focar nessas coisas, a biografia de Ricardinho fala de seus inúmeros títulos, certificações, as suas empresas e os seus inúmeros livros escritos – livros estes que foram o que o alavancou para a fama.
Os outros nomes poderosos do GP no Brasil também costumam ser conhecidos por suas palestras e treinamentos. Uma vez, quando o PMI lançou o “standard para Gerenciamento de Portifólios”, eu fui fazer um treinamento de gestão de portifólio com um desses fodões do mercado. Foi o pior treinamento que já fiz em toda a minha vida: o cara gastou 10 minutos lendo o fluxograma do livro e depois passou o resto do tempo repetindo coisas sobre gerenciamento de projetos (era um treinamento de portifólio!), mostrando videozinhos motivacionais, falando de coisas nada a ver. Eu desci tanto o pau no formulário de avaliação do curso que o pessoal da escola chegou a me telefonar pra saber o que tinha sido tão errado.
No ano retrasado, Rita Mulcahy veio ao Brasil para uma palestra. Rita é uma personalidade mundial do gerenciamento de projetos – se você estudou para a certificação PMP, com certeza usou o “Livro da Rita”, já que ela é autora do melhor livro preparatório para o exame. Um amigo meu foi ver a (disputadíssima) palestra dela e ficou horrorizado: foi basicamente uma palestra de auto-ajuda, cheia de “dinâmicas de integração”, piadinhas, lições de moral estilo Paulo Coelho.ppt… e nenhum resultado de projeto foi mencionado.
De fato, se você for ver a programação dos grandes eventos e seminários de GP que acontecem todo ano, no Brasil ou no mundo, vai ver como também nestes casos a falta de foco em resultados e a masturbação metodológica é predominante. Em novembro tem o Congresso Brasileiro de GP, no Ceará. São três dias de palestras. Apenas UMA delas é um estudo de caso – que eu aposto que vai focar na metodologia usada na gestão do projeto e não no que ele entregou. Eu já cheguei ao absurdo de ver eventos desses cuja programação incluía palestras sobre o gerenciamento dos jogos panamericanos do Rio – que foram cheios de atrasos e que custaram mais de 10 vezes o que foi previsto!
Aí você pergunta: “então ferrou, como é que eu vou tocar meus projetos então?”. Bom, lá na firrrma o que tem dado certo é:
1) Ignorar quase tudo do PMI e usar metodologias ágeis, como o Scrum. A turminha de agile acertou muito a mão, mesmo porque eles partiram da premissa certa para montar sua forma de trabalho.
Isso fica bem óbvio no Agile Manifesto:
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Percebe que, nas entrelinhas dos últimos quatro parágrafos, eles não somente elencam os principais problemas de projetos de software como também proclamam um modo de trabalho focado nos fins, nos resultados, ao invés dos meios?
Importante: este post não é propaganda gratuita de Scrum – mesmo porque o Scrum, apesar de eficaz, tem problemas bem parecidos com o PMI, como por exemplo uma “indústria de certificação” onde basta você fazer um treinamento de 16 horas para se tornar um Certified ScrumMaster. É ridículo.
2) Formalizar só o que for estritamente necessário, tomando muito cuidado pra não “solucionar problemas que não existem” e adicionar complexidade onde não precisa. Por exemplo: para vários projetos pequenos lá da agência um simples email de “briefing” do trabalho vale como declaração de escopo do projeto. Porque no tempo que eu levaria para montar uma WBS, dicionário da WBS, declaração formal de escopo e não-escopo, já passou metade do prazo e o escopo já vai ter mudado todo…
Pra descobrir o que tem que ser formalizado e documentado, sugiro uma regra simples: se a falta de formalização de alguma coisa é causa de problemas nos projetos, formalize. Caso contrário, deixe como está. É como dizem: “se não está quebrado, não conserte”.
3) Selecionar GPs com “sangue no olho”, mesmo sem conhecimento do método. Sabe aquele cara que pode nunca ter tido um treinamento de GP na vida, mas que tem sabe avaliar um problema, tem uma atenção obsessiva para datas (mesmo sem cronograma) e um carisma tamanho que a equipe do projeto toda come na mão dele? Esse cara vale mais do que qualquer metodologia de projeto. Porque na hora em que tudo dá errado o que você precisa mesmo é de alguém que demonstre liderança, que pegue o touro pelo chifre, que articule com todo mundo no olho do furacão e faça o que for preciso pra entregar.
Além do mais, é fácil dar conhecimento do método para um GP – basta botá-lo em treinamentos. Já “sangue no olho”, foco nos resultados, ou o cara tem ou não tem, não há treinamento ou coaching no mundo que implante isso, especialmente nos viciados em metodologia.
Pronto, falei. Agora me xingue aí nos comentários, afinal estamos na internet é pra isso 
