Me tornei um Product Owner, e agora?
Lembro do dia em que aceitei me tornar um Product Owner (PO) na Empiricus. O head de e-commerce me convidou para assumir esse papel devido ao meu conhecimento do negócio, e porque eu já vinha atuando em projetos de lojas virtuais nos últimos anos.
Na época eu já tinha noção dos desafios deste papel por ter trabalhado em empresas que utilizavam metodologias ágeis, e por ter feito alguns cursos do framework Scrum, mas percebi ao longo do tempo que muitas pessoas não tinham clareza sobre o que significa ser um PO.
O que é um Product Owner e o que ele faz?
O PO é o membro de um time ágil que cuida do produto, definindo e priorizando o backlog, e o seu principal objetivo é ser a ponte entre o time de negócios e o time de desenvolvimento. Ele é também responsável por manter a integridade conceitual de novas funcionalidades, bugs ou melhorias, sempre seguindo a visão definida na estratégia do negócio.
“O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento. Como isso é feito pode variar amplamente através das organizações, times scrum e indivíduos.” — Scrum Guide
Como é estruturado um Backlog?
De forma geral, um backlog é uma “lista de pedidos” em espera, e o PO precisa mantê-la atualizada para facilitar o planejamento e a priorização dos itens que entrarão em cada iteração/sprint/ciclo. Os pedidos podem ser funcionalidades, defeitos ou melhorias solicitadas tanto pelo negócio quanto pelo time de tecnologia.
Semanalmente fazemos reuniões de refinamento de para priorizar os itens desta lista e também otimizar as histórias de usuário já cadastradas. Recentemente publicamos um artigo aqui no blog que apresenta ferramentas interessantes para organizar e priorizar o seu backlog.
O que é uma história de usuário e porque é utilizada?
Para responder essa pergunta vamos quebrar o significado em duas partes:
- Uma história neste contexto é uma “narrativa de ficção, oral ou escrita”
- Um usuário é uma persona que faz uso de um sistema ou que participa de um processo.
Histórias descrevem o funcionamento de um produto, e podemos dizer de forma macro, que uma história de usuário é uma narrativa escrita sobre a utilização de um sistema.
Cada user story tem um formato simples no qual narramos o contexto da necessidade/funcionalidade, o que precisa ser feito e os seus critérios de aceitação. Exemplo:
Contexto:
Como <tipo de usuário>, quero <algum objetivo> para que eu possa <algum motivo>.
Critérios de aceitação:
- Entregáveis precisam ter o formato PDF;
- Ao clicar no botão QUERO COMPRAR, a página precisa ser redirecionada para a seguinte URL;
OK! Já sei o que é um backlog e uma user story, mas o que mais um PO faz?
Uma outra responsabilidade do PO é cuidar da qualidade do produto, ou seja, ele é a figura do time ágil que aceita ou rejeita o desenvolvimento feito na sprint. Um produto com histórias bem escritas e bem priorizado tem altas chances de sucesso. O PO também participa de praticamente todos os momentos e cerimônias dentro de uma sprint, e eu abordarei isso no próximo tópico.
A minha rotina de PO na Empiricus
Geralmente cada sprint tem 2 semanas, e no primeiro e último dia realizamos alguns eventos (chamados de cerimônias) importantes.
No primeiro dia executamos um planejamento (planning) para cada projeto do squad. É neste momento que apresentamos as histórias para o time e estimamos o tempo necessário para deenvolvê-lo. Nós usamos a técnica de planning poker para estimar. Em seguida, eu me junto ao head do squad para validar a capacidade, e é nesse momento que geralmente retiramos do escopo as atividades menos prioritárias que não couberam na iteração.
No último dia executamos a retrospectiva da sprint, e neste momento todo o time discuti sobre “o que foi bom” na última iteração e “o que podemos melhorar” na próxima. Listamos também as “ações” que tomaremos em resposta às nossas principais dores. (eu escreverei um outro post sobre esse tema futuramente).
Nos outros dias da sprint executamos o nosso “daily meeting”, que é um evento do Scrum onde cada membro do time expõe “o que fez ontem”, “o que vai fazer hoje” e “se possui algum impedimento”.
Segue abaixo um exemplo do meu posicionamento na daily:
“Ontem eu escrevi as histórias do hotsite institucional do Empiricus Rewards”.
“Hoje nós vamos refinar as histórias que foram solicitadas pelo time de disparos”.
“Não tenho impedimentos”.
Ao menos 1 dia da semana, geralmente as quartas-feiras, fazemos uma reunião de refinamento de histórias e planejamento do roadmap dos projetos e produtos.
Como PO, eu cuido e prezo muito pela qualidade das entregas. Sempre que uma atividade é entregue e revisada pelo membro do time que cuida do QA (Quality Assurance), eu faço o double check e aceito ou não a história. Geralmente quando não aceito, eu volto com um comentário de uma possível correção ou sobre o que não bateu no critério de aceite.
É comum não ser tão assertivo na descrição de contexto ou se esquecer de algum critério de aceitação, principalmente quando você está começando a atuar em um projeto/produto. É exatamente por isso que realizamos as reuniões de refinamento e planejamento, visando a eficiência e evitando retrabalhos.
Enfim ou finalmente…
Meus caros leitores que chegaram até aqui, desde já agradeço a paciência. Quero dizer que se você está pensando em se tornar um Product Owner saiba que não é um bicho de sete cabeças. Como todo trabalho é preciso dedicação, comunicação e muito zelo pelos produtos e projetos que você irá cuidar. Refine bem as suas histórias, seja muito comunicativo com os times de negócio e de desenvolvimento, e seja crítico com os aceites de entregas porque isso impactará a experiência fornecida na jornada do usuário.
Obrigado a todos e um excelente 2021!
Até a próxima.
