AGILE para Gestores de Projeto: Desafios e Oportunidades

Os gestores de projeto que são confrontados com a necessidade de mudar para o AGILE enfrentam, para além da necessidade de aprender novas técnicas e métodos, um dilema cultural.

De facto, quando uma organização decide adotar o AGILE como metodologia de gestão de projetos, essa decisão é tomada com base numa análise dos potenciais custos e benefícios para a organização, raramente tendo em atenção os benefícios, e os eventuais prejuízos que, a nível pessoal essa decisão pode acarretar para quem, na prática vai ter de a implementar e conviver com ela.

Sendo verdade que o AGILE implica mudanças profundas nos vários níveis da organização, e afeta todas as pessoas que nela trabalham, também não é menos verdade que alguns dos mais afetados são aqueles que têm como profissão e responsabilidade a gestão dos projetos dessa organização.

As razões para isso estão explicadas abaixo e têm origem na cultura que está subjacente à gestão de projetos que tradicionalmente é realizada na maior parte das nossas organizações.

1) Alterações nos Processos de Levantamento e Recolha dos Requisitos

Quando a gestão de projetos segue uma abordagem tradicional as funcionalidades e os requisitos do projeto são recolhidos da forma mais completa possível nas fases iniciais do projeto. O fundamento assenta numa ótica sistémica e no principio de que necessitamos de saber claramente as funcionalidades daquilo que necessita de ser criado para que possamos planear com detalhe as atividades que são necessárias para criar e integrar cada uma dessas funcionalidades. 

Claro que depois, ao longo de todo o ciclo de vida do projeto, as equipas irão aprendendo mais, o ambiente em que o projeto se desenvolve e, muitas vezes, as necessidades dos utilizadores irão mudando o que faz com que o projeto e a sua gestão se tenham de adaptar. Contudo, á luz das metodologias tradicionais, este é o campo de atuação dos processos de gestão e controlo das alterações.  

Reconhecendo a necessidade de introduzir mudanças e alterações de forma a que o projeto responda e se adapte ao contexto e às necessidades dos utilizadores, a metodologia tradicional vê esta capacidade de adaptação como uma força antagónica, e que por isso deve ser minimizada, entre o esforço inicial de planeamento detalhado e a necessidade de entregar no final do projeto um produto ou serviço que satisfaça o negócio (cliente) mas que não afetam no essencial o plano detalhado que foi feito inicialmente.

No AGILE a estratégia de abordagem aos requisitos do projeto assenta num processo de parceria que se inicia quando, em conjunto com o cliente, se define a visão que existe para aquele projeto, isto é, os objetivos que se pretendem atingir. Ao contrário do que acontece nos processos tradicionais de gestão de projetos, essa parceria continua ao longo de todo o projeto, com o cliente/utilizador empenhado no trabalho de detalhe das funcionalidades a criar e na prioridade com que essas funcionalidades devem ser criadas. 

A consequência mais direta desta diferente abordagem consiste no facto ela permitir, e exigir, um maior envolvimento do cliente e, consequentemente, um maior compromisso por parte deste em relação ao produto final que lhe será entregue. Desta primeira e maior consequência direta deriva igualmente uma maior facilidade em incorporar alterações ao produto final, e uma maior abrangência dessas alterações uma vez que os processos de gestão em vez de se focarem na prevenção das mudanças se centram em escolher, a cada momento, o que é mais importante para o cliente final.

Assim no AGILE é muito importante que comecemos o projeto com a descoberta de quais são as necessidades básicas do nosso cliente que pretendemos satisfazer e qual é a sua visão sobre o que ele quer ser no futuro, quando o projeto terminar e ele puder usufruir do produto ou serviço que foi criado. Perceber e fixar no inicio do projeto para onde queremos ir é fundamental para entender a direção que iremos tomar e para podermos decidir sobre o que deve estar dentro e fora do âmbito do projeto.

2) Paradoxo da Linha de Costa

Quais são os 10 países da Europa com maior linha de costa? A resposta a esta questão pode não ser fácil. Isso acontece devido ao paradoxo da linha de costa. De facto, de acordo com este paradoxo, quanto menor for a unidade de medida, maior será o comprimento da linha de costa. Ou, dito de outra forma, quanto mais ao pormenor formos, mais côncavos e re-concavos conseguimos medir e, portanto, maior será o resultado.

Em determinados tipos de projeto, medir a sua dimensão total é uma tarefa particularmente complicada na medida em que, quanto mais conhecemos sobre o produto ou serviço a criar e sobre as atividades e tarefas que irão ser necessárias, maior o trabalho nos parece. Quanto mais aprofundamos as funcionalidades mais requisitos descobrimos e mais detalhes queremos definir. Este esforço de detalhe torna o trabalho comprovadamente maior. E quando o trabalho é maior, dividido em mais atividades e em tarefas mais complexas, os recursos necessários para o executar crescem em proporção. Ou seja, devido ao paradoxo da linha de costa a micro gestão/planeamento do projeto tem como resultado estimativas de maior dimensão em termos de recursos consumidos.

