InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

O Product Owner deveria ser somente Uma Pessoa?

Postado por Amr Elssamadisy , traduzido por Flávia Castro de Oliveira em 18 Fev 2009

Seções
Processos e Práticas
Tópicos
Técnicas Ágeis ,
Agile ,
Agile nas empresas
Tags
Scrum

Há uma importante discussão acontecendo na lista ScrumDevelopment. Há uma dúvida sobre o papel do membro mais importante do time - o product owner. Jean Richardson começou a conversa com a seguinte questão:

Eu estou trabalhando com um cliente que é novo em Scrum. Até agora, eles estão muito anciosos. Nós tivemos e estendemos lições aprendidas na semana passada em um ½ projeto difícil e eles vêem Scrum como a resposta para suas preces. O seu gerente leu /Gerenciamento de Projetos Ágeis com Scrum/, e um dos membros do time está na metade do livro.
Entretanto, o gerente pediu uma reunião comigo no final desta semana em relação a “quem seria o Product Owner.” Eu acho que seu time está empurrando-o para compartilhar esse papel entre todos eles—ou ao menos 3 deles (ele próprio e mais dois). Então, minha questão é, como é que funciona compartilhar esse papel através de duas ou mais pessoas. Será que isso funciona bem? Se sim, o que é preciso para que isso funcione bem? Que tipos de coisas você vê acontecendo?

Isto é, evidentemente, uma questão ou ocorrência comum.  A maioria dos conselhos caiu em duas áreas:

Área 1: Você deveria ter somente um product owner.  Por exemplo, Dan Rawsthorne sugeriu:

Eu sempre tenho uma resposta simples para "quem será seu product owner". Eu pergunto: "quem deve ser responsável pelo sucesso? Quem tem um alvo em suas costas? Esse é o seu product owner." Na minha experiencia, o PO é normalmente ungido em seu exterior.

Isso trouxe uma série de observações interessantes, uma das quais evocando uma inconsistência na maneira que o product owner é tratado e percebido:

No entanto, isso não traz à tona uma dicotomia interessante para o Scrum? Se o PO é o único com a corda no pescoço da perspectiva de requisitos/ROI, por quê não há uma única pessoa com a corda no pescoço da perspectiva do time?
Eu pergunto porque eu já tive inúmeras conversas com os doutores do Scrum que apontam a falta de responsabilidade no time. Enquanto o time é responsável por tornar-se auto organizado e finalmente fazer o que precisa ser feito, não há nenhuma corda no pescoço quando eles não o fazem. Eu tenho visto os times lutando para se tornar auto organizados. Alguns nunca tem sucesso. É difícil de responsabilizar o time inteiro, especialmente quando muitos membros fazem o seu melhor.

Área 2: No front do "isso depende", o comentário de George Dinwiddie foi exemplar:

Sim, isso pode funcionar bem e ainda dividir a carga de trabalho entre os três. Isso também pode ser um desastre. Eu vi os dois.

Eles compartilham a mesma visão do projeto? Se não, qual a visão que os desenvolvedores tem?

Todos os três podem trabalhar na sala com os desenvolvedores? Se não, isso é uma bandeira vermelha para mim.

Os três podem tomar decisões rápidas juntos? Se não, acho que não irá progredir.

Eles podem "falar como uma só voz?" Se não, quem os desenvolvedores vão seguir?

Quando eles discordarem, tem uma maneira segura de resolver o conflito? Se não, quem os desenvolvedores vão seguir?

Para responder adequadamente a questão, deve existir um acordo sobre qual o papel e quais as responsabilidades reais de um product owner. É ser o 'único pescoço em jogo'? Será que as responsabilidades são muito mais abrangentes de forma que não possam ser cumpridas em um grande ambiente? Quais são seus pensamentos e experiências?

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.