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

Uma das principais habilidades que desenvolvemos enquanto consultores é a de fazer boas perguntas. Uma vez que as pessoas percebem o poder que tem uma boa pergunta, colocada ali na hora certa e que muda o destino de uma reunião,…

Há cerca de uma semana um estudo com um título bombástico tomou conta da web: “268% dos projetos que passaram a utilizar Métodos Ágeis pioraram e 56% passaram a falhar”, dizia o título. E ao ler o conteúdo, pareceu que…

A polêmica da semana é sobre o suspeitíssimo “estudo” afirmando que projetos com Agilidade teriam 268% mais chance de falhar.  Muito rapidamente os cavaleiros do apocalipse já se apropriaram do conteúdo para poder dizer que já sabiam! Claro que esse…

Oi time! Vamos conversar rapidinho sobre como podemos fazer nossas reuniões renderem mais sem deixar ninguém na corda bamba com a agenda lotada. Aqui vão algumas dicas pra gente manter o equilíbrio: A) Marcando as reuniões: 1) Checagem de Disponibilidade:…