Quando se fala de melhorar técnicas de estimativa ou aproveitar lições aprendidas de projetos passados, para que os mesmos erros não se repitam, sempre há quem se lembre da necessidade de implementar uma base de conhecimento, uma base histórica ou algo assim...

Mas, quando o assunto esgueira-se ao “como” e ao “o quê”, tudo fica mais complicado, pois há muita confusão e falta de entendimento a respeito do tema.

Há três pontos fundamentais que devemos considerar:

1. Base de conhecimento não é simplesmente um “caldeirão” de materiais de projetos anteriores

Toda a documentação dos projetos deve ser guardada, mas este oceano de dados não vale muito se não for organizado e seu uso não for direcionado. Não é razoável esperar que um gerente de projetos fique garimpando este manancial em busca de algo útil para seu novo projeto como se fosse um estudante fazendo uma busca na internet para reunir elementos para o próximo trabalho da escola. Até porque o próximo projeto pode não ter muito a ver com os anteriores, dado o cenário mutante de requisitos e tecnologia em que vivemos.

A disponibilização de fóruns de discussão pode ser uma boa idéia, mas somente se as pessoas dedicarem-se bastante aos mesmos, contribuindo ativamente. Normalmente, não se tem muito tempo para isto, salvo os casos de aficionados, participando em altas horas. Neste caso, uma boa forma de lançar um tópico é reportando um problema, ou uma necessidade, e perguntando quem já passou por aquilo ou possui algum material aproveitável para a questão.

2. É preciso saber e ter o que guardar, de forma prática

Quanto mais orientada for a contribuição à base de conhecimento, melhor. Desde que, é claro, não seja preciso realizar um verdadeiro projeto à parte ao final dos trabalhos para formatar as informações. Há peças do projeto que já carregam para a finalização elementos importantes prontos, como por exemplo versões finais de cronogramas e planilhas de controle financeiro.

Quanto a lições aprendidas, é mandatório realizar uma reunião ao final do projeto (post-mortem) para discuti-las e organizá-las, mas tal evento só será produtivo se ao longo de todo o projeto tiver havido um esforço de capturar as tais lições – isto porque fica muito difícil lembrar de todas na reunião (as mais marcantes virão facilmente, mas muito se perde pelo caminho). Assim sendo, recomenda-se instituir na equipe o hábito de ter uma folha de papel na mesa de cada um destinada anotar as “cabeçadas” assim que elas ocorrem. Na reunião de lições aprendidas, todos trazem suas folhas. Isto tem uma eficácia extraordinária. Vale lembrar também que, em projetos de tecnologia massiva, como os de TI, numerosas lições advém de aspectos de arquitetura técnica.

3. As informações de projetos anteriores precisam ser tratadas

A simples existência de um conjunto de registros semelhantes ao apresentado no item 2 sem o devido uso dos mesmos de nada vale. Seguem algumas idéias para a utilização:

- Na inicialização de cada projeto, selecionar na base os registros de tecnologias, clientes e tamanhos similares e apresentar a quem vai gerenciar o novo projeto. Com isto, a pessoa terá uma visão do que se passou naquele contexto. Uma boa idéia também é fazer uma imersão com o gerente do novo projeto no contrato que foi celebrado, para que possa ser entendido o que foi vendido, que aspectos mais foram discutidos na negociação, que premissas ou restrições excepcionais foram ventiladas, quais são as pessoas e os assuntos “difíceis” para o novo projeto etc.

- Observar os conteúdos dos registros para melhorar o dimensionamento inicial dos projetos e a composição de premissas. Uma área elaboradora de propostas, por exemplo, pode ter subsídios para ajustar suas estimativas, observar curvas de aprendizado (com base nos indicadores) e compor premissas (com base nos riscos realizados e lições aprendidas). Poderemos ver também o montante de mudanças que ocorreu em cada cliente, obtendo indícios de quanto ele tipicamente apresenta de mudanças em seus projetos.

A estrutura organizacional que deve cuidar da composição, crescimento, organização e uso de uma base de conhecimento é o escritório de projetos (PMO). Isto muita gente sabe mas pouca gente faz. Afinal, estão todos ocupados corrigindo falhas que, muitas vezes, já aconteceram em projetos anteriores.

Uma última observação (talvez um pouco frustrante) sobre o tema: projetos são muitas vezes complexos e bem diferentes entre si. Não devemos esperar que uma base histórica seja uma bola de cristal, pois isto só seria possível se muitos projetos bem parecidos, e razoavelmente simples, tivessem acontecido e estivessem registrados (e bem) na base. Sendo empreitadas que envolvem tecnologias (em rápida evolução), requisitos (via de regra mutantes) e, em especial, pessoas (complexas por natureza), projetos reais de alguma complexidade não se enquadram tão bem em processos definidos, não são tão repetíveis e não sinalizam tanto assim sobre como os próximos serão. Contudo, como gerentes de projetos, temos de morrer lutando – é a nossa sina.

Autor: Roberto Pina Rizzo, MSc, PMP - Diretor Executivo - Verx Consulting

Se desejar entrar em contato com o autor, escreva para: O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo.