1. Framework LeSS
  2. Product Owner

Product Owner

Conceitualmente o papel do Product Owner no LeSS é idêntico ao Scrum com uma única equipe. Entretanto, ao escalar, o foco muda levemente para uma visão mais abrangente e de garantia da obtenção do máximo de retorno sobre o investimento (ROI) do produto.

Product Owner Escalado

É comum no desenvolvimento de produtos em grande escala que pessoas diferentes conduzam visões e direções diferentes e que as equipes sejam distribuídas dentro de cada visão. Manter um único Product Owner com foco em um único produto suporta o foco em todo o produto.

Em grupos de produtos tradicionais de grande escala, há um grupo (muitas vezes os gerentes de produto) que se concentra pensando em uma visão abrangente do produto e um grupo (geralmente os desenvolvedores) que se concentra pensando em detalhes do produto - e os dois nunca ou pouco interagem. No LeSS, um único Product Owner possui tempo livre para focar nos clientes (visão abrangente) e suas prioridades enquanto também está disponível para pensar em detalhes do produto junto com as equipes. Ele atua como um conector, trazendo equipes e clientes/usuários juntos para que as equipes tenham cada vez mais foco no cliente.

Em contraste com outras abordagens de Scrum escalado, é possível escalar o papel do Product Owner dentro do LeSS com apenas uma pessoa, de forma efetiva, pois existem menos papéis, menos posições e menos complexidade.

Priorização mais que Esclarecimento

Existem duas etapas-chave de informações no Scrum relacionadas ao Product Owner: (1) priorização (ordenação) de itens no Product Backlog e (2) esclarecimento de itens do Product Backlog. Na primeira etapa (priorização), informações relativas aos geradores de lucro, clientes estratégicos, riscos de negócios e outros interesses de negócio são pesquisadas e analisadas. Na segunda etapa (esclarecimento), a informação é pesquisada para detalhar o comportamento e qualidade dos itens, experiência do usuário e outras preocupações sobre design de funcionalidades.

Um Product Owner LeSS concentra-se em pensar seriamente sobre priorização, mas colabora com as equipes no esclarecimento. Além disso, ele incentiva e ajuda as equipes a conversarem diretamente com os usuários e clientes diretos para esclarecimentos. Ele age como um conector, e não um intermediário.

Por que enfatizar a interação direta entre equipes e clientes/usuários? As razões incluem : (1) evitar a perda de informações nas transições do produto para operação, (2) promover a cocriação de soluções para os problemas reais dos clientes, e (3) melhorar a motivação e empatia dos clientes por terem os desenvolvedores colaborando com eles diretamente.

É interessante notar que, quando as equipes fazem a maior parte do trabalho de esclarecimento, o Product Owner tem mais tempo e energia para se concentrar no produto, priorizando continuamente e explorando novas e estratégicas oportunidades.

Encontre um Product Owner Para o Seu Tipo de Desenvolvimento

Passo 1: Conheça Seu Tipo de Desenvolvimento

Encontrar o Product Owner certo depende do tipo de desenvolvimento que você está fazendo:

  • Desenvolvimento de produto—Para clientes externos ou mercado.
  • Desenvolvimento (produto) interno—Para um ou mais usuários da empresa. O grupo de desenvolvimento geralmente é chamado de Desenvolvimento de TI ou Sistemas.
  • Desenvolvimento de projeto—Geralmente para um único cliente externo. O trabalho é organizado e contratado como um projeto, o que não necessariamente significa que é um contrato de escopo/tempo/custo fixo. A empresa de desenvolvimento geralmente é uma empresa terceirizada ou uma integradora de sistemas. O cliente, ou a empresa do cliente, inclui um departamento de compras e os usuários, que nem sempre estão no mesmo departamento.

Passo 2: Encontrando o Product Owner Certo

Desenvolvimento de produto—A empresa terá que: (1) ter uma unidade de negócios conduzindo a iniciativa de produto, ou (2) ter um departamento de Gestão de Produtos conduzindo a iniciativa. Uma Gestão de Produtos tradicional é responsável por analisar os clientes e os concorrentes, a visão de produto, detalhamento, seleção e priorização de funcionalidades de alto nível, e outras atividades não-técnicas. Não há o gerenciamento do trabalho de um grupo tradicional de desenvolvimento.

Onde encontrar um Product Owner para um grupo que está adotando LeSS? Se houver um departamento de Gestão de Produto, então um gerente de produto pode ser uma boa escolha. Caso contrário, procure uma pessoa da unidade de negócios que está conduzindo a iniciativa. Algo importante para se ter em mente é que o Product Owner selecionado para o desenvolvimento do produto deve vir da área relacionada ao negócio.

Desenvolvimento (produto) interno—Um bom Product Owner para desenvolvimento interno de produto interno no LeSS está (1) dentro do grupo que vai usar o sistema, e (2) está intimamente envolvido, e é profundamente experiente, no trabalho real que o sistema irá suportar. Este está muito próximo dos usuários reais.

Desenvolvimento de projeto—O ponto-chave para o desenvolvimento do projeto é que o Product Owner seja da empresa contratante do sistema. Tal como acontece com o desenvolvimento interno, ele deve estar envolvido, e ser profundamente experiente, nos trabalhos do dia a dia que o sistema irá suportar, e estar próximo dos usuários.

Uma variante comum para tanto para desenvolvimento interno quanto para desenvolvimento de projeto, é quando o sistema for usado por muitos departamentos. Então, uma boa escolha é um experiente indivíduo do dia a dia de um dos principais departamentos dos usuários, que esteja interessado em assumir o papel e possua habilidade política.

Em todos os casos, um grande Product Owner tem uma paixão para o produto.

Quando não for possível encontrar o Product Owner ideal imediatamente, você pode rapidamente começar a adoção do LeSS com um Product Owner temporário que entende o que está acontecendo e pode executar a mecânica do papel, mas não não pertence ao lado do negócio. Deixe que as equipes completem várias Sprints com o Product Owner temporário até que grandes itens sejam trabalhados e - isto é importante - as equipes de desenvolvimento possam entregar um incremento de verdadeiramente ‘Concluído’ e lançável (ou potencialmente lançável) a cada Sprint. Por que? As equipes de produto provavelmente se sentirão mais estimuladas a encontrarem o Product Owner ideal para o longo prazo, se eles conseguirem visualizar novas funcionalidades atraentes que oferecem benefícios de negócio tangíveis. É extremamente importante que todos entendam que o Product Owner temporário é apenas uma solução paliativa. Muitas vezes usamos o termo “fake Product Owner” para indicar o quão prejudicial pode ser ter um Product Owner temporário.

Passo 3: Dê Autoridade e Responsabilidade a um Real Product Owner

Product Owner não é um novo nome para um gerente de projeto tradicional, que oferece um contrato de escopo e prazo de trabalho. Em vez disso, um Product Owner deve ter a autoridade independente para escolher e mudar o conteúdo, datas de lançamento, prioridades, visão, etc. É claro que ele colabora com as partes interessadas, mas um verdadeiro Product Owner tem poder de decisão final.

Cinco Relacionamentos

O Product Owner precisa entender e trabalhar para melhorar cinco relacionamentos-chave que são afetados pela adoção do LeSS:

  • Product Owner<–>Equipes
    As equipes devem ajudar o Product Owner a criar o melhor produto possível para os clientes. Elas precisam saber o que deve ser construído e se irão atingir as metas ou não. O Product Owner precisa saber do que as equipes precisam e como ele pode ajudá-las.
  • Product Owner<–>Clientes
    O Product Owner e as equipes estão tentando criar o melhor produto possível para os clientes. Os clientes precisam saber quando eles terão as funcionalidades que eles desejam e, talvez, o raciocínio por trás das prioridades. Envolvê-los, tanto quanto possível, gera transparência. O Product Owner precisa conhecer os reais objetivos e problemas deles (ou imaginar algo além de suas visões) e recolher as informações que irão ajudá-lo a priorizar corretamente.
  • Equipes<–>Clientes
    As equipes estão tentando criar o melhor produto possível para os clientes. Elas precisam saber o contexto das funcionalidades e ter um detalhado domínio de conhecimento. Idealmente, as equipes cocriam soluções diretamente com os clientes identificando de forma efetiva (em vez de superficial) metas essenciais e problemas dos clientes. As equipes precisam confirmar com os clientes que eles compreendam plenamente os requisitos que estão esclarecendo juntos.
  • Product Owner<–>Alta Gestão
    A alta gestão, além do grupo de produtos (gestores de carteira, executivos C-level, etc.), deve enxergar o Product Owner como alguém que presta contas e possui responsabilidade final sobre o sucesso do produto. Ele é responsável por tornar o status do desenvolvimento visível e realizar o desejo da alta gestão (muitas vezes implícito) otimizando os impactos desejados (por exemplo, ROI e market share). O Product Owner, com o apoio dos Scrum Masters, engajam a alta gestão para ajudar a melhorar a estrutura organizacional.
  • Product Owner<->Scrum Masters
    As relações acima estão diretamente relacionadas com a “propriedade do produto”, mas esta é diferente. Está relacionada com o conhecimento e o comportamento do Product Owner. Os Scrum Masters precisam conhecer as preocupações, dúvidas e obstáculos do Product Owner para que eles possam ajudar. Um bom Scrum Master pode ser um ouvido amigo ou um ombro para chorar. Os Scrum Masters devem educar e fornecer feedback para que o Product Owner possa evoluir.

Cerimônias LeSS

Quando introduzimos o LeSS, uma pergunta frequente é: “Como é um Product Owner irá gerenciar todas essas reuniões com todas essas equipes?” Felizmente, a preocupação por trás dessa questão é baseada em um mal-entendido. O único Product Owner do LeSS participa apenas das reuniões onde todas as equipes participam juntas. E a quantidade de membros das equipes nessas reuniões é administrável. Se houver apenas duas equipes, todos podem efetivamente assistir e participar. Se houver muitas equipes, apenas dois representantes de cada equipe podem participar.

Quais cerimônias LeSS o Product Owner deve participar e qual a duração média destas cerimônias com base em uma Sprint de duas semanas?

Assim, o tempo total gasto nas cerimônias LeSS dura, em média, cerca de oito horas em uma Sprint de duas semanas.

O Product Owner não precisa comparecer nas seguintes cerimônias específicas das equipes: Planejamento de Sprint - Parte 2, Daily Scrums, Refinamento do Product Backlog das equipes, Retrospectiva das equipes.