menu

Escalando o papel do Product Owner

Por

Qual o papel do Product Owner (PO)? Seria ele um oráculo? Um mágico? Um visionário? Teria ele seguidores? Seria o PO representado somente por uma pessoa? Seria Deus?

Muito já se discutiu na comunidade Agile sobre o papel do Product Owner. Alguns gostam de traduzir o termo como “O dono do produto” outros como “O responsável pelo produto”. Outros, ainda, traduzem somente como “O cliente”. Todavia, a pergunta ainda persiste: O que ele faz?

Eliel Júnior, gerente de projetos da Plataformatec, falou recentemente ao InfoQ Brasil sobre O real papel de um Product Owner, em que diz preferir, em particular, a explicação dada por Mike Cohn ao dizer que o PO é aquele que determina as metas e conduz o time na entrega constante de valor. Ou seja, se a filosofia Agile se refere a entrega de valor, o PO, portanto, tem papel essencial no funcionamento da agilidade.

O próprio Mike Cohn, entretanto, já chegou a dizer em seu livro User Stories Applied (Histórias de Usuário Aplicadas), que o PO seria aquele que: escreve as histórias, prioriza as demandas e responde às perguntas dos desenvolvedores de forma onisciente. Esse cara é o PO! 🙂

Apesar de Cohn atualizar sua definição de PO no livro Succeeding with Agile (Alcançando o Sucesso com Agile), responsabilizando-o “somente” pela meta e pelo valor de negócio, ainda assim, o peso sobre este papel parece grande demais para ser feito somente por uma pessoa.

E não é feito somente por uma pessoa, principalmente no contexto de grandes empresas. Como afirma Júnior, na entrevista ao InfoQ Brasil, o profissional atribuído a este papel não tem o tempo necessário para estudar seu produto, a concorrência, testar conceitos, aprender e construir sozinho um produto.

Poderia haver mais de um PO?

Será, portanto, que precisamos de mais POs? Em outras palavras, precisamos de mais pessoas desempenhando o papel de Product Owner? Será que aumentando o número de POs não corremos o risco de ter “um cachorro com vários donos” e “morrermos de fome”?

O Scrum Guide (Guia Scrum), uma das principais referências deste assunto, diz o seguinte sobre o PO:

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. (…)

A citação acima apoia nossa afirmação anterior sobre a responsabilidade do PO em gerenciar o valor do produto, e segue dizendo que o PO pode delegar tais atribuições, quando convier, apesar de ainda ser o responsável primário por elas. Em seguida, no mesmo guia, temos a confirmação teórica que esse papel deve ser exercido somente por 1 (uma) pessoa:

O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.

E agora? Temos, por um lado, o Scrum Guide defendendo a observância de um PO único e, por outro lado, a real evidência de que não há PO onisciente ou que consiga, principalmente em grandes empresas, conciliar seus afazeres diários e as atividades de PO. Como resolvemos isso?

Simpatizo, em particular, com a ideia de haver somente um PO, porque na prática existe apenas uma visão a ser seguida em um produto. Não é possível haver duas pessoas com a mesma autoridade de negócio, pois poderiam conflitar os interesses e as visões. Ter uma visão fraca ou debilitada é tão ruim quanto não a ter.

Entretanto, dado o tamanho do projeto; dos produtos a serem desenvolvidos; do perfil do PO; e do contexto no qual este profissional está inserido, haverá de contar com muita ajuda…

Escalando o papel do PO

Para dar base às sugestões logo a frente, vamos considerar três situações comuns na qual um Product Owner pode se encontrar:

  • PO que não é PO;
  • PO de um grande produto;
  • PO novato.

PO que não é PO

Um time que tem um PO que não tem habilidades, autoridade e influência necessária para exercer o papel, é um grande problema para o desenvolvimento da agilidade em todas as suas vertentes, como citamos anteriormente. Essa situação se dá, geralmente, em grandes empresas, ou em empresas de filosofia tradicional, ou ainda naquelas em que a adoção das práticas ágeis está no início.

O PO, nesse contexto, é o antigo “cliente”. Aquele que demanda um certo trabalho por “empreitada”, pois não irá acompanhar o desenvolvimento do produto no dia a dia. Tem certa noção do que o produto precisa solucionar, mas não está apto a realizar testes e aprender com a evolução do produto.

Do mercado, entretanto, já emergiram algumas soluções para o problema do semi-PO. Apesar de tais soluções não estarem nos livros ou na teoria formal, já fazem parte do dia a dia das empresas. A solução foi criar um novo papel, que alguns chamam de “Proxy Product Owner” (Product Owner Intermediário) outros chamam de “Business Analysts” (Analistas de Negócio). Como assumimos, porém, que não é recomendável ter dois POs ou mais, e como não vejo diferenciação entre os papéis de Analista de Negócio e PO Intermediário, daqui em diante chamaremos o PO Intermediário simplesmente de Analistas de Negócio.

