Arquivo | Gestão de Conflitos RSS feed for this section

Scrum Master vs Gerente de Projetos, PMP: Presente e Passado?

4 Jul

Se você ainda não vivenciou uma situação parecida com que vou descrever, então imagine: de um lado um ScrumMaster certificado (CSM) e do outro um PMP, e algumas pessoas em volta observando a discussão de quem é o melhor perfil para gerenciar projetos!!!

Seria mais uma daquelas discussões intermináveis?!

Pensando nisso, resolvi escrever este post: seria o CSM o presente e o PMP o passado na gerência de projetos?

Lembro que a proposta de ser iterativo e incremental, pregada pelo Scrum, não é nova. Há várias metodologias na Engenharia de Software que pregam a construção baseada em ciclos e releases. Não pretendo com isso minimizar a importância do Scrum, ao contrário. Eu vejo a força desta metodologia na forma de organização do time do projeto e na condução das iterações (sprints) durante o desenvolvimento do projeto, além  da questão da qualidade nos produtos desenvolvidos. Realmente acredito nesta proposta! Mas não é isto que torna o ScrumMaster o grande profissional de gerenciamento de projeto.

De acordo com o Scrum Guide de 2010, a equipe Scrum (Scrum teams) é designada para otimizar a flexibilidade e produtividade do projeto; e para este fim, a equipe é auto-organizada, são cross-functional  (time com diferentes experiências e habilidades voltadas para um objetivo comum) e trabalham por interações.

Faz parte da equipe Scrum: o ScrumMaster; o Proprietário do Produto e a Equipe Scrum.

O ScrumMaster é o responsável por garantir que o processo é compreendido e seguido por TODOS.

Atenção! É também premissa básica, super importante, fundamental etc. etc. etc., que o PMP garanta o processo adotado para o gerenciamento do projeto e que todos os envolvidos tenham ciência deste processo e o execute de maneira coerente, ok?!??!

As figuras do Sponsor (PMBOK) e do Proprietário do Produto (Scrum) dão um encaminhamento distinto para a atuação dos dois perfis, veja:

O Proprietário do Produto é o responsável por maximizar o valor do trabalho que o Time SCRUM realiza.  Já o Sponsor, como apontado no PMBOK, é a pessoa ou grupo que fornece os recursos financeiros, em dinheiro ou em espécie, para o projeto.

Fundamentalmente isso já traz uma consequência para a atuação do ScrumMaster e o Gerente de Projetos que se baseia no PMBOK, concorda?

Observe que o Proprietário do Produto atua em conjunto com a equipe para que o projeto atenda aos requisitos necessários. Já  Sponsor é uma espécie de suporte ao gerente de projeto, para tratar de assuntos relacionados à mudança, além de ser o porta-voz do gerente de projetos para os níveis gerenciais mais altos.  Esta diferença é realmente importante e na prática acaba fazendo toda a diferença.

O ScrumMaster de acordo com o Scrum Guide:

  • Trabalha com os clientes e gestão para identificar e indicar um Proprietário do Produto.
  • Ensina o Proprietário do Produto como fazer o seu trabalho. Espera-se que o Proprietário do Produto saiba como conseguir otimizar valor usando Scrum. Se não, temos o ScrumMaster responsável.
  • Pode ser um membro da equipe, por exemplo, um desenvolvedor que executa tarefas no Sprint (iteração)No entanto, isso muitas vezes leva a conflitos quando o ScrumMaster tem que escolher entre remover impedimentos e realizar tarefas.
  • Nunca deve ser o Proprietário do Produto.

O Gerente de Projetos segundo o Guia PMBOK:

  • Pessoa designada pela organização executora para atingir os objetivos do projeto;
  • Sua autonomia depende do tipo de estrutura organizacional que projeto será desenvolvido;
  • Requer habilidades da área específica e das proficiências ou competências de gerenciamento geral;
  • Ter capacidade de realização;
  • Ter liderança;
  • Capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge os objetivos e equilibra as restrições do mesmo;
  • Dependendo do contexto do projeto, o GP poderá determinar a necessidade de um controle mais eficaz sobre certas entregas;
  • Cabe ao Gerente de Projetos e a sua equipe, determinar o método mais apropriado de execução do projeto.
  • Gerenciar as expectativas das partes interessadas;
  • Desenvolve o plano de gerenciamento de projeto e todos os componentes relacionados;
  • Identifica e monitora os riscos;
  • Fornece relatórios precisos e oportunos das métricas do projeto;
  • É o líder responsável pela comunicação com todas as partes interessadas;

As funções do Proprietário do Produto e do ScrumMaster são bem definidas e claras. Já o PMBOK dá ao gerente de projetos a responsabilidade sobre atividades que poderiam ser compartilhadas com o Sponsor do Projeto.

Resultado disso na prática:

Bom, aí penso que nem todos os projetos cabem, unicamente, em um ou em outro perfil. O contexto mais uma vez vai direcionar qual a melhor forma de orientar e conduzir os trabalhos.  O momento atual do manifesto ágil é muito bom, mas não significa que a filosofia PMI seja ultrapassada, afirmar isso, a meu ver, seria leviano.

Os profissionais PMP passam por um regime mais rigoroso de certificação que os certificados ScrumMaster, isto tem que ser levado em consideração ao avaliarmos os perfis. 

O IT-Management, baseado em uma pesquisa realizada pelo site de empregos de TI, Dice Learning, publicou sobre as certificações percebidas como de grande valor, e a certificação PMP aparece no topo, sendo que a CSM nem na lista aparece. Pense nisso!

O mercado, no entanto, quer alguém que responda com mais agilidade e seja menos burocrático ou estritamente metodológico. Por muitas vezes, já presenciei gestores importantes referindo-se aos PMP’s como “grandes burocratas de alto custo”.  Vejo como demasiadamente dura a afirmação.

Talvez, digam isso por perceberem que os profissionais que conduzem projetos, baseados no manifesto ágil, dão maior foco nos resultados funcionais do projeto. No entanto, vejo que os PMP’s, para projetos de alta criticidade, que requerem maior controle de custos, riscos e recursos, são os mais adequados.

Para que funcione bem, o Scrum requer uma equipe mais experiente, que saiba como se auto-organizar e que tenha em seu “líder” alguém que seja um facilitador para os problemas que surgem no dia-a-dia do projeto e garanta o processo. Por mais belo que isso seja na teoria, nem sempre é fácil de realizar na prática.

Finalizando: nem o PMP é passado e nem o CSM é o presente. Ambos são realidades! Quem é melhor… Aí é uma discussão interminável, do tipo projetista JAVA  vs projetista C#…

Abraços e até a próxima!

Anúncios

PMO. O QUE EU TENHO HAVER COM ISSO?

3 Maio

O escritório de projetos (PMO – Project Management Office) é um tema recorrente em congressos, workshops, fóruns e por aí vai. Confesso que tenho até me afastado das discussões que envolvem este tema.

Explico: primeiro que é uma discussão sem fim sobre os reais benefícios que ele gera; segundo que cada empresa tem sua cultura e realidade e, portanto, não teremos modelos de escritório de projetos que sirvam para todas as organizações; e, por fim, nada é mais chato do que comparar um caso de “sucesso” com outro caso de “sucesso” que ninguém saiba exatamente do que se trata.

Oras, então porque falar sobre PMO neste post? Continue lendo que você vai entender!!

http://www.thepmoblotter.org/

imagem retirada de: http://www.thepmoblotter.org/

O engraçado, apesar de tudo, é que gosto muito do tema, exatamente por ele não ter uma fórmula pronta. Ou seja, é uma ideia em construção!

E o melhor: demoraremos muito tempo em ter um modelo único, pronto e consolidado, isso se conseguirmos ter algum.

O gerente de projetos, com certa experiência, sabe que para o projeto dar certo, ele dependerá muito do seu esforço pessoal e do comprometimento da equipe com o trabalho a ser desenvolvido. E quando o GP descobre isso, o PMO poderá ficar a ver navios. Se o escritório tem o objetivo de consolidar uma metodologia por toda a organização, o gerente de projetos pode ser seu algoz, pois ele irá fazer do jeito que ele acredita ser certo e não que alguém acredita que seja. Pode soar estranho… mas continue lendo.

O PMO quando posicionado em nível elevado na estrutura organizacional da empresa, pode muitas vezes ter uma visão muito macro das dificuldades setoriais em que os gerentes de projeto estão envolvidos. Já os gerentes de projetos, conhecem como poucos a cultura do seu setor/área dentro da organização. E isso torna a informação assimétrica em favor do gerente de projetos, principalmente, quando ele não faz parte do escritório de projetos.

  • Outra coisa que me questiono muito é quando um escritório de projetos é implantado sem o cuidado de se ter desenvolvido um plano estratégico para ele.
  • Qual a visão, missão, objetivos e metas deste escritório?

Todos na organização têm conhecimento sobre a visão e as metas de curto, médio e longo prazo deste escritório?  Lembro que muitas vezes nem mesmo o plano estratégico da empresa é conhecido por todos.

Ainda nesta linha, vejo muitos escritórios com o objeto de sua existência muito grandioso, o que tende a perder o foco no médio prazo. Em organizações que não tem cultura de gerenciamento de projetos é fácil tornar o PMO alvo de criticas por aqueles que o vêem como um ameaçador ou frustrar àqueles que o viam com solução para seus problemas.

E não é muito difícil adivinhar porque isso ocorre: não há entregas de curto prazo que mostrem os benefícios reais de se ter o escritório.

Volto a dizer: começar pequeno e bem planejado é fundamental.

