Lições aprendidas de uma gerência falha de projetos

Hoje quero compartilhar com vocês uma das experiências que adquiri com um projeto problema do qual gerencio.

Inicialmente este projeto de software era para ser piloto do processo padrão de desenvolvimento de software que definimos aqui. Este processo, por sua vez, foi definido com o foco em manutenção do software e na certificação do nível G do MPS.BR.

A equipe do projeto foi definida e composta por 4 pessoas: 1 gerente de projetos, 1 analista e 2 desenvolvedores. Tudo seria perfeito se não tivéssemos cometidos erros graves.

Testamos um processo com foco em manutenção num projeto que era de desenvolvimento. Além disto, o projeto em questão passou a ser piloto também de uma nova arquitetura que seria definido como padrão, isto é, o projeto passou a ter um foco correndo com os demais já estabelecidos anteriormente. A equipe por ser toda inexperiente (uns sem experiência com as regras de negocio e outros com o própria função) focou mais em preencher os templates e seguir o processo a risca do que na própria essência do projeto (extrair os requisitos do cliente, modelar uma solução viável e eficiente, etc). A equipe não era envolvida já que tudo chegava por documentos, a comunicação verbal era escassa. Enfim tivemos muitos problemas inerentes da inexperiência.

Então vamos às lições aprendidas:

1 - Nunca defina uma equipe no qual todos sejam inexperientes;

2 - Nunca deixe que os documentos de gerência (relatório de acompanhamentos semanais, atas de reunião, cronograma, ...) substitua a comunicação verbal. Pelo contrário, utilize os documentos apenas para registrar o que foi decidido pela equipe.

3 - Evolva toda equipe, para que cada um se sinta responsável por TODO o projeto;

4 - Escolha uma ferramenta de Gerência de Projetos que mais atenda as necessidades do projeto - isso ajudará em muito no controle e na visibilidade do andamento do projeto;

5 - Não se prenda a artefatos que DEVEM ser produzidos, mas sim às práticas do gerenciamento de projetos;

6 - Faça SEMPRE atas das reuniões e obtenha a aprovação de todos os participantes - não confie na sua memória e nem na dos outros - a ata te garante todas as decisões registradas e aprovadas;

7 - Nunca mude no meio do caminho a tecnologia utilizada para desenvolvimento da aplicação, sem antes avaliar os recursos disponíveis para tal mudança - e ainda que essa decisão venha "de cima" (dos chefes-mor), elabore argumentos que convence-os a mudar de idéia;

8 - Decida-se preferencialmente, para que um projeto não seja piloto para testar um novo processo aliado a ser teste de uma nova arquitetura.

Diante disso, o projeto começou a mudar de direção quando mudamos as práticas. Passamos a fazer reuniões semanais com a equipe interna para definir as tarefas da semana e resolver os impedimentos que surgiam. O resultado desta prática, foi um envolvimento maior da equipe, que passou a trabalhar em prol de todo o projeto e não apenas de resolver os problemas relacionados a sua função. Além disto, as atividades do projeto passaram a ser resolvidas em menos tempo. Começamos a utilizar o REDMINE (assunto para um outro post) para gerenciar as atividades do projeto. Foi incrível como a adoção desta ferramenta ajudou na visibilidade e organização do projeto.

Enfim, o que quero deixar para vocês são resultados de experiências, para que possamos avaliar como temos feito nosso trabalho e o que podemos melhorar.

Espero ajudar outras pessoas que se encontram em situações semelhantes.