Desenvolvimento

Ξ Deixe um comentário

Problemas comuns no Gerenciamento de Projetos de Software e opções de aplicação mesclando diversas práticas (Parte 1)

publicado por Anderson Moysés de Araújo

Problemas comuns no Gerenciamento de Projetos de Software e opções de aplicação mesclando diversas práticas (Parte 1)Desde o advento das Metodologias Ágeis existem muitas discussões sobre os prós e os contras de se aplicar o modelo tradicional de gestão de projeto em cenários como o desenvolvimento de software. A complexidade de cadeia de processos das metodologias tradicionais em relação às metodologias ágeis é muito maior, e se não for bem observada e otimizada, pode trazer problemas relacionados ao prazo, custo e até mesmo na qualidade do projeto.

Em geral o planejamento e execução dos projetos seguem a cadeia baseada nas fases Iniciação, Planejamento, Execução, Testes, Implantação e Fechamento. Esta forma de trabalho é extremamente efetiva em casos de projetos que o escopo é dominado por ambas as partes (Cliente e Fornecedor) de forma que o planejamento da ordem das atividades e a métrica para este projeto são assertivas o suficiente para garantir o completo sucesso do projeto, mas tratando-se de projetos de desenvolvimento de software, este cenário de alto domínio do negócio e da expectativa do cliente não ocorrem com frequência.

Em função da diversidade de necessidades que um cliente pode ter, a complexidade do projeto varia muito, sendo necessário assim, estar preparado para se adaptar a constantes mudanças. Em consequência disto, o gestor deve estar preparado para adaptar a forma como planeja e controla o seu projeto conforme o cenário apresentado.

A seguir irei detalhar o Processo de Gerenciamento de Projetos de Software desde a sua concepção e alguns problemas que ocorrem comumente.

Pré-venda

salesDurante a fase de pré-venda o fornecedor precisa levantar rapidamente todos os requisitos do projeto em um nível de abstração que seja o suficiente para estabelecer a precificação do projeto (baseando-se em métricas como Pontos de Função, Pontos por Caso de Uso, Nesma, etc.) e também estabelecer a duração prevista do mesmo, afim de manter o fluxo de caixa saudável para o projeto. Tomando por base essa precificação, o cliente avalia o cenário e se ele julgar um valor factível de ser pago, ele fecha o projeto.

O primeiro cuidado que deve-se ter está neste momento. O processo de precificação deve envolver uma ou mais pessoas (de preferência o time de desenvolvimento) para validar esta métrica evitando possíveis erros de precificação (construção do preço sob o olhar pessimista ou otimista demais). Eu costumo praticar com a minha equipe de desenvolvimento o Planning Poker baseando-se nas histórias inicialmente levantadas.  A partir deste exercício, atividades inerentes à gestão de projetos devem ser inseridas tomando por base os artefatos que o PMO da sua empresa exige, para só assim, fechar a precificação do projeto.

Uma alternativa seria utilizar métricas de mercado como já havia mencionado anteriormente, mas para que isto seja possível, o nível de detalhamento na proposta técnica deve ser  muito bem detalhado uma vez que estas métricas levam em consideração as relações entre classes (ou tabelas), seus atributos e a complexidade de implementação. Vale ressaltar mais uma vez que estas métricas contemplam assim como o caso do planning poker somente o processo de desenvolvimento de software, sendo necessário incluir os demais artefatos demandados pelo PMO (Reuniões de status report, Especificações Funcionais, Mapeamentos de Arquitetura, etc.).

Requisitos não funcionais devem ser detalhados na proposta e ressaltados durante o levantamento com a equipe, pois eles muitas vezes se tornam fator de complexidade no desenvolvimento de uma funcionalidade, e acima de tudo, deve-se deixar muito claro as regras quanto à mudança de escopo prevalecendo a transparência na relação entre o cliente e o fornecedor.

Sem estes cuidados, o projeto pode nascer já com um fator de sucesso baixo, uma vez que sem que estas medidas básicas sejam tomadas, o projeto tende a ser subestimado.

Na semana que vem eu seguirei com a parte 2 do artigo onde falarei sobre fase de iniciação e planejamento do projeto.

[Crédito da Imagem: Gerenciamento de Projeto de Software – ShutterStock]

Autor

Atualmente sou coordenador de serviços, com mais de 10 anos na área de TI. Gerencio projetos de fábrica de software na plataforma Microsoft. Sou pós-graduado em Engenharia de Produção com Ênfase em Gestão de Projetos pela UERJ e também sou certificado CSM pela Scrum Alliance. Possuo conhecimento em gestão de projetos de desenvolvimento de software Orientados a Objetos utilizando metodologias ágeis como Scrum, Kanban atuando também com o PMBOK. Meu objetivo é atuar em projetos afim de otimizar projetos de desenvolvimento de softwares e motivar pessoas para atingir os objetivos propostos. Minhas especialidades são: Gestão de Projetos baseada no PMBOK, Gestão de Projetos Ágeis com SCRUM, Gestão de Projetos Ágeis com Kanban, Governança de TI, Motivar pessoas para que metas sejam alcançadas, Engenharia de Software, Desenvolvimento de Projetos de Software OO.

Anderson Moysés de Araújo

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes