3P – Piores Práticas de Projeto (parte 2)

Continuamos falando sobre as piores práticas de projeto, mais uma vez com o intuito de alertar e prevenir tais práticas:

Telefone sem fio – a comunicação é essencial não apenas para a sobrevivência do ser humano, mas como também para a dos projetos. Portanto, devemos estar sempre nos perguntando se a informação está sendo gerada, coletada, documentada e passada para a pessoa certa. Segundo o PMI há quatro processos de gerenciamento das comunicações:

  • Planejamento das comunicações – determinação das necessidades  de informações e comunicações das partes interessadas no projeto.
  • Distribuição das informações – colocação das informações necessárias à disposição das partes interessadas no projeto no momento adequado.
  • Relatório de desempenho – coleta e distribuição das informações sobre o desempenho. Isso inclui o relatório de andamento, medição do progresso e previsão.
  • Gerenciar  as partes interessadas – gerenciamento das  comunicações para satisfazer os  requisitos das partes  interessadas no projeto  e resolver problemas com elas.

Eu quero eu posso – Essa é uma prática muito natural, sempre achamos que basta querer para poder realizar ou obter algo. Em projetos devemos avaliar o quanto de esforço que ele demandará e se o time está preparado, caso contrário o projeto terá grandes chances de sofrer atrasos, aumento de custo ou até fracassar. Um exemplo dessa prática foi o Pan de 2007, o maior evento poliesportivo já realizado no país, onde devido a falta de preparo dos realizadores e a problemas políticos o orçamento final ficou 1.289% a mais do que estava previsto inicialmente.

Excesso de documentação – documentação é um dos fantasmas em projetos de TI, isso porque o bom senso muitas vezes não é usado. E quando a equipe do projeto tem grande preocupação em documentar ou a metodologia usada tem como base a geração de documentos para tudo, um risco que aparece é o excesso de documentação, onde podemos ainda estar realizando a análise de risco e o prazo do projeto já ter acabado. Uma das medidas para evitar tal prática é sempre averiguar a importância que a documentação terá para o projeto e o que será documentado e o que não será. Lembrando que mais importante do que documentação gerada é software funcionando.

‘Achômetro’ – por último umas das práticas mais utilizadas não somente em projetos de TI, mas como também na nossa vida. Afinal, o ‘achômetro’ tem como base o conselho que segundo o texto de Mary Schmich, que foi transformado em um discurso musicado por Pedro Bial com o nome Filtro Solar:

Conselho é uma forma de nostalgia. Compartilhar conselhos é um jeito de pescar o passado do lixo, esfregá-lo, repintar as partes feias e reciclar tudo por mais do que vale. (“Advice, like youth, probably just wasted on the young”- Mary Schmich)

Devemos usar o ‘achômetro’ somente em momentos que realmente não teríamos como obter um histórico de dados, como por exemplo, no primeiro projeto de uma recém criada empresa. Sempre que possível, precisamos justificar as nossas ações e estratégias com base em informações e não na opinião própria ou de outras pessoas.

Aqui chego ao fim das 3P, mas com certeza há ainda muitas piores práticas de projetos que não foram citadas. Por isso, caso alguém queira colocar alguma prática que vivenciou ou conhece, por favor sinta-se à vontade. O seu comentário será bem-vindo!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK); Terceira edição, 2004. Project Management Institute, Four Compus Boulevard, Newton Square, PA 19073-3299 EUA.

http://www1.folha.uol.com.br/folha/esporte/ult92u450247.shtml

Anúncios

3P – Piores Práticas de Projeto (parte 1)

Melhores Práticas de Projeto é um dos temas que mais vem ganhando espaço no mundo de TI, pois percebemos que um bom gerenciamento é fundamental para o sucesso do projeto. Mas se temos as melhores práticas, quais seriam as piores práticas?

Abaixo explico algumas das piores práticas de projeto (3P) que devemos tomar cuidado para não cometemos:

Não envolvimento dos stakeholders – Por mais absurdo que possa parecer, essa é uma das práticas que mais acontecem, na qual um ou mais stakeholders (envolvidos com o projeto) não participam ativamente do projeto, ou participam apenas no início, ocasionando vários problemas, como requisitos mal especificados. Este é uns dos problemas que afetam diretamente o prazo e custo do projeto e em determinados casos, pode até representar o fim de um projeto. Um exemplo de não envolvimento dos stakeholders aconteceu com o projeto do Rodoanel, onde grupos ambientais não foram colocados como stakeholders no início do projeto, e esses acabaram gerando impasses para o governo, resultando em grandes atrasos nas obras e aumento do custo.

Contratação de funcionários, quando o projeto está atrasado –  No desespero, muitos gerentes acabam contratando novos funcionários, quando o prazo do projeto já está com seu prazo vencendo, pois acreditam na teoria de quanto mais pessoas mais produtividade. Porém, na prática a história é outra, esse novo funcionário, por mais habilidoso e experiente que seja, terá que receber um treinamento a ser dado por um funcionário, portanto o projeto perderá um funcionário ao invés de ganhar um. Para entender melhor, seria como você contratar um novo jogador de futebol faltando cinco rodadas para o término do campeonato, por mais habilidoso que ele seja, ele terá o seu tempo de adaptação e se ele for colocado em campo, o desentrosamento pode prejudicar o time.

Falta de documentação – essa é umas práticas mais adotadas pelas empresas, por parecer a curto prazo uma boa prática, pois economizará tempo. Porém, a longo prazo ela pode fazer com que o projeto seja o caos. Imagine a seguinte situação: na empresa XPTO Zé é  programador sênior e responsável por um módulo crítico da aplicação, porém não costuma documentar nada que faz, nem ao menos comenta o código. Um certo dia, Zé consegue um emprego melhor e sai da XPTO. E agora como o projeto continuará sem o Zé? Ele era o único que tinha conhecimento sobre aquele módulo e sem esse módulo o projeto não poderá ser entregue.

É pessoal, vocês podem estarem achando que tal situação apresentada não acontece nas empresas, mas por mais incrível que pareça essa é uma das que mais acontece e que faz muitos dos gerentes “arrancarem os cabelos” (quando ainda tem). Por isso o projeto tem que ser documentado e bem documentado.

Documentar no final – Não sei o que é pior, não documentar ou documentar no final do projeto. Uma documentação feita no final do projeto, por mais esforço que se faça, será fraca e imprecisa e a razão para isso é simples, as pessoas acabam esquecendo o que elas fazem. Para exemplificar uma pergunta clássica: o que você comeu ontem no almoço?

Talvez, você até se lembre do que você comeu ontem, mas e antes de ontem, e na semana passada?

Se eu fosse pedir para você me fazer uma documentação do seu almoço por um mês, ela teria que ser feita antes do almoço, onde você colocaria qual o restaurante que você vai almoçar, qual será o pedido, etc; durante o almoço, situação em que você falaria sobre a qualidade da comida escolhida; e após o término do almoço, você iria descrever como foi o atendimento e quanto custou o almoço.

Logo percebemos que a documentação é uma tarefa que tem que ser feita, durante todo o projeto e não somente durante uma determinada etapa do projeto.

Bem pessoal, por hoje é só. Em breve trarei a segunda parte do 3P. Até a próxima!

Fique por dentro das novidades, assine o feed do QualidadeBR.
Subscribe