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?