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

Este post não tem tags.

Compartilhe:

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.

Sobre o autor(a)

Co-fundador e Trainer na K21

Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível 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 equipes em mais de 15 países na Europa, América e Ásia.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

As ferramentas de Inteligência Artificial (IA) já são uma realidade. Todavia, como saber qual escolher. Neste artigo quero apresentar os atuais modelos de IA que temos disponíveis para te ajudar nessa escolha. Antes vamos a alguns avisos importantes 1. A…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Já tem um bom tempo que não falo sobre assuntos técnicos por aqui. No entanto, outro dia tivemos que pagar uma dívida técnica bem alta e isso acendeu alguns alertas. Os produtos dos meus times sofrem atualizações constantes seja por…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sempre que falamos de gestão de produtos, a discussão sobre os papéis de Product Owner (PO), Product Manager (PM) e Gerente de Projetos (GP) ressurge. Muito se fala sobre as vantagens da separação deles. Mas pouco se fala sobre o…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Em 2008 comecei a utilizar Métodos Ágeis. Já faz tanto tempo que parece que eu nunca trabalhei de outras formas, porém já passei pelo Método Cascata clássico, Rational Unified Process (RUP), PMBOK e até a implantação do MPS.Br. Pelo mais…