Qual o papel de um Product Owner?

Segundo o “Scrum Guide”, o Product Owner (ou Dono do Produto), também conhecido como P.O., “é o responsável por maximizar o valor do produto que é entregue pelo time de desenvolvimento”. Segue o link da versão em português do guia Scrum, caso você queira mais detalhes da definição oficial.

Mas como realmente é esse papel, o próprio guia já nos indica, que pode variar conforme a cultura da sua companhia!

Antes de falar para você sobre o papel e as responsabilidades que um Product Owner tem dentro de um time Scrum, vou falar um pouco sobre o conhecimento de negócio e algumas habilidades que um P.O. precisa ter, pois você será o representante da área de negócio dentro do time Scrum. Você será o elo de ligação entre os Stakeholders e o time do projeto.

O que é esperado:

Conhecer bem o(s) produto(s) da sua organização, saber o motivo dele existir, quem utiliza o seu produto, o que ele resolve;
Ter capacidade analítica para analisar o mercado, fornecedores, identificar o MVP (Produto Mínimo Viável) e entender sobre cálculo de ROI;
Saber se comunicar muito bem, pois terá que se comunicar com diversos tipo de público, tanto para prestar contas para os executivos da organização, quanto para informar a equipe técnica do projeto;
Conhecer sobre técnicas de negociação, pois você terá que negociar prioridades e até mesmo saber dizer não quando tiver que tratar do escopo do seu projeto;
Se você tiver conhecimento técnico, sobre desenvolvimento de sistemas, será um forte diferencial ao seu favor;
Seja comprometido, faça tudo que for possível para entregar o melhor resultado do seu projeto

Qual é o papel do P.O.?

Agora vamos falar sobre esse papel, o Product Owner! Sim, ele é um dos 3 papeis fundamentais de um time Scrum! E como você já viu o conhecimento necessário e quais habilidades você precisa ter para ser um P.O., agora verá onde terá que empregar cada uma das suas habilidades.

Mas novamente vou fazer um alinhamento sobre o que é o “Product Backlog” para o guia Scrum: “é uma lista ordenada de tudo que é conhecido ser necessário para a criação e/ou alteração do produto. É a única origem dos requisitos, é dinâmico. Pode mudar constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil.” Lembre-se: esse documento será o direcionador de todo o projeto.

Pronto agora que você já sabe o que é o P.B. (ou só Backlog), saiba que as funções do seu papel como P.O. é:

criá-lo e/ou modificá-lo;
Ordená-lo através das prioridades do negócio;
Divulgá-lo para todos os stakholders do projeto;
Aceitá-lo como concluído.

Quais são as responsabilidades de um Product Owner?

Como P.O. você poderá delegar algumas das suas atividades operacionais para outra pessoa executar, mas você sempre será o responsável pela gestão do Product Backlog.

Pois vamos detalhar cada uma das suas responsabilidades:

Criar e/ou modificar o P.B.

Ao criar os itens que compõe o seu Backlog, você precisa ser objetivo e garantir clareza para cada um deles, lembre-se que você terá vários tipos de públicos.
Neste documento você terá de incluir todas as necessidades, interesses e expectativas o seu público está esperando do seu projeto.
Você deve orientar o time do Scrum sobre “o que” precisa ser desenvolvido, tem que ser claro ao informar o que precisa ser construído. É sua responsabilidade fazer com que todos estejam “na mesma página”;
Como você, P.O., detém as informações sobre o projeto, será sua responsabilidade refinar o PB, criando as estórias para que o time de desenvolvimento saiba “o que”, “para quem” e “por que” o produto será criado e também como “validar” o que será entregue.

Já viu quantas das suas habilidades já serão necessárias só para esse item?

Ordenar o P.B.

Ao priorizar o seu backlog, você estará dando o time qual a direção ele deve seguir, portanto você deverá ter certeza que essa ordem irá maximizar o valor do trabalho do time Scrum;
Você tem a responsabilidade de garantir que a ordem das entregas trará os resultados esperados conforme a expectativa do público do seu projeto;
Num time Scrum, o SM ajuda o time ganhar produtividade, mas você também tem que colaborar com esse ganho, e a sua colaboração se dará priorizando corretamente os itens PB, e mantendo as soluções simples, onde deve manter o lema “menos é mais”, e não esqueça: ó ótimo é inimigo do bom”.

Divulgar o P.B.

Você terá que divulgar o Backlog para todo o público interessado no seu projeto, e entenda como o seu público todo o time Scrum, bem como os executivos que estão investindo no seu produto, e os usuários que vão utilizar o seu sistema;
Você terá que fazer uma gestão ativa sobre o seu P.B. e toda vez que ocorreu uma mudança, seja ela de inclusão, exclusão de novos itens ou mudança de priorização, todos muito bem informados. Seu P.B. deve ser transparente para todos.

Aceitar o P.B. como concluído

Quando você criou o seu P.B. e detalhou as suas estórias, você escreveu quais são os critérios que vai utilizar pra determinar que cada estória está concluída.
Portanto, agora é a hora de validar se o que o time de desenvolvimento entregou está atendo;
Você é o único responsável para determinar que uma estória está concluída!

Você é PO? Faz sentido pra você?