No passado escrevemos sobre as disfunções que encontramos nas responsabilidades de Scrum Master (SM) e Time de Desenvolvimento, atualmente chamado de Desenvolvedores, desde a última atualização do Guia do Scrum. Na verdade, as disfunções destes foram divididas em Parte 1 e Parte 2.
Ouça este artigo!
Neste Artigo
Eu jurava que tinha escrito sobre o Product Owner (PO), mas em uma turma de CSPO descobri que havia esquecido desse importantíssimo papel. Então, vamos falar quais são as disfunções mais comuns que encontramos no PO.
O Product Owner (PO)
Antes de continuarmos, vamos ver o que é esperado do Dono do Produto – Product Owner (PO)? Recomendo a leitura do artigo Product Owner: quem é e o que faz e também ver a definição direto no Guia do Scrum (p. 7).
De forma resumida, o Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. É a pessoa que se comunica com o Time Scrum, clientes e demais stakeholders para capturar as necessidades e expectativas deles.
Também é o responsável por compreender o mercado em que sua organização se insere, obter métricas de uso e eficácia do produto ou serviço de quem é dono / dona e, com todas essas informações, alimentar, priorizar e gerir o Backlog do Produto (Product Backlog).
É um trabalho de análise de problemas e síntese de hipóteses de solução, no qual o trabalho de Fatiar, Descartar e Priorizar é fundamental.
O que é uma Disfunção
Um dos grandes deslizes que cometemos como facilitadores é chegar em um time e falar: “VOCÊS ESTÃO ERRADOS!!!”. Isso é terrível e agride as pessoas. Elas entrarão em modo sobrevivência e atacarão qualquer ideia que você der.
As disfunções surgem por algum motivo. Tradicionalmente elas são o resultado de soluções passadas. Havia um problema, alguém propôs uma solução, aplicou e na hora deu algum resultado. Entretanto, ao longo do tempo a solução causou novos problemas. Muitas das vezes maiores do que aqueles que ela deveria solucionar.
Não agrida as pessoas, trate as disfunções acolhendo-as e demonstrando com fatos, dados e métricas que há caminhos melhores.
Quando começamos a escrever esse artigo, listamos as disfunções que conhecíamos, mas conforme escrevíamos vimos que eram muitas e deixariam esse artigo muito longo. Então, separamos em duas partes. Nesta primeira, falaremos sobre os problemas causados pela forma como algumas organizações compreendem o papel de Product Owner.
No segundo artigo, escreveremos sobre as disfunções causadas pela personalidade e características da pessoa que desempenha esse papel.
Product Manager, Business Manager e toda hierarquia criada para ninguém ser dono de nada.
Essa tem sido a disfunção mais comum nas organizações. O PO não tem acesso às informações e pessoas que deveria ter acesso. Só consegue ver as métricas do seu produto se pedir autorização para todo mundo e quando recebe já são as informações do mês passado. Além de desconhecer o mercado e não receber treinamento sobre como aprimorar as habilidades necessárias.
Alguém tem então a brilhante ideia de colocar alguém acima do PO. O Gerente do Produto – Product Manager (PM). Esse é o cara. Ele vai resolver os problemas. Na prática fica uma bola dividida e como em um jogo de vôlei em que um jogador olha para o outro esperando que o seu amigo pegue a bola, ela fica caindo no chão. O tempo todo.
No artigo Qual é a diferença entre Product Manager e Product Owner? Magno Santana escreveu sobre as origens dessa disfunção e os problemas que ela causa. Na prática você pode ter na sua organização pessoas com o papel de Product Owner ou você pode chamá-las de Product Manager, mas ter os dois simultaneamente é um sinal de que terá problemas. Gosto muito da frase do Marcos Garrido:
“PO é o CEO do Produto”
Se a sua empresa estiver nesse caso de ter criado uma estrutura paralela com Product Owners, Product Manager, Business Owners e outros nomes bacanas, faça o seguinte exercício de É, Não É, Faz, Não Faz.
Primeiro você define o que seria o Dono / Dona do Produto ideal. Você pode utilizar como base o artigo da Andressa Chiara: Product Owner: quem é e o que faz e é claro as definições do Guia do Scrum. Dê um nome para esse papel: Nirvana do PO, Senhor das Priorizações, Rainha do Backlog, use a sua criatividade.
Em seguida, faça a mesma dinâmica do “É, Não É, Faz, Não Faz” para todos os papéis que a organização tem hoje e estão relacionados à responsabilidade de tomada de decisão quanto à direção de produtos: Product Owner atual, Product Manager etc.
Agora compare as interseções entre os papéis. No contexto ideal, o PO atual é o DONO / DONA do Produto, logo o PO Atual deveria estar contido no PO ideal.
Na Figura acima nascem as desavenças entre os papéis. Toda vez que temos uma sobreposição entre o PO Atual e o Product Manager, temos uma zona de brigas e conflitos. Decisões sendo tomadas ora por uma pessoa, ora por outra e os desenvolvedores no meio da confusão sem saber para onde ir.
Quando temos uma área sem sobreposição entre o Ideal e os dois papéis, temos responsabilidades não assumidas. Como o espaço não pode ficar vazio, é nesse momento que nascem novos papéis para adicionar mais um pouco de desordem no caos.
Já quando o Product Owner ou o Product Manager tem atribuições sem interseção com o Ideal, temos, possivelmente, pessoas assumindo outros papéis além desses e isso representa um conflito de interesse para a pessoa.
Se você é a pessoa que facilita ou é gestora em uma empresa que tem um contexto desses, trabalhe para que haja um único papel responsável pela gestão do produto.
Atenção: O nome que você escolhe para o papel que desempenhará essa funçao de gestão do produto não é a parte mais importante. A empresa pode utilizar o Product Owner, Product Manager, Produteiro / Produteira ou qualquer outro nome que achar interessante. A disfunção que falamos aqui não está relacionada à nomenclatura e sim a criação de uma hierarquia de “donos” que acarreta nos problemas supracitados.
PO Comitê
“Um é pouco, dois é bom e três é demais” já diz o ditado popular. Na verdade, para as funções do PO não se aplica. Dois já pode ser um problema. Como uma vez me disse minha amiga Sonia Moreira, “cachorro que tem dois donos ou morre de fome ou come demais”. O Guia do Scrum é muito claro quanto a isso:
“O Product Owner é uma pessoa, não um comitê.”
Normalmente essa disfunção nasce dos mesmos problemas que criam os múltiplos papéis descritos na subseção anterior. Outro motivo é o questionamento: “E quando o PO tirar férias?”. O Time Scrum deveria assumir esse papel enquanto o PO estivesse indisponível.
Muitas das vezes o PO age como a pessoa do meio. Ele fala com as pessoas de negócio, “traduz” para os desenvolvedores e vice-versa. Isso infantiliza os desenvolvedores que nunca terão contato com o negócio e não se apropriarão do contexto em que estão atuando e nem da linguagem de negócio.
Parte do trabalho do PO é fazer com que o time entenda o contexto em que está inserido, saiba quais resultados eles estão gerando e consigam administrar o Backlog na sua ausência. Voltemos ao Guia do Scrum:
“O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o Product Owner ainda é o responsável.” (Guia do Scrum, p. 7).
PO Desempoderado
Normalmente é a causa das outras disfunções desta seção. Ele já recebeu um backlog prontinho e a missão dele é acabar o backlog. A tradução de Product Owner é Dono do Produto, mas ali ele não manda nada. Muitas das vezes, quem inclui ou remove os itens são os gestores ou papéis alternativos como o Product Manager.
Já vi casos em que o cliente era quem mexia no backlog. Ele só aceita e segue o barco — que pode estar indo para o norte ou para o sul. Tanto faz.
Já tratamos o caso de sobreposições de papéis, mas e quando elas não existem e mesmo assim o PO continua desempoderado? A principal solução para esse problema é começar a mergulhar em métricas.
Como é o uso do produto ou serviço? Quem são os seus clientes? Qual o faturamento? Qual o churn? Com isso, quando esse PO for discutir com outros stakeholders, ele terá autoridade porque demonstra, não através de achismos mas com fatos e dados, porque ele tomou as decisões que tomou. Nossa frase aqui é:
“PO, quer poder? Tenha métricas!”.
PO Chapeleiro Maluco
Ele ou ela é Product Owner, Scrum Master do time e nas horas vagas ainda desenvolve. Veste todos os chapéus do time e topa qualquer parada. Infelizmente os humanos são péssimos em fazer muitas coisas simultaneamente. Logo, essa pessoa irá escolher o que prefere fazer e deixar os outros papéis de lado. Caso entre na paranoia de tentar fazer tudo, burnout será o resultado.
PO Equilibrista
“Já que o PO não tem quase nada para fazer, então ele será o PO de 2, 3, 4, 5 produtos simultaneamente.” É praticamente o mesmo problema do Chapeleiro maluco. Na prática ou o PO escolhe um produto e deixa os outros ao “Deus proverá” ou tenta fazer todos ao mesmo tempo e mais uma vez caminha a passos largos para o burnout .
Conclusão
Veja a continuação deste artigo em As Disfunções do Papel de Product Owner (PO) – Parte II
As empresas devem entender qual o papel do Product Owner e trabalhar para que as pessoas que assumam esse papel tenham total condição para executá-lo da melhor forma possível. O investimento em um bom PO representa um grande resultado no futuro.
Aguarde que em breve publicaremos a segunda parte deste artigo. Mas você não precisa esperar, entenda o que é um PO no nosso treinamento de Certified Scrum Product Owner® (CSPO)
