Tag Archives: Sprint

Case Projeto Automação BPM: PMBOK e o Manifesto Ágio, mistura possível?

19 Abr

No post deste mês gostaria de escrever sobre algo que pudesse conciliar teoria com prática e, ao mesmo tempo, fosse conciso e prazeroso de ser lido. Foi aí que, pra variar, em conversas “informais” com amigos ligados ao gerenciamento de projetos e outros da engenharia de software, surgiu à ideia de falar sobre os ingredientes que utilizei para gerenciar um projeto de Automação de Processos (BPM) em um órgão público de Brasília. Esses ingredientes foram às práticas do Guia PMBOK v4 e o Manifesto Ágil, mais precisamente as ideias propostas pelo SCRUM.

Só para contextualizar, o projeto de Automação BPM já vinha se arrastando na empresa há alguns anos e vários tipos de recursos já haviam sido despendidos. No entanto, os resultados práticos da automação não aconteceram. Ou seja, os processos já tinham sido modelados “as/is” e diagnosticados para uma melhoria “to/be”, mas TUDO estava em grandes mapas plotados ou na ferramenta utilizada para modelagem. A automação em si, não havia acontecido. Para agravar a situação, temos uma característica básica quando trabalhamos com processos, eles são vivos e não estáticos que perduram ao longo dos anos. Ao contrário disso, eles se modificam!

Já se pode imaginar qual era a missão? Fazer acontecer à automação de pelo menos uma área negócio da empresa. Então vamos lá: restrição de prazo, custo, recursos e baixíssima credibilidade dos tomadores de decisão quanto ao projeto e a estima da equipe bem abalada. Este era o cenário. E para apimentá-lo, havia um ponto fundamental, este era o primeiro projeto da área de TI que seguiria uma metodologia de gerenciamento de projetos que havia sido elaborada pelo escritório de projetos recém-implantado. Ou seja, o cliente interno não tinha a cultura dos projetos de TI serem desenvolvidos de forma estruturada. Mas este era o cenário e tínhamos que encará-lo!

Os ingredientes propostos pelo SCRUM e o PMBOK v4 se casaram bem à medida que colocamos a força de cada um no seu devido lugar. Para ilustrar, utilizarei o cronograma, a EAP e o Product Backolog para demonstrar como os dois “paradigmas” podem funcionar juntos.

Acreditei naquilo que o PMBOK talvez tenha de melhor: os processos de iniciação, planejamento, gestão de mudanças e monitoramento do projeto. Não é porque deve ser “ágil” que o projeto não deva ser planejado. Lembrando que o conceito de “ágil” no manifesto não se refere à velocidade, rapidez de entrega, mas sim, de agilidade em resposta a mudança. E como não poderia ser diferente, os órgãos públicos exigem, por força de lei, forte controle de custos e prazos, além dos recursos humanos envolvidos. O Guia PMBOK é uma boa sugestão para ser utilizado para estes casos.

clique para ampliar

Primeira coisa: eu precisava saber se os processos mapeados para a automação continuavam válidos. Foi aí que entrou o processo de iniciação e a atividade de análise de documentação pré-projeto, previsto no PMBOK. Daí foi possível compreender o escopo e, consequentemente, foi hora de definir o product backlog do projeto. Sim, este conceito vem do SCRUM e tem objetivo similar ao da EAP. Tanto que fiz um product backlog para a execução e a EAP para a gerência do projeto. Duplo trabalho? Claro que não! A EAP é uma ótima ferramenta de comunicação com os gestores do projeto e o product backlog é excelente para lidar com a equipe técnica e o “product owner” do projeto. Mais do que isso, no caso desta empresa pública, em que o projeto foi desenvolvido, há uma metodologia de gestão de projetos em que  a EAP é um artefato obrigatório, já o product backlog foi algo acrescentado pela circunstância do projeto.

clique para ampliar

A execução do projeto foi toda direcionada para que  o manifesto ágil prega: desenvolvimento iterativo, incremental e equipe pequena (havia 4 pessoas voltadas a execução).  Toda a execução foi divida em sprints com igual período de execução. Minha função na execução do projeto era de um facilitador junto à equipe técnica e perante a gestão da empresa, eu era o gerente de projetos que controlava custo, tempo, recursos, escopo, mudanças e realizava a comunicação. O prazo definido pela equipe, a partir da definição do product backlog e do sprint backlog, se fez totalmente compatível com a restrição de prazo que havia para o projeto. Outra iniciativa que trouxe do SCRUM foi a realização das reuniões diárias com a equipe. A reunião propicia excelentes resultados junto à própria equipe, que não fica ilhada em demandas isoladas. As reuniões criam o senso de equipe, pois todos sabem o que está acontecendo e, mais do que isso, se propõe em fazer um ajudar ao outro.

clique para ampliar

Em fim, qual o grande barato disso: é possível adequar dois paradigmas e obter bons resultados. Os projetos críticos, com altos níveis de riscos, não podem ser planejados exclusivamente com base em requisitos funcionais. Deve-se, por exemplo, levar em consideração as etapas da área de conhecimento de riscos, que por sinal é bem descrita no guia PMBOK.

Como já disse aqui, ter a perspicácia do que utilizar e quando utilizar pode levar o projeto ao sucesso. As ideias dos paradigmas do Guia PMOBK e do Manifesto Ágil podem ser trabalhadas em conjunto sim!

Até a próxima!

%d bloggers like this: