domingo, março 01, 2009

Product Owner em crise de identidade

Recentemente, num intervalo de poucas semanas, diferentes pessoas me fizeram a mesma pergunta: o Product Owner é MESMO um Pig? Tem certeza? Adicionalmente a isto, tenho visto que grande parte dos clientes que visito, e que já "utilizam" Scrum por algum tempo, sempre me apresentam a mesma queixa "Usamos Scrum, mas o papel de Product Owner não está funcionando bem!" - ou algo do gênero.

Em várias discussões na lista Scrum-Brasil durante o ano passado, eu, o Rodrigo Yoshima e outros, discutimos bastante sobre o papel do Product Owner. O foco da discussão era: O P.O. deve ser do cliente ou do fornecedor? E ao final dela acho que ficou claro a todos os envolvidos que isso depende de vários fatores, mas que ambas as opções são aceitas. Nesta discussão mencionei que, principalmente num momento inicial de adoção de Scrum, meu grande medo de ter o cliente como P.O. era de, com isso, ter um P.O. apenas envolvido com o projeto - e não comprometido, ou seja: um Chicken! E ter um Product Owner "Chicken", para mim, é o primeiro passo para o fracasso com Scrum. Com efeito, o Rodrigo chegou até a usar a seguinte frase "Um PO Chicken é uma aberração para Scrum".
Quase um ano depois (talvez menos) vejo que há uma grande quantidade de Chickens atuando no papel de Product Owner, e, para minha surpresa, isso vem acontecendo mesmo em ambientes em que o P.O. é do fornecedor.

Minha pergunta é: ScrumMasters, por que vocês não estão educando o Product Owner de seus projetos de forma a fazê-los trabalhar como um Pig? Lembrem-se, vocês são os responsáveis por fazer o processo funcionar...e ter um Product Owner comprometido é vital para o processo funcionar!

Vamos relembrar algumas das responsabilidades do Product Owner:
- Definir a Visão do produto.
- Apresentar um Product Backlog P-R-I-O-R-I-Z-A-D-O, de acordo com o que realmente é importante para o cliente naquele momento.
- Pensar e agir sempre com os olhos no RoI (Return of Investment).
- Participar S-E-M-P-R-E das Reuniões de Planejamento e das Reviews.
- Apresentar ao time a meta de negócio para aquela Sprint.
- G-A-R-A-N-T-I-R que pessoas que conheçam os detalhes do negócio (Analista de Negócio? Esp. Domínio? Etc?) estejam disponíveis para o time no decorrer da Sprint.
- Tomar decisões.
- Gerenciar as entregas.
...dentre outras coisas.

Agora, o que não é um Product Owner:
- Um organizador de to-do list.
- Um garoto de recados entre fornecedor e cliente.
- Alguém que é chamado de P.O. pelo time, mas que nem sabe que está atuando neste papel (Por que eles me chamam de P.O.? Meu nome nem é Paulo Otávio)...e se soubesse não faria muita diferença, pois não foi educado para atuar como tal.
- Alguém não comprometido com os interesses do cliente.
- Uma pessoa que prioriza um Product Backlog como se estivesse brincando de Lego.
- Alguém que não respeita o Time.
- Alguém que não conhece Scrum.
...dentre outras coisas.

Como já disse, ter um Product Owner comprometido é extremamente importante para Scrum...então pense nisso! Vejo empresas focando em tantas coisas "Agile" ao mesmo tempo que, sequer, possuem o papel de Product Owner funcionando efetivamente...isso não é ser mais "ágil", mas sim ser mais "frágil".

4 comentários:

Rafael de F. Ferreira disse...

O Jeff Patton escreveu um artigo ótimo sobre o papel do PO:
http://agileproductdesign.com/blog/2009/product_owner_and_problem_shaped_hole.html

Achei especialmente interessante a observacão que a literatura agile é esparsa em práticas para ajudar o PO.

Jordano Gonzatto disse...

Alexandre, muito pertinente seu comentário. Estamos enfrentando dificuldades aqui em nossa empresa quanto a essa questão, minha dúvida é quando o PO é ativo demasiado, explosivo e quer ver as coisas acontecendo rapidamente e não espera o tempo da equipe, como agir nesse caso?
att

felipespsousa disse...

fui indicado pelo pellegrino para ler esse artigo que cabe direitinho o que está acontecendo em minha equipe...

Obrigado por nos refrescar a mente.

Abs

Luciano Henrique disse...

Olá Alexandre,

Gostei muito do blog e como foi bem explicado, acho que os conceitos servem de referência sim. Uma coisa que deve ser feita e coloca de forma bem clara os objetivos a serem obtidos.
Aquelas coisa que muita empresa não passa, que muitos funcionários não sabem se quer a visão e missão da empresa em que trabalha.

Acredito que para pequenos projetos é complicado não o PO um stackhold do projeto. Em ambientes web como trabalho, sempre trabalho com os Product Owner vindo do cliente. Já tive problemas mais com experiências passadas agente procura diblar e para a próxima produção nós podemos produzir um resultado cada vez melhor.

Acho que podem falar em sorte, mas tive mais pontos positivos do que negativos.

Acho que o que importa mais é o ROI para ambos (cliente/contratado).

Um abraço e aguardo curso de SCRUM MASTER aqui em RECIFE.