sexta-feira, 17 de abril de 2009

Desenvolvendo sua própria ferramenta de GPR para o MPS.BR

No meu último artigo sobre a Gerência de Projetos do MPS.BR, fiquei devendo algumas dicas sobre como implementar uma ferramenta que atenda a esse modelo de melhoria. Estava pensando em escrever um artigo sobre isso somente no final da série “Desmistificando...”, mas recebi um comentário de um leitor perguntando mais sobre o assunto. Ele gostaria de saber ‘quais as funcionalidades básicas que uma ferramenta própria’ (desenvolvida inhouse) deveria ter para atender à GPR e, inclusive, gerenciar o portfólio de projetos, supondo ter vários projetos para uma mesma equipe.
Antes de tudo, vale ressaltar que, conforme citei naquele artigo, o MPS.BR não exige a utilização de um ferramenta para realizar o gerenciamento de projetos. Contudo, isso fica nas entrelinhas e, obviamente, é algo desejável!
Não vai ser possível esgotar aqui todos os aspectos necessários para que uma ferramenta suporte 100% dos resultados esperados pela GPR. Vou tentar cobrir apenas os principais. Aí vai.
1. Escopo
O primeiro resultado esperado da GPR tem a ver com escopo. Para isso, a ferramenta deve oferecer uma função para registro e manutenção do escopo do projeto. De acordo com o GPR 1 (leia-se: resultado esperado nr. 1 da GPR), basta que o escopo esteja definido. Contudo, é nesse ponto que a GPR se relaciona com a GRE (Gerência de Requisitos). Como falei no último artigo daquela série, o escopo de um projeto é formado pelos requisitos que foram levantados. E, de acordo com o GRE 5, mudanças nos requisitos devem ser gerenciadas, controladas. Assim, é importante que a sua ferramenta de projetos restrinja eventuais alterações no escopo após a aprovação do escopo pelos envolvidos. Caso seja necessário alterar o escopo, a ferramenta deve guardar um histórico das alterações. É desejável também que a ferramenta permita que o registro da aprovação por cada envolvido. Se a aprovação puder ser feita por um usuário externo – no caso de você ser contratado isso é muito comum – a ferramenta deve possibilitar anexar uma cópia eletrônica do documento formal de aprovação do escopo.
O escopo pode ser um simples campo texto ou, dependendo da sua realidade, algo mais estruturado. Aqui onde trabalho, estruturamos o escopo em funções a implementar. Cada função, na maioria dos casos, vai representar um caso de uso. Se quiser sofisticar mais um pouco, crie um atributo para priorizar essas funções.
2. Modelo e ciclo de vida do projeto
O MPS.BR não entra no mérito sobre qual modelo de gerenciamento de projetos você deve adotar – mas exige que você adote algum. A sua teoria se baseou muito no PMBoK. Por isso, na prática, é bom você adotar um modelo que utilize pelo menos algumas das “boas práticas” preconizadas pelo PMI. A ferramenta deve representar esse modelo e o ciclo de vida que ele propõe. Por exemplo, se o modelo adotado estipula quatro fases de gerenciamento – iniciação, planejamento, execução e encerramento – a ferramenta deve representar essas fases em algum atributo que guarde o estado do projeto (exemplo: “em andamento”, “planejando”, “em encerramento”, etc). Só uma ressalva, não confunda as fases de gerenciamento do projeto com as fases de desenvolvimento, ok? Em geral, as fases de desenvolvimento estão dentro da fase de execução do projeto.
3. Orçamento e cronograma
A ferramenta deve também permitir a definir do cronograma e orçamento. De forma simples, o cronograma trata-se de uma lista de atividades e suas respectivas datas de início e fim. Essas datas, claro, são apenas estimativas e podem divergir do realizado quando o projeto entrar em franco andamento. Já orçar significa dizer quanto você vai gastar em cada atividade. Um erro comum que encontro nas ferramentas disponíveis no mercado é adotar “quantidade de dias” para o orçamento de atividades. Essa medida não é prática, pois varia conforme os recursos que você vai alocar em cada atividade. Ao invés da quantidade de dias, utilize algo que represente melhor o esforço de desenvolvimento. Não use pontos de função, pois você não vai conseguir orçar as atividades de gerenciamento do projeto com essa medida. Ao invés disso, sugiro utilizar a quantidade de horas que você planeja gastar. Escolha uma atividade e imagine quanto tempo você gastará para realizá-la com o trabalho de apenas uma pessoa. Esse é o orçamento.
Ah, é importante permitir o agrupamento de atividades para facilitar o gerenciamento e definir os marcos do projeto.
4. Riscos
O GPR 6 exige que os riscos sejam registrados e gerenciados. Se você quer que a sua ferramenta auxilie nisso, implemente uma lista de riscos. A lista deve conter a descrição do risco, o impacto, a probabilidade de ocorrência e uma classificação de prioridade. Qual unidade de medida utilizar no impacto? Bom, recomendo que você utilize a mesma unidade de medida que você utilizou no orçamento. Por exemplo, se você utilizou horas, um risco vai impactar “n” horas no projeto, i.e., o projeto corre o risco de atrasar “n” horas. Indo um pouco além do MPS.BR Nível G, sugiro que a ferramenta ofereça também uma função para vincular atividades e riscos em uma relação “n:n”. Isso vai lhe permitir identificar e registrar quais atividades existem para tratar de algum risco que exiga uma ação mais específica que precise ser definida no cronograma – vai ser útil quando você for implementar outros níveis.
5. Progresso e monitoração
O GPR 13 define que o progresso do processo deve ser monitorado. Para realizar esse monitoramento, é útil definir indicadores que sejam calculados automaticamente pela ferramenta. Os indicadores devem mostrar, por exemplo, se o projeto está atrasado, quais atividades merecem atenção, qual foi o desvio sobre o planejado, etc.
6. Promover o envolvimento de todos os interessados
A ferramenta deve permitir definir os responsáveis por cada atividade do cronograma que serão encarregados de registrar o seu andamento. Como alguns projetos envolvem usuários externos, o envolvimento desses deve ser registrado na forma de atas e outros fatos de comunicação (e-mails, ofícios, etc). Por isso, a ferramenta deve permitir que se anexe documentos desse tipo também nas atividades.
7. Marcos do projeto
Por fim, o MPS.BR fala de revisões nos marcos do projeto. Para que você saiba em qual momento deve realizar essas revisões é necessário que a ferramenta lhe permita registrar os marcos do projeto. Para facilitar a coisa, sugiro que você crie “atividades marcos”. Pode ser um simples atributo na atividade dizendo se ela é um marco ou não. Essas atividades podem receber uma atenção especial e servirem como pontos de controle.
Conclusão
Com certeza não foi possível cobrir aqui todos os aspectos abordados pela GPR. Inclusive, deixei de fora os resultados esperados não exigidos no Nível G. Mas espero ter dado alguma idéia do que uma ferramenta deve oferecer para lhe auxiliar na melhoria dos seus processos. Se não, mande sua dúvida!
Alguns outros processos, como a Gerência de Configuração, afetam bastante a GPR e seus artefatos. Assim, se você quiser se preparar para o próximo nível de maturidade, vale a pena dar uma olhadinha no guia de implementação para observar o quê você já pode prever na ferramenta para evitar dores de cabeça no futuro.
Um abraço e até o próximo artigo!

4 comentários:

Silvana Castro disse...

Lá na empresa estamos com um pouco de dificuldade com o programa de gerenciamento de projeto (PS8, já ouviu falar?). Em relação ao projeto, é ótimo, mas quando começa a colocar o cronograma das áreas de apoio, estoura o pulmão. A gente tá estudando uma forma para não estourar. Caso conheças a ferramenta, faz alguma idéia?

Samuel Diniz Casimiro disse...

Silvana, infelizmente não conheço essa ferramenta em detalhes. O que você quer dizer com "estoura o pulmão"?

Silvana Castro disse...

Desculpa a demora. Estava de férias ;)
Bom... O PS8 é uma ferramenta de gerencimaneto de projetos que trabalha com o conceito de Corrente Crítica (parecido com o Caminho Crítico), onde além de considerar o caminho mais longo, considera também a disponibilidade do recurso, evitando uma superposição. De grosso modo, a teoria da Corrente Crítica (verificando que o atrapalho dos projetos é devido à Síndrome do estudante e a Lei de Parkinson) faz com que as tarefas comecem o mais tarde possível, considerando o tempo seco (tempo que a pessoa levaria para fazer a tarefa se ninguém atrapalhá-la) e o tempo seguro (parando para atender intercorrências). Esse tempo seguro é jogado sempre pro final do projeto, que é chamado de pulmão. O gerenciamento é todo feito em cima desse pulmão. Enquanto o pulmão estiver verde, mesmo que tenha algumas tarefas atrasadas, dá para terminar no prazo. Esse pulmão, é calculado por fórmula, que o próprio PS8 faz. Agora funciona muito bem só para os atuantes diretos (programadores e analistas). No momento em que você precisa colocar o pessoal de Apoio, esse pulmão é consumido.
Daí não sabemos se é para fazer alguma coisa diferente ou é assim mesmo.

Thiago Ghisi disse...

Samuel, Sensacional!

Sem dúvida, são dicas cruciais que você passa para quem pretende atingir o nível G e que também continuam valendo para os níveis superiores do MPS.BR.

Fomos avaliados nível F com sucesso esse mês e sei que essas dicas teriam sido bem úteis se eu tivesse as lido antes de começar a desenvolver a nossa ferramenta de GPR.

Essas dicas são válidas não só para quem vai desenvolver sua própria ferramenta de GPR, mas também para quem vai procurar no mercado ou soluções open-source, pois são funcionalidades que devem existir de qualquer forma.

Parabéns mais uma vez!

Abs,