Essa é uma questão me fazem vez ou outra. Me senti na dívida de explicar melhor o assunto, e cá estamos. A questão ocorre como se ao adotar uma metodologia ágil, a pessoa estivesse de alguma forma “subvertendo os preceitos do PMBoK”, e isso poderia estar indo contra o “código de ética dos PMP’s”, como se um padre pregasse sem seguir a Bíblia ou coisa assim. Que pecado!

A má interpretação mais recorrente é que o PMBoK é um processo, assim como seriam as metodologias ágeis, e que esse processo deve ser seguido fielmente pra seu projeto dar certo, pra você ser um bom gerente de projetos, ter sucesso, etc. O PMBoK não define um processo, é um conjunto de conhecimentos e as ditas melhores práticas.  Da introdução:

“O Conjunto de conhecimentos em gerenciamento de projetos é a soma dos conhecimentos intrínsecos à profissão de gerenciamento de projetos. (…) inclui práticas tradicionais comprovadas amplamente aplicadas, além de práticas inovadoras que estão surgindo na profissão, inclusive materiais publicados e não publicados. (…) está em constante evolução.” (PMBoK pág. 3)

Tenho visto cursos que ensinam gerência de projetos através dos processos descritos no PMBoK, inclusive passando aquela noção errada de que gerenciar é seguir fidedignamente todos aqueles processos, preenchendo toda documentação de cada caixinha, suas entradas e saídas. (O próprio livro diz que os processos podem interagir de diversas formas, como definir uma ordem?)
Ora, gerenciar não é preencher papel! Imagina ter que fazer tudo que o livro traz em cada projeto em todas os tipos de projetos? Seria o segredo para o fracasso na verdade! Já pensou? Por exemplo, já vi projetos simples de sites que deveriam ficar prontos em 15 dias, um mês às vezes… Não daria pra fazer nem metade dos formulários! Imagina os recursos gastos, mesmo reaproveitando os textos! Ou você sempre estouraria o orçamento, ou seria caríssimo, logo pouco competitivo. De qualquer forma terminaria fora do mercado.

Outro exemplo: pra desenvolver um sistema em tempo real, digamos para um avião, você tem que dedicar muita atenção ao gerenciamento de riscos. Realmente cabe documentar bem, várias análises, gente preocupada só com isso pra assegurar que gente não morra. Imagina fazer isso tudo pro simples site exemplificado anteriormente…

O PMBoK traz resposta pra isso, na mesma página, quando se refere a seus objetivos:

“O principal objetivo do Guia PMBoK é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico.” (PMBoK pág 3, destaque do livro).

E isso é reforçado na página 37:

“Isso não significa que o conhecimento, as habilidades e os processos descritos devam ser sempre aplicados uniformemente em todos os projetos. O gerente de projetos, em colaboração com a equipe do projeto, é sempre responsável pela determinação dos processos adequados e do grau adequado de rigor de cada processo, para qualquer projeto específico.” (também em negrito no livro)

Esses parágrafos esclarecem toda a questão, não? O próprio livro as destaca! A equipe é responsável por determinar quais áreas de conhecimento devem ser aplicadas, quais processos, em que grau, rigor, com quais entradas e saídas e em que nível de formalismo. A equipe que deve escolher as ferramentas mais adequadas para cada situação!

Está sendo atribuída ao PMBoK a mesma responsabilidade que muitas vezes é atribuída ao RUP. Nem no RUP, que é de fato um processo, você deve usar toda documentação, completa, com todas atividades, na ordem determinada, com cada pessoa pra exercer um papel, etc. Alguém, exercendo o papel de engenheiro de processo, deveria customizar o processo, selecionar artefatos e adequar tudo aquilo que se tem à disposição para o projeto em particular.

Isso não era feito, o processo virava um cascatão super burocrático, complicado, cheio de atropelos, cheio de gente e a culpa ia pro RUP (que também tinha melhores práticas e conhecimento agregado de anos de experiência da Rational em desenvolvimento de software).

Talvez o RUP tenha sido apresentado como um remédio para todos os males das organizações, traumatizadas pelos projetos que não tinham documentação nenhuma, ficavam na mão de analistas do mau, que às vezes às chantageavam, sabendo que eram insubstituíveis pois levariam consigo todo conhecimento dos sistemas. Projetos eram jogados inteiros no lixo porque ninguém conseguia entender ou dar manutenção, milhões eram perdidos…

Mas como todo remédio, dependendo da dosagem, pode fazer mal. E partimos dum extremo sem documentação nenhuma pra outro com documentação demais!

“Adotar o RUP” não adiantou. Projetos continuavam falhando. As organizações então devem ter pensado: “Deve ter sido por falha de gerência…” Que venham os PMPs!
E quando virem que só isso também não vai bastar, quais letrinhas serão adotadas?
A culpa vai ser sempre dessa sopa de letrinhas!

Pessoal, claro que isso tudo foi só uma brincadeira…

E as metodologias ágeis? Ser ágil é seguir os valores do manifesto. Só! Só que é o que faz toda a diferença nos projetos. O XP traz práticas alinhadas aos valores, mais focadas na engenharia, o SCRUM traz um framework para gerenciar projetos favorecendo os valores e assim por diante.

Logo, casar as duas coisas é totalmente possível! Não está ferindo nada!

Se ainda não se convenceu, seguem aqui mais algumas fontes de leitura que achei interessantes, (já devem até ter surgido outras desde que fiz essa pesquisa):

• Aqui, uma relação das áreas de conhecimento de integração, escopo, risco e qualidade, do PMBoK, com práticas ágeis de uma autora, Michele Sliger, que é PMP e CSM. Recomendo!

• Nesta apresentação, ela traz, além do mapeamento das áreas de conhecimento, Evidências de que as Metodologias ágeis são aceitas pelo PMI como  revistas do PMI com publicações sobre Agile, fala de mais gente do PMI que adotam Agile, etc.

• Uma interessante apresentação do Alan S. Koch, do PMI de Pittsburg, em que ele analisa cada processo do PMBoK e aponta suas compatibilidades e incompatibilidades, concluindo que nada nas metodologias ágeis é incompatível ao PMBoK, e adicionar alguns processos do PMBoK pode ser recomendável, mas só onde realmente necessário e de preferência que não comprometa a agilidade.

• Um anuncio de encontro no PMI de Tulsa com David Prior para falar sobre o mesmo tema.

• Video da infoQ com uma introdução a Agile para gerentes de projetos tradicionais.

• E, se você estiver com receio de perder o emprego porque as equipe são auto-gerenciáveis.

Faltam iniciativas do Brasil, né? O que está faltando pra nos convencermos?

Abraços,

Renato Willi

Trabalho como gerente de projetos de desenvolvimento de software na SEA Tecnologia, atualmente utilizando e divulgando metodologias ágeis em Brasília.
Formado em Computação na UnB, Pós-Graduado em Software Livre pela UNISUL e cursando MBA em Projetos pela FGV. Certificado como PMP, ITIL Foundations, Java Programmer, IBM RMUC e IBM RUP Specialist.