Pode ser que sua organização esteja apenas começando sua transformação ágil ou ainda não tenha começado. Também é possível que isso aconteça há algum tempo, mas que você não tenha feito o progresso que esperava em termos de lançamentos de software ou capacidade de resposta ao cliente.
Se você está no começo ou tentando promover mudanças, um dos desafios mais significativos que já vi para equipes ágeis é lidar com um product owner que não preenche todas as funções que a ele é esperado para jogar.
Para começar, qual é o papel que o product owner espera jogar?
Bem, de acordo com Jeff Sutherland (co-criador do Scrum) e JJ Sutherland (PMO da Scrum, Inc.), o PO:
“… [Precisa] passar metade do tempo conversando com as pessoas que compram o produto (obtendo seus pensamentos sobre o último lançamento incremental e como ele forneceu valor) e metade do tempo com a equipe criando o Backlog (mostrando o que o cliente valoriza e o que eles não o fizeram. ”
Essa é uma tarefa relativamente alta por si só – um PO precisa passar metade do tempo com os clientes e metade com uma equipe de desenvolvimento de software.
Mas, mesmo além dos desafios básicos, há simplesmente uma questão de como organizar esse trabalho.
Um product owner pode já estar fazendo isso, mas não está entregando tudo que a equipe precisa. Veja algumas práticas recomendadas para se tornar um melhor PO:
1. TENHA UMA HISTÓRIA SENDO ESCRITA
Se você está tentando descobrir como melhorar o backlog do produto ou preenchê-lo de forma mais eficaz, essa é a ferramenta que você precisa empregar. Um workshop de redação de histórias é uma oportunidade para um grupo de partes interessadas: pessoas de negócios, líderes e membros da equipe de scrum se unirem e adicionar ao backlog do produto de maneira significativa.
Freqüência normal: uma vez por trimestre.
2. REFINAMENTO DO BACKLOG DO PRODUTO
Já tem um backlog substancial, mas precisa de ajuda? Entre com os membros da equipe e trabalhe nisso. Mais uma vez, concentre-se nos itens mais importantes. A expectativa é que esse trabalho aconteça a cada sprint para garantir que o backlog do produto seja preparado e priorizado para sprints futuros.
Freqüência normal: uma vez por sprint.
3. ATENDE AS ESCOLHAS REGULARMENTE
O product owner é um dos pilares do Scrum. Participar de reuniões de equipe regulares e participantes mostrará sua dedicação à equipe, ajude sua equipe a entender melhor como você está preparando o backlog para os próximos sprints e demonstre sua compreensão do processo.
Frequência normal: todos os dias ou várias vezes por semana.
4. DEFINIR UMA VISÃO
Você deve ter uma visão do produto geral e ter uma visão do seu ciclo de lançamento atual. Isso deve ser maior do que apenas o que estamos completando este sprint – a menos que o seu sprint atual seja o culminar de um trabalho anterior. Ele deve definir metas significativas e desafiadoras para sua equipe reuni-las e mantê-las concentradas por um longo período de tempo – um trimestre fiscal é um bom objetivo. Se você não tem uma visão, o que está prendendo sua equipe e definindo-a em um caminho motivado?
Freqüência Normal: Uma vez para todo o produto, em uma base trimestral para os principais objetivos do produto.
5. DEFINIR PAPÉIS DE USUÁRIO
Se você não tiver funções claramente definidas para seus usuários, precisará criá-las. Muitos projetos começam aqui, mas se você está herdando um produto que se transformou ao longo do tempo ou simplesmente nunca os definiu, vale a pena gastar um pouco de tempo definindo claramente as funções do seu sistema.
Frequência normal: no início de um projeto, uma vez quando novas funções são adicionadas.
6. MAPEAMENTO DE HISTÓRIAS
Uma técnica adicional para ajudar na priorização e poder construir um roteiro é a ideia do mapeamento de histórias . O mapeamento da história pode ser feito como uma continuação em um Workshop de Escrita de História, ou pode ser feito seguindo um refinamento de backlog de produto. É uma maneira útil de entender seu MVP, priorizar e garantir que você crie um produto funcional.
Freqüência normal: conforme necessário
Em conjunto, isso pode parecer intimidante, mas tenha em mente que cada peça adiciona um valor incremental. Fazer apenas um deles pode fazer uma diferença significativa.
As seis melhores práticas acima estão listadas na ordem em que devem ser colocadas em prática (se já não estiverem). Por exemplo, se um backlog não for definido ou bem priorizado, a equipe está paralisada – isso está acontecendo agora – eles não são tão eficazes quanto deveriam e devem ser corrigidos. Imediatamente.
De muitas maneiras, a Visão do Produto é a coisa mais importante nessa lista. É relativamente fácil de fornecer e o proprietário do produto deve fornecê-lo. No entanto, como acontece com as funções do usuário, uma equipe já pode estar trabalhando com sua própria visão e pode efetivamente trabalhar sem que o PO forneça uma para eles. A visão da equipe pode não ser a mesma que a visão do PO, que é algo que deve ser corrigido o mais rápido possível, mas é uma emergência menos terrível do que um backlog que precisa de refinamento.
Os POs têm um tempo especialmente difícil – muitas vezes, eles vêm da empresa, tendo tido empregos voltados para o cliente – e, muitas vezes, são solicitados a continuar realizando esses trabalhos, além de serem POs. Isso é um desafio. Tentar abordar tudo de uma vez é difícil, mas usando a lista acima, eles podem adicionar valor incremental e passar cada vez mais para a função de PO que a organização precisa.
Gostou das dicas, tem algo que não falei aqui e quer acrescentar? Posso lhe ajudar? Vamos?