Pesquisar este blog

segunda-feira, 28 de novembro de 2011

O Gerente de Projetos - Um profissional temporário

Olá pessoal.

Já faz algum tempo que não publico nada aqui neste blog. Ultimamente o meu acesso à internet estava um tanto quanto escasso, e a vontade de ficar navegando após o dia inteiro de trabalho era muito pequena. Minhas sinceras desculpas.

Alguns fatos que ocorreram ultimamente me motivaram a publicar esta postagem - com um tema um tanto polêmico - sobre a condição temporária da maioria dos gerentes de projetos profissionais.

Vejamos bem: Os projetos - nossa área de atuação - tem uma característica fundamental, muito bem descrita pelo PMBOK: tratam-se de empreendimentos temporários, com começo e fim determinados. Mas o que dizer dos profissionais que se dedicam ao gerenciamento desses empreendimentos? Pois é... uma grande parte deles também tem "prazo de validade".

Não entendam esse post como uma reclamação, muito menos como uma lamentação. Trata-se de um alerta àqueles que pensam ingressar nesta área. Perdoem-me a franqueza e frieza, mas os profissionais de projetos tem uma "usabilidade" determinada, sendo que, ao fim do projeto, seu trabalho costuma não mais ser necessário (salvo alguns poucos que se dedicam prioritariamente à execução de projetos em fábricas de software ou em empresas dedicadas especificamente à venda de projetos).

Para aqueles que dão a sorte de tomar parte em projetos de verdade - aqueles com P maiúsculo, inéditos de fato, com prazos, metas e objetivos definidos - devem ter em mente que o seu trabalho também acaba ao término do projeto... Caso você pretenda entrar nessa área, tenha isso em mente: o seu trabalho é temporário!

Mas então como lidar com essa característica na sua vida profissional? Ora, você planeja muito bem os projetos dos seus contratantes, não é mesmo? Então planeje muito bem o seu projeto de vida, para não ser pego de surpresa por essa situação. Fatos previsíveis não podem ser considerados supresas - lembre-se da gestão de riscos e aplique-a à sua vida!

No meu caso, já atuo com projetos há mais de 10 anos, portanto, já me adaptei a essa "vida nômade" que levamos, sendo assim dedico uma parcela daquilo que ganho para os intervalos entre os projetos. Para ser sincero, me adaptei tão bem que às vezes eu cobro de mim mesmo mudanças de ares quando não vejo mais perspectivas reais para o desenvolvimento pessoal e profissional.

Então, sendo bem direto: se você não quer prazo de validade para sua vida profissional, pense duas vezes antes de investir seu tempo e dinheiro em uma formação em gerenciamento de projetos...

Agora, se você está buscando uma vida menos acomodada, com oportunidades de crescimento a cada nova experiência, aumento da sua rede de contatos (a real, não aquela da internet!), então você está no caminho certo! E, como não há bem que sempre dure, e não há mal que nunca acabe, saiba tirar o melhor de cada oportunidade que a vida te der. Programe-se para os períodos de vacas magras e viva intensamente todas as suas experiências profissionais, sejam elas permanentes ou temporárias.

E não se deixe abater caso perceba que seu trabalho terminou. Isso é um dos sinais de que seu trabalho foi bem feito! Tenha isso em mente, levante a cabeça, perceba que você cumpriu com aquilo com o que se comprometeu - e isso é o maior sinal do seu sucesso!

Um grande abraço, em especial para os valentes profissionais que se dedicam para elevar o gerenciamento de projetos ao título de profissão.

Saúde e sucesso,

Rodrigo Ramos, PMP



sexta-feira, 23 de setembro de 2011

Agile Project Management - Funciona para você?

Bom dia pessoal, tudo bem?

Já faz algum tempo que me interesso bastante pelo tema dos métodos ágeis para gerenciamento de projetos e como elas podem agregar valor ao projeto e principalmente ao moral do time. Não há como negar que algumas vezes a burocracia que metodologias mais conservadoras impõe sobre o trabalho do projeto acabam por causar problemas no logo prazo dentro da equipe, como a insatisfação, falta de motivação e às vezes um sentimento de frustração.

Para quem vive o mundo do PMI, quando lemos o Manifesto Ágil, sentimentos antagônicos de encantamento e de estranheza sempre aparecem. Mas os pontos relevantes (que aqui colocarei em uma tradução livre) do manifesto causam tanto impacto que não podemos deixar de levá-lo em consideração. Neste manifesto os pontos de destaque (na minha modesta opinião) são:
  • As pessoas e as interações entre elas são mais importantes que os processos e ferramentas
  • Produto funcionando é mais importante que documentação abrangente
  • Colaboração com o cliente é mais importante que negociação de contratos
  • Responder às mudanças é mais importante que seguir o plano
