Recentemente recebi uma pergunta através do Facebook: O que faz um Product Owner?

Gostaria de responder a pergunta e deixar minha opinião registrada através deste post.

A pergunta foi mais ou menos assim:

Onde eu trabalho estou para assumir o desafio de ser PO, e parece que a empresa não tem bem definido o quais são as funções do PO pois alguns dos POs desenham diagramas como um analista de requisitos, isto está correto?

Segundo eles esta é a lista de atividades:

• Entender, criticar, questionar e mapear processos de negócio do cliente;
• Levantar requisitos funcionais e não funcionais de sistema;
• Mapear e descrever atores e casos de usos/user stories de sistema;
• Definir complexidade dos requisitos de negócio;
• Elaborar documento de escopo do sistema;
• Prototipar interfaces de usuário do sistema;
• Realizar reuniões de licitação de requisitos com cliente;

Vamos então as origens. De acordo com o Scrum Guides:

O Product Owner é responsável por maximizar o valor do trabalho que o Time de Scrum faz, […] é  a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time.

Essa pessoa mantém o Product Backlog e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.

O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá que convencer o Product Owner.

Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo.

Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outro conjunto de prioridades, e os Times não podem dar ouvidos a ninguém que diga o contrário.

As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz o papel de Product Owner exigente e  recompensador ao mesmo tempo.

Isso dito, vamos fazer uma analise.

Product Owner (PO) é apenas um Papel do Scrum

Scrum é um  é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software [Wikipedia]. O processo define 3 papéis, entre eles o do Product Owner . Dessa forma em se tratando de Product Owner, podemos afirmar apenas que suas responsabilidades são apenas o que dita o processo:

1. Maximizar o valor do trabalho que o Time
2. Gerenciar o Backlog (Manter, Priorizar, etc)

Isso significa que um Product Owner não pode fazer nada além disso? Não. Product Owner  não é um Cargo, é um papel, ou seja, é muito provavel que a pessoa que assumir esse papel tenha outras responsabilidades na sua organização, e isso tem uma relação direta com o contexto (projeto, produto, equipe,  cliente, etc.).  

O Product Owner pode ser o próprio cliente, pode ser uma pessoa que faz parte da equipe do cliente (um médico, um advogado, um contador, um CEO), pode ser um gerente de produtos, pode ser um analista de negócios, etc. Se essa pessoa tiver disponibilidade para estar perto do time e estiver capacitada a maximizar o valor do trabalho do time e gerenciar o backlog, do ponto de vista do processo, não há nada de errado com isso.

Em outras palavras, se o PO fizer bem o papel, e tiver outras atividades, não há problema algum, e essas outras atividades que fizer estiverem relacionadas à gestão do Backlog e a Maximizar o trabalho do time, melhor ainda.   Considere utilizar o Acelerato para organizar seu backlog, priorizar o que fazer primeiro e definir as próximas entregas do seu projeto.

Mas então quais são essas atividades?

• Criar protótipos?
• Fazer Pesquisas de Mercado?
• Detalhar Requisitos?
• Visitar Diferentes Clientes?
• Pesquisar Produtos Concorrentes?
• Conversar com Usuários?
• Desenhar Diagramas?
• Escrever Testes de Aceitação?
• Documentar?
• Manter um Documento de Visão?
• Servir Café aos Desenvolvedores?

A resposta, na minha opinião, é: Depende do Contexto/Cenário!  

Alguns produtos são criados para um único cliente, outros para centenas de milhares, alguns envolvem grande complexidade, outros baixíssima, alguns produtos envolvem diversas áreas de conhecimento, como é o caso de um ERP, por exemplo, alguns produtos são tão grandes, ou tem um prazo tão curto que precisam que diversos times trabalhem simultaneamente para um mesmo target release (Agile Release Train), alguns produtos são construídos em empresas com 20 funcionários, outros em empresas com milhares.

Conclusão

Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada. 

H L Mencken

Podemos concluir que não existe bala de prata! Ou seja não há um conjunto único de atividades (baixo nível) que um PO possa fazer que seja eficiente em todos os projetos e contextos.

Você precisará, através de um processo de inspeção e adaptação, encontrar quais são essas atividades que fazem sentido na sua organização.

Se você quer aprender mais sobre o papel do Product Owner, e outros papéis importantes em métodos ágeis, leia de meu livro, ou um dos livros nacionais ou livros internacionais recomendados sobre métodos ágeis.