Gestão ágil para projetos industriais de pequeno porte

Diante do pouco tempo hábil que existe para concretização de projetos, será que não se pode fazer as coisas de uma maneira mais rápida, sem perder o foco da gestão?

* Danilo Piccolo

Que atire a primeira pedra o gerente de projetos do setor que nunca recebeu a seguinte demanda: “Preciso de um projeto para aumentar a moagem em 10% gastando o mínimo. Precisamos disso pronto pra ontem. Afinal, já estamos em novembro, temos que comprar os equipamentos e só teremos três meses de entressafra.”

O PMBoK, que com certeza não foi escrito por uma equipe de gestores do setor sucroenergético brasileiro, nos recomenda dizer “não, não dá pra fazer”. Mas, deste lado do Equador, as coisas são diferentes. Trabalhamos com recursos escassos e normalmente o gerente de projetos e sua equipe ainda têm que se dividir entre o acompanhamento da produção e as demandas do projeto.

Esta restrição de recursos está bastante potencializada com a crise e com a burocracia que normalmente envolve a liberação de orçamento por parte da alta administração para um determinado projeto. Temos acompanhado inúmeros casos em que a execução do projeto ficou “espremida” pela decisão estratégica de go/no go.

Junte-se a isso o fato de que um grande número de projetos neste nível possui escopo incerto. No exemplo citado na abertura deste artigo, a demanda é aumentar a moagem em 10%. Isto significa que, antes de qualquer coisa, precisa-se saber como fazer este aumento. As restrições de prazo, custo e o escopo incerto são uma receita para o risco. E, consequentemente, para o insucesso.

Deste escopo bem delimitado é que deve nascer o plano do projeto, composto pelos planos de gerenciamento de escopo, tempo, custo, qualidade, recursos humanos, aquisições, riscos e comunicações.

Este procedimento de gestão de projetos é conhecido como waterfall (ou em cascata) pelo fato de que se necessita finalizar uma etapa anterior para prosseguir a etapa seguinte. No caso específico do nosso exemplo, só se pode iniciar o plano de projeto uma vez que se tenha um escopo bem conhecido e delimitado. E isto demanda tempo.

Além disso, como normalmente o gerente de projetos também faz parte da equipe técnica, parece meio ilógico gastar muito tempo produzindo documentos de gestão do projeto quando mal se tem tempo para executá-lo.

Será que não se pode fazer as coisas de uma maneira mais rápida, sem perder o foco da gestão?

Os métodos ágeis de gestão de projetos nasceram na área de TI, mais especificamente na engenharia de softwares. As equipes de gestão destes projetos sempre encontraram dificuldade em trabalhar com o procedimento tradicional de gestão pelo fato de conduzirem projetos de escopo indefinido, com muitas mudanças de rumo e com prazos agressivos.

Aliás, no mercado de softwares, o custo de oportunidade costuma ser muito alto. Perder um prazo de lançamento de produto pode ser a ruína de uma empresa, pois a concorrência pode ser mais rápida. Nestes casos, é preferível ter o produto funcionando a tê-lo todo documentado e fora do prazo.

Trazendo para a nossa realidade, perder o início de uma safra tem um custo muito alto. É preferível iniciar, mesmo que sobrem alguns pontos para serem resolvidos durante a safra, do que esperar terminar.

Em 2001, um grupo de programadores elaborou o “Manifesto for Agile Software Development”, que é composto por quatro valores fundamentais:

• Os indivíduos e suas interações acima de procedimentos e ferramentas;

• O funcionamento do software acima de documentação abrangente;

• A colaboração dos clientes acima da negociação de contratos;

• A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

Dentro das metodologias ágeis existentes no mercado, o Scrum é a mais conhecida. Scrum é um processo de gestão iterativo onde a entrega final (produto) é dividida em Sprints nos quais devem ser gerados subprodutos. O Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser executado. Normalmente, um Sprint dura de duas a quatro semanas.

Os itens a serem implementados no projeto são mantidos em uma lista que é conhecida como Lista de Requisitos do Projeto (Product Backlog), que nada mais é do que uma listagem dos requisitos do projeto.

No início de cada Sprint, faz-se uma reunião de planejamento, na qual o cliente (por exemplo, o gerente industrial da planta) prioriza todos os itens da Lista de Requisitos e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. Os aspectos relativos ao planejamento do Sprint são os mesmos dos utilizados no planejamento no método tradicional. A diferença é que se planeja cada “pacote” de entregas. As informações do progresso do Sprint anterior alimentam o planejamento dos Sprints seguintes.

Para acompanhamento das tarefas do projeto, a equipe pode ter um quadro de atividades (Kanban) que deixe claro quais atividades estão em andamento, quais estão na fila e quais estão concluídas. Diariamente, a equipe de projeto faz uma breve reunião de, no máximo, 15 minutos com todos os participantes em pé, chamada Daily Scrum. O objetivo é cada integrante dizer o que fez no dia anterior, o que pretende fazer no dia que se inicia e se existe algo que esteja bloqueando o cumprimento de suas entregas.

O acompanhamento do progresso do projeto se dá através do Burn Down Chart, que é uma representação simplificada, clara e bastante objetiva.

Mesmo em um ambiente ágil é preciso realizar algumas atividades formais, principalmente para registrar certas passagens importantes do projeto, como a oficialização do seu início (Termo de Abertura), a identificação dos stakeholders e o desenvolvimento do plano de gerenciamento de projetos simplificado (escopo, custo, qualidade, risco, recursos e aquisições). Estes itens continuam sendo mandatórios e são base para o planejamento de cada Sprint. A diferença é que este planejamento é iterativo na medida em que avança cada Sprint. Toda a documentação gerada no projeto deve se basear nos seguintes princípios:

1. Não burocratizar.

2. Não documentar excessivamente.

3. Não realizar processos desnecessários.

4. Não acrescentar lentidão ao Time de Projeto e aos seus trabalhos.

5. Não deixar o gerente de projetos como único braço gerencial.

Então, por que não proceder desta maneira com todos os projetos? As metodologias ágeis são ferramentas importantes para usos específicos. Não se pode imaginar o uso deste tipo de método para um greenfield com dois a três anos de duração com um número enorme de partes interessadas e orçamento na casa das centenas de milhões de reais. As interações são muito mais complexas, assim como a estrutura necessária para a gestão do projeto.

Assim, é importante ter em mente os seguintes aspectos na seleção de uma metodologia ágil para a execução de um projeto:

1º. A operacionalização do plano estratégico da empresa “apertou” a execução do projeto. Isto precisa ficar claro;

2º. Não foram executados os projetos conceitual e básico que permitissem ter um escopo mais bem definido;

3º. O projeto é suficientemente pequeno para ser dividido em Sprints;

4º. O número de partes interessadas é reduzido;

5º. A restrição de prazo é dominante no projeto em questão;

6º. O grau de incerteza (e de risco) do projeto será maior;

7º. A alta administração estar ciente de como o projeto será conduzido e apoiar a equipe de gestão;

8º. E não menos importante, projetos ruins geram resultados ruins. Os processos de gestão só podem ajudar bons projetos a terem maior probabilidade de sucesso.

Voltando ao desafio do projeto inicial deste artigo, é possível minimizar os riscos de implantação mesmo nestas situações adversas usando as ferramentas corretas e nivelando as expectativas dos envolvidos.

* Danilo Piccolo é mestre em Engenharia de Processos, PMI-PMP® e gestor de projetos na Reunion Engenharia