BT

O problema do Product Owner único e possíveis soluções

por Vikas Hazrati , traduzido por Giovanni Abner em 12 Abr 2011 |

Pode-se dizer que o papel de Product Owner ("dono do produto", em tradução literal) é um dos mais trabalhosos no Scrum. O product owner (ou PO) é responsável pelo sucesso do projeto e espera-se que lidere o esforço de desenvolvimento e ajude a equipe a produzir o maior valor de negócio possível. Mas não seriam expectativas demais para um só papel?

Marko Taipale sugere vários argumentos justificando que o modelo de um só product owner não funciona. Segundo ele, seguir à risca a definição de PO levaria a uma série de ineficiências.

Taipale propõe que em vez de contar com apenas um product owner, equipes deveriam adotar paralelamente os conceitos de "desenvolvimento do cliente" e "desenvolvimento do produto". Desenvolvimento do cliente significa delinear e entender usuário, para que o produto correto seja construído. Já o desenvolvimento do produto começa com as informações obtidas pelo desenvolvimento do cliente, e esse processo continua.

Devem existir duas equipes para conduzir esses processos. A equipe do problema, que cuida do "quê", e a equipe da solução, que descobre a melhor maneira de resolver o problema. A equipe do problema consiste em pessoas de vendas, marketing, tecnologia, usabilidade, qualidade e executivos; a equipe da solução é composta por um grupo de desenvolvimento multifuncional, além das mesmas pessoas de qualidade, usabilidade e tecnologia que estão na equipe do problema.

Segundo Taipale, essa colaboração traz diversas vantagens:

As duas equipes tentam, juntas, maximizar o valor gerado. A equipe do problema contribui procurando conhecer melhor o cliente e identificando quais problemas vale a pena resolver. Já a equipe da solução oferece uma visão clara do feedback do mercado [...] normalmente em forma de estatísticas fornecidas pela própria solução.

Entre as vantagens estão:

  • Melhor compartilhamento da informação e do conhecimento
  • Melhor alinhamento com o objetivo
  • Múltiplas visões das necessidades do cliente
  • Presença de um canal para feedback construtivo
  • Vários pontos de comunicação
  • Uma visão compartilhada pela equipe

Na mesma linha, Roman Pichler sugere que, assim que um projeto deixa de ser simples, surge a necessidade de se ter mais de um product owner. Ele propõe a utilização de uma hierarquia de POs, com um PO chefe.

Uma hierarquia de product owners pode ir de uma pequena equipe, com product owners liderados por um chefe, até uma estrutura complexa com vários níveis de product owners.

Mike Cottmeyer reconhece que em muitas circunstâncias o papel do product owner é complexo demais para uma só pessoa e exige uma equipe para desempenhá-lo. Em vez de haver uma única pessoa para atender a todas as atribuições, pode-se ter uma equipe de product owners, em que várias pessoas trabalham coordenadamente. Essa equipe poderia incluir papéis como:

  • Gerente de Produto: Trabalha junto às partes interessadas (stakeholders), identifica requisitos e estabelece prioridades.
  • Gerente de Projeto: Mantém uma visão dos objetivos globais; gerencia recursos, custos, dependências externas etc.
  • Analista de Negócio: Responsável por documentar os critérios de aceitação e as conversas relativas às user stories. O Analista é o primeiro ponto de contato para esclarecimento de requisitos durante o sprint.
  • Designer: Prepara protótipos de tela, wireframes etc.

Cottmeyer sugere o seguinte:

A equipe de product owners deve ser relativamente pequena e autônoma, mas ao mesmo tempo ter todas as pessoas necessárias para executar as atribuições de product owner. Esse grupo deve ser capaz de decompor o backlog do produto de acordo com os princípios INVEST. Trata-se de um trabalho formidável, que normalmente exige que a equipe de product owners tenha pelo menos representantes das áreas de gerenciamento de produtos, gerenciamento de projetos, arquitetura, desenvolvimento, qualidade e análise de negócio.

Portanto, parece existir um consenso de que, com exceção de projetos relativamente simples, o modelo de um único product owner pode não funcionar em muitas situações. Qual tem sido a sua experiência?

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

Divergências ? by Reinaldo Braga

Mas sendo uma equipe, será que não haverão muitas divergências e no final o processo se tornará muito demorado causando problemas de gargalo para a equipe ?
Na minha opinião a grande vantagem de ser apenas uma pessoa é a facilidade da decisão.

Re: Divergências ? by Rodrigo Jardim

Apenas adicionando ao que o Reinaldo escreveu, mais de um Product Owner não traria os mesmos problemas que Design by Comite, onde ninguem é realmente responsável pelas decisões?

Por uma menor hierarquia by Paulo Rebelo

Por mais que os produtos sejam complexos, não vejo a necessidade de estruturas "inchadas", pois talvez estejamos entregando um produto, mas que na verdade são 2 ou mais e, nesse caso, realmente precisaremos de um Product Owner para cada produto. Mas, a mesma aplicabilidade de termos user stories pequenas o suficientes para entregarmos em curto espaço de tempo, podemos também sugerir para os produtos, "quebrando-os" em produtos menores com responsabilidades divididas em diversos Product Owners. O time pode ser composto de um designer, analista de negócio e gerente de projetos, mas não fazendo parte de uma equipe de Product Owners, e sim do Agile Team. O que realmente, em alguns casos, pode fazer sentido, é uma comunidade de Product Owners, da qual interaja em conjunto, com a finalidade de trocar conhecimentos, dúvidas, problemas em comum, padrões, entre outros tópicos.

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

3 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-2014 C4Media Inc.
Política de privacidade
BT