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.
