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.

Qual o real papel do analista?

Quero começar compartilhando um artigo de um blog que li, muito interessante.

Qual o verdadeiro papel do analista? O perfil dele deve ser de desenvolvedor como o mercado hoje exige, ou deve ser alguém totalmente independente de tecnologia e focada apenas no entendimento das regras de negócio?

Segundo Philip, o autor deste artigo, o analista deve ser focado nas regras de negócio.

"O analista deve trabalhar em conjunto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente."

"Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos."

Particularmente, eu sou de acordo com a idéia que o analista deve sim ser expert em entender a regra de negócio, ou ainda, ter perfil de negociador, isto é, alguém que sabe como fazer o cliente expor as informações chaves e  necessárias para solução do problema dele, e principalmente para convencer o cliente do que ele realmente necessita. Pois o que temos hoje são equipes que possuem desenvolvedores que não entendem do negócio e clientes que não sabem exatamente o que necessitam, resultando em sistemas que vão ao ar não contendo "exatamente o que o cliente necessita, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores".

Para uma metodologia mais ágil de gerenciamento de projetos, essa visão de analista seria muito mais eficaz, uma vez que o analista seria o facilitador para que a equipe pudesse trabalhar de forma mais objetiva e específica, atuando no problema bem definido e não na "lista interminável de desejos do cliente" que só descobre não serem necessários no final, quando já se gastou muito tempo e esforço para o seu desenvolvimento.

Portanto é preciso avaliar cada cenário e diagnosticar qual será a verdadeira função de um analista dentro de cada cenário.

Quem quiser ler o artigo do Philip, acesse: http://blog.fragmental.com.br/2008/11/23/deixa-para-os-analistas-de-verdade/ - Deixa Para os Analistas de Verdade… por Philip