Os desafios diários dos gerentes de projeto

Depois de alguns anos afastado do gerenciamento de projetos - foquei minha carreira na gestão de serviços durante os últimos 4-5 anos - tive a oportunidade de voltar ao mundo do gerenciamento de projetos.
Confesso que já estava sentindo falta da rotina desta profissão: metas e entregas, conclusão de etapas (e comemoração por elas), enxergar o fim do projeto se aproximando são coisas que costumam motivar aqueles que escolheram, de fato, essa profissão. Comigo, pelo menos, é assim que a coisa funciona.

Não deixei de participar de fóruns e grupos de discussão relacionados a gerenciamento de projetos, e uma discussão, em particular, me chamou a atenção: era um professor meu, da FGV, comentando sobre problemas que estava encontrando em uma de suas consultorias, e muitos deles relacionados a gestão de tempo e cronograma do projeto.

Não é raro ver que muitos GPs ainda consideram que a maior parte do tempo que investem nos seus empregos é relacionado à manutenção de cronogramas. Apesar de ser algo comum, não pode ser considerada uma boa prática de gestão de projetos. O cronograma deveria ser o resultado de um trabalho, não o trabalho em si.

Criar um cronograma realista é, na imensa maioria das vezes, um enorme desafio para o GP. Se você pensou que isso se deve à complexidade de inserir e gerenciar o Project (por exemplo), você está enganado... Normalmente os cronogramas nascem de necessidades de negócio específicas: uma venda para um cliente que tem prazo para entrega, uma determinação do BACEN para uma instituição financeira, uma nova legislação que tem prazo fixo para entrar em vigor, um cliente exigente que já vendeu uma ideia de resultado e agora busca quem implemente seu sonho (em alguns casos, seu devaneio...). Esta é a maior dificuldade: fazer o trabalho do projeto caber no cronograma, que já sai com uma data de conclusão preenchida por outras pessoas, muitas vezes sem qualquer participação do GP ou dos grupos executores.

Some a isso a questão de recursamento do seu projeto e lembre-se que, no Brasil, a grande maioria das empresas é baseada em uma estrutura funcional rígida, ou com pouca flexibilidade, em que os GPs irão "disputar" os recursos humanos com as áreas operacionais. Nessa "briga" quem normalmente perde é o projeto, e não a operação (este é tema para o próximo post).

Então, se você está sofrendo para colocar seu cronograma em dia, faça as seguintes perguntas a si mesmo, talvez encontre a real causa da sua aflição:

Meu projeto já tem uma data de conclusão acordada, sem o meu consentimento

Se a resposta é SIM, então você já sabe que parte dos seus problemas com gestão de tempo não são causados diretamente pelo projeto em si, mas pela falta de planejamento adequado de quem tomou as decisões antes do plano.
Nesses casos, a melhor solução é entender os motivos que estão por trás dessa decisão. Não adianta lutar contra ela, pois, no pior dos casos, ela foi tomada com base em uma necessidade do negócio e dificilmente poderá ser mudada (ao menos no papel).

• Obtenha um bom sponsorship para o projeto: o sponsor certamente poderá te ajudar a obter mais recursos, sejam eles materiais ou humanos, de forma a cumprir com a maior parte do plano. 
• Negocie entregas parciais: negocie, sempre que possível, a entrega de funcionalidades básicas que permitam a operação para a data acordada, e tente deixar para uma segunda onda os refinamentos e melhorias do projeto, pode ser uma saída para cronogramas impossíveis.

Eu errei no planejamento, sendo otimista demais com algumas tarefas

Esse é o tipo de erro que mais costuma ser associado com as falhas diretas do GP, mas nem sempre isso é verdade. Se o devido cuidado foi tomado, o plano deve ter sido criado com apoio de especialistas no produto que o projeto está entregando, então a responsabilidade pelo planejamento excessivamente otimista, ainda que seja do GP, pode ser compartilhada com a equipe de planejamento/design.

Isso resolve o problema? De maneira nenhuma. Mas dá ao GP alguma margem para negociar uma maior dedicação dos times funcionais, através de acordos com os times de design.

• Obtenha sponsorship adequado: mais uma vez, é uma coisa vital e fundamental para todo projeto. Seu sponsor pode e deve te ajudar a obter recursos para o projeto, pois o interesse em vê-lo implementado é dele também. Se você não tem, ou não identificou um sponsor forte, reveja seu mapa de stakeholders e localize qual deles é o mais interessado nos resultados do projeto, compartilhe os riscos e as alternativas de redução de prazo.
• Mapeie todos os riscos sempre que precisar revisar e comprimir o cronograma: toda compressão traz consigo o risco inerente da pressa, e como sabemos, ela sempre foi inimiga da perfeição. Aponte os eventuais atrasos que podem ocorrer ao cronograma caso os riscos se tornem problemas reais. Aja antes dos riscos se tornarem problemas e compartilhe as expectativas reais com seus stakeholders.
• Adote o conceito de right first time: evite retrabalhos. Todo retrabalho custa tempo e dinheiro, invista um pouco mais no correto planejamento de cada atividade.

Eu não tenho autonomia sobre os recursos, e as tarefas não estão sendo cumpridas

Esta talvez seja a situação mais crítica e complexa de se resolver. Como comentei, a grande maioria das empresas possui uma organização funcional, baseada em departamentos. Sendo assim, você certamente precisará investir um bocado de tempo e esforço para obter os recursos necessários junto aos times operacionais. É possível manter uma boa relação com esses grupos, desde que você também observe regras de etiqueta básicas:

• Compartilhe o plano de trabalho: ao solicitar recursos a um time funcional, compartilhe, caso não tenha feito antes, os objetivos da tarefa e o prazo necessário para que ela seja concluída. Se o prazo for inviável, o recurso não se comprometerá com o resultado
• Respeite os acordos firmados: se o recurso foi disponibilizado por um tempo determinado, respeite este período e "devolva" o recurso para suas atividades rotineiras quando o prazo acabar. Negocie antecipadamente qualquer extensão neste prazo.
• Compartilhe as conquistas com o time que cedeu o recurso para o projeto: demonstre apreço e reconheça o esforço extra que os times funcionais desempenham para cumprir com a entrega do projeto, este não é o trabalho oficial deles, portanto, reconhecimento e elogios formais são importantes aliados.

O projeto é mais complexo do que inicialmente planejado

Esta falha é difícil de aceitar quando a notícia é dada tarde demais. Como GP você precisa estar atento às mudanças de escopo e ao refinamento do plano do projeto, e compartilhar essas informações tão logo as tenha reconhecido. Antecipação é a chave, ninguém gosta de ser pego de "calças curtas".

• Antecipe problemas: tão logo identifique riscos de atraso, aumento de custo, mudança de escopo, ou outros impactos para o projeto, certifique-se de entender as causas e as opções de contorno, mapeie os impactos e reporte-os adequadamente, em uma lista de riscos controlada.
• Tenha sempre um plano de ação: lembre-se: seu sponsor não quer saber dos problemas, mas sim do que foi ou está sendo feito para solucioná-los. Apresentar um risco sem plano de mitigação é o mesmo que dizer: "o gato subiu no telhado".
• Replaneje: sempre que possível, procure fazer alguns exercícios de planejamento das atividades futuras. Tempo perdido no passado somente pode ser recuperado com melhor performance no futuro. Quanto enfrentar um atraso no cronograma, apresente-o juntamente com as alternativas possíveis de compressão das atividades futuras, tentando minimizar o impacto para o projeto. Isso demonstra que você explorou as alternativas antes de simplesmente assumir um atraso na entrega.

Depois de tudo isso, tenha sempre em mente o seguinte: Não somos super-homens. 

