BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Sendo um Product Owner melhor

Sendo um Product Owner melhor

Favoritos

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?

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT