“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.
O que não gosto – e já experimentei acontecer – de ter dois PO’s em um mesmo produto, é, principalmente, a falta de responsabilidade. Responsabilidade no caso de “se algo der errado a quem apontar o dedo?”. Isso faz com que o Time de Desenvolvimento não saiba para quem deverá tirar dúvidas.
Na minha opinião, o dito “PO Proxy” poderia ser um stakeholder, uma parte interessada, que, quando fosse apresentado o incremento na Revisão da Sprint, pudesse avaliar melhor pelo ponto de vista do negócio e dar sua opinião. Isso motivaria mudanças e adaptações, que seriam discutidas na Retrospectiva da Sprint e no Planning, direcionando o desenvolvimento para um rumo certo.
CurtirCurtir
Obrigada pelo Comentário Pedro! Concordo 100% contigo.
CurtirCurtir
Oi Pedro, obrigada pela Leitura.
Dois PO’s para um mesmo time, não funciona e nunca funcionou (tem algumas excessões aqui, quando pensamos a nível de maturidade ou tendo uma squad completa).
O Artigo ele fala sobre Diretores/Gerentes que querem / queriam ter o papel de PO dentro dos projetos, por ser algo da moda, e a falta de entendimento dos direitos e deveres de um PO, então eu sugeria ter um PO Linha, que seria efetivamente o PO, sendo o Diretor / Gerente um aprovador.
CurtirCurtir