Em 2009/2010 fiz um estudo sobre implantação de PMO’s no serviço público brasileiro e ao final dele constatei algo que meu orientador já me questionava: afinal pra que serve um PMO? Que benefícios ele traz? PRA QUÊ PRECISAMOS DISSO? Confesso que não consegui responder em sua totalidade estes questionamentos, algo que me frustrou.

Pra não dizer que sou pessimista quanto à implantação de um escritório de projetos, vou indicar quatro pontos que penso que não podem faltar quando se pensa em realizar um PMO:

  1. Defina os resultados de curtíssimo prazo (eu disse CURTÍSSIMO PRAZO) e que gere benefícios para toda organização. Dê visibilidade e atenda as expectativas iniciais.
  2. Reúna pessoas que compartilhem das propostas do gerenciamento de projetos. Envolva, principalmente, os gestores que se animam com a ideia!
  3. Desenvolva competências (e isso não pode ser feito depois da implantação). As competências preparam o ambiente para consolidar a infraestrutura do PMO quando ele for implantado. Você já terá pessoas que compartilham suas idéias! Ou seja, você terá seguidores!!!!!
  4. Não subestime o estado atual do processo em que as pessoas trabalham. Muitas vezes o inicio da maturidade do processo pode estar na consolidação dos processos que já são realizados há anos pela empresa.

Por fim, gostaria de dizer que acredito nos escritórios como disseminadores da cultura de gerenciamento de projetos, como estimuladores do processo de aprendizagem e de controle dos registros de lições aprendidas. Claro que vários outros objetivos podem ser contemplados, mas aí, uma nova discussão se inicia…

Abraços!!!

Geração a, Baby Boomer, c… Y,X..z…

7 Jan

Muito vem se falando da geração Y. Mas conversando com algumas pessoas – que não são muito ligadas (fãs) a categorização ou agrupamento de gente – observei algo que vale um post.

Primeira coisa seria entendermos as denominadas gerações X, Y e Baby Boomer. Tem uma paródia que o Grupo FOCO fez com o filme “A queda” que vale ser assistida.

De acordo com os especialistas,

A geração dos Baby Boomer compreende a turma que tem entre 35 e 45 anos. O termo surgiu  nos EUA no período da segunda grande guerra. Houve uma explosão de registros de crianças nascidas naquele período, por isso o termo Baby Boom.

Mas o que importa aqui são as características desta geração. Acredita-se que o pessoal que está nesta faixa etária tenha um perfil mais conservador, que tende a optar por uma estabilidade no emprego, admira grandes personalidades, gosta de padrões e rotinas….etc etc

Já a Geração X, com idade entre 23 e 35 anos, possui uma visão claramente contrária àquelas da geração Baby Boomer. A idéia é contradizer os padrões das gerações anteriores.  É a geração da queda do Muro de Berlim.

E a Geração Y? Bom, compreende a turma até 22 anos. Essa geração tem em seu sangue a interatividade, a informação em tempo real. É a geração Iphone, Internet… Para essa geração, tudo é pra ontem, a noção de tempo é totalmente diferente em relação àqueles das gerações anteriores.

Minha opinião a respeito:

Conflito de gerações sempre existiu e sempre existirá. Concordo que categorizar pode levar a preconceitos, pois rotula-se e isso não é legal.

Para fins de gestão, temos que conviver com todas essas gerações e outras  que surgirão. Estamos diante de um grande potencial de conflitos.

E gerenciar conflitos é função de quem? Sim, do Gerente de Projetos!!!

Querem algo mais conflituoso do que um projeto?

Ao trabalharmos com a gestão de projetos, temos vários interessados e pessoas que serão atingidas direta e indiretamente pelos resultados do projeto.

Neste caso específico, vejo com bons olhos os conflitos gerados pelas gerações. Cada um teve uma necessidade diferente, decorrente do tempo em que foram criados e formados. As experiências de todas as gerações são válidas e contribuem para qualquer contexto.

Evidente que gerenciar conflitos é uma arte, mas gerenciar em si é uma arte!

Vejo a Geração X (a minha geração) como uma geração de transição. É a geração que viveu a queda de ditaduras, de crises economicas, da revolução tecnológica… e para qualquer um que vive transição a coisa é mais complicada.

Mas também penso que a atual geração Y será a geração da transição no futuro. Os ciclos de revoluções serão cada vez mais menores.   A velocidade da informação e do conhecimento que se tem atualmente atingi a tudo e a todos. Imaginem no futuro? O Futuro já não estará tão distante, ou melhor, o futuro é o próximo instante. É a noção de tempo que se modificará.

Enfim, que sejam bem-vindos essa turma da interatividade!

 

 

fontes:

* Mais tempo, mais dinheiro – christian barbosa, gustavo cerbas

* O Poder do Pensamento Positivo e o  Trabalho – alice potter

* Marketing experimental – Exame – Bernd H Schmitt

%d bloggers like this: