O Gerente de Projeto e o Gerente de Produto 

Jun/12
15

√Č muito comum no √Ęmbito do Scrum ou de qualquer modelo moderno de gerenciamento ouvirmos falar no Product Owner (Dono do Produto). Este nome “Product Owner” nada mais √© que um sin√īnimo de “Product Manager. Portanto, o Dono do Produto √© na realidade apenas o Gerente do Produto. Mas quem √© o Gerente de Produto ?

As responsabilidades do Gerente de Produto s√£o bem entendidas e sua defini√ß√£o e escopo antecedem o advento do Movimento √Āgil.¬† Portanto, vamos esquecer um pouco o Movimento √Āgil e focar nas diferen√ßas cl√°ssicas¬† entre Gerente de Produto e Gerente de Projeto no contexto n√£o-√°gil. Voltaremos a este ponto, depois.

O Gerente do Produto, como o nome indica, est√° preocupado com coisas relacionadas ao produto. Isto parece √≥bvio. O problema √© saber estabelecer o que pertence ao produto e o que n√£o pertence ao produto. √Č mais f√°cil de entender se come√ßarmos pensando em um produto que j√° existe. Imagine uma empresa que j√° tem uma vers√£o comercializ√°vel de um produto de software. Imaginemos que se trata de um ERP.

Como sabemos pela lei fundamental do software : um produto de software nunca está pronto. O que significa que ao longo do tempo as pessoas sempre terão novas ideias de como aumentar as funcionalidades do software ou simplificar as que já existem.  Imaginemos, portanto, que a empresa decide criar um novo módulo para o ERP especialmente voltado para hospitais. E por outro lado,  decide que o look and feel da aplicação precisa de uma modernização.

Do ponto de vista do produto s√£o duas altera√ß√Ķes independentes que cont√©m valor diferente tanto para a empresa como para o produto e para os usu√°rios do produto e clientes da empresa. O papel do Gerente de Produto √© saber qual delas tem mais valor e qual tem maior retorno sobre o investimento (ROI). Ou¬† seja, qual vale a pena perseguir primeiro.¬† Neste momento nada est√° sendo realizado. O objetivo ainda √© s√≥ entender o que as modifica√ß√Ķes implicam e como isso ir√° impactar o mercado e o status do produto nesse mercado , al√©m de projetar o retorno que isso ter√° para a empresa, tanto financeiramente como em termos de prest√≠gio, share de mercado e imagem – entre outras coisas.

Suponhamos que o Gerente de Produto decide que o modulo hospitalar √© uma melhor aposta e que os recursos da empresa ser√£o melhor empregues nessa atividade.¬† Contudo, o Gerente de Produto levantou alguns constrangimentos . A atividade s√≥ ser√° mais rent√°vel que a altera√ß√£o est√©tica do sistema se poder ser realizada em um ano ao menos e dentro de um or√ßamento de 200 mil reais. O desafio √© portanto concretizar que a atividade seja realizada em um ano ou menos utilizando 200 mil reais ou menos. A empresa ent√£o cria um projeto para a realiza√ß√£o da modifica√ß√£o do produto. Porque agora ha um projeto, ent√£o ha um Gerente de Projeto. O Gerente de Projeto n√£o vem do departamento de produto e n√£o lhe importa o que o produto realmente faz ou como a atividade do projeto ser√° melhor ou pior para a empresa. O Gerente de Projeto √© mais com um contador que est√° preocupado em que a atividade n√£o consuma mais recursos que aqueles que foram alocados. Portanto al√©m de controlar o tempo e o custo do projeto o Gerente de Projeto tem que ficar alerta para poss√≠veis riscos que coloquem em perigo o bom t√©rmino da atividade. Quando a atividade √© terminada, e ela sempre √© terminada, pode ser que o tempo ou o or√ßamento tenham sido maiores que o esperado. A responsabilidade por isso recai sobre o Gerente de Projeto e n√£o sobre o Gerente de Produto. Por outro lado, se o Gerente de Projeto faz o seu trabalho e come√ßa a entender que n√£o vai dar , o Gerente de Produto ter√° que fazer algumas modifica√ß√Ķes ou cortar algumas das partes da atividade.

Ao terminar o projeto o Gerente de Projeto ir√° fazer outra coisa. Cuidar de outro projeto. Enquanto que o Gerente de Produto continuar√° trabalhando sobre o mesmo produto e preparando projetos futuros.

Entenda-se que o Gerente de Projeto e o Gerente de Produto s√£o papeis e n√£o pessoas. √Č poss√≠vel que a mesma pessoa represente os dois papeis. Contudo, o bom senso comanda que sempre que dois papeis s√£o concorrentes n√£o podem ser desempenhados pela mesma pessoa. Portanto, embora sendo poss√≠vel √© um considerado um risco demasiado grande para valer a pena. Existe um cabo-de-guerra entre os dois papeis, e portanto √© necess√°rio ter duas pessoas. A menos, √© claro, que voc√™ conte com algu√©m esquizofr√™nico na sua equipe que possa trocar entre papeis a gosto.

Ha uma importante diferen√ßa entre Produto e Projeto. Projeto √© algo limitado no tempo , no escopo e no custo para alcan√ßar um objetivo. √Č um tiro. No final, o produto ganhou alguma coisa. √Č poss√≠vel realizar diversos projetos, paralelos ou n√£o, sob o mesmo produto. No nosso exemplo, a empresa poderia ter escolhido realizar os dois projetos em paralelo um para criar o novo modulo e outro para modificar a interface gr√°fica. Ter√≠amos dois Gerentes de Projeto e um Gerente de Produto.

Obviamente eu simplifiquei as coisas. Na realidade o Gerente de Projeto também irá ajudar a dimensionar o tempo e o custo até porque o Gerente de Projeto se irá responsabilizar por levar a bom porto esse plano.

A import√Ęncia de ter dois papeis s√≥ √© √≥bvia quando ha problemas. E, como sabemos, haver√° problemas. O tempo ou o dinheiro ir√£o come√ßar a faltar. O gerente de projeto ir√° come√ßar a cortar arestas e a diminuir a qualidade ou a remover aleatoriamente tarefas do projeto. Aqui o Gerente de Produto ir√° interferir para otimizar a qualidade e remover as tarefas na ordem de menos import√Ęncia tentando maximizar o valor das altera√ß√Ķes e diminuindo o numero de altera√ß√Ķes.¬† Por outro lado, o Gerente de Produto ir√° querer modificar uma mesma feature 10 vezes ou adicionar novas modifica√ß√Ķes que antes n√£o estavam planejadas. O Gerente de Projeto ir√° avaliar o impacto no custo e no tempo dadas essas altera√ß√Ķes e ir√° poder vet√°-las ou exigir que o Gerente de Produto fa√ßa concess√Ķes como seja abandonar uma outra feature ou substituir uma modifica√ß√£o por outra.

Repare que n√£o falamos em momento algum da equipe que realiza as modifica√ß√Ķes de fato. Essa discuss√£o n√£o √© relevante aqui. O ponto aqui √© entender que existem de fato dois papeis concorrentes que defendem lados opostos e interesses que podem ser antag√īnicos.¬† O cabo-de-guerra entre esses dois lados √© que ir√° determinar o sucesso ou fracasso do projeto e do produto.

Embora seja amplamente conhecido [1] [2] [3]  que estes papeis existem e são diferentes, ha uma tendência forte Рe falo sobretudo no Brasil Рde ignorar o papel do Gerente de Produto e focar no papel menos importante do Gerente do Projeto. Porquê menos importante ? Porque sem produto não ha projeto. Tem que haver uma visão à priori do produto, do mercado, de onde se quer chegar e da concorrência antes de sequer começar a pensar em projetos. Por outro lado, é possível iniciar diferentes projetos em paralelo para no final integrar os seus artefatos através de um novo projeto.  Digamos que no grande esquema das coisas, produtos são incrementados através de projetos.  Produtos não são criados. São apenas incrementados.Por outro lado, produtos são da empresa, projetos podem ser terceirizados.

O movimento √°gil entende e raciocina de uma forma orientada ao produto e ao cliente que pagar√° pelo uso do produto. Por isso o Movimento √Āgil foca a figura do Gerente do Produto pois √© ele que tem condi√ß√Ķes de decidir sobre o produto.

Em condi√ß√Ķes ideais , em equipes extremamente afinadas, a equipe como um todo ir√° realizar em conjunto o papel do Gerente de Projeto. Este √© o modelo do XP. Ou seja, dado que o Gerente de Projeto n√£o √© um decisor e apenas atua como um contador,¬† um apontador de riscos e um √°rbitro quando os limites impostos est√£o prestes a serem ultrapassado ent√£o seria conceitualmente poss√≠vel incluir todos esses controles no processo, ao inv√©s de em uma pessoa. O controle seria ent√£o autom√°tico e imparcial. O Gerente de Produto n√£o pode fazer o que quiser, simplesmente porque os constrangimentos do processo n√£o o deixam, e n√£o porque ha uma pessoa controlando a outra ponta. Isto √© ben√©fico porque onde ha pessoas, sempre ha o risco de falha politica e¬† por conseguinte sempre ha o risco da pessoa especifica que atua como Gerente de Produto ser politicamente mais forte que o Gerente de Projeto ( ou vice-versa) e sempre conseguir o que quer √† rebeldia do que est√° sendo indicado pelo seu contraparte e √† rebeldia do que √© interessante para o produto, para os usu√°rios , para o cliente e para a empresa.

A ideia √© portanto muito semelhante √† da teoria de Pesos e Medidas da politica onde o mecanismo garante a sanidade dos objetivos independentemente das pessoas que os perseguem.¬† Como disse, isto seria num cen√°rio ideal onde todos s√£o perfeitos. Num cen√°rio real o Gerente de Projeto sempre ir√° tentar colocar uma feature a mais e se preocupar menos com tempos e or√ßamentos. Afinal se ele n√£o pensar assim, ele n√£o ser√° um bom Gerente de Produto. E isto √© aceite mesmo em √Āgil. √Č por isso que existe a figura do Scrum Master em scrum.¬† Ora a diferen√ßa entre um Scrum Master e um Gerente de Projeto est√° exatamente na forma do poder e n√£o na fun√ß√£o. Explicando;¬† enquanto que no modelo tradicional o Gerente de Projeto tem o poder que dizer que n√£o e argumentar com o Gerente de Produto, o Scrum Master tem apenas o poder de manter o Gerente de Produto na linha, dentro das regras. Ou seja, n√£o ha argumenta√ß√£o, e portanto, n√£o ha negocia√ß√£o. O Gerente de Produto n√£o pode corromper o Scrum Master porque ele realmente n√£o tem poder de nega√ß√£o. Ele s√≥ tem o poder de dizer “vc est√° pisando no risco e logo, logo, ir√° passar do limite” e expor esse fato para todos os interessados. Ser√° a press√£o dos outros stakeholders sobre o Gerente de Produto que ir√° prover mudan√ßas e n√£o o Scrum Master em si mesmo. √Č por isto que o Scrum Master n√£o √© considerado um stakeholder porque ele n√£o decide. Ele apenas apresenta e aponta o dedo. O Gerente de Projeto, por outro lado, seria um stakeholder.

Em √Āgil mantemos a ideia que o Gerente de Produto √© suficiente para levar o produto a bom porto e removemos a figura do “projeto” substituindo-a pela figura da “itera√ß√£o” ( o projeto √© limitado no tempo, a itera√ß√£o tamb√©m. Mas a itera√ß√£o pode ser repetida em sequencia quantas vezes quisermos). O projeto √© uma entidade muito burocr√°tica para ser repetida em sequencia repetidamente. Assim sendo ,removemos a figura do Gerente de Projeto pelas regras do Scrum em si mesmo e colocamos uma pessoa para vigiar que essas regras est√£o sendo entendidas e seguidas. Na realidade mais que regras, em Scrum falamos de Valores.¬† Ao fazer isto removemos o cabo-de-guerra e colocamos o foco onde interessa : no produto e no seu gerente. Se o Gerente de Produto estimou mal o ROI o scrum lhe d√° as ferramentas para entender isso e realizar ajustes rapidamente. Mais rapidamente do que se existisse um gerente de projeto.

A transi√ß√£o do Modelo Tradicional para o Modelo √Āgil n√£o passa apenas por incluir as pr√°ticas do Scrum ou qualquer outro framework √°gil. Passa primeiro por re-estruturar a empresa para criar uma √°rea de produto , treinar gerentes de produto e depois aplicar o √°gil. Em empresas onde j√° existe uma estrutura de Ger√™ncia de Produto incluir o √°gil √© muito natural j√° que √© apenas colocar uma estrutura a mais onde j√° existia uma estrutura anterior e um knowhow maior em gerencia de produto. Mas, nas empresas chamadas “f√°bricas de software” n√£o existe este conceito. Temos apenas o conceito de “projeto” e nunca o de “produto” at√© porque se entende que o “produto √© do cliente”, ou seja, n√≥s fazemos o que o cliente quiser e n√£o temos responsabilidade sobre as consequ√™ncias. Esta √© uma forma de entender.

Mas n√£o √© a forma correta. A forma correta √© entender que neste cen√°rio a Gerencia de Produto est√° do lado do cliente que nos contratou. √Č aqui que entra o conceito √°gil de identificar o Product Owner, ou seja, a empresa “f√°brica de software” n√£o conhece os mecanismos e canais que levam √†s decis√Ķes sobre o software, mas o software continua sendo um produto. Ent√£o, ao identificar o Product Owner estamos apenas perguntando “quem poder√° tomar as decis√Ķes soberanas e dia-a-dia sobre este produto, na sua empresa” – esse √© o Gerente de Produto. Neste cen√°rio a empresa de “f√°brica” ir√° alocar um Gerente de Projeto. Contudo, bastaria estipular as regras e um arbitro. As regras podem at√© ser formalizadas contratualmente e o arbitro ser um terceiro que n√£o √© nem do contratado nem do contratante ( como um √°rbitro de futebol que n√£o pertence a nenhuma equipe). Desta forma garantimos que o “projeto”, ou melhor, as itera√ß√Ķes, seguem o valor estipulado pelo Cliente e que n√£o ha cabo-de-guerra com algu√©m da empresa de “f√°brica”.

Nos modelos tradicionais comuns não existe o Gerente de Produto, mas é indicado na teoria clássica e a sua falta é uma questão cultural do processo tradicional e não do processo clássico. Após este ajuste, o uso do modelo ágil encaixará que nem uma luva.

Uma outra op√ß√£o √© entender o Gerente de Projeto como um dos stakeholders cuja √ļnica miss√£o √© vigiar or√ßamentos, tempos , etc.. Desde ponto de vista o Gerente de Produto (ou o Product Owner) teria que argumentar e negociar com o Gerente de Projeto como faria com qualquer outro stakholder. Esta √© uma op√ß√£o poss√≠vel durante uma transi√ß√£o para o modelo √°gil , embora possa ser entendido como o modos operadi correto e padr√£o de intera√ß√£o entre os dois papeis.

Mesmo que você não seja um fan do modelo ágil, não pode esquecer o fato real do Gerente de Produto realizar tarefas diferentes do Gerente de Projeto e que uma empresa apenas com Gerentes de Projeto está fadada ao insucesso a longo prazo, já que falta a pessoa que  visão do grande esquema das coisas : o Gerente de Produto.

Acho que a falha em compreender que existe uma diferen√ßa e a falha em criar compartimentos separados dentro da organiza√ß√£o para cada um dos gerentes √© um dos motivos, n√£o apenas para a dif√≠cil aceita√ß√£o do Scrum, mas tamb√©m , inclusive, do insucesso das empresas. Mesmo quando se trata de uma “f√°brica” de software.¬† N√£o vendemos projetos, vendemos “cria√ß√£o de produtos”.

Um comentário para “O Gerente de Projeto e o Gerente de Produto”

  1. […] meu ultimo post falei sobre o Gerente de Produto e o Gerente de Projeto. Mas acho que o assunto n√£o fica completo sem falar o que √© um Produto, o que √© um Projeto e a […]

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos