quinta-feira, 2 de abril de 2009

Desmistificando o MPS.BR – Gerência de Projetos (GPR)

No meu último artigo desta série, fiz uma breve introdução sobre a estrutura do MPS.BR. Vimos que os processos propostos pelo modelo podem ser classificados em pelo menos dois tipos: (1) gestão e (2) engenharia de software. Apesar de não existir essa classificação, ela fica subentendida (no CMMI isso é explícito). Vimos também que a verificação da maturidade de um processo se dá pela observação de seus resultados. É importante lembrar que o AP 1.1 está relacionado com os resultados esperados específicos de cada processo. Ou seja, atender aos RAPs do processo é o mesmo que atender ao RAP 1 do AP 1.1.
A GRE é um processo aparentemente simples. Não é à toa que a grande maioria das empresas já executa atividades relacionadas com a disciplina de requisitos. Como se trata de um processo simples e não recebi perguntas sobre o meu último artigo, vou passar direto para a Gerência de Projetos (GPR).
Reaproveitamento de boas práticas
De cara, pode ser que você se assuste com a quantidade de resultados esperados para esse processo. A GPR tem 25 resultados esperados – muito, quando comparados com a GRE – que possui apenas 5. A boa notícia é que nem todos os resultados são exigidos no Nível G.
Na verdade, existe uma explicação para esse número de RAPs. Os teóricos do MPS.BR tentaram reaproveitar as boas práticas do PMBoK, do PMI. Inclusive, isso é explicitado no Guia de Implementação. Fica claro que o GPR é ineretemente um processo de gestão. E se você tem alguma dúvida de como chegar aos resultados esperados para esse processo, uma boa dica é estudar o PMBoK e tentar aplicar algumas de suas técnicas e ferramentas.
Falando em ferramenta, o MPS.BR não exige a utilização de nenhuma ferramenta para a gestão dos projetos. Entretanto, é interessante que a empresa adote algum programa para facilitar a vida dos gerentes de projeto. Aqui, faço questão de transmitir um pouco da minha experiência pessoal: muita cautela ao adquirir uma ferramenta de mercado. Elas prometem maravilhas. Na prática, são complexas, lentas (ou exigem uma infraestrutura cara), burocráticas e cheias de recursos que provavelmente você não irá utilizar (ou não precisaria utilizar). Uma boa ferramenta para gerenciamento de projetos deve ser simples. Sugiro que sua empresa desenvolva sua própria ferramenta – quem sabe na Intranet, utilizando uma interface web. É barato, simples e novos recursos podem ser adicionados conforme a necessidade e o orçamento disponível. Uma boa ferramenta não precisa ter gráficos nem fluxos muito complexos. Fico devendo um artigo para falar mais sobre o que uma ferramenta dessas deve ter para atender ao MPS.BR.
Tudo tem que ser projeto
Como já comentei em artigos anteriores, o MPS.BR parte da premissa que tudo é encarado como projeto. Ou seja, toda demanda, solicitação, pedido, versionamento, etc, , com exceção da manutenção, devem ser rotulados de “projeto”. Na prática isso não muda muita coisa pois, como veremos, para garantir a transparência e gerenciabilidade dos processos, teríamos de todo jeito que definir os trabalhos de forma bem clara, com início e fim planejados. Assim, rotular os trabalhos de projeto acaba sendo uma conseqüência natural e inevitável.
Isso pode envolver um certo grau de mudança organizacional. Mas os gestores devem enfatizar para as equipes que rotular os trabalhos de projeto não significa necessariamente aumento da burocracia. É possível gerenciar os projetos de forma ágil. Tudo depende de como a empresa implementará esse processo. Repito: a ferramenta de gerenciamento de projetos pode e precisa ser simples para garantir a agilidade das atividades.
Resultados esperados
Apesar de a GPR conter 25 RAPs, apenas os primeiros 17 são exigidos no Nível G. Os outros são alcançados conforme a organização vai amuderecendo e subindo de nível. Vamos agora dar uma olhada geral nesses 17 resultados.
É notório como algumas palavras se repetem na definição dos RAPs desse processo. Destaco as seguintes: plano, planejamento, planejar, planejado. Até aqui já é possível entender que a GPR é sobre planejar, planejar e planejar. Planejar o quê? Tudo! É necessário planejar as fases do projeto, atividades e tarefas. Orçamento, riscos e recursos humanos também precisam constar no planejamento.
Além de planejar, a GPR também exige que sejam estabelecidas atividades de controle para verificar o atendimento ao Plano do Projeto. Falando nisso, o Plano do Projeto é o principal artefato (documento) utilizado na GPR – praticamente tudo gira em torno dele. Assim, é importante definir padrões para a sua construção e normas para controlar o atendimento ao que foi planejado. A construção desse documento deve envolver todos os interessados no projeto. Indicadores e metas podem ser úteis para controlar os trabalhos e acompanhar a sua execução. Vale ressaltar que não basta criar o Plano do Projeto – ele precisa ser mantido. Em outras palavras, qualquer alteração no planejado precisa ser registrada no plano. Isso é importante, pois os planos de projetos passados servirão de base para a definição de planos de projetos semelhantes no futuro.
Como a GPR define basicamente atividades de gestão, algumas empresas têm preferido separar essas atividades do desenvolvimento de software propriamente dito. Como? Por criar "pools" de gerentes de projeto responsáveis por essas atividades. Essa estratégia é interessante, pois contribui para a unificação dos métodos de gerenciamento dos diversos projetos da organização. Essa unificação vai ser muito útil quando a empresa estiver implementando o Nível E em diante, quando a forma de gerenciamento de projetos vai precisar ser padronizada. Apesar disso, algumas empresas têm preferido manter pessoas responsáveis pelo gerenciamento do projeto espalhadas pelas equipes de desenvolvimento. A vantagem dessa abordagem é que ela possibilita um acompanhamento mais próximo da execução. A desvantagem é que ela pode perder a independência, que varia conforme a ingerência do gerente da equipe sobre o gerente do projeto, e dificulta a unificação dos métodos, como já mencionei acima.
Não vou comentar aqui cada RAP, pois o Guia de Implementação já contém informações suficientes para se chegar aos resultados esperados. Não há mistério em entender os RAPs da GPR. Todos se baseiam em práticas há muito tempo recomendadas pelo PMI. Material sobre isso é vasto e fácil de obter.
GPR x GRE
Como esses dois processos se relacionam? Bom, ainda não disse que umas das maiores preocupações da GPR, depois do planejamento, é gerenciar o escopo do projeto. O escopo precisa ser bem definido e quaisquer alterações devem ser controladas e registradas. E o escopo nada mais é do que o resultado do levantamento de requisitos. Perceba que tudo na execução do projeto gira em torno dos requisitos. Talvez você se pergunte: Se o escopo é resultado do levantamento de requisitos, como vou iniciar o projeto se os requisitos só serão levantados durante a sua execução? Simples. Não inicie o projeto sem antes levantar os requisitos.
É comum encontrarmos projetos com atividades de levantamento de requisitos no cronograma. Não faça isso! Um projeto só deve ser iniciado com uma idéia bastante clara do que se deseja desenvolver. E isso você só vai conseguir se o levantamento de requisitos já estiver concluído. Se preciso, inicie primeiro um projeto apenas para fazer o levantamento de requisitos. No segundo projeto, pegue os resultados do primeiro para a definição do escopo. É um erro iniciar um projeto de desenvolvimento de software sem que o levantamento de requisitos esteja concluído. Não há como planejar sem essas informações.
Entretanto, pode ser necessário refinar ou alterar alguns requisitos durante o projeto. Por isso, inclua atividades de reavaliação de requisitos antes de cada iteração. Se requisitos forem incluídos ou alterados, trate isso como alterações no escopo do projeto. E lembre-se que alterações no escopo em geral afetam o planejamento.
Conclusão
Assim concluímos a análise do primeiro nível do MPS.BR, o Nível G. Ao implementar esse nível, os projetos da organização estarão com o escopo bem definido e o planejamento estará sendo acompanhado para corrigir eventuais desvios. O gerente de projetos tem um papel importante no alcance dos resultados esperados.
Contudo, apesar de haver controle sobre o andamento e escopo do projeto, não há nenhuma garantia de que os produtos de trabalho tenham qualidade. É isso que veremos no próximo artigo, quando falarei sobre o Nível F.
Um abraço e até lá.