Para muitos praticantes do que chamo PMI'ismo, essas coisas podem chegar a causar arrepios, afinal, o PMBOK é fundamentado em processos bem definidos, tem passagens importantes sobre o controle de mudanças, negociação de contratos, enfim, é um antagonismo que pode causar desconforto naqueles mais ortodoxos.

Porém alguns fatos importantes devem ser considerados ao analisarmos ambientes de projetos específicos, em especial projetos de desenvolvimento de novos produtos, que inicialmente adotou o PMBOK como padrão para a gestão de projetos. Nessa área, um fato começou a se tornar visível: o índice de sucesso e satisfação dos clientes sempre estava abaixo da expectativa.

Ora, se estamos desenvolvendo um produto, algumas caraterísticas devem ser observadas:
  1. O produto deve se adequar a novos requisitos que aparecem durante o processo de desenvolvimento
  2. As mudanças no produto podem significar maior índice de sucesso deste produto depois do projeto concluído
  3. O cliente (que é o dono do produto) deveria participar ativamente das decisões do projeto, e alterá-lo de acordo com o seu plano de negócios
  4. O plano de negócios também pode mudar no decorrer do projeto
  5. O cliente sempre quer ver alguma coisa pronta nas reuniões de status
  6. A equipe quer trabalhar em paz durante o processo de criação do produto
Em resumo: o processo de desenvolvimento de produtos não combina muito com o método do PMI (voltarei a este assunto no próximo post). Era necessário alguma coisa nova, que quebrasse o paradigma da rigidez ditada pelo PMBOK. Nasceram então as metodologias ágeis de gerenciamento de projetos.

Hoje em dia todos pensam que isso só se aplica a desenvolvimento de software, mas os "ratos da informática" estão enganados. O método ágil surgiu (pasmem) na indústria automobilística, no processo de desenvolvimento de novos modelos de carros. Mais tarde foi adaptado e amplamente adotado pela indústria de desenvolvimento de software, onde o Scrum emergiu.

Os princípios são básicos e muito simples: rodadas de planejamento e rodadas de execução do plano, nada muito diferente do modelo tradicional. A diferença está na maneira como isso é realizado. O PMI e seu método nasceram em um momento onde os "chefes" e "gerentes" tinham formação técnica, e conheciam muito mais do que seus subordinados. Por isso o GP era o centro de tudo. Todas as decisões, todas as medidas eram tomadas por ele. Claro que ele ouvia sua equipe, mas a decisão final era do GP.

Hoje, com o alto grau de especialização dos trabalhadores, muitas vezes o "gerente" não é mais o grande técnico do passado. Normalmente seus subordinados conhecem a tecnologia em um nível muito maior do que ele. Pensando nisso, alguns visionários resolveram "derreter" a função do gerente do projeto, dando maior liberdade para a equipe do projeto (que deve ser multidisciplinar) se auto-organizar.

Após algumas experiências, percebeu-se que o moral da equipe estava mais elevado, as entregas do projeto haviam sido realizadas em prazo menor e com menor esforço. Estavam criados os fundamentos do APM (Agile Project Management).

Alguns devem estar se perguntando: e onde foi parar o gerente do projeto?

Bem, essa resposta não é simples, uma vez que a orientação dos métodos ágeis é mais aderente à gestão de produtos, e não de projetos, a função do GP foi dividida em 3 partes:
  1. Macro gestão - Atribuída ao "dono do produto"
  2. Micro gestão - Atribuída ao time de desenvolvimento
  3. Processos - Atribuída ao que poderia ser chamado de GP
O "GP" nesses casos é o líder servidor ou colaborativo. Ele trabalha para que a equipe não tenha nenhum tipo de impedimento durante o desenvolvimento do produto. O "GP PMI" também exerce esse papel, porém quando somos ágeis, a equipe é responsável por resolver seus próprios problemas, excluindo do GP a função de gestão micro de RH (conflitos, etc.). Isso passa a ser responsabilidade da equipe, assim como o planejamento de cada ciclo de desenvolvimento e a resolução de problemas técnicos do projeto.

Então o que o GP faz? Ele remove os impedimentos. Um impedimento é algo que está além da capacidade de resolução da equipe, como por exemplo falta de um treinamento específico, algum recurso material necessário para o projeto e coisas desse tipo. O GP também é o responsável por proteger a equipe das influências externas, pois, durante um ciclo de desenvolvimento, a equipe deve estar focada exclusivamente na resolução dos problemas do projeto.

