Quando eu era desenvolvedor nas consultorias, meu ex-GP´s só delegavam a pressão que o cliente impunhava, ou seja, não tinham nenhum poder na decisão do projeto, só sabiam repassar a pressão do cliente. “É pra ontem e prazos e mais prazos ridiculos”
[quote=mazinhospinter]Caros,
… utilizo as melhores práticas do PMI utilizo também ITIL que dá suporte a serviços de TI. …
… o “PMI apresenta as melhores práticas para também levar ao sucesso do projeto” …
[/quote]
Desculpe a implicância, mas a expressão m… práticas me parece muito perigosa, para
qualquer metodologia ou modelo. Dá a entender que essas práticas são sempre boas,
tipo balas de prata, o que pode não bater com a experiência de várias pessoas que já postaram aqui.
Não gosto de usar essa expressão nem para as coisas em que eu acredito.
Dito isto, concordo em linhas gerais com o que o Luca postou. Agrego que o modelo usado para a
certificação PMP, na experiência de quem trabalhou em uma organização com uma dúzia de PMPs,
costuma se traduzir em práticas nefastas para grande parte dos projetos: detalhamento precoce
em WBSs fossilizados, atividades 87,65 % prontas, gestão por números, desligamento do desconfiômetro dos gestores e endeusamento de ferramentas como MS Project e Primavera.
Lendo o material do PMI, você encontra muita coisa aplicável, e muita coisa que se sabe que não funciona
há décadas em outras áreas. De que maneira isso descamba para o pessoal pegar apenas a parte ruim
desafia meu entendimento.
Não digo que todo PMP aja assim, mas gato escaldado tem medo de água fria …
Jorge
"
"
Planejamento, processos e métricas não são a solução para este problema. Envolver o cliente no projeto sim. Se você quiser fazer isso com todo o overhead do PMBoK, fique à vontade, mas te garanto que com uma abordagem Lean é bem mais fácil.
Já trabalhei como gerente algumas vezes e nas últimas semanas fui convidado a fazê-lo de novo e recusei. Quanto mais estudo gerência de projetos, mais acredito que num projeto de software no final das contas o sucesso depende dos desenvolvedores, então prefiro botar a mão na massa e fazer a diferença junto com eles.
Vamos ser pragmáticos. Vou levantar 2 questões típicas de qq projeto de software e gostaria que vc respondesse como um típico GP PMP…
-
Quando o software deve ser testado no ciclo de desenvolvimento?
-
O que o GP deve fazer caso o usuário/cliente deseje modificar o escopo do projeto?
Seria bom se vc pudesse colocar referências do PMBook que sustentem suas argumentações.
"
"
Nao acredito que isso seja relevante nessa discussao porque as ideias aqui discutidas (lean, scrum, agile) sao aplicadas com sucesso em outras industrias ao redor mundo. Lamentavelmente no Brasil as empresas de sw estao atrasadas para as metodologias ageis. O profissional agil brasileiro tem poucas opcoes de trabalho aqui e alguns ate deixam o pais por causa disso.
Agile nao e um guia sobre praticas e ferramentas mas um mindset. Isso que a diferencia, e diferente do que vc insinua ela contempla sim os diferentes tipos de colaboradores.
Gerência de projetos na teoria não deveria ter nada a ver com desenvolvimento de software de forma direta, a gerencia deve estar um nível abstrato acima. Coordenando o projeto sem interferir nos aspectos técnicos do projeto.
Metodologias ágeis não são gerência de projetos em regra.
A confusão se dá porque a turma insistiu em adotar PMBOk aliado a CMMi [potencializando a ineficiência da cultura CMMi] como modelo de desenvolvimento de softwares, as vezes junto de RUP [aí se tem a tragédia completa].
Escrevi no meu blog recentemente que Gerente de projetos não necessariamente deve ser um técnico, tem um pouco a ver com essa discussão, http://www.milfont.org/tech/2008/09/25/gerentes-de-projetos-nao-sao-tecnicos/
Acredito que hoje é até melhor que o gerente não seja técnico para não ter perigo de assumir papéis dentro da equipe.
"
Referência muito genérica. É vc quem está tentando provar q PMI está alinhado com Agilidade.
Solicitação integrada de mudança=Burocracia?
Avaliar o impacto das mudanças no cronograma que determina a entrega para daqui a X meses?
Isso me cheira a algo para esfregar na cara do cliente, caso vc precise justificar um atraso na data de entrega do projeto.
Eu conheço: waterfall.
Prédios, pontes e estádios são construídos utilizando o modelo waterfall e é isso o que o PMI ensina.
Software é completamente diferente. 
pmbok tem nada a ver com waterfall
"
Por que PM* não funciona então pra software? 
Porque a cultura PMBOK vai de encontro com o próprio PMBOK, a maioria dos profissionais PMP que conheço misturam a atividade de gerencia que é algo abstrato com o desenvolvimento do software, quando não muito assumindo ações que não são dele e interferindo na equipe.
"
"
E o projeto segue uma metodologia eficaz, qual a importância do guia? Meu problema com o PMI é que a gerência vira o centro das atenções do projeto. E como você mesmo disse, pra um gerente pisar na bola é fácil fácil.
"