5 comentários:

NeTo disse...

Olá Samuel,

Li todos os seus artigos sobre o MPS.BR e gostei muito do seu ponto de vista.

Estou implementando esse modelo na empresa em que trabalho, juntamente com uma consultoria.

Nós desenvolvemos uma ferramenta para gerenciar os projetos seguindo as diretrizes do modelo e partes da metodologia SCRUM.

Gostaria de saber quais são as funcionalidades básicas de uma ferramenta própria, como gerenciar o portifólio de projetos, supondo ter vários projetos para uma equipe.

Samuel Diniz Casimiro disse...

Neto, fico feliz de saber que vocês estão utilizando o SCRUM. Apesar de não ser 100% compliance com o MPS.BR ele é um ótimo (talvez o melhor) ponto de partida, pois não é muito burocrático. Só não acredito em equipes auto-organizadas, mas talvez dê certo na empresa onde você trabalha. Antes de responder a sua pergunta, gostaria de saber que nível do modelo vocês estão implementando.

NeTo disse...

Samuel, estamos implementando o nível G do MPS.BR e escolhemos o SCRUM pois temos apenas uma equipe para todos os projetos da micro-empresa.

Samuel Diniz Casimiro disse...

Neto, achei sua pergunta tão interessante, que estou antecipando um artigo que só iria escrever no fim da série. Não vai ser possível (devido ao meu pouco tempo livre) abordar todos os detalhes que uma ferramenta de GPR precisa ter para atender ao Nível G do MPS.BR. Mas vou tentar me concentrar naqueles mais importantes. Devo publicar o artigo hoje ou amanhã, ok? Espero que sirva para o que você precisa. Um grande abraço!

Samuel Diniz Casimiro disse...

Neto, acabei de publicar o artigo. Espero que seja útil.