Confuso? Eu também achava... Assustado? Eu também fiquei... Isso é a morte dos PMP's? Certamente não.

Os métodos ágeis funcionam muito bem quando não se tem um escopo claro e definido, quando iterações no plano são desejadas e esperadas, quando o time-to-market de um produto precisa ser reduzido (ainda que ele seja apresentado com menos funcionalidades do que o produto final). Para aqueles projetos onde o escopo é claro, o prazo e o custo são definidos, o modelo PMI ainda se aplica de forma mais eficaz. Imaginem um prédio ser planejado e construído em etapas independentes? Provavelmente não seria o método mais eficiente e eficaz para fazer isso...

O que não podemos é virar as costas para o movimento ágil, pois ele preenche lacunas expressivas que o PMBOK não sabe como tratar. Até mesmo a integração dos métodos ágil e tradicional é possível, e até mesmo saudável!

O que nós, gerentes de projetos e agentes de mudanças, precisamos ter claro em nossas mentes é que toda metodologia, todo framework, todas as boas práticas são adaptáveis e devem ser adaptadas à nossa realidade. Por isso eu indico sempre o estudo. Estude sempre. Leve consigo o que considerar adequado, guarde para o futuro aquilo que não considera ideal hoje e esteja pronto para quebrar os seus próprios paradigmas na sua profissão. Você não é gerente de projetos, você está gerente de projetos. Aproveite a jornada!

Um grande abraço!

Saúde e sucesso,
Rodrigo Ramos, PMP, CSM

terça-feira, 23 de agosto de 2011

PMI lança nova certificação em metodologia ágil: PMI-ACP

Olá pessoal, tudo bem?

Tenho certeza que muitos dos leitores deste blog já ouviram falar em metodologias ágeis para o gerenciamento de projetos. Muitos têm sentido o crescimento de demanda do mercado por profissionais capazes de colocar em prática o potencial das metodologias ágeis.

As empresas que adotaram metodologias ágeis tem registrado o valor agregado por esta prática:
  • Feedback do cliente: como o cliente está envolvido no desenvolvimento do projeto, existe uma tendência de que o resultado do projeto esteja mais alinhado com sua expectativa, reduzindo retrabalhos;
  • A maior visibilidade e influência sobre o progresso do projeto possibilita corrigir desvios mais cedo;
  • Medições e retornos facilitados: a maior visibilidade sobre o escopo e sobre os prazos dos entregáveis possibilita um retorno de investimento sobre o projeto mais rápido.

Existem diversas iniciativas no campo das metodologias ágeis, e a mais bem sucedida até o momento é o SCRUM. Obviamente o PMI não quer ficar de fora da festa, então lançou o seu próprio programa de certificação em metodologias ágeis, o PMI-ACP, ou Agile Certified Practitioner.

Esta decisão do PMI se baseou no resultado de uma pesquisa (Pulse of the Professional), que demonstrou que a adoção de práticas padronizadas para a gestão de projetos resultam em melhor performance na execução dos projetos.

Uma das práticas monitoradas nos últimos anos pelo PMI é o contínuo crescimento das metodologias ágeis, notando que muitos profissionais de gerenciamento de projetos apontavam esta prática como seu "canivete suíço" da sua "caixa de ferramentas".

Como resultado, muitos PMOs têm solicitado aos seus GPs que apliquem métodos ágeis nos seus projetos.

Segundo a pesquisa, 68% das organizações entrevistadas que utilização métodos ágeis revelaram que uma certificação ágil traria valor para os profissionais e para a organização. Outro dado relevante foi o fato de que 63% dos empregadores considerarem e apoiarem seus colaboradores a possuir uma certificação ágil.

Os requisitos para a prova são parecidos com os da certificação PMP:
  • Diploma de 2º grau;
  • 2000 horas de experiência em projetos comprovadas nos últimos 5 anos;
  • 1500 horas de experiência em metodologias ágeis, apuradas nos últimos 2 anos;
  • 21 horas de treinamento em metodologias ágeis
Os custos divulgados pelo PMI também são expressivos:
  • Para membros do PMI: USD 435,00
  • Para não-membros: USD 495,00
O exame consiste de uma prova realizada em computador, composta de 120 questões, das quais as 20 primeiras serão utilizadas como pré-teste, e não contam para o resultado do exame. O exame tem a duração de 3 horas.

Ainda segundo o PMI, o conteúdo da prova se baseia em:
  • Ferramentas e técnicas ágeis: 50%
  • Habilidades e conhecimentos em metodologias ágeis: 50%
