Polêmica: o melhor Product Owner NÃO é o cliente

O Product Owner (PO) é certamente o mais negligenciado dos três papéis do Scrum. Exatamente por essa razão, muitas organizações acabam por adotar um caminho aparentemente mais fácil do que formar ou contratar um bom PO: dar ao próprio cliente esse chapéu.

Em função disso, já ouvimos muito por aí a propagação da ideia de que o melhor Product Owner é o cliente. As principais justificativas para essa afirmação envolvem o interesse do cliente no sucesso do projeto e seu conhecimento sobre o negócio e suas próprias necessidades.

Mas será que isso é realmente uma boa ideia? Muito pelo contrário. Em muitas das empresas que visitamos no nosso dia a dia como consultores, encontramos projetos em sérios apuros como consequência de um profundo desalinhamento entre PO e Time de Desenvolvimento. Essas empresas têm justamente essa característica em comum: o PO é o cliente. Mas então por que ter um PO-cliente é um problema?

1) O PO-cliente pensa em funcionalidades e não em problemas

O cliente raramente sabe o que quer: clientes geralmente têm dificuldade em entender os próprios problemas a serem resolvidos e, por conta disso, não é nada incomum haver clientes trazendo soluções “prontas” para problemas que eles não entenderam ainda. U

m PO-cliente causa a seguinte disfunção nesse caso: ao invés de levar problemas de negócio para resolver com o time, ele leva propostas de soluções prontas e que no final das contas não entregam muito valor. O time pode fazer exatamente o que o cliente pediu, mas como os problemas reais não são resolvidos, esse cliente não fica satisfeito. Quem nunca viu isso acontecer?

2) Relação de time ou de cliente-fornecedor?

A relação do PO-cliente com o time é tensa: no Scrum, PO, ScrumMaster e Time de Desenvolvimento formam o Time de Scrum, que deve se unir em torno do projeto. Só que quando o PO é o cliente, a relação deixa de ser de time e passa a ser de cobrança. Ao invés de colaborar com o time, o PO passa a assumir a postura de gerente de projetos, uma vez que é ele mesmo quem está “pagando” pelo produto que está sendo construído.

É bem comum nesse caso ver PO usando a Daily Scrum como status report, Retrospectiva para apertar o time e Sprint Planning para empurrar “só mais uma história”. Além disso, o PO-cliente sofre uma pressão direta e constante dos seus stakeholders por resultados. Assim, ao invés de proteger e colaborar com o time para organizar o trabalho, o PO-cliente quer tirar o máximo de seu “fornecedor”. Um efeito direto disso é que para esse PO-cliente tudo é prioridade, comprometendo uma das práticas essenciais do Scrum: a priorização.

3) Ausência frequente

O PO-cliente raramente tem disponibilidade para estar junto com o time para tirar dúvidas e para colaborarem para refinar os itens de trabalho. Aliás quando o PO é cliente, ele provavelmente está em outro local físico, o que dificulta a comunicação, causando diversas disfunções no projeto. Aliando essa questão ao problema número 2, a vida do time fica realmente complicada. Mesmo quando o projeto é interno, o PO-cliente acaba tendo outras atividades e prioridades, deixando o time muitas vezes perdido.

Se seu time tem um PO-cliente e você tem certeza que não enfrentam esses três problemas, excelente, mas saiba que vocês são uma exceção. No caso geral, nós da K21 defendemos que o melhor Product Owner NÃO é o cliente.

É fundamental que a escolha do Product Owner seja feita com bastante critério, de forma a se trabalhar com alguém que entenda de gestão ágil de produtos, que tenha disponibilidade para o papel, que saiba se comunicar com o cliente e stakeholders de forma eficiente e que trabalhe com o time de desenvolvimento em um regime de colaboração contínua. Só assim será possível formar um verdadeiro “Time de Scrum”, conforme definido por Jeff Sutherland e Ken Schwaber, os criadores do Scrum.

Click here to read this post in english.

Autor(es)

Rafael Sabbagh
Rafael Sabbagh
Rafael Sabbagh, co-fundador da Knowledge21 e membro do Board de Diretores da Scrum Alliance entre 2015 e 2017, é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban Univesity. Atuando como Executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e Membros de Time em mais de 15 países na Europa, América e Ásia.

Comentários

9 Comentários

  1. […] os testes de aceitação, podemos (ou devemos!) usar os critérios de aceitação descrito pelos Product Owners nas Histórias de usuário. Estando estes testes implementados, rodando, e passando com sucesso, […]

  2. […] O único cenário em que a participação do Product Owner na retrospectiva acaba gerando desconforto é quando o PO é o próprio cliente. Nem todo mundo curte a ideia de ter o cliente na sala no momento em que nossas fragilidades e problemas são levantados, mesmo que seja com o objetivo de melhorar sempre. Tratei desse tema em outro post – Polêmica: o melhor PO não é o cliente! […]

  3. […] Pela web, encontrei Luis Gonçalves com o artigo Product Owner antipatterns, o qual tem disfunções sobre PO com dicas, tenham cuidado em escolher a mais adequada para o seu contexto. Também gostei dos comentários do Rafael Sabbagh no post Polêmica – o melhor product owner não é o cliente. […]

  4. […] repeated here and there, as if the team’s role in the Sprint Review meeting were to obtain Approval by the Product Owner for the items developed. This way of thinking also reveals other dysfunctions that are usually […]

  5. […] A scenario where the Product Owner’s participation in the retrospective makes people uncomfortable is when the PO is also the client. Not everyone likes the idea of having the client in the room just when all the weak spots and issues are being exposed, even if the goal is to always improve. I’ve addressed this topic in another post – Controversy: The best PO is not the client! […]

  6. […] input to write acceptance tests, we can (or should!) use the acceptance criteria described by the Product Owners in the User Stories. When these tests have been implemented, are running and passing successfully, […]

  7. […] ainda seja dita por aí como se o papel do time na reunião de Sprint Review fosse conseguir a Aprovação do Product Owner para os itens desenvolvidos. Esse pensamento ainda revela algumas outras disfunções que […]

  8. Leonardo Rodrigues Marques 27/02/2019 em 11:32- Responder

    Será que o problema não é do time que aceitou tudo sem questionar? A culta é do P.O. ou foi do time scrum que não sabia trabalhar direcionado ao problema? Não faltou um Scrum Master para facilitar um levantamento de backlog dos problemas com o time e o P.O.?

  9. Leonardo Rodrigues Marques 27/02/2019 em 11:48- Responder

    No exemplo dado no artigo, “P.O. se fazendo de gerente de projeto”, é um exemplo da total ausência do ScrumMaster.

    Não deveria ser papel do ScrumMaster manter o objetivo das Daily, da Retrospectiva, da Sprint Planning?

    Sei que isso acontece, por isso, temos o ScrumMaster, o guardião dos processos do SCRUM.

    O ScrumMaster protege a equipe de desenvolvimento de interferências externas para que eles possam manter o foco na entrega de valor a cada sprint.

    Não importa qual a fonte da interferência, o Scrum Master atua como um interceptor para que a equipe possa se concentrar na entrega de valor.

Deixar um comentário