Definir as prioridades na vida pessoal ou profissional muitas vezes não é tarefa fácil, pois normalmente as variáveis como tempo e dinheiro são “dimmers” que devemos ajustar de acordo com a sua disponibilidade, raramente encontrada em fartura em tempos de globalização e alta competitividade.

Nos anos 90” aprendi arduamente com um amigo engenheiro que tempo, qualidade, custo e escopo são variáveis cruciais para a tomada de decisão e muitas vezes a corporação entendia que poderia resolver apenas com aportes no projeto. Se o tempo fosse o inimigo, investia-se em escalar times para tentar viabilizar a antecipação de uma entrega, o que pode trazer grandes riscos de comunicação e sincronização entre os times, mas essa é uma outra questão que poderei abordar em outro post.

Diante de muitos fatores que podem impactar positivamente ou negativamente no desenvolvimento de um produto digital, quero citar algumas técnicas que podemos utilizar para nos auxiliar no processo de tomada de decisão que muitas vezes é um desafio para o Product Owner,  que deve equilibrar as necessidades das partes interessadas, bem como buscar o melhor retorno para o produto.

MATRIZ DE PRIORIDADES

A Matriz de Prioridades é um exemplo que podemos utilizar para relacionar algumas possíveis funcionalidades a serem implementadas para um aplicativo mobile:

FUNCIONALIDADE

Tendo em mente o contexto de classificação do maior para menor, partindo de Épico > Histórias > Tarefas e Sub-tarefas, liste nesta coluna todos os itens que estão mapeados em seu backlog e que você deseja que estejam disponíveis em seus próximos releases. É muito importante que as funcionalidades sejam compostas da real motivação para que seja realizada para que possamos identificar o “custo x benefício”.

ESFORÇO

Durante o Sprint Planning ou até mesmo durante o Refinement das funcionalidades, o time de desenvolvimento realiza a pontuação de cada funcionalidade. A pontuação pode seguir por exemplo o método T-Shirt (Pequeno, Médio, Grande) ou Fibonacci. Como a nossa matriz realiza cálculo simples, utilizei a sequência de Fibonacci para demonstrar o nível de esforço para cada funcionalidade. Vale lembrar que essa sequência é composta pela soma do número atual com o número anterior, ou seja 0, 1, 2, 3, 5, 8, 13, 21 e assim por diante.

Neste contexto, é uma boa prática limitar o tamanho da sequência para que seja possível identificar as lacunas no entendimento da funcionalidade que será desenvolvida pelo time, bem como compreender que se o time pontuou a funcionalidade “Como cliente vip, gostaria de “Pagar com Cartão Fidelidade” para resgatar os pontos que tenho acumulado” com 5 pontos, estão querendo dizer que o intervalo dessa pontuação pode ser entre 3 e 8 pontos, ou seja, o nível de assertividade está no intervalo e não na pontuação cravada.

Observe que quanto maior a pontuação, maior será a incerteza que o time possui em realizar a implementação da funcionalidade e neste caso o Product Owner deve atuar para fatiá-la em partes menores.

VALOR DO NEGÓCIO

Digamos que o seu background é financeiro, então digamos que uma boa forma de entendimento se um projeto é atrativo financeiramente, você poderia aplicar a formula de Taxa Interna de Retorno (TIR) acompanhado do Valor Presente Líquido (VPL), pois seriam informações que auxiliariam para a sua tomada de decisão. O campo de valor do negócio (business value) pode ser composto por TIR, VPL ou um valor que simbolize a importância daquela funcionalidade.

Neste cenário escolhi valorizar em reais aleatoriamente para simbolizar essa importância, porém muitas vezes a importância de uma determinada funcionalidade para mim é diferente para um patrocinador ou outra parte interessada. Neste caso, podemos aplicar uma dinâmica que venha a equilibrar o entendimento de valor de cada funcionalidade, o qual cada integrante do exercício recebe uma quantidade igual de moedas de igual valor e a cada rodada “investe” suas moedas em cada funcionalidade. Ao término das moedas, as funcionalidades são classificadas do maior para o menor valor.

ROI

O Return On Investiment (ROI) é a relação da quantidade de dinheiro ganho (ou perdido) em um aporte realizado. Em nosso contexto, queremos saber o resultado do valor do negócio dividido pelo esforço, desta forma poderemos ordenar do maior para o menor valor a funcionalidade mais atrativa para aquele momento. Observando a tabela podemos identificar que as funcionalidades mais prioritárias seriam na ordem (ID) de 3,4,2,1.

CONCLUSÃO

O uso de ferramentas simples podem ser úteis para alcançar consenso e propriedade coletiva. Simplicidade pode ajudar um grupo diversificado a permanecer focado no trabalho a ser realizado e evita que todos fiquem perdidos apenas em detalhes.

Em último caso –  e quando todas as funcionalidades são urgentes e devem ser feitas de imediato e você não consegue abrir mão de funcionalidade alguma – pense que você morreu e encontra-se de frente para o Capiroto com todas as funcionalidades escritas em post-it e apenas uma das funcionalidades te levaria para o céu. Qual você escolheria?

O importante é entendermos que nem tudo é prioridade máxima e você deve exercitar atividades ao decorrer do seu dia de trabalho que venham a dar cadência ao time e visibilidade do Roadmap. Lembre-se, o product backlog é dinâmico!