A estratégia de criar um sistema mínimo mas funcional, a que no AGILE se chama um "produto viável mínimo" é o equivalente a começarmos por medir a dimensão do nosso projeto usando um menor grau de detalhe mas que tem como objetivo fornecer um ponto de partida que irá posteriormente sendo refinado e complementado à medida que o projeto decorre. Isto permite à equipa de projeto e ao cliente, focar-se no essencial.
 

Para além disso esta forma de planear obriga-nos a pensar primeiro o âmbito como algo completo, apropriado e adequado ao cronograma e ao orçamento do projeto. Se definirmos o ambito detalhado em todas as áreas do projeto, sem considerar essas restrições, é improvável que consigamos chegar a um resultado que satisfaça o constrangimento triplo - Âmbito, Tempo, Custo - que é habitualmente considerado como um indicador do sucesso do seu projeto (Leia aqui um pouco mais sobre os critérios de sucesso do projeto) 
 

Claro que "um sistema mínimo mas funcional" depende muito do tipo de projeto que temos para executar e dos processos que usamos para criar o produto ou serviço final. Nuns projetos esse mínimo será mesmo mínimo, noutros nem tanto. Contudo, o relevante é entender o quadro mental e a cultura que deve estar subjacente e saber usa-lo no contexto especifico de cada um dos nossos projetos.

3) A Segmentação das Atividades

A estrutura tradicional de detalhe do trabalho (EAP / WBS) tenta listar todas as tarefas que precisam ser realizadas. Isso tem como pressuposto que, quando essas tarefas forem concluídas, o sistema também o será e o projeto estará terminado. O problema é que, na realidade do dia-a-dia dos projetos essa suposição não é verdadeira uma vez que no decurso da execução do projeto haverá sempre tarefas que constataremos não constam da lista mas têm de ser executadas, tarefas que estão definidas de forma diferente daquilo que são na prática e tarefas que depois de concluídas tem de ser reabertas para corrigir anomalias e defeitos detetados à posteriori. 

Esta realidade cria a necessidade de planear e executar novas tarefas que não estão relacionadas com a construção do produto ou serviço que será o resultado do projeto, mas sim com a maneira como abordamos a construção desse produto ou serviço.

Também aqui o AGILE recomenda uma estratégia diferente e defende que o que deve ser feito é negociar com o cliente uma abordagem iterativa e incremental de forma a que o cliente espere receber entregas periódicas de componentes que cumpra com critérios funcionais específicos e valorizáveis pelo cliente.  Em troca dessa expectativa, a equipa de projeto é libertada da obrigação de  adivinhar corretamente a interpretação adequada de todos os requisitos do projeto passando isso a ser um trabalho que decorre, de forma partilhada entre equipa de projeto e cliente, ao longo de todo o projeto.

4. Mudanças na Forma Como os Gestores de Projeto São Avaliados

Qualquer gestor de projeto com alguns anos de atividade terá sido já por certo confrontado com situações em que lhe pedem estimativas sobre o projeto que você não tem condições para dar. Seja nas reuniões iniciais com o promotor (Sponsor) do projeto, seja nas apresentações do projeto ao comité de acompanhamento (Steering Comitee), o mais frequente é que o maior interesse de quem o ouve seja saber quando é que o projeto termina e quanto é que ele vai custar.

Não raro o gestor de projeto é pressionado para apresentar respostas a essas questões ainda que o projeto esteja na sua fases mais iniciais em que, as poucas coisas de concreto que se sabem são a intenção que levou a organização a dar inicio ao projeto e uns quantos, poucos, detalhes sobre o que tem de ser feito e como será feito (ver artigo sobre a elaboração do documento inicial do projeto - Projet Charter).

Se você já esteve numa situação como esta, sabe como a mesma é difícil uma vez que, como gestor de um projeto, você é avaliado com base no grau de cumprimento das estimativas que apresenta mas, em muitas situações, essas estimativas são-lhe exigidas numa fase do projeto é que você não tem os dados, nem o conhecimento, necessário para poder elaborar estimativas com um grau de fiabilidade compatível com as exigências que lhe estão a ser feitas.

Numa situação como a descrita uma abordagem ágil pode ajudar o gestor de projeto a lidar com os riscos na medida que advoga que a melhor forma de abordar a questão das estimativas nesta fase dos projetos passa pela análise de projetos anteriores, que tenham sido executados pelo mesmo fornecedor e projetos anteriores que tenham sido realizados no contexto, ou pela mesma, unidade de negócios para ter uma ideia da escala de tempo e dos custos que poderão estar em causa. Essa análise permite ao gestor de projeto realizar uma estimativa que recorre à melhor informação disponível e, com base no conhecimento entretanto adquirido, ter uma ideia bastante precisa dos riscos em presença de forma a poder definir o valor das provisões para contingências. Este tipo de estimativa é habitualmente conhecido pelo nome de Estimativas por Analogia, e elas só são possíveis de realizar com fiabilidade se a organização possuir um Sistema de Informação para a Gestão de Projetos (PMIS) que permita guardar e reusar a informação relevante sobre projetos passados.

Votos de bons projetos.

Grp2ALL


Adaptado de: ProjectManagement.com