BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Sendo um Product Owner melhor

por Mike Bria , traduzido por André Pantalião Ferreira em 10 Mar 2009 |

Qualquer um que passou algum tempo efetivamente executando um projeto ágil pode comprovar o fato que a colaboração do Product Owner (ou, no XP, o "Cliente") com o time de desenvolvimento desempenha um papel chave no sucesso de um time. Peter Stevens oferece um pequeno conselho para ajudar pessoas nesse papel desempenharem bem.

Um Product Owner (ou igualmente, em termos XP, um "Cliente") indiscutivelmente tem um dos trabalhos mais duros em um projeto ágil. Para fazer bem este trabalho, eles devem se manter ativos e relevantes em seus domínios ("manter seus trabalhos diários") enquanto ainda permacendo um membro ativo, participativo, colaborativo de seu time de desenvolvimento ágil. Não é incomum o Product Owner ter tempos difíceis gerencianto isto bem, e como um resultado terminam prejudicando sua efetividade como um membro participativo de seus times. Como consequência, o time sofre também.

Um post recente por Peter Stevens pretende ajudar Product Owners saber o que buscar se eles estiverem querendo saber como estão indo em suas funções, e fornece uma lista rápida de dicas para ajudá-los a fazer um trabalho melhor.

Stevens oferece 4 coisas para buscar como sinais de aviso que o relacionamento do time com seu Product Owner pode precisar de melhorias:

  • "O Teste da Galinha": se o time está tratando o Product Owner como se ele não fosse um membro do time, então há uma alta probabilidade que exista algo sobre o comportamento do P.O que está deixando o time desconfortável.
  • "Sprints que falharam, impossibilidade de soltar um release": é possível que problemas com stories da iteração tenham causado isto e elas podem ser rastreadas de volta para os problemas em colaboração com o Product Owner.
  • "Quem é o responsável?": Problemas causados por um time recebendo sinais misturados ou em direções ambíguas de múltiplos Product Owners.
  • "Seu time está desmotivado": a falta de um tempo adequado face-a-face com seu Product Owner causando a perda de motivação do time.

O principal do post de Stevens vem na forma de 3 dicas para o Product Owners (ou Cliente XP) para melhor comunicação e report com seus times.

  1. Seja um jogador do time. Jogue pelas regras.
    Participe totalmente de todos os rituais do Scrum, incluindo o Scrum diário e as retrospectivas. Assista o scrum diário e a retrospectiva do sprint como um participante normal. Responda as mesmas questões que todos os outros. Escute. Não use a oportunidade para jogar seu "peso" nos rituais. Talvez você deva se oferecer para ficar em silêncio por um sprint ou dois para construir a confiança. Isto vai ajudar você entender seu time e o que eles necessitam para serem bem sucedidos. Eles também vão entender seus problemas e desafios melhor.
     
  2. Honre seus compromissos
    Você faz um acordo com o time em todo planejamento do sprint. Mantenha seu lado da barganha. Não venha para o seu time com trabalho extra durante a sprint. Não mude sua opinião caprochosamente - ser ágil não é a mesma coisa que ter falta de visão. Proteja seu time da interferência de qualquer um na companhia. Sim, este é trabalho do Scrum Master, mas assuntos serão escalados para você.
     
  3. Esteja disponível quando seu time precisa de você
    Venha para reuniões no horário marcado e esteja por toda a duração. Reserve o suficiente de sua capacidade para atendet as necessidades de seu time. Se seu tempo é limitado, então ache qual o impacto que sua ausência está causando no projeto. Planeje releases em torno de datas que não são alteradas, como férias, feiras de negócio e outros eventos importantes, para que você possa estar presente em fases críticas do projeto.

Para não ser repetitivo, mas vale estressar que enquanto Stevens apresenta sua mensagem em termos Scrum, este conselho é igualmente aplicável para aqueles em ambientes não-Scrum.  Se você está praticando XP, por exemplo, então este conselho é para o "Cliente" e seu "sprint" é sua "iteração", etc.

Então, Product Owners do mundo, este artigo parece com você? Como sua experiência se encaixa com o conselho de Stevens?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Product Owner é tambem um membro da equipe, um programando by Sabrina Cruz

Product Owner é tambem um membro da equipe, um programando. Como lidamos com isso? Como fazer que ele entenda que determinados requisitos que nao fazem parte da sprint nao devem ser discutidos durantes as reuniões.?

Re: Product Owner é tambem um membro da equipe, um programando by Felipe Rodrigues

Olá Sabrina,

O ideal é que o Product Owner não seja membro da equipe de desenvolvimento. Se não houver alternativa para isso, então deve-se escolher alguém com perfil flexível o suficiente para separar os momentos. Como um ator.

Uma boa definição de como deve-se escrever um estória ou item do backlog ajuda. Uma boa definição do processo, indicando como tratar questões técnicas por exemplo também ajuda. Uma boa base sobre design evolutivo e condução dos processos ágeis é vital para essa pessoa.

Sem esses itens, não há muito o que fazer e o projeto pode ser sériamente afetado.

Grande Abraço,

Felipe Rodrigues de Almeida

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT