RICE é um dos métodos que ajuda os gerentes de produto na priorização de iniciativas por pontuação considerando seu impacto potencial nos usuários, o esforço necessário para implementá-los, o nível de confiança no resultado esperado e o número de usuários que se beneficiariam com eles.
Olha que coisa linda, não é? Uma receita de bolo, data-driven, que vai resolver toda a “encheção de saco” trimestre a trimestre dos seus stakeholders para decidir o que vai ser construído logo em seguida.
Imagine que um stakeholder pergunta: “Por que a funcionalidade X é mais importante que a Y?”. E você responde: “Porque a RICE me disse que é”. Afinal, alcance, impacto, confiança e esforço são 100% do que precisamos para decidir o que queremos.
É um método simples, rápido, conveniente e que promove uma fácil convergência. Tudo que um gerente de produto quer na vida.
Mas é tudo o que gerenciamento de produto não é. Pois o método também é inerentemente subjetivo, superficial e péssimo para tomadas de decisão.
Sim, eu entendo por que você ainda usa RICE
Lá está você, gerente de produto, com um backlog do tamanho de uma bíblia, recebendo uma série de inputs sobre novas funcionalidades e sugestões de melhorias na experiência do usuário. Sem mencionar os bugs e débitos técnicos que você vem adiando há algum tempo. Tudo isso no final de um trimestre.
Vamos combinar, todo mundo já passou por isso.
Sua liderança chega e fala para você: “Precisamos do roadmap para o próximo quarter”. Você olha para o seu backlog, chama a sua equipe de desenvolvimento, pega mais um ou outro “gato-pingado” de atendimento, marketing e sucesso do cliente, coloca todos em uma sala do Teams com uma planilha aberta e inicia a dinâmica de pontuação de Reach, Impact, Confidence e Effort (RICE).
Você explica cada uma das iniciativas do seu backlog e dá 1 minuto para todo mundo pontuar cada fator. Ao final, faz a média, ranqueia, troca uma ideia com o seu tech lead para entender o que pode ser feito em um trimestre, e pronto, está feito o seu roadmap.
Ao final é sempre o mesmo: várias iniciativas com um score meio “médião”, você desconfiado de que essa priorização está bem mais ou menos, e todo mundo pouco confiante nas notas que foram dadas.
Me arrepia pensar nesse cenário.
Não porque ele é muito possível de acontecer, com a diferença de um detalhe ou outro. Mas porque eu mesmo já passei por isso.
“Ah, mas você está fazendo o método totalmente errado.” Claro que dei uma exagerada para poder causar um impacto sobre o quão ridículo é esse cenário. Porém, minha luta aqui não é contra essa bagunça, mas pelo fato de que ainda se usa pontuação para priorizar iniciativas como se fossem verdades absolutas.
Independentemente do cenário, a questão é que você ou está debatendo entre múltiplas possibilidades onde a melhor escolha não é óbvia, ou tentando priorizar a sua iniciativa frente a de outras pessoas. Então, precisamos entender o impacto daquilo que estamos escolhendo, o famoso trade-off.
Quer ser data-driven? Então vamos pensar assim…
Toda vez que pontuamos algo, existe uma coisa que se chama margem de erro. Ela é uma medida da incerteza ou precisão de uma estimativa estatística ou resultado. Representa a faixa de valores dentro da qual o valor real da população que está sendo estudada provavelmente cairá com um certo nível de confiança.
Por exemplo, toda vez que sai uma pesquisa eleitoral, existe uma margem de erro que representa a população total, dado o recorte de amostragem realizado.
É importante considerar a margem de erro ao interpretar estimativas, pois ela fornece uma medida da confiabilidade e precisão da estimativa. Uma margem de erro menor indica uma estimativa mais precisa, enquanto uma margem de erro maior indica mais incerteza.
Ou seja, em cada pontuação que você coloca no cálculo da RICE, há uma margem de erro embutida. E segundo a minha explicação acima, você acha que essa margem de erro é grande ou pequena?
O cálculo de propagação dessa margem se multiplica pela interferência do tamanho de cada fator. Se uma das variáveis de entrada for muito maior que as outras, então sua margem de erro dominará a margem de erro propagada da RICE. Por exemplo, se Alcance for muito maior que Impacto, Confiança e Esforço, a margem de erro da RICE será mais sensível à margem de erro de Alcance.
“Ah, mas eu tenho total certeza da pontuação que eu coloco.” Vamos discutir sobre isso então.
Somos um balde ambulante de vieses
Cada uma dessas entradas tem seu próprio nível inerente de incerteza e erros ou vieses. Se o erro de algum desses fatores se agravar, isso vai resultar em erros significativos no processo de priorização.
Pontuar assume que cada entrada pode ser quantificada e ponderada apropriadamente. No entanto, atribuir valores numéricos a conceitos abstratos como alcance ou confiança é, no mínimo, muito corajoso. Além disso, diferentes pessoas têm opiniões diferentes sobre como ponderar cada fator, levando a inconsistências no processo de priorização.
Eu garanto que se você fez esse método com mais de uma pessoa, quando foi conferir o resultado você pensou: “Nossa, fulano está viajando”.
Não, ela não viajou, ela simplesmente foi honesta com seus próprios vieses. O que você está fazendo através desse score de funcionalidades nada mais é do que dar um número para a tendência dessa pessoa. Inclusive para a sua própria.
Além disso, nada dessa pontuação considera interdependências entre recursos, funcionalidades ou risco de suposições e hipóteses. Priorizar iniciativas isoladamente pode levar a resultados abaixo do ideal se as interações entre elas não forem consideradas. Por exemplo, algo de alto impacto, mas de baixo esforço, pode ser menos valioso se depender de outro que ainda não foi construído.
Então, como fazer a priorização?
Mantenha o mais simples possível! E faça uma comparação entre as iniciativas, não as trate isoladamente.
Aqui, estou admitindo que você tem um direcionamento claro, com métricas, históricos consistentes, princípios de desenvolvimento de produto definidos (por mais que não seja a realidade de grande parte das empresas) e uma liderança que saiba comunicar com clareza. Então, priorização é o seu único problema.
Faça uma stack comparando uma iniciativa a outra e aí, sim, as pontue individualmente por cada fator, sendo a que fica abaixo no stack com valor 0 e a que fica no topo com valor 10.
Desenhe um plano cartesiano de Impacto vs Certeza. Impacto você conecta com o direcionamento estratégico atual. E a Certeza você pode atrelar a algum tipo de risco ou suposição mais arriscada. E entenda onde cada iniciativa está em cada quadrante do seu plano.
“Ah, mas e o esforço?”
Veja depois, com mais calma, com o código aberto na frente do seu tech lead. Lembra sobre diminuir incertezas? Meu irmão e minha irmã, não vai querer uma estimativa de esforço sem ao menos ter uma compreensão correta, não é?
Conclusão
Um ponto importante aqui é que qualquer tipo de priorização tem o seu viés e a possibilidade de erro.
A grande pegada é que boas equipes de Produto erram menos. Ainda erram, mas a assertividade é maior, de fato. O que te faz errar menos é a quantidade de contexto, informações, estudos e dados a que você tem acesso. Caso contrário, vão ser brigas de opiniões.
E como quebrar esse padrão? Traga novas informações à mesa. Não vai ser o framework mais famoso que vai te salvar.
