O que é um Product Owner?

Rafael Vieira
Produto Diário
Published in
6 min readJan 27, 2017

--

Então é mais um dia comum na sua vida: você acorda, toma um café e vai trabalhar. No trabalho, seu chefe te chama para um bate papo e te comunica:

Precisamos que você assuma o papel de PO em nosso time.

Se você não faz ideia do que isso significa, não se preocupe. Vou te dar uma mão :P.

O Product Owner, ou PO, é o membro de um time que utiliza Scrum (ou alguma técnica similar) para definir estórias e priorizar o backlog de um produto ou projeto. Ele é responsável por manter a integridade conceitual das novas funcionalidades, bugs ou melhorias, para que essas sigam uma visão definida para o produto ou projeto. Além disso, ele também é responsável pela qualidade final das entregas, sendo o único que deve ter poder de aceitar estórias como concluídas.

Em muitas empresas que utilizam alguma forma de Scrum o PO surge como uma necessidade urgente que geralmente se transforma em um trabalho em tempo integral, sendo necessário um PO para cada time de desenvolvimento.

O dia-a-dia do Product Owner

Como elo de ligação entre a equipe de desenvolvimento e clientes, o Product Owner deve colaborar de perto com ambos os grupos para garantir que há uma compreensão clara de quais recursos são necessários no produto ou aplicação. Porque pode haver uma variedade de tipos de clientes e usuários, o Product Owner deve ter uma sólida compreensão do domínio do negócio e as diferentes necessidades de diferentes tipos de usuários. Podemos dizer que ele precisa estar entre dois mundos.

A sprint do scrum começa com uma reunião de planejamento em que o PO transmite e prioriza os requisitos ou recursos do aplicativo para a equipe de desenvolvimento. O proprietário do produto ajuda a priorizar as histórias de usuário do backlog para que a equipe sabe que histórias para trabalhar durante a sprint. Nesse ponto, o PO é responsável por responder a quaisquer perguntas da equipe de desenvolvimento para ajudar a esclarecer quaisquer detalhes para que eles possam executar seu trabalho.

As responsabilidades do Product Owner

O trabalho do PO é quase que inteiramente composto por planejamento, comunicação e mais comunicação. O time precisa ter uma visão clara sobre o que fazer em cada sprint, os stakeholders precisam ter um canal aberto para feedback e entregas e todos devem seguir a mesma visão definida para o produto. Entenda as responsabilidades do PO:

Refinamento do Backlog: Com o input de Arquitetos, Engenheiros de software e outros stakeholders, o PO tem a responsabilidade de construir, aprimorar e manter o backlog do time. O backlog é geralmente constituído de novas funcionalidades, porém também contém erros (bugs) e melhorias. Ele é priorizado com base em seu valor para os usuários, tempo de desenvolvimento e outras dependências, que podem ser identificadas na reunião de planejamento de cada Sprint. Saiba mais sobre Backlogs aqui: O que é um Product Backlog?

Planejamento de Sprints: O PO revisa e reprioriza as estórias do backlog como parte do trabalho preparatório da reunião de planejamento de sprint. Isso pode incluir a coordenação e gerenciamento de dependências entre outros times (com outros Product Owners). Durante as reuniões de planejamento de sprints, o PO deve ser a maior fonte de informações sobre o detalhe das estórias e prioridades e tem a responsabilidade de aceitar o planejamento final feito pelo time.

Elaboração de estórias no dia-a-dia: A maioria dos itens do backlog são elaborados e quebrados em estórias para desenvolvimento. Isso pode acontecer antes da sprint, durante a reunião de planejamento ou durante a própria sprint. Qualquer membro do time pode escrever estórias e critérios de aceitação e o PO tem a responsabilidade de manter o processo fluido. Geralmente é bom ter o equivalente a duas sprints em estórias escritas, pois ajuda a manter o ritmo do time em caso de imprevistos. Saiba mais sobre user stories aqui: O que é uma user story?

Auxiliar no BDD (BDD — Behavior Driven Development (Desenvolvimento Guiado por Comportamento): O PO também pode participar no desenvolvimento dos critério de aceitação para estórias. O BDD é uma abordagem que visa focar no comportamento de uma determinada parte do sistema onde se espera atingir um objetivo e geralmente excede os limites da equipe de tecnologia, com uma linguagem de fácil interpretação. Para saber mais sobre o BBD, leia mais aqui.

Obs: anteriormente, eu havia de forma errônea mencionado o TDD como o ponto foco desse parágrafo, obrigado pelo toque Vladson! :)

Aceitando estórias: O PO é o único membro do time que pode aceitar estórias como concluídas.Isso inclui a validação de que a estória possui os critérios para aceitação e tem o testes de aceitação persistentes e apropriados. Fazendo isso, o PO realiza sua função de garantia de qualidade, focando primariamente em produtos prontos para usar.

Entendendo o trabalho de facilitador: Facilitadores são as pessoas que ajudam os implementadores a se concentrar na implementação. Eles se certificam que todos os implementadores estão aptos trabalhar e com o mesmo objetivo, removendo obstáculos do caminho. O PO é o facilitador do time e deve abraçar essa causa para que o time faça um trabalho bem feito.

Participar na retrospectiva e no demo: Como um membro integral do time e o responsável pelos requerimentos, o PO tem um importante papel na reunião de demonstração para revisar e aceitar estórias. Nessa reunião o PO também deve prover feedback para o time e coletar informações para os stakeholders.

O papel do Product Owner em projetos e programas

As iterações (ou sprints) e times servem um propósito maior: realizar entregas frequentes e confiáveis de soluções com valor agregado. Durante o curso de cada iteração, o Product Owner deve coordenar o planejamento com outros Product Owners. Isso é geralmente alcançado através de uma reunião semanal com outros POs para sincronizar as prioridades e dependências.

Nesse caso, o PO também deve ser responsável por criar e manter um roadmap de funcionalidades de alto valor futuras. Assim é possível coordenar as prioridades entre outros POs e stakeholders.

As diferenças entre Product Owner e um Product Manager

Em escala, é impossível que uma pessoa lide com a estratégia de produto e marketing e também se dedique a um time ágil. Por isso, já que o Product Manager e o Product Owner compartilham a autoridade sobre o conteúdo e estórias de cada projeto, é importante haver uma distinção clara dos papéis e responsabilidades de cada um, conforme ilustrado abaixo:

Considerações finais

O trabalho de PO pode ser extremamente cansativo, porém é igualmente satisfatório e enriquecedor. Você pode ter certeza de que vai aprender muito nessa função e a partir daí poderá voar longe. E não se esqueça: procedimentos e processos são ótimos, mas como o próprio manifesto agile diz:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

  • Indivíduos e interação entre eles mais que processos e ferramentas.
  • Software em funcionamento mais que documentação abrangente.
  • Colaboração com o cliente mais que negociação de contratos.
  • Responder a mudanças mais que seguir um plano

Gostou do artigo e quer aprender mais sobre Gestão de Produtos? Acesse: https://skillcore.io/produtodiario e participe de nossa comunidade!

--

--