Estamos notando que o crescimento e a adoção de metodologias ágeis é um processo irreversível. O PMI não quer ficar de fora dessa onda e tratou de preparar uma certificação neste contexto.

O processo ainda está em fase experimental, sendo que as primeiras provas devem ser realizadas a partir deste mês (agosto/11) .

É mais uma opção para rechear o currículo, e, em conjunto com a certificação CSM (Certified Scrum Master), uma forma de demonstrar proficiência nesta prática que tem cada vez mais adeptos.

Saúde e sucesso!

Rodrigo Ramos, PMP


quarta-feira, 13 de julho de 2011

Como implantar uma metodologia para gerenciamento de projetos na minha empresa?

Olá pessoal, tudo bem?

Gostaria de, neste post, comentar sobre as adaptações que as empresas fazem em relação aos processos descritos no PMBOK e como essas alterações podem ser utilizadas para moldar o gerenciamento de projetos para um modelo adequado à sua empresa.

O primeiro passo que precisamos dar é entender o quê o cliente espera ganhar com o gerenciamento de projetos, para podermos criar uma linha de trabalho que tenha como objetivo atender às expectativas deste cliente.
O caso onde atuei possuía alguns requisitos bem definidos:
  1. A alta gerência e diretoria comercial queriam ter visibilidade do status dos projetos em andamento, em planejamento e encerrados;
  2. Necessidade de melhorar a definição e o controle do escopo dos projetos, pois quase sempre havia desvios nas entregas não mapeados, gerando retrabalhos;
  3. Desejo de criar um padrão para a entrega de documentação dos projetos;
  4. Criar um ambiente de colaboração para as equipes do projeto;
  5. Dar visibilidade de todo o processo de gerenciamento do projeto através de indicadores de fácil compreensão.
Este conjunto de requisitos é complementado por um conjunto de variáveis ambientais, tais como:
  1. A equipe de projetos não controla o custo real dos projetos, apenas as horas trabalhadas.
  2. A equipe de projetos não realiza compras diretamente, apenas as requisita para o departamento de compras;
  3. Os projetos na sua maioria são muito semelhantes em escopo
  4. Os projetos são em sua grande maioria de curto prazo (< 2 semanas)
  5. A documentação dos projetos possui um conjunto restrito de documentos.
Estas diretrizes nos dão algumas pistas de como devemos adaptar os processos do PMBOK (que foram escritos baseados em projetos para levar o homem à Lua, mas podem não ser adequados para pequenos projetos...) para que eles funcionem no mundo real da sua empresa. Por exemplo: Uma vez que a equipe de projetos não controla os custos reais do projeto, seria necessário um grande processo de gerenciamento de custos?

Adaptar significa, muitas vezes, remover alguns processos do PMBOK do âmbito de gerenciamento de projetos da empresa, de modo a simplificar a implantação de uma metodologia que crie um padrão de entrega, pois quanto mais processos gerenciados existem, maior é o custo e o tempo gasto pelos gerentes e analistas de projetos nessas atividades.

Outro passo importante para aumentar as chances de uma nova metodologia ser bem sucedida, é observar a aderência a processos já seguidos, ainda que informalmente, pela empresa. Para isso, é necessário observar como a empresa funciona HOJE. Esta etapa, no meu ponto de vista é a mais importante do processo de implantação. Com base no que se faz hoje será definido como a empresa poderá funcionar amanhã.

Esta fase por vezes é "esquecida" durante um projeto de implantação de uma nova metodologia. Algumas consultorias possuem um "kit padrão" que acreditam funcionar (com o mínimo de adaptações) para qualquer cliente. Nem sempre é assim que a coisa acontece na prática...

Muitas vezes as empresas já possuem um processo informal em vigor, os colaboradores sabem o que fazer e como fazer, porém, por não haver um padrão estabelecido, cada um executa as atividades ao seu modo. O resultado: falta de padrão, sensação de desorganização e de falta de preparo da equipe.

O mapeamento dessas atividades pode ser muito útil para a criação de uma metodologia que de fato funciona para aquela empresa, e isso certamente irá diminuir a resistência à sua adoção pelos colaboradores, uma vez que as suas atividades diárias serão menos impactadas do que se tentássemos uma implementação "do zero".

Voltando ao caso que originou este post: a metodologia do cliente em questão reduziu de 42 processos definidos no PMBOK para apenas 14, observando sempre todos os sistemas existentes na empresa, fontes de dados e padrões de documentação. Desses 14 processos, cerca de 10 já eram executados pela equipe do cliente, ainda que nem eles mesmos soubessem. Coube ao projeto de implantação da metodologia o trabalho de documentar as rotinas e procedimentos de forma a padronizar o trabalho dos analistas, bem como as saídas de cada processo.

