Antes de começarmos, me acompanhe nessa pequena história:
Lá está você, gestora(or) de produto, com um backlog do tamanho de uma Bíblia, recebendo uma série de sugetões 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.
Sua liderança chega em você e diz: precisamos do roadmap para o próximo quarter. Você olha para o seu backlog, chama a sua equipe de desenvolvimento - afinal você leu Inspired - pega mais um ou outro gato-pingado de atendimento, marketing e sucesso do cliente, coloca geral 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, da 1 minuto para todo mundo pontuar cada fator, ao final faz a média, ranqueia, troca uma ideia com o seu techlead para entender o que pode ser feito em um trimestre e está feito o seu roadmap.
O final é sempre mais do mesmo: várias iniciativas com um score meio “médião”, você desconfiado que essa priorização está bem mais ou menos, e todo mundo pouco confiante nas notas que foram dadas.
Até 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, a minha luta aqui não é contra essa bagunça, mas pelo fato que ainda se usa pontuação para priorizar iniciativas.
Independente 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.
Sim, eu entendo o porquê você ainda usa
Para quem está perdidinho nesse pagode, o RICE é um dos métodos que ajuda os gestores de produto a priorizar 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 beneficiaram com eles.
Olha que coisa linda, não é? Uma receita de bolo, data-driven, que vai resolver toda encheção de saco trimestre a trimestre dos seus stakeholders para decidir o que vai ser construído logo em seguida.
“Por que a funcionalidade X é mais importante que a Y?” Porque o RICE me disse que é.
É um método simples, rápido, conveniente e promove uma fácil convergência. Tudo o que um gerente de produto quer na sua vida.
Mas, é tudo o que gerenciamento de produto não é. Pois o método também é inerentemente subjetivo, superficial e não é bom para tomar grandes decisões.
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 recorde 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 do 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 do RICE. Por exemplo, se Alcance for muito maior que Impacto, Confiança e Esforço, a margem de erro de 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 de vieses ambulante
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 resultará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 impacto do usuário é, 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 em mais de uma pessoa, quando foi conferir o resultado dela 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 apostas. 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 o que eu faço?
Ainda mantenha o mais simples possível. E faça uma comparação entre as iniciativas, não trate elas isoladamente.
Aqui eu estou admitindo que você tem um direcionamento claro, com métricas, históricos consistentes e princípios de desenvolvimento de produto definidos (por mais que não seja a realidade geralmente). Então a priorização é o seu único problema.
Faça um plano cartesiano de Impacto vs Certeza. Pelo menos a Certeza você pode atrelar a algum tipo de risco. E compare as iniciativas entre si.
“Ah, mas e o esforço?”
Veja depois, com mais calma, com o VSCode aberto na frente do seu techlead. Lembra sobre diminuir incertezas? Meu irmão e minha irmã, não vão querer uma estimativa de esforço sem ao menos abrir o código, não é?
