“O Product Owner é aquele que determina as metas e conduz o time na entrega constante de valor” (Cohn, 2009, Succeeding with Agile)
Recentemente assumi um projeto (iniciado a 3 meses por um fornecedor em metodologia tradicional), e projeto apresentava a cada status report a dependência/premissa de ter declarado o PRODUCT OWNER, mas neste caso leia-se dono do projeto, a pessoa que aprova ou não as entregas.
Para o fornecedor essa pessoa deveria ser alguém da área de negócios, e por isto foi apontado um gerente de uma área de negocio, que além de todas as suas atividades diárias ele deveria também tocar as atividades deste projeto (o profissional atribuído a este papel deveria estudar o produto, testar conceitos e construir o produto).
O Scrum Guide , uma das referências do assunto, descreve o PO como:
“É o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. (…)
Sendo o “Product Owner uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.”
Cerejinha do bolo, este projeto possui duas áreas de negócios envolvidas (Limão e Laranja e por este motivo não será possível UM Product Owner.
Qual a probabilidade destes DOIS gerentes quererem assumir mais uma função, com uma parte da atividade que eles desconhecem, de um projeto já iniciado e que ele não tinha conhecimento do escopo que foi fechado?
O PO neste cenário é o que chamamos de “cliente”, ele tem noção do que o produto precisa solucionar, mas não tem conhecimentos técnicos para realizar testes, cuidar da evolução do produto e dar diretrizes para o time (pensando na questão técnica), principalmente, sendo dois clientes com objetivos distintos dentro do produto.
Quando me coloquei a par do projeto sugeri trazer uma “nova” função/papel para o projeto, um PO LINHA (tem quem conheça essa função como PO Proxy), essa pessoa tem o perfil de um analista de negócios/requisitos que prepara todo o material (escreve user stories (traduz as necessidades do cliente – E ELE É TIME!), deixa as estórias em critério de ready para inicio da Sprint, declara os critérios de aceite das histórias, faz a ponte com o time) tudo isto em conjunto com os Product Owners do projeto, neste caso os gerentes das áreas de negócio.
Esse caso que estou contanto é recente e tem 10 dias que se iniciaram as atividades e venho contar aqui as evoluções de 2 semanas:
– O Product Owner consegue tocar todas as suas atividades diárias e o projeto não é considerado um peso (declaração do próprio PO)
– O PO linha já apresentou as regras de negócio para a primeira Sprint para que o Product Owner valide e dê o seu de acordo (DOR/DOD) e já estamos trabalhando nas histórias de 2 Sprints a frente.
Já é uma prática de mercado utilizar canvas para obtenção de dados para o que quer que seja, já vi scrum team canvas, machine learning canvas… Tem Canvas para todos os gostos. O canvas acabou caindo no gosto dos analistas, product owners e demais profissionais do mercado porque facilita o entendimento de todas as partes e direciona um brainstorm, por exemplo.
Priscila Chagas 