Agile Project Management - Funciona para você?

Bom dia pessoal, tudo bem?

Já faz algum tempo que me interesso bastante pelo tema dos métodos ágeis para gerenciamento de projetos e como elas podem agregar valor ao projeto e principalmente ao moral do time. Não há como negar que algumas vezes a burocracia que metodologias mais conservadoras impõe sobre o trabalho do projeto acabam por causar problemas no logo prazo dentro da equipe, como a insatisfação, falta de motivação e às vezes um sentimento de frustração.

Para quem vive o mundo do PMI, quando lemos o Manifesto Ágil, sentimentos antagônicos de encantamento e de estranheza sempre aparecem. Mas os pontos relevantes (que aqui colocarei em uma tradução livre) do manifesto causam tanto impacto que não podemos deixar de levá-lo em consideração. Neste manifesto os pontos de destaque (na minha modesta opinião) são:

• As pessoas e as interações entre elas são mais importantes que os processos e ferramentas
• Produto funcionando é mais importante que documentação abrangente
• Colaboração com o cliente é mais importante que negociação de contratos
• Responder às mudanças é mais importante que seguir o plano

Para muitos praticantes do que chamo PMI'ismo, essas coisas podem chegar a causar arrepios, afinal, o PMBOK é fundamentado em processos bem definidos, tem passagens importantes sobre o controle de mudanças, negociação de contratos, enfim, é um antagonismo que pode causar desconforto naqueles mais ortodoxos.

Porém alguns fatos importantes devem ser considerados ao analisarmos ambientes de projetos específicos, em especial projetos de desenvolvimento de novos produtos, que inicialmente adotou o PMBOK como padrão para a gestão de projetos. Nessa área, um fato começou a se tornar visível: o índice de sucesso e satisfação dos clientes sempre estava abaixo da expectativa.

Ora, se estamos desenvolvendo um produto, algumas caraterísticas devem ser observadas:

1. O produto deve se adequar a novos requisitos que aparecem durante o processo de desenvolvimento
2. As mudanças no produto podem significar maior índice de sucesso deste produto depois do projeto concluído
3. O cliente (que é o dono do produto) deveria participar ativamente das decisões do projeto, e alterá-lo de acordo com o seu plano de negócios
4. O plano de negócios também pode mudar no decorrer do projeto
5. O cliente sempre quer ver alguma coisa pronta nas reuniões de status
6. A equipe quer trabalhar em paz durante o processo de criação do produto

Em resumo: o processo de desenvolvimento de produtos não combina muito com o método do PMI (voltarei a este assunto no próximo post). Era necessário alguma coisa nova, que quebrasse o paradigma da rigidez ditada pelo PMBOK. Nasceram então as metodologias ágeis de gerenciamento de projetos.

Hoje em dia todos pensam que isso só se aplica a desenvolvimento de software, mas os "ratos da informática" estão enganados. O método ágil surgiu (pasmem) na indústria automobilística, no processo de desenvolvimento de novos modelos de carros. Mais tarde foi adaptado e amplamente adotado pela indústria de desenvolvimento de software, onde o Scrum emergiu.

Os princípios são básicos e muito simples: rodadas de planejamento e rodadas de execução do plano, nada muito diferente do modelo tradicional. A diferença está na maneira como isso é realizado. O PMI e seu método nasceram em um momento onde os "chefes" e "gerentes" tinham formação técnica, e conheciam muito mais do que seus subordinados. Por isso o GP era o centro de tudo. Todas as decisões, todas as medidas eram tomadas por ele. Claro que ele ouvia sua equipe, mas a decisão final era do GP.

Hoje, com o alto grau de especialização dos trabalhadores, muitas vezes o "gerente" não é mais o grande técnico do passado. Normalmente seus subordinados conhecem a tecnologia em um nível muito maior do que ele. Pensando nisso, alguns visionários resolveram "derreter" a função do gerente do projeto, dando maior liberdade para a equipe do projeto (que deve ser multidisciplinar) se auto-organizar.

Após algumas experiências, percebeu-se que o moral da equipe estava mais elevado, as entregas do projeto haviam sido realizadas em prazo menor e com menor esforço. Estavam criados os fundamentos do APM (Agile Project Management).

Alguns devem estar se perguntando: e onde foi parar o gerente do projeto?

Bem, essa resposta não é simples, uma vez que a orientação dos métodos ágeis é mais aderente à gestão de produtos, e não de projetos, a função do GP foi dividida em 3 partes:

1. Macro gestão - Atribuída ao "dono do produto"
2. Micro gestão - Atribuída ao time de desenvolvimento
3. Processos - Atribuída ao que poderia ser chamado de GP

O "GP" nesses casos é o líder servidor ou colaborativo. Ele trabalha para que a equipe não tenha nenhum tipo de impedimento durante o desenvolvimento do produto. O "GP PMI" também exerce esse papel, porém quando somos ágeis, a equipe é responsável por resolver seus próprios problemas, excluindo do GP a função de gestão micro de RH (conflitos, etc.). Isso passa a ser responsabilidade da equipe, assim como o planejamento de cada ciclo de desenvolvimento e a resolução de problemas técnicos do projeto.

Então o que o GP faz? Ele remove os impedimentos. Um impedimento é algo que está além da capacidade de resolução da equipe, como por exemplo falta de um treinamento específico, algum recurso material necessário para o projeto e coisas desse tipo. O GP também é o responsável por proteger a equipe das influências externas, pois, durante um ciclo de desenvolvimento, a equipe deve estar focada exclusivamente na resolução dos problemas do projeto.

Confuso? Eu também achava... Assustado? Eu também fiquei... Isso é a morte dos PMP's? Certamente não.

Os métodos ágeis funcionam muito bem quando não se tem um escopo claro e definido, quando iterações no plano são desejadas e esperadas, quando o time-to-market de um produto precisa ser reduzido (ainda que ele seja apresentado com menos funcionalidades do que o produto final). Para aqueles projetos onde o escopo é claro, o prazo e o custo são definidos, o modelo PMI ainda se aplica de forma mais eficaz. Imaginem um prédio ser planejado e construído em etapas independentes? Provavelmente não seria o método mais eficiente e eficaz para fazer isso...

O que não podemos é virar as costas para o movimento ágil, pois ele preenche lacunas expressivas que o PMBOK não sabe como tratar. Até mesmo a integração dos métodos ágil e tradicional é possível, e até mesmo saudável!

O que nós, gerentes de projetos e agentes de mudanças, precisamos ter claro em nossas mentes é que toda metodologia, todo framework, todas as boas práticas são adaptáveis e devem ser adaptadas à nossa realidade. Por isso eu indico sempre o estudo. Estude sempre. Leve consigo o que considerar adequado, guarde para o futuro aquilo que não considera ideal hoje e esteja pronto para quebrar os seus próprios paradigmas na sua profissão. Você não é gerente de projetos, você está gerente de projetos. Aproveite a jornada!

Um grande abraço!

Saúde e sucesso,
Rodrigo Ramos, PMP, CSM