Todos somos feitos de carne, ossos e de sentimentos. Ficar angustiado ao fazer uma reunião de status report ou outra apresentação sobre os resultados/andamento do projeto raramente fará com que as coisas se desenrolem melhor, muito pelo contrário. Procure manter-se calmo e raciocinar antes de agir.

A vida de um gerente de projetos não é a mais tranquila do mundo, mas ela pode ser muito melhor com algumas precauções e atitudes assertivas da nossa parte.

Saúde e sucesso.

As certificações e o mercado de trabalho

Olá pessoal, tudo bem?

Vou começar este post com uma pergunta direta: Você acredita nas certificações profissionais?

Se a sua resposta foi sim, você está entre a grande maioria das pessoas que aprova a realização de exames de certificação como uma forma de comprovação das habilidades adquiridas por um profissional.

No entanto, toda vez que se discute o assunto “certificação” uma sensação vem à tona: “O fulano vai lá, estuda através de simulados “testkings” da vida e passa na prova mesmo sem saber do que ela se trata...”

Isso me faz pensar que existem dois tipos de pessoas que se aventuram no mundo das certificações. O primeiro tipo é o do easy way of life, que chamarei carinhosamente de grupo TestKing, composto por aqueles que simplesmente pegam o simulado “de grátis” na internet, decoram e fazem a prova. Já o segundo tipo (espero que seja a maioria) vai pelo caminho das pedras – começam pelo estudo (em sala de aula ou independente), fazem os simulados, para depois comprovarem seus conhecimentos no exame de certificação.

Penso que a prática adotada pelo primeiro grupo, de fato tira um pouco do brilho das certificações, e, infelizmente, não há como negar que a prática é considerada comum no meio da TI.

Porém, eu procuro entender as certificações de um modo mais abrangente. Se uma pessoa se dedicou a estudar um tema específico a ponto de conseguir responder 50, 60 questões de forma correta em um exame de certificação, isso certamente demonstra que pelo menos essa pessoa possui duas qualidades: a primeira é a capacidade de aprendizado, pois, para ser aprovado no exame, este indivíduo preciso ao menos decorar as questões. A segunda é o interesse pelo tema, porque esta pessoa abriu mão de passar algumas horas no seu Playstation para ler e fazer os simulados para poder fazer a prova. Sendo assim, mesmo aqueles que optam por testking ainda obtém vantagens com a certificação.

Já o segundo grupo é composto por aqueles que acreditam na boa fé das pessoas e seguem o ritual da certificação – cursos, estudo, testes, labs e, por fim, a prova. Essas pessoas tem um diferencial ainda maior em relação aos membros do primeiro grupo: elas realmente conhecem o tema e sabem sobre o que estão falando. Fazem questão de montar laboratórios para testar o que estão estudando, visando não apenas a certificação, mas sim aquilo que é mais importante para a vida prática – o conhecimento.

Agora vamos para o lado prático da coisa: Imagine que você esteja contratando alguém e precisa optar entre duas pessoas em uma vaga de emprego, ambas com a mesma formação e qualificadas para a vaga, porém, uma delas com 2 certificações na área e a outra sem nenhuma. Qual das duas você escolheria? Eu não pensaria duas vezes antes de escolher aquela que apresentou as certificações... 

Mas como saber se um candidato é do grupo testking ou não? Isso, meu amigo, só o tempo dirá. Os testkingers tendem a sofrer no dia-a-dia, pois os problemas reais nem sempre aparecem na prova... E nem sempre existe uma resposta pronta para ele no Google. Por isso, avalie todo o contexto, não apenas as certificações. 

Em resumo: para mim, quem tirou a certificação demonstrou mais interesse pelo assunto, foi atrás, descobriu como fazer a prova, estudou (ainda que por testking) e passou na prova. Isso é suficiente para reconhecer que se trata de um profissional diferente da maioria. Não porque é mais inteligente, mas porque é mais interessado.

Em um tempo onde a informação é gratuita, o que diferencia uma pessoa da outra é a capacidade de transformar essa informação em conhecimento, e por consequência, o conhecimento em resultados.