O próximo passo é realizar avaliações constantes no processo, além de medir o desempenho atual contra o que se realizava no passado, para buscar melhorias e aumento na performance dos projetos. Tenham certeza que voltarei com os resultados, assim que os tiver disponíveis, para compartilhar com vocês.

A adoção de uma metodologia própria traz inúmeras vantagens para o processo de implantação, porém, cria a necessidade de uma manutenção mais constante, muitas vezes sendo necessária a criação de um PMO, ainda que simples, para "tomar conta" do processo e identificar e corrigir os desvios.

A lição que eu tirei deste projeto é que, independente do tamanho e do grau de maturidade de uma empresa, ela sempre poderá se beneficiar de uma metodologia para gerir seus projetos. E o caminho para o sucesso ao implementar uma metodologia pode ser retirado da sabedoria popular: nem tanto ao mar nem tanto à terra.

E uma dica: É mais fácil adaptar a metodologia ao funcionamento da empresa do que a empresa à metodologia.

Saúde e sucesso!

Rodrigo Ramos, PMP

quarta-feira, 15 de junho de 2011

PMI: Reportando PDUs – Mantenha sua certificação PMP!


Você estudou, treinou, ralou e finalmente conseguiu se tornar um PMP. Parabéns pelo seu esforço e pela dedicação que realmente foram necessários para esta conquista!

Ao contrário de muitas certificações de mercado, onde basta passar na prova para estar certificado pelo resto da vida, o PMI exige que os profissionais que possuem suas certificações participem de um programa de reciclagem e aprimoramento profissional.

Para manter sua certificação é necessário cumprir um plano de desenvolvimento profissional, monitorado pelo PMI, através do report de PDUs, ou Professional Development Units. O processo de reporte de PDUs é feito pelo site do PMI (www.pmi.org).

Para garantir sua certificação o PMI exige que cada profissional certificado reporte ao menos 60 PDUs durante o período de 3 anos o qual a certificação é válida.

O processo foi atualizado em 1º de Março de 2011, de modo a simplificar a vida dos certificados. Entre as mudanças que ocorreram podemos destacar:

•    A estrutura de classificação das PDUs foi reduzida de 18 categorias para apenas 6;
•    Todas as categorias obedecem a regra de 1 hora de estudo = 1 PDU;
•    As categorias foram expandidas para abrigar os avanços da WEB 2.0 (Ambientes de colaboração);
•    Foram criados limites para determinadas categorias, obrigando os certificados a buscarem a educação continuada em gerenciamento de projetos para manterem sua credencial.


As categorias de PDUs são divididas basicamente em Educacional e Aprimoramento Profissional. Cada categoria possui 3 classes, conforme a tabela abaixo:





No novo padrão de reporte, as PDUs referentes ao Aprimoramento Profissional (D, E e F) foram limitadas a 45 PDUs por ciclo de 3 anos, sendo que a categoria F. possui limite de 15 PDUs.
A categoria C. Auto-estudo também possui limite de 30 PDUs por ciclo. As demais categorias educacionais não possuem limites de reporte.

Esta proposta visa manter os profissionais atualizados com as novidades da área de gerenciamento de projetos, sendo assim, estudar (em sala de aula) é obrigatório para manter-se certificado.

O processo de report no site do PMI é bastante simples. Ao clicar em Report PDUs, você será direcionado ao site específico para entrar com os dados referentes à sua solicitação de PDUs.




O processo é autoexplicativo, mas prepare-se: será necessário digitar um grande número de informações para cada reporte, tais como: nome do projeto, duração do projeto, áreas de conhecimento envolvidas, nome da instituição de ensino, datas de realização de cursos, duração de cursos, etc.
Abaixo segue a tabela extraída diretamente do site do PMI, onde constam os limites para cada categoria de PDUs disponível no site do PMI para acesso público.

Limites de PDUs por categoria
É importante ressaltar: A manutenção da sua certificação depende do reporte de PDUs. Se você não cumprir o estabelecido pelo PMI (60 PDUs a cada 3 anos), você perderá sua certificação. Não existe segunda chance nesse caso, se acontecer, todo o processo de certificação deverá ser iniciado novamente a partir do zero. É claro que ninguém quer que isso aconteça, por isso, com esse post espero ter ajudado a esclarecer algumas dúvidas sobre o processo de report de PDUs, e também sobre a manutenção da sua credencial PMP.

Saúde e sucesso!

Rodrigo Ramos, PMP