BT

Como lidar com a ausência de um Product Owner efetivo

Postado por Paulo Rebelo em 04 Jul 2011 |

O papel do Product Owner tem grande importância no Scrum, mas muitos dos profissionais que assumem esse papel não possuem o tempo necessário para acompanhar a equipe, não tendo disponibilidade sequer para a evolução do produto da forma que merece. Neste artigo, são exploradas alternativas para tornar mais efetivo o papel do Product Owner. 

Papel e responsabilidades

Em Scrum, lembrando, temos três papéis bem claros: ScrumMaster, Product Owner e membro da Equipe (ou do Time). Nosso foco é no Product Owner, que possui basicamente as seguintes responsabilidades:

  • Conceber o produto, escrevendo suas histórias e funcionalidades gerais;
  • Priorizar as histórias de mais alto valor;
  • Estar disponível para a equipe, ajudando-a a entender os requisitos;
  • Aprovar as histórias realizadas pela equipe;
  • Definir as necessidades dos usuários;
  • Garantir o retorno de investimento para cada funcionalidade entregue;
  • Possibilitar que seja feito o mais simples possível, mantendo a funcionalidade necessária.

A efetiva contribuiçāo do Product Owner (PO), como se vê, é um fator chave para o sucesso do projeto. Mas será que os POs possuem a dedicação exigida para a entrega de um produto? Da mesma forma que a equipe e o ScrumMaster, o PO também precisa ter o foco necessário, sendo este um valor importante do Scrum.

É importante que o PO participe das reuniões diárias, e sua presença é obrigatória em Reviews e Plannings (lembrando que Review é a reunião de apresentação do que foi realizado pelo time, e Planning é a reunião de planejamento do que será feito em um determinado ciclo de entrega). 

Recomenda-se ainda que o PO esteja disponível para a equipe, para lidar com eventuais dúvidas e sugestões. Além disso, na reunião de Product Grooming, contamos com o PO para trazer as respostas e os direcionamentos necessários.

No entanto, isso frequentemente não é o que acontece na prática, pois muitos dos Product Owners são extremamente ocupados, não possuindo o tempo para dedicação à equipe e principalmente ao produto. Muitos dos eleitos para a função de PO cuidam de outras atividades, outros produtos, até mesmo gerenciam outras equipes, dentre varias responsabilidades adicionais. Esse acúmulo de funções pode ser enormemente prejudicial para todos os envolvidos no projeto. 

Alternativas

Como lidar com essa situação? Em muitos casos, o que se pode fazer é tratar o PO atribulado como um Business Owner, delegando as tarefas do PO de fato, com o foco no desenvolvimento do produto e na equipe. Saber delegar e confiar no profissional para o qual está passando essa responsabilidade traz retorno para o próprio Business Owner. O PO precisa se conscientizar (ou ser conscientizado) de que não é possível "encaixar" mais um papel em seu dia-a-dia. Deve-se ainda reforçar que esta é uma responsabilidade básica para o Scrum.

É neste último ponto que talvez esteja o problema: será que a implantação do Scrum nas empresas fica realmente clara e transparente para todos? Às vezes, "transformamos" o atual Gerente de Projetos em ScrumMaster, treinamos o time de desenvolvimento em técnicas ágeis, mas e o Product Owner? Não bastaria apenas treinar aquele que hoje responde pelo produto, pois é ele mesmo quem deveria exercer essa função?

Querendo ou não, a denominação de PO do Scrum é confundida por muitos, talvez pela tradução literal da palavra ("dono do produto"). Mas, o fato é que a escolha do PO pode ser decisivo para o sucesso de um projeto. Imagine um PO sem capacidade de determinar o retorno de investimento do seu produto; ou que não saiba o que gera mais valor.

Existem implantações de Scrum, nas quais já participei, em que existia um grupo de Product Owners e um Chief Product Owner (recomendo a leitura do artigo de Roman Pichler que trata do papel de Chief Product Owner). O Chief Product Owner é um profissional responsável por treinar, colaborar e conduzir os Product Owners. Na minha experiência, o modelo funcionou bem, pois os CPOs eram focados na função e por existir essa comunidade, compartilhavam muitas experiências. Os Product Owners faziam a interface com a área de negócio e o dono real do produto era considerado o Business Owner (leia mais sobre o conceito de Business Owner no artigo de Dean Leffingwell).

Outra opção para garantir uma boa condução do produto é a alocação de um analista de negócio. Esta pessoa faz o detalhamento dos épicos, temas e histórias; fica ao lado do time e responde às dúvidas de negócio, viabilizando a geração de valor para o produto, entre outras funções. Mas novamente aqui podemos cair em uma armadilha: o analista não é um Product Owner de fato, e muitas vezes requisitaria certo tempo do verdadeiro Product Owner. Isso porque não teria a mesma autonomia para priorizar ou aceitar as histórias, por exemplo.