Em resumo: O processo é falho? Sim, certamente... Mas ele não é inválido!

Para os candidatos uma dica:  lembre-se que os contratantes estão avaliando uma série de informações no seu perfil – entre elas o seu interesse pelo assunto, traduzindo, certificações... 

Por isso, se estiver em dúvida se deve ou não fazer determinado curso ou certificação, eu aconselharia: Faça todas que puder, sempre considerando o seu objetivo profissional. Fazer diversas certificações em áreas muito distintas (como por exemplo misturar certificações de infra e de desenvolvimento) podem dar a entender que o profissional não sabe bem qual carreira quer seguir, isso pode ser prejudicial. Escolha a carreira, depois se especialize! Mas faça do jeito certo: Opte pelo conhecimento, não pelo testking!

Saúde e sucesso!

Rodrigo Ramos, PMP

A empregabilidade do Gerente de Projetos

Olá pessoal, tudo bem?
No meu último post prometi falar um pouco sobre a empregabilidade do gerente de projetos. Não consegui retornar a este tema até hoje, pois estava iniciando uma nova jornada, em uma nova empresa. Este post é um complemento de um post antigo sobre a característica temporária deste profissional. (Link para este post: http://mundopmp.blogspot.com.br/2011/11/o-gerente-de-projetos-um-profissional.html).

Não pretendo fazer um tratado sobre empregabilidade, apenas relatar fatos que ocorreram comigo nos últimos anos, além de alguns relatos de colegas de profissão.

Quando decidi dar um rumo diferente para a minha carreira, deixando de ser um engenheiro para me tornar gerente de projetos, fiz o que todos deveriam fazer antes de escolher uma profissão. Eu estava escolhendo a minha pela segunda vez, então pensei em uma estratégia para isso: classificados! A minha estratégia consistiu em analisar o que eu poderia oferecer com a minha formação e experiência profissional, e com isso avaliei quais eram as profissões nas quais meu perfil se enquadrava, e, de posse disso, passei a estudar anúncios da seção de empregos dos jornais e sites especializados. Logo percebi que havia uma ligação forte entre o meu histórico profissional e a função de gerente de projetos, e o melhor, o mercado estava precisando (e muito!) deste tipo de profissional.

Isso aconteceu há quase 8 anos atrás. Muita coisa mudou. A profissão ganhou reconhecimento e os profissionais passaram a ser assediados pelas empresas, pois estas logo perceberam que ter um profissional especialista na gestão de projetos poderia aumentar significativamente a chance de sucesso nas suas empreitadas.

E com isso o mercado mudou. Hoje em algumas áreas como TI, Engenharia, Automação de processos, Telecom, Civil entre outras, não se executa um projeto sem que haja ao menos um profissional em gestão de projetos. Isso faz com que a mobilidade desses profissionais seja enorme, trazendo consigo uma certa "guerra mercadológica" pelos melhores profissionais, mas é claro que sempre sobram vagas para aqueles que estão começando a carreira!

Se você está pensando em entrar nessa, reforço uma dica antiga: certificações são muito importantes, mas elas não garantem seu ingresso nesse mercado. Ter experiência técnica é um grande diferencial para poder começar nesta área sem grandes sustos. Cursos de especialização na área também são importantes. E é claro, acumule experiência. Só ela trará o conjunto de habilidades necessárias para ser bem sucedido nessa carreira.

Se você já está nessa há algum tempo, aproveite a boa fase que estamos vivendo e vá à luta! Existem muitas vagas esperando por profissionais preparados e dispostos a encarar a luta diária da carreira de gestão de projetos!

Saúde e sucesso!

Rodrigo Ramos, PMP

Metodologias ágeis - segunda parte

Olá pessoal, tudo bem?

Algumas mudanças aconteceram na minha vida profissional nos últimos dias, dias corridos e cheios de surpresas, a grande maioria boas surpresas. Vou dedicar uma postagem para falar exclusivamente da empregabilidade do gerente de projetos, mas esse é um outro assunto...

Voltando à ativa no blog, gostaria de retomar as questões que discuti no meu penúltimo post, quando comecei a falar sobre metodologias ágeis e sua origem nos projetos de criação de produtos.
Naquele post fiz menção de que a metodologia PMI não era adequada a projetos de desenvolvimento de produtos, devido ao alto grau de incertezas presentes nesse tipo de projeto, este post é para defender esse ponto de vista, sem querer ser o dono da verdade, mas fazendo uma análise crítica sobre os prós e contras para que vocês possam tirar suas próprias conclusões.

Em ambientes de projeto convencionais, baseados no PMI, o termo requisição de mudança ou change request normalmente causa arrepios em muitos stakeholders. Mudanças normalmente não são benvindas em projetos. Mudanças (em geral) não são benvindas em nossas vidas. Somos moldados para resistir à mudança pelos nossos costumes, hábitos, crenças, etc, etc, etc... sem nos lembrarmos que foi a mudança que deu origem à raça humana....

Pois bem, depois da divagação, vamos voltar ao ambiente de projeto. Imagine que você está gerenciando um projeto e tudo está caminhando bem, os prazos estão sendo cumpridos, o orçamento, apesar de apertado, vai cobrir todo o restante do trabalho e o status de completude está em 95%. Você e a equipe já estão em ritmo de festa, planejando o que irão fazer no próximo fim de semana, coisa e tal, quando um gerente do negócio entra na sala (claro que isso sempre acontece às sextas-feiras às 17 e alguma coisa...) e diz aquilo que todos não querem escutar: "Pessoal, acabamos de sair de uma reunião, e a diretoria precisa mudar um pouco o projeto..." Não preciso dizer qual seria a cara de quase todos os membros da equipe, que dirá a do gerente do projeto. O pensamento "poxa, logo agora que a gente ia terminar esse projeto???" quase sempre vem à cabeça de todos...

Sob a ótica do PMI serão mais horas e horas de replanejamento, retrabalho, documentos, procedimentos e tudo o mais que normalmente é exigido para controlar uma mudança. O ímpeto humano de resistir aparece forte como o incrível Hulk e a reação é quase sempre a de dizer "ah, isso não dá pra fazer"...

Quantos de vocês já não tiveram vontade ou fizeram isso nessas situações? Acredito que muitos...

Mas porque somos tão avessos à mudanças? Por que ninguém gosta de trabalhar com incertezas... A incerteza gera insegurança, e isso mina as resistências de qualquer um. Outra coisa é que as mudanças normalmente não são acompanhadas de um aumento de prazo, ou de mais verba para o projeto. Tem que mudar e pronto!

A visão sobre as mudanças instituída pelos métodos ágeis é de que elas são inevitáveis, e muitas vezes são benéficas ao produto que o projeto está produzindo (principalmente em projetos com alto grau de incerteza), sendo assim, lutar contra as mudanças é inútil, pois elas SEMPRE ocorrerão. Então vamos encara-las como parte do projeto, e vamos trata-las adequadamente para que elas sejam encaixadas no plano.

A vantagem do método ágil para o tradicional neste quesito é que, como a mudança é esperada, a equipe não fica surpresa com isso (e nem o GP), e existe um fluxo pré-combinado com os stakeholders, onde as mudanças são avaliadas, mensuradas e então implementadas em prazo exequível. Tudo numa boa... E como o produto vai sendo desenhado de forma progressiva, e entregue em pacotes funcionais, as mudanças normalmente não são tão impactantes para o projeto como um todo, pois o que foi entregue e aceito está pronto, desse modo a mudança não impactará nos itens já entregues.

Parece sonho? Mágica? É... na prática as coisas nem sempre são assim... Mas mudar a atitude diante de uma mudança não planejada já é o primeiro passo para parar de sofrer com ela... Pense nisso!

Saúde e sucesso!

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

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

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