O que faz e como é a vida de um Product Owner

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.

Você como Product Owner puxando a demanda para o lado certo.
Você como Product Owner tentando puxar a demanda para o lado certo.

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 a seguir.

Refinamento do Backlog:

Pesquisa

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 dependências, que podem ser identificadas nas reuniões de planejamento.

Planejamento de Sprints

Configuração

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:

Escrevendo estórias

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 o PO tem a responsabilidade de manter esse processo constante. Por esse motivo é uma boa ideia ter o equivalente a duas sprints em estórias escritas, isso ajuda a manter o ritmo do time em caso de imprevistos.

Auxiliar no Test-Driven Development:

Garantir a garantia de qualidade

O PO também pode participar no desenvolvimento dos critério de aceitação para estórias. Test Driven Development (TDD) é uma técnica de desenvolvimento de software que baseia em desenvolver código prontos para testes desde o princípio. Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis. Saiba mais sobre Test-Driven Development aqui.

Aceitando estórias

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.

Trabalhando como um facilitador:

Tiro ao alvo

Facilitadores são as pessoas que ajudam os implementadores a se concentrar na implementação. Eles se certificam de 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 seu trabalho.

Participar na retrospectiva e no demo:

Demonstração

O PO é  um membro integral do time e responsável pelos requerimentos. Por isso, deve revisar e aceitar estórias na reunião de demonstração. 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

É impossível apenas um profissional ser responsável pela estratégia de produto, marketing e a de um time ágil. Por isso, é importante haver uma distinção clara dos papéis e responsabilidades de cada um desses profissionais:

Matriz de definição de responsabilidades

Leia mais sobre alguns mitos a profissão de Gerente de Produtos aqui

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

Gerente de Produto, Empreendedor e podcaster @_nadacontece. Apaixonado pela criação de produtos novos e excitantes.

Leave a reply:

Your email address will not be published.