Melhores práticas para priorizar seu Backlog

Existem alguns frameworks de priorização de tarefas, cada um com suas virtudes e problemas. Vou falar de um único problema que você precisa identificar e da virtude que todos os bons frameworks têm em comum.

Começando pelo problema, as pessoas dão muito glamour aos números sem entender porque eles surgiram. A matemática foi desenvolvida para ser uma linguagem universal que descreve quaisquer tipos de fenômeno, conhecidos ou desconhecidos. Se algo pode ser modelado matematicamente e é comprovado, é verdade independente do que acreditamos.

A gente tá acostumado com essa noção desde a escola. Ainda usamos expressões como “é como 2 mais 2 são 4” pra dizer que algo é verdadeiro e indiscutível. Então é um erro meter número em coisas subjetivas.

O jeito mais comum de cometer esse erro é botar prioridade numérica nas coisas. “Isso é prioridade 2, isso é prioridade 1”... As coisas a fazer não têm essa propriedade como parte indissociável delas. A prioridade surge após análises ou dependem do cargo de quem pediu. É subjetiva. Quantas vezes já ouvi “Isso é prioridade 1, mas aquilo também é prioridade 1”. E aí, qual vem primeiro? E quem quer ser a prioridade 19? Na prática as pessoas levam esses números muito a sério e vão brigar pra terem o melhor número possível. O fato é que o número aqui não está ajudando a mensurar nada, é só uma ferramenta política tentando tornar matemático algo que é completamente subjetivo.

Outro exemplo: Quantificar “Confiança”, usada no framework ICE. “Eu tenho confiança 8 nessa feature, naquela tenho 6” é uma frase um tanto estapafúrdia. Não existe essa medida. Mas botamos um número lá pra dar a impressão de algo medido e portanto não passível de debate. Nosso backlog está ordenado pela ordem matematicamente calculada! Ainda dá pra entrar no mérito qual a importância do PM se sentir confiante ou não no sucesso de alguma feature e quantas vezes quebrei a cara com isso, mas talvez em artigos futuros.

A moral da história é fugir de framework numérico que empurra pra baixo do tapete todas as incertezas intrínsecas ao processo. Já perdi mais da metade dos leitores aqui, mas vamos em frente falar do que funciona (pra talvez perder a outra metade):

Toda priorização bem feita acaba tendo uma versão destas duas dimensões: Esforço e Impacto. O que a gente quer é impactar o público o máximo possível com o menor trabalho possível - para poder ter mais tempo e fazer mais tarefas e impactar mais ainda.

Eu uso só essas duas, e não boto número. Aqui está o pulo do gato.

Ao invés de métrica de esforço que pode virar política, peço pro time de execução (SIM, Engenharia/Design e não você ou seu stakeholder) classificar em “simples” ou “complexo”, sendo que algo complexo é algo ou com muitas interdependências com outros sistemas ou com muitos pontos que ainda não temos certeza de como fazer. Mas e algo simples que será demorado? É melhor priorizar algo assim que uma coisa complexa qualquer, muito mais propensa a “criar tentáculos” e botar o time pra resolver um monte de problemas não previstos até conseguir botar no ar.

Pra impacto, eu uso “Direto” ou “Indireto”. E não penso em impacto no público. Tudo impacta o público, a questão aqui é se impacta da forma específica que a empresa está preocupada. Então uso impacto no OKR ou no objetivo da área. Melhorar o login impacta diretamente na conversão? E inserir um novo meio de pagamento? E mudar uma fase na Landing page? E remover um campo do formulário?

Com todas as tarefas classificadas nestas duas dimensões, fica fácil:

O que tiver esforço “Simples” e impacto “Direto” nada mais é que o famoso “Quick Win”. Devem sempre ser o topo do backlog. Tem muitas tarefas classificadas assim? Primeiro, parabéns, a chance do seu time fazer um golaço está altíssima. Segundo, se precisar ordenar comece pelas tarefas mais curtas (Entregar mais sempre aumenta sua chance de sucesso do que entregar pouco) ou as que são pré-requisitos das próximas.

O oposto disso, tarefas “Complexas” com impacto “Indireto” devem ser jogadas no abismo do inferno e jamais serem feitas. Não precisa bradar isso em voz alta, só mova-as pra fim do backlog, e use de termômetro do quão funcional seu time de produto está. Se você chegar nessas tarefas tem algo errado com sua ideação, devia ter aparecido novas coisas melhores pra fazer.

Agora temos o balanço pra fazer entre “Simples/Indireto” e “Complexo/Direto”. Não tem regra de ouro, mas eu tendo a ir puxando “Complexo/Direto” até um ponto onde faço um Sprint pra resolver todas as “Simples/Indireto”, mais ou menos como um Sprint de débito técnico ou de bugs. Afinal, uma tarefa dessa faz pouca diferença, mas 20 delas talvez mexam o ponteiro.

Ao não botar números percebi que resolvi um outro grande problema na priorização: Fica muito mais fácil gerar consenso. Os times de execução podem ter dúvida se uma tarefa é “3” ou “5” no poker planning, mas normalmente são unânimes sobre a complexidade ou não de algo. Da mesma forma, é bem mais fácil levar os stakeholders a concordar sobre quão diretamente o lançamento de alguma ideia impactará nas metas. Assim, não só eu consigo ter uma ordem que deixa claro meu caminho de sucesso como torno todos os times parte da decisão, não ficando pra mim o ônus de defender a priorização.

Não é revolucionário, mas é muito eficaz.

--------

OpenAI me sugere um tema de Produto, eu escrevo o post, nº5. Todo os dias até eu desistir. Siga #oraculodeproduto pra ver a série.