O Problema da indisponibilidade

A falta de tempo do PO tende a se tornar um círculo vicioso, que na maioria das vezes acaba sobrecarregando o ScrumMaster. Se o PO não cumpre com a sua função como deveria, o ScrumMaster é quem acaba assumindo grande parte da responsabilidade. Não é raro encontrar um ScrumMaster refinando uma história para o time ou até mesmo criando-a. 

Dito isso, algumas questões vêm à tona: será que foram dadas as condições necessárias para o PO realizar efetivamente o seu trabalho; ou seja, não deveria o PO ser um Business Owner, e permanecer em um papel com menos responsabilidades? Para isso acontecer, no entanto, precisaria ele contratar um PO e delegar essa função, ou deixar a resolução do impasse a cargo de quem implantou o Scrum? 

A Implantação do Scrum nas Empresas 

Toda a culpa parece ficar por conta do Scrum, o que não é verdade. Apesar de ser um framework baseado em princípios simples, o Scrum detém complexidade significativa e sua implantação em empresas exige cuidado e atenção a detalhes. Se a implantação não ocorrer de forma bem planejada, novos problemas surgirão e a impressão do Scrum ficará comprometida. 

Os papéis e as responsabilidades de cada um devem ficar muito claros, não pode haver sobreposição de tarefas (por exemplo, um PO deve se dedicar a essa função). Além disso, treinamentos são necessários para todos, inclusive para os profissionais nas demais funções, que, de uma forma ou de outra, serão afetados pela implantação. E, talvez o mais importante, é a transformação cultural da empresa, e o aprendizado e a adaptação dos profissionais que a compõem.

Conclusões

O papel de Product Owner no Scrum é complexo, envolvendo múltiplas tarefas e responsabilidades. É preciso ter foco no produto a ser entregue e tempo de dedicação. Portanto, a escolha do Product Owner é de vital importância para todos os envolvidos. É o Product Owner quem direciona o produto. Mas se não tem o tempo necessário, e não for possível fazer mudanças na empresa para que o tenha, será melhor considerá-lo como Business Owner e contratar um Product Owner que realize essa função.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

PO deve ser presente! by Noaldo Sales

Não consigo enxergar um projeto obtendo sucesso sem essa figura. Entendo que muitas vezes fica difícil de tê-lo tão presente, mas se colocarmos outra pessoa assumindo esse papel, podemos cair no mesmo problema.

Acredito deva haver o comprometimento da equipe (SM, PO e Team) para que o projeto flua e atinja o seu objetivo. Sabe aquela velha história de porcos e galinhas? Tb teremos problemas se os membros do Team não estiverem dedicados ao projeto ou o próprio ScrumMaster for ausente.

Acho que o PO deve assumir o projeto e dedicar seu tempo a ele, bem como tb assumir o papel de Business Owner, como citado acima, aliás, ele deve entender bem do negócio.

Me corrijam se estiver errado.

Grande abraço!

@noaldofilho

Re: PO deve ser presente! by Paulo Rebelo

Oi Noaldo!

É uma questão de delegar responsabilidades, pois esses três papeis precisam de dedicação e foco no produto. Se algum deles não o tem, é porque chegou a hora de passar essa responsabilidade para outra pessoa e essa transição deveria ser natural, pois centralizarmos, às vezes, é prejudicial até para a difusão do conhecimento e colaboração, algo muito saudável. Nada impede que o Business Owner ainda tenha responsabilidade sobre o produto, voltado a tarefas menores e coaching do Product Owner.

[]s,

Paulo.

reais responsabilidades do PO by Sergio Vellozo

Me parece errado delegar ao PO "Conceber o produto, escrevendo suas histórias e funcionalidades gerais". Para mim quem concebe o produto é antes o time que o PO. O PO não sabe fazer software. O PO sabe o que o negócio necessita. Ter um time que faz o que o PO determinou tende a ser um fracasso a menos que o PO seja Steve Jobs.

Sds

Re: reais responsabilidades do PO by Noaldo Sales

Sérgio, não concordo com essa forma de pensamento. O Steve Jobs quando dá seu aval para os produtos, ele está enchergando como cliente. Ele quer o melhor, da melhor qualidade, com as melhores funcionalidades.

Como desenvolvedores, temos que atender a uma demanda e quem deve informar o que deseja é o cliente. Ele sabe exatamente o que quer. Pode até não saber como, mas sabe o que quer.

Não podemos assumir a responsabilidade pelas funcionalidades do software uma vez que não é para nós que estamos desenvolvendo. O cliente é que tem que dizer o que quer e quando estará do jeito que ele quer.

Até mais!

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

4 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT