menu

#SomosTodosPOs

Por

Quem é o PO

Qual a função principal de um Product Owner (PO)? Uma resposta bem sucinta poderia ser: Buscar entregar o máximo de valor no menor tempo possível. Outra representação rápida do papel do PO seria: Maximizar o retorno sobre o investimento. O Scrum Guide™ 2013 (PDF) define que:

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento.

Prefiro sempre estas definições que usam a palavra valor à aquelas que dizem que o PO seria aquele que mantém o backlog do produto. Esta última diz muito pouco sobre a essência de um PO e também é bem menos charmosa 🙂

Somos todos POs

Abstraindo agora o conceito de Product Owner e indo além das definições que o Scrum traz, me parece que todo time que busca construir um produto precisa de uma referencia que guie e traga forma àquilo que se deseja. Logo, acredito também que este papel nesta função é alguém que influencia muito o sentimento de propósito para a realização de algo novo. É um empreendedor que sabe o quê fazer e quando fazer determinadas coisas.


+ Escalando o papel do Product Owner

+ Sua história é uma hipótese… e ai?


Numa organização, seja com 1 ou milhões de colaboradores, todos estão entregando alguma coisa como resultado direto de seu trabalho. O analista pleno II da área de marketing está entregando uma campanha nova ao seu imediato. O arquiteto especialista III está entregando um serviço ao orientar os times sobre uma nova abordagem técnica. A assistente senior bilingue IV entrega relatórios e assessora o vice presidente nas conversas internacionais…

Enfim, todos nós estamos entregando, cada um em seu específico contexto de trabalho, um produto ou serviço que são resultados de nossos esforços diários. Esforços que se traduzem em ações que nós mesmos escolhemos quando e como realiza-las. Priorizamos e buscamos entregar valor para algum cliente, seja ele interno ou externo à organização. Logo, por esta perspectiva: Não seríamos todos nós também Product Owners?

Reflexão: Maximizamos o valor de nossas entregas?

Neste ponto, então, cabe-nos um reflexão interessante: Estaríamos todos nós tão preocupados quanto um PO com nossas próprias entregas individuais? Priorizando-as e remodelando-as a fim de maximiza-las?

Com isso em mente, fiz um pequeno exercício de como seria, na minha visão, a aplicação do conceito de Product Owner aos outros papéis do Scrum:

O ScrumMaster como PO

O grande produto do ScrumMaster é a cultura vigente e seus clientes são tanto o Time de Desenvolvimento e o PO quanto a própria organização em que trabalha. Dependendo do que precisa ser melhorado em seu “produto” o ScrumMaster terá uma lista de ações de mudança que precisará priorizar. Ele se pegará pensando: Qual ação de mudança trará o maior impacto com o menor esforço? Qual comportamento mais importante que se alterado trará o maior benefício ao time? Qual processo que, se melhorado, permitirá potencializar as entregas do Time de Desenvolvimento?

E assim como o PO, o ScrumMaster pode se encontrar, se não refletir e tomar cuidado, numa posição de “tirador de pedidos”. É a secretária do Time de Desenvolvimento. Se acontece o mesmo problema 18 vezes, ele resolve as 18, mas não busca otimizar seu tempo e analisar a causa-raiz do problema a fim de não ter mais que lidar com isso. Ou ainda, é um profissional reativo, que não está constantemente em busca de entender a cultura e criar ações de mudança significativas. É equivalente ao PO que mantém um produto sempre do mesmo jeito, sem inovação e sem melhorias. Não ouve as dores do cliente e, portanto, não agrega valor.

O Time de Desenvolvimento como PO

Há muitas formas do Time de Desenvolvimento incorporar conceitos de PO em seu dia a dia. Uma das que eu mais admiro é discutir e tentar maximizar a quantidade de trabalho não-necessário. É sentir-se parte da construção do produto e não a “pastelaria do PO”: que já traz já a solução sobre como pretende resolver os problema. Ao permitir a “pastelaria” o Desenvolvedor se coloca na posição de executor e não contribui para a maximização do valor.

Outra forma de ser mais PO no Desenvolvimento é analisar o trabalho a ser feito e atacar aquelas tarefas que sejam dependentes de outros times ou que contenham o maior risco de não ser aquilo que fora planejado. Desta forma o Time de Desenvolvimento trabalha minimizando riscos, antecipando mudanças e garantindo as entregas.

E você. Outra ideias sobre como ser mais PO em outras funções?

3 comments

  1. Elderclei Reami

    Mestre Buzon,

    Achei muito interessante suas colocações e acho que são muito pertinentes. Ownership é parte de ser profissional no que faz e é parte fundamental para criar um ciclo virtuoso de melhoria contínua. De outro lado, prefiro não envolver o termo PO nesta discussão, uma vez que ele já é vago e confuso o suficiente sem criarmos outras acepções para o mesmo.

    Tudo isto posto: “Let’s all be owners of our crafts!”

    Abraço.

    Posted on julho 23, 2014
  2. Rafael Buzon

    Grande Elderclei,

    Obrigado pelos comentários.
    Queria ouvir um pouco mais sobre essa confusão do papel do PO. Acha que é vago propositalmente ou o contexto o faz vago?

    Grande abraço,

    Posted on julho 23, 2014
  3. Ciro Verdi

    Isso ai Buzon,

    Todos no time precisam ter postura de dono e contribuir para maximizar o resultado.

    Abs!

    Posted on julho 24, 2014

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top