O que um Product Owner precisa saber?

Índice Show

O dia-a-dia do Product Owner
As responsabilidades do Product Owner
O papel do Product Owner em projetos e programas
As diferenças entre Product Owner e um Product Manager
Considerações finais
O que preciso saber para ser Product Owner?
O que um Product Owner deve fazer?
O que é mais importante para um Product Owner?
O que o Product Owner não deve fazer?

O Product Owner representa os interesses de todos os envolvidos (Stakeholders), define as funcionalidades do produto e prioriza os itens de Product Backlog.

Conjuntos de Funções: Time Scrum

Relacionamentos

Descrição Principal

O Product Owner tem as seguintes responsabilidades:

Definir as funcionalidades do produto (Backlog do Produto);
Priorizar as funcionalidades de acordo com o valor de negócio;
Ajustar funcionalidades e prioridades a cada Sprint, conforme necessário;
Garantir que o Backlog do Produto seja visível, transparente e claro para todos;
Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário;
Decidir a data de liberação e conteúdo do Release; e,
Aceitar ou Rejeitar os resultados de trabalho.

O Product Owner é o maior interessado nos eventos de Preparação e Reunião de Planejamento da Sprint. A participação dele é essencial, pois no primeiro o Backlog do Produto é definido e priorizado, enquanto que no segundo cada item do Backlog do Produto é esclarecido e estimado de modo que possa ser selecionado para o desenvolvimento.

O Time Scrum analisa a priorização dos itens do Backlog do Produto, refina os itens a partir da prioridade e se compromete a finalizá-los durante a Sprint. Esses itens tornam-se parte do Backlog da Sprint.

Em retribuição ao comprometimento do Time Scrum em completar/finalizar as tarefas selecionadas, o Product Owner se compromete a não impor novos requisitos ao time durante a Sprint. É permitido alterar os requisitos, mas apenas fora da Sprint. Uma vez que o time inicie o Sprint, deve-se buscar atingir a Meta da Sprint (Sprint Goal).

Criação da Equipe

Abordagens da Designação

Único para um Time de Scrum, pois deve haver apenas um foco de decisões sobre o produto para o Time de Desenvolvimento;
Disponível para colaborar com o Time de Desenvolvimento, para estar presente nas reuniões do Scrum em que sua presença é obrigatória, para interagir com os clientes e demais partes interessadas, e para manter e priorizar o Backlog do Produto;
Competente para a definição do produto, com conhecimento e poder suficiente para tomar decisões rápidas e adequadas;
Pode ser um representante do cliente ou um procurador do cliente.

A Escolha do Product Owner

A escolha mais comum para Product Owners em projetos de desenvolvimento de software se dá entre o próprio cliente ou um representante indicado por ele.

Esse é um papel que exige disponibilidade e colaboração. Mesmo que esse Product Owner do cliente possua os conhecimentos e habilidades necessários, é bem possível que ele não possua tempo disponível para executar o seu papel, pois provavelmente estará envolvido em outras questões de seu próprio dia a dia de trabalho no cliente. Isso pode prejudicar sua relação com o Time de Desenvolvimento e o andamento do projeto.

Nesses casos, recomendamos fortemente, que o Product Owner seja designado pela própria organização ou grupo contratado para gerar o produto. Deve ser alguém formado para tal, com as habilidades e conhecimentos necessários. Ele realizará seu trabalho a partir do contato frequente com os clientes do projeto e com as demais partes interessadas, balanceando as necessidades das partes interessadas, mas tomando decisões alinhadas com ou em direção aos objetivos da sua própria organização.

Lembro que, para ser de fato um Product Owner, essa pessoa deve ter a autoridade para tomar as decisões necessárias sobre o produto. Ou seja, mesmo que não seja alguém do cliente, o Product Owner é sempre quem de fato define o produto.

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? Que tal me dar uma força no: https://skillcore.io/produtodiario

O que preciso saber para ser Product Owner?

Para atuar com produto é imprescindível ter conhecimentos em metodologias ágeis, ser analítico, ter conhecimento de ux e tecnologia, saber delegar tarefas e cobrar resultados, e principalmente conhecer todas as fases de desenvolvimento de um produto.

O que um Product Owner deve fazer?

O Product Owner tem as seguintes responsabilidades:.

Definir as funcionalidades do produto (Backlog do Produto);.

Priorizar as funcionalidades de acordo com o valor de negócio;.

Ajustar funcionalidades e prioridades a cada Sprint, conforme necessário;.

O que é mais importante para um Product Owner?

O Product Owner deve se comprometer com o projeto, a visão e os negócios. Deve estar presente em todas as reuniões, trabalhar com todos os membros da equipe e garantir o sucesso da gestão.