O Analista de Negócio, em um contexto de PO-que-não-é-PO, incorpora todas as funções que um PO precisa exercer, exceto a autoridade total sobre o backlog. Em última instância, o PO-que-não-é-PO ainda responderá pelo produto e decidirá os rumos de acordo com sua semivisão. De fato, a nomenclatura acaba por satisfazer somente a um capricho político-organizacional, pois o PO, in charge, é o Analista de Negócio, e o “Cliente” um stakeholder importante.

O Analista de Negócio deve atuar, neste cenário, como um Adapter (Adaptador), no intuito de compor, com o cliente, o papel do PO necessário ao projeto. Atuando como um “Adaptador” o Analista de Negócio traduz as necessidades do cliente; auxilia-o na compreensão dos stakeholders; e faz a ponte com o time, adaptando, portanto, as pontas desta interação cliente-time.

PO de um grande produto

Imaginando que o PO de um grande produto seja, de fato, um PO, o desafio agora é articular várias frentes que compõe o(s) projeto(s). Como manter a visão compartilhada sempre presente em todas as iniciativas e sub-produtos sendo construídos? Como manter o backlog atualizado e priorizado de todas as frentes abertas que se inter-relacionam? Como manter a comunicação com os vários stakeholders desse programa?

Novamente a figura do Analista de Negócio entra em cena. Agora não mais para ser o PO interino, como acontecida no caso do PO-que-não-é-PO, mas para dar alcance ao PO por direito, que precisa de “braços” e “cabeças” focadas em seus vários sub-produtos. O Analista, aqui, cuidará da parte burocrática que faz parte da função do PO, como escrever histórias, mas dele também será exigido que entenda o produto e discuta alternativas, abordagens e simplificações que valorizem o produto rumo à visão. Pode influenciar, sob a ótica do PO, os stakeholders e os times que atuam no produto, tendo “carta branca” em vários pontos, mas consciente de não estar em seu próprio território.

Em alguns lugares, aparece um papel de “Product Manager” (Gerente do Produto), que, por vezes, faz o papel de PO geral, com Analistas de Negócio trabalhando para ele. Novamente, as nomenclaturas podem ser abstraídas destas explicações.

PO novato

É bem comum lidarmos com POs novatos. Aliás, sem exagerar muito, todas as aplicações ágeis são relativamente novas no mercado. Mas aqui podemos ter algumas condições que colaboram com o papel do PO:

PO novato + Time novato: Será necessário uma atuação forte do Scrum Master (não novato), atuando como o facilitador dos papéis, e assumindo, por vezes, funções adicionais. O Analista de negócio pode entrar neste contexto também como coach do PO, que, apesar de novato, tem todas as condições e habilidades para ser um PO efetivo.

PO novato + Time maduro: Como Scrum Master novato, já aprendi muito com o time. Logo, creio que o PO também possa se desenvolver conforme interage com um time maduro e que já enraizou os conceitos e princípios ágeis. Um Analista de negócio, salvo as proporções do projeto, poderia atuar algum tempo como coach do PO, que, mais tarde, exercerá suas funções sem problemas.

Em ambos os casos, um Analista de Negócio pode contribuir no coaching do PO, ora como Adaptador (como comentamos anteriormente), ora sendo mais “braços” e “cabeças” para pensar o produto; ensinando-o a não priorizar demandas desnecessárias; filtrando a entrada das demandas; desenvolvendo uma linguagem comum com o time técnico, etc…

Difundindo uma visão de PO no time

O fato de se adicionar mais Analistas de Negócio não implica que se pode escalar o papel do Product Owner. O PO, em última instância, é responsável por cultivar o propósito do produto no time e criar um ecossistema que permita que ideias e feedbacks aconteçam facilmente. Com isso, o PO dilui um pouco o seu papel pelo time, se beneficiando de visões ricas de quem está criando seu produto no dia a dia.

Anselmo Martelini, gerente ágil na Abril, criticou também a utopia do PO onisciente em seu post “Sua história é uma hipótese, e ai?” e defende testes efetivos sobre o sucesso das histórias lançadas em produção. Segundo Martelini, ao manter visíveis as hipóteses (propósito da história) e seus resultados, o PO permite que todo o time tenha ciência dos caminhos a se trilhar e ganha, com isso, potenciais analistas em todo o time.

E na sua organização? Como acontece o papel do PO? Compartilhe conosco!

Para outros detalhes sobre o papel do PO, veja um vídeo bem interessante.

Agile Product Ownership in a Nutshell

por Henrik Kniberg


Referências

http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/

http://www.scrumalliance.org/articles/459-your-client-isnt-your-product-owner

http://blog.andrefaria.com/mas-o-que-faz-um-product-owner

http://www.accelright.com/agile-scrum/what-is-a-proxy-product-owner/

http://www.infoq.com/br/interviews/papel-product-owner

http://scaledagileframework.com/

2 comments

  1. Pingback: #SomosTodosPOs | Kudoos

  2. Pingback: Rafael F. Buzon | O Desenvolvedor ainda aperta parafusos?

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top