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

Durante 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.

Olá Leitores

Em 2012 eu iniciei a empreitada de criar um blog e compartilhar minhas experiências profissionais e minhas análises resultantes do meu constante estudo sobre Engenharia de Software e Gestão de Projetos de TI, Porém meu tempo reduzido me impediram de continuar a empreitada e neste meio tempo outros projeto pessoais apareceram e tive que segurar a retomada do blog.

Com o meu retorno, espero criar artigos com textos simples porém com conteúdo que possa agregar conhecimento e permitir também a troca de experiências na área de comentários. Espero contar com vocês com sugestões, complementações, dúvidas, etc.

Espero que gostem e meu compromisso é a melhoria contínua. Entrem e fiquem à vontade.

Burocracia X Procedimento. É a mesma coisa?

Com o aumento da busca pela qualidade incessante dos processos, profissionalização constante do processo de concepção e gestão de projetos, cada vez mais se houve a seguinte afirmativa: “Nossa é muita burocracia. Perco muito tempo escrevendo um documento que não agrega valor ao meu produto.” Sim. Tenho certeza que todos nós profissionais de TI já nos deparamos com alguma situação em que repetimos esta frase ou ouvimos alguém repeti-la.

Na realidade a palavra burocracia nasceu na segunda metade do século XVIII, sendo de origem francesa e naquela época, se referia aos trabalhos e trâmites administrativos da máquina pública, submetidos a processo de rígidas normas e hierarquia de cargos.  Hoje ainda esta palavra é utilizada para se referir a estes processos engessados que atrapalham o bom andamento de um projeto de TI.

Mas porque existem tantas pessoas que apoiam o fim da burocracia se ela é baseada na padronização do trabalho e aumento da produtividade. Estas premissas estão presentes nas metas de todos os gerentes de projetos. Diante disto mesmo os gerentes de projeto mais experientes acabam criando uma enorme gama de documentos e normas que visam melhorar o processo e aumentar a qualidade dos artefatos gerados, acabam muitas vezes gerando forte dependência deste processo de formalização.

Todo processo quando é mapeado pode ser eficiente e eficaz. Para validar a sua eficácia e eficiência devemos fazer sempre que este processo é utilizado a seguinte pergunta: Faz sentido o que eu estou fazendo? Esta pergunta responde ao questionamento se para você este processo é um padrão ou mais um agente complicador gerador da tão conhecida burocracia. Vale destacar também que mesmo tendo em mãos este poderoso questionamento podemos nos equivocar. Equivocamos-nos por falta de embasamento, por não dominarmos a rotina, ou por estarmos em uma zona de conforto onde mudanças não são bem vindas.

Um exemplo bem interessante é a geração do Plano de Comunicação do Projeto. Um Plano de Comunicação bem redigido pode prevenir diversos problemas causados pela distância de uma equipe de projetos localizada na França e a Fábrica de Software que está localizada na Índia. Imagine como seria realizar reuniões e acompanhar o andamento da fábrica sem que as regras de comunicação bem como os seus respectivos meios estejam definidos. É algo realmente complexo.

Este mesmo Plano de Comunicação de Projeto deixa de fazer sentido para um projeto de 50 horas para confecção de um script de banco para carga fria de novos funcionários da empresa. Na linha de Gerenciamento de Projetos erros como este podem ocorrer, pois as ditas boas práticas devem ser conhecidas e aplicadas sempre que possível. Uma metodologia dificilmente é aplicada 100%. Metodologia não é norma. Mesmo as metodologias ágeis podem se tornar burocráticas, se mal aplicadas.

Por isso sempre digo para se tomar cuidado com a palavra Burocracia. Antes de julgar alguma atividade a ser executada como burocrática, faça as seguintes perguntas a si mesmo:

1. Tenho domínio do objetivo e do como realizar o processo?
2. Faz sentido para mim ou para os stakeholders do projeto?
3. Se não faz, porquê?

Com estas três perguntas conseguimos com total consciência saber a diferença entre Burocracia e Procedimento e a convicção de o que estamos fazendo realmente está agregando valor ou se é só mais um documento que temos que preencher.