No gerenciamento de projeto o conceito de liderança e outras competências comportamentais necessárias têm sido extensivamente estudados, o mesmo não se vê para a contribuição do conhecimento técnico e especialista no desenvolvimento das diversas funções de gerenciamento, é possível identificar no profissional gerente de projeto diferentes tipos de perfis, dentre os mais difundidos estão os do tipo generalista, especialista e técnico, desta forma este trabalho estuda a importância do conhecimento técnico para o gestor de projeto na área de desenvolvimento de software com ênfase na construção de sistemas de suporte à tomada de decisão.

Leia meu trabalho na integra diretamente no site do PMI Chapter São Paulo.

Parece brincadeira mas situações como esta não é tão difícil de acontecer no mundo dos projetos de desenvolvimento de sistema. O ideal é que para a saúde de um projeto e comprometimento de todos nunca aconteça. Mas sempre tem um engraçadinho!

Deixe um comentário com alguma experiência que você passou a respeito. (Pode ser até sobre aquele cliente que tentou te “Entubar” uma lista de melhorias dizendo que era bug! rs. Não precisa se identificar.

As metodologias ágeis são baseadas no processo iterativo, mas usam como comunicação o mecanismo de controle primário, que vem de testes e uso das versões do software desenvolvido, e para atender ao mercado de maneira rápida e eficiente a evolução é vista a todo o momento, seja em uma reunião, seja ao final de cada semana de trabalho.

Hoje podemos encontrar diversas metodologias para desenvolvimento de software ágil como SCRUM, Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), entre outras, abaixo um pouco mais sobre essas metodologias.

• SCRUM é uma metodologia de gestão e baseia-se em atividades de monitoramento e feedback, com reuniões rápidas e diárias com suas equipes de poucos integrantes, visando a identificação e correção de qualquer problema no processo de desenvolvimento.
• Extreme Programmimg é uma metodologia voltada para equipes pequenas e médias, que desenvolvem software baseado em requisitos não totalmente definidos e que se modificam rapidamente.
• Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma das seis metodologias ágeis originais, cujos representantes redigiram o Manifesto Ágil para Desenvolvimento de Software (http://agilemanifesto.org/), em 2001.
• Dynamic Systems Development Method (DSDM) é uma metodologia de desenvolvimento de software inicialmente baseada na metodologia Rapid Application Development, sendo iterativa e incremental, com uma abordagem que enfatiza a continuidade do envolvimento dos utilizadores.

Grande parte dessas metodologias tem como foco principal o desenvolvimento de software em períodos curtos que são chamados iterações. Essas iterações duram em média de duas a quatro semanas e são tratadas como miniaturas do projeto. Ao final de cada período de iteração é possível ter um software já com partes funcionais, possível de ser usado. Além disso, elas possuem todas as etapas necessárias para o desenvolvimento do software.

Mas é preciso ressaltar que mudar a metodologia de dese­nvolvimento de software de uma empresa não acontece da noite para o dia, é preciso mudar o jeito de agir e pensar de todos os integrantes da equipe de desenvolvimento e outras pessoas envolvidas com essa equipe, ou seja, uma mudança cultural deve acontecer de forma gradual. O primeiro passo para essa mudança é adaptar os processos da metodologia ágil que será utilizada, pois as práticas propostas por essa metodologia nem sempre são necessárias para a sua empresa, ou mesmo não são totalmente acopláveis a sua equipe e visão cultural da empresa.

Agradeço a todos que de alguma forma contribuíram para a conclusão deste artigo, orientadora, amigos e principalmente aqueles que participaram respondendo a pesquisa de essencial importância para o desenvolvimento do tema deste trabalho.

Obteve-se a opinião de 126 profissionais gestores de projetos, todos responderam um questionário com 13 perguntas que procurou traçar não só o perfil do respondente como suas qualificações técnica e a importância que ela exerce sobre o sucesso dos projetos que este gerência. O principal canal de divulgação foram listas de discussões sobre gestão de projetos (meus sinceros agradecimentos pelo espaço) e network pessoal.

O artigo já foi submetido e aguarda publicação. Após sua publicação poderei divulgar para a comunidade acadêmica e interessados todas as respostas, análise dos dados e conclusão do mesmo. Até lá segue uma amostra dos dados coletados:

Faixa de idade dos respondentes

Você já gerenciou com sucesso projetos que não seja de TI?

Antes de assumir a posição de gerente de projeto você desempenhou alguma posição técnica e/ou especialista?

Qual o grau de importância que seu conhecimento técnico promove para a boa gestão dos projetos que gerência.

Fique a vontade para deixar seu comentário.

O trabalho foi publicado no PMI Chapter São Paulo e pode ser acessado através do link: http://www.pmisp.org.br/enews/edicao1001/artigo_01.asp

Em síntese para ser elegível  à certificação PMP, o candidato necessita atender alguns requisitos de formação profissional inclusive comprovar experiência em gestão de projetos. Para ser um PMP é necessário ser aprovado no exame de 200 questões de múltipla escolha (1 certa em 4 opções onde questões erradas NÃO, anulam questões certas) com duração de 4 horas, ou seja, 1 min. e 12 seg. por questão.  detalhe é que a nova versão da prova seleciona aleatóriamente 25 questões que não entram na contagem de questões certas. Das 175 questões válidas o candidato tem que acertar no mínimo 106 para ser aprovado.

Para obter a carta de elegibilidade para a prova PMP, o candidato deverá comprovar horas de experiência em gerenciamento de projetos, conforme abaixo:

• Categoria I (profissionais com 3º grau completo): 4.500 horas e 36 meses de experiência nos últimos 6 anos;
• Categoria II (profissionais com 2º grau completo): 7.500 horas e 60 meses de experiência nos últimos 8 anos.

Estas horas devem estar distribuidas entre as áreas de Iniciação, Planejamento, Execução, Controle e Monitoramento e Encerramento, com um certo balanceamento, ou seja, se o candidato tiver apenas horas de gerenciamento em execução a carta poderá ser recusada.

Portanto,  não pode ser lançado as horas totais do projeto e sim as horas que o candidato efetivamente trabalhou gerenciando o projeto, divididas pelas fases do projeto.

Fonte: PMI – SP, Grupo de Discussão PMI-SP

E no meio do caminho tinha um poste. Que desrespeito aos deficientes.

Nesta porta deve ter uma placa pendurada: “Ao abrir verifique se as escadas se encontram neste andar”

Que interessante, banheiro tamanho familia. Você pode bater um papo ou jogar baralho após aquela feijoada…

Atravesse pela faixa de pedestre.

Sem comentários…

Espero que você não encontre uma placa dessa estando em uma rodovia de mão unica a mais de 100km/h. Ainda mais se a placa estiver pendurada na dita cuja arvore!