Pesquisar neste blog

24 de jul. de 2012

O Gerente De Projeto E O Gerente De Produto

Por: javabuilding.com
Em: http://sergiotaborda.javabuilding.com/2012/06/o-gerente-de-projeto-e-o-gerente-de-produto/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javabuilding%2Fsergiotaborda+%28Sergio+Taborda%29

É 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”.

Nenhum comentário:

Postar um comentário