Pergunte a qualquer Product Owner. Vá lá… Pode perguntar “qual é o maior problema que você enfrenta como PO?”. Você vai ouvir alguns resmungando sobre a maturidade do time, sobre estimativa, sobre o SM fantasiado de papel de parede… Mas a esmagadora maioria vai ter alguma história de horror para contar sobre como ser um proxy¹ é, disparado, o maior desmotivador na vida de um gestor de produto.

Eu, certamente, vivo esse problema há muito tempo, e testo formas de contorná-lo desde 2008. Assim, achei válido compartilhar o que funcionou até agora; e foi pensando nisso que bolei uma palestra para o TDC de Porto Alegre.

O desafio de lidar com o HiPPO e as percepções

Você faz pesquisa, corre atrás dos usuários, bola um product discovery com dinâmicas de consenso para gerar um backlog de produto com seus stakeholders. Para cada release, você quer definir com os stakeholders uma hipótese a ser validada. Você coleta os dados, apresenta e, na hora de priorizar o backlog, acontece isso aqui:

E você pensa “cara, não é possível. Eu estou fazendo algo errado. Não tenho talento pra isso. Vou vender sanduíche na praia”.

Bom, eu tenho uma boa notícia para você: pode parar de pensar nos sabores de sanduíche. O problema não está em você. O problema pode inclusive não estar no seu stakeholder. Será que você daria uma chance para testar algo novo?

Geralmente, o que acontece no momento em que você está priorizando um backlog é que o stakeholder (ou os stakeholders) estão muito focados em uma necessidade específica que eles precisam atender. Não acredita? Coloque vários stakeholders de áreas (e portanto interesses) diferentes em uma sala. Pegue seu backlog, com cada item atendendo a uma área diferente. Tente priorizar. A expectativa é que eles tenham uma postura colaborativa, civilizada, certo?

O x da questão aqui é encontrar uma forma de lidar com os diferentes interesses, seja do produto e do stakeholder principal (que nem sempre estão alinhados), seja dos vários stakeholders de um mesmo produto. O problema é que esses interesses são subjetivos. Eles são derivados de uma percepção que os stakeholders têm de suas próprias necessidades e uma percepção ainda mais vaga que cada stakeholder tem da necessidade da outra área, ou do produto. Quem nunca travou uma batalha campal para impedir um stakeholder de pedir uma feature que destrói a usabilidade do produto, ou causa insatisfação, ou arrebenta a performance?

A bala de prata aqui é transformar essa percepção em algo quantificável e comparável, exatamente como a gente faz quando estamos falando de usabilidade, de feedback e de iteração de produto. Chega a ser cômico ver como somos capazes na hora de gerir o produto, mas falhos na hora de gerir as pessoas. Esperamos que nossos meros argumentos tenham o efeito de um truque Jedi: “esse não é o item de backlog que você procura”.

Métricas, o sabre de luz que você já sabe usar

Martin Luther King dizia que um grande líder não procura consenso. Ele molda consenso. E este costuma ser nosso erro, pois insistimos em procurar consenso como se ele fosse algo a ser encontrado, como se você fosse dar uma de Indiana Jones e descobrir, em alguma ruína de uma cidade perdida, uma ideia mágica sobre a qual tanto seus stakeholders, quanto seu time concordam.

O que precisamos fazer é esculpir o consenso com técnica e disciplina, da mesma forma que abordamos o produto. Mas que técnicas usar?

Quando estamos medindo esforço, o planning poker é o que ajuda o time de desenvolvimento a equilibrar as diferentes necessidades e visões. Ele é uma técnica que nós já sabemos usar, e que nos ajuda a moldar o consenso dentro do time. No entanto, usar uma única métrica de consenso de valor para cada item de backlog, na minha experiência, não é tão produtivo quanto o Fibonacci do planning poker é para o time.

Por um período, testei uma técnica de priorização chamada GUT, e quando estamos tratando correções e pequenas melhorias, ela funciona muito bem. O problema é que ela não se aplica aos casos de descoberta de produto de uma forma tão aderente. Então, eu fiz uma pequena adaptação que trouxe grandes resultados: a RUT, abrangendo Relevância, Urgência e Tendência.

A vantagem da RUT é que, para cada um dos critérios, os stakeholders e o time vão consensar valor usando uma lista de definições, e não as suas próprias percepções. Em todos os testes que fiz até hoje, essa técnica aumentou a empatia entre os stakeholders e os membros da equipe, ajudou os envolvidos a olharem para a visão de produto em detrimento de suas necessidades pessoais e trouxe imparcialidade para a discussão, facilitando imensamente o meu trabalho de moldar o consenso.

RUT: como funciona?

Esta técnica de consenso é para ser simples e rápida. No entanto, como o Fibonacci, os primeiros minutos são os que o grupo está se adaptando às definições, então, não desanime se houver dúvidas. Pelo contrário: aproveite este momento para alinhar o entendimento de todos os participantes sobre os critérios.

Projete a tabela abaixo para os participantes. Como no poker, você vai ler sobre um item de backlog, todos poderão fazer perguntas e, então, votam em uma nota para cada critério. Como os valores vão de 1 a 5, basta usar as mãos para votar. Garanta que todos revelem seu voto ao mesmo tempo para evitar ancoragem, e promova o debate quando houver divergência, de forma que cada lado exponha o motivo do seu voto, e todos possam contribuir para alinhar o entendimento.

Dinâmicas com participantes que já conhecem RUT acabam levando de 2 a 3 minutos em média por item de backlog, já contemplando as pausas para debater divergências. Você pode inclusive planejar o tempo das dinâmicas levando esse ponto em consideração.

Ao final da votação de cada item e critério, anote no seu backlog o resultado consensado e multiplique os valores de Relevância x Urgência x Tendência para obter o valor final do item.

A partir deste ponto, você poderá priorizar seu backlog por valor. Se você tiver a medida de esforço estimada pelo time para cada item, pode também priorizar o backlog pelo ROI. Basta dividir o valor em RUT pelo esforço estimado.

Uma das maiores vantagens é que essa técnica pode continuar sendo usada à medida que o produto evolui, sendo aplicável mesmo quando o valor de cada item não puder ser mensurado diretamente em receita. Isso faz com que você tenha uma métrica única para todo o backlog, e possa acompanhar a curva de valor agregado pelo produto sprint a sprint.

O feedback da palestra foi bastante positivo. A avaliação era opcional e realizada pelo app do TDC, então, considerei que 30 pessoas avaliando foi uma boa amostragem:

Conteúdo da palestra – 90% achou ótimo ou bom.

Apresentação da palestra – 90% achou ótimo ou bom.

Postura do palestrante – 80% achou ótimo ou bom.

Slides da palestra aqui.

¹ PO com perfil proxy é aquele que atua enquanto um mero representante das vontades dos stakeholders, sem filtros. Ele coleta os requisitos e entrega para o time, e não se posiciona de forma a ter qualquer tipo de mandato sobre o produto exceto enquanto reprodutor das necessidades e percepções dos stakeholders. Para saber mais sobre os tipos de PO, recomendo este artigo aqui.

Ficou alguma dúvida ou tem alguma contribuição? Aproveite os campos abaixo e até a próxima!

***

Artigo publicado originalmente em: http://www.concretesolutions.com.br/2016/11/15/como-priorizar-sem-traumas/