As disfunções do papel do PO.

  • 40
  • 5
  •  
  •  

E aí, galera!

Vocês já passaram por uma situação onde o Product Owner (PO) fatia as histórias de um jeito quase impossível de ser feito? E quando não agrega valor para o produto? No post de hoje vou falar sobre algumas disfunções desse papel que já vi por aí.

Em nosso pub, nós já falamos sobre o papel do Product Owner (PO). Ou seja, descrevendo bem superficialmente, é aquela pessoa responsável pela parte de negócio do produto. E o que isso quer dizer? É ela que vai gerenciar o backlog, buscando maximizar o RoI (Return On Investiment). Outro ponto bem importante é que ela tem a obrigação de responder todos os porquês relacionados ao negócio do produto para o restante do time.

Gostou? Quer saber mais sobre esse papel importante? Então dá uma lida no post onde falamos mais sobre! :) 

Então vamos lá começar com algumas disfunções.

Um bom PO é um profundo conhecedor da parte técnica do produto.

Não necessariamente! Você não precisa ser uma pessoa técnica para exercer o papel de PO. O PO deve ter conhecimento profundo sobre o negócio do produto. A parte técnica é responsabilidade dos desenvolvedores. Entretanto, um bom PO não fecha os olhos para esse lado, pois isso o ajuda a fatiar melhor as histórias. Em algumas conversas que tive sobre esse assunto, algumas pessoas tinham receio em se aprofundar como PO, pois não sabiam nada de programação. Então, calma! Você pode ser um bom PO sem isso. 🙂

Já conheci designers que foram excelentes como PO.
O cliente tem sempre razão.

Outra disfunção bastante comum. Gosto de ponderar bastante sobre esse ponto. No contexto de serviços, é natural aceitar tudo o que nossos clientes pedem, afinal de contas, são eles que estão pagando, certo? Entretanto, um bom PO sabe negociar muito bem e todos nós sabemos que negociar com o cliente não é nada fácil.

Diogo, então você está dizendo que o cliente não tem poder de decisão? Em nenhum momento disse isso. Conhecer a capacidade do time é essencial para o PO entender a demanda que aquele time pode fazer em determinado timebox. Aprender a dizer não para o seu cliente é uma forma de se trabalhar a eficiência do produto e a eficácia do time.

A grande dificuldade aqui está em como dizer isso para o seu cliente, certo? Uma abordagem que aprendi é demonstrar o impacto do que o cliente está pedindo.

Ex. Querido cliente, a gente pode fazer isso o que você está pedindo. Entretanto, aceitando  isso, não conseguiremos entregar todas as funcionalidades que a gente acordou previamente. Por isso, será preciso substituir alguma delas pelo seu pedido.

Um bom PO sabe negociar em prol do sucesso do produto. Comunicação não violenta é essencial para isso acontecer com mais facilidade.
Eu quero essa funcionalidade até sexta-feira.

Essa também é clássica. Às vezes negócios e desenvolvimento não andam na mesma velocidade e o nosso querido PO compromete-se com datas sem alinhar com o resto do time. Entretanto, quem conhece a capacidade de desenvolvimento é quem coloca a mão na massa. Logo, são eles que devem indicar os prazos baseado em seu ritmo de entrega. Caso isso não aconteça, o comprometimento de todos pode ser afetado, resultando em muito estresse, hora extra, entre outros.

PO também faz parte do time e não deve ficar isolado em seu mundo. Um bom PO deve estar em constante comunicação e sempre disponível para o time. Relembrando aqui um tópico muito importante do livro Scrum – Gestão Ágil Para Projetos de Sucesso.

Simplicidade – A arte de se maximizar a quantidade de trabalho não feito – é essencial. 

Ou seja, simplifique para diminuir a complexidade! 🙂

Fatias dependentes

Saber fatiar é essencial na função de um bom PO. Entretanto, ainda encontramos fatias dependentes uma das outras. Um bom exemplo disso que já vi foi entregar primeiro o backend em uma sprint e o front-end em outra. Isso faz com que o nosso ciclo de feedback seja mais lento, resultando em maior incerteza na aceitação do usuário.

Em desenvolvimento de software, quanto menor o ciclo de feedback, mais rápido estamos entregando valor para nossos usuários. Ou seja, o time todo (e não apenas o PO) deve ter em mente a visão e objetivos do projeto / produto.

Como falei anteriormente, o PO faz parte do time. Então procure envolver todo time para ajudá-lo a fatiar com mais qualidade. Em geral, isso acontece durante o refinamento do backlog.

PO não ter controle sobre o backlog.

Ora, nosso querido PO é o guardião disso. Mas, isso não quer dizer que ele tenha que fazer tudo sozinho. Colaboração é essencial para isso e todo o time deve dar pitaco em cima do backlog, entretanto o ÚNICO que tem poder para alterar qualquer coisa nele é o PO.

Esses foram algumas disfunções que já vivenciei e que foram excelentes oportunidades de aprendizado para mim. Claro que há sempre contextos e contextos, mas tentando pensar numa regra de ouro para ajudar a combater essas disfunções, seria de fato a colaboração e empatia. Procure envolver seu time nas tomadas de decisões e coloque-se no lugar de seu usuário, isso vai ajudar a realizar diversos aspectos do papel de um PO com mais facilidade.

E vocês? Quais disfunções já vivenciaram? Deixa ai nós comentários. 😉

Grande abraço

Showing 4 comments
  • Marcos Fabrício
    Responder

    Meu pesadelo pessoal infelizmente…
    Disfunção 1: o PO deve exercer um papel, mas este papel não é apresentado para a equipe, logo o PO não consegue realizar suas incumbências.
    Disfunção 2: PO dese sim ter um conhecimento geral de todas as áreas para saber fatiar as coisas. Mas não é legal quando o PO (nem para ele nem para a equipe) assume papel de Tester, o Designer e ou SM
    Certamente o pessoal aí deve ter mais dessas

    • Rennan Reis
      Responder

      Me identifiquei bastante com as disfunções que você apresentou Marcos. Em uma experiência recente, uma disfunção que se enquadra bem nesses casos, é quando temos uma nova empresa responsável pelo fornecimento visual do site/aplicação e essa empresa tem dificuldades em entender o papel do PO, pois, por serem a parte visual da coisa, tomam a responsabilidade apenas para eles. Mas com bastante esforço e união entre as empresas, conseguimos definir certinho as expectativas e papeis e no final se tornou uma experiência bem gratificante.

  • Raphael Albino
    Responder

    Olá Diogo, ótimo texto!

    Recentemente escrevi sobre a complexidade por trás do papel de PO/PM.
    Quando a pessoa de produto deixa de exercer seu papel, ela atrapalha o desempenho da equipe, atividades básicas são abandonadas e há uma falta de foco.

    Deixe seu feedback no texto depois 😉

    Abraço

  • Henrique Fontana
    Responder

    Olá Diogo, conheci hoje o Agile.Pub e achei excelente, tem material para estudar por um bom tempo.
    Sobre essa questão do PO e da gestão de Backlog, demos uma palestra nos TDCs de POA e Floripa sobre como estamos abordando essa situação aqui na Trier Sistemas.
    As equipes passaram a ser donas do seu backlog, as decisões de priorização são multi-setoriais, o PO passou a ser um consultor das equipes, enfim, estamos buscando mais agilidade e colaboração na gestão de backlog.

    Se alguém tiver interesse em dar uma olhada e nos ajudar com opiniões, segue a apresentação:
    https://pt.slideshare.net/GuilhermeVandresen/tdc2018-organizando-o-caos

    Grande abraço.

Leave a Comment