Como priorizar pedidos de funcionalidades
6 min de leitura
Rastrear pedidos de funcionalidades resolve onde eles vivem. Não resolve qual sai primeiro, e essa segunda pergunta é onde os times realmente travam. Um backlog de trezentos pedidos, já agrupados e etiquetados, ainda precisa de uma regra de decisão, porque “construa o que foi mais pedido” só funciona até dois pedidos ficarem próximos e um terceiro ter uma defensora barulhenta, o que acontece na maioria das semanas. Os frameworks abaixo não são respostas concorrentes para a mesma pergunta. Cada um combina com um tipo diferente de pedido, e usar só um para todos costuma ser o erro de verdade.
O que diferencia priorizar pedidos de funcionalidades de priorizar um roadmap?
Uma decisão de roadmap parte da estratégia e pergunta o que construir. Uma decisão sobre um pedido de funcionalidade parte de uma demanda que já existe e pergunta se vale agir sobre ela, e as duas puxam para lados diferentes com frequência suficiente para que um pedido tenha demanda alta e ainda assim seja errado construí-lo, ou tenha demanda baixa e ainda assim valha a pena porque desbloqueia uma conta estratégica. Tratar cada pedido como um voto de roadmap pula essa checagem.
| Framework | O que pesa | Onde falha |
|---|---|---|
| Contagem bruta de pedidos | Quantas pessoas pediram | Recompensa nomes fáceis de lembrar em vez de demanda real |
| RICE | Alcance, impacto, confiança, esforço | Precisa de estimativas que ninguém tem para um pedido novo |
| Ponderado por receita | Quem pediu, pelo valor da conta | Ignora pedidos de contas que ainda não valem muito |
| Votos públicos | Sinal visível, baixo esforço | Só alcança usuários que já sabem onde olhar |
O que é RICE, e ele funciona para pedidos de funcionalidades?
O RICE avalia uma ideia por alcance, impacto, confiança e esforço, depois divide os três primeiros pelo quarto para chegar a um número comparável. Foi criado para ideias de roadmap em que um time já acredita, onde a parte difícil é comparar apostas diferentes entre si. Pedidos de funcionalidades já vêm com um número de alcance, a contagem de gente que pediu, o que é mais concreto do que o alcance que uma ideia de roadmap recém-nascida costuma ter. Onde o RICE tensiona com um pedido é confiança e impacto: um time pode ter certeza de que um pedido é real e ainda assim não ter base para saber o quanto isso vai mover uma métrica, porque “impacto” para um pedido que já tem nome e um rastro de usuários reais é um tipo diferente de estimativa do que o impacto de uma ideia que ninguém fora da sala ainda viu.
Use o RICE para pedidos que estão sendo levados a sério e ainda não foram decididos. Não aplique em todo pedido que chega; o esforço de pontuar só compensa nos que estão próximos o suficiente para precisar de um critério de desempate.
Deveria ponderar por receita, ou por quem pediu?
Por quem pediu, mas não só por receita. Uma conta perto da renovação, uma conta que já escalou antes, e uma conta cujo pedido desbloqueia um negócio em andamento carregam uma urgência que um número plano de receita, sozinho, não capta, e um pedido de um cadastro de teste ainda pode importar se está bloqueando uma decisão que logo vira receita. A ponderação por receita é a mais fácil de calcular entre todas essas, e é justamente por isso a mais fácil de confiar demais: ela remove corretamente o ruído de contas sem interesse real, e com a mesma facilidade pode rebaixar um pedido que traria uma conta muito maior, ainda no funil.
Qual papel os votos realmente cumprem?
Um sinal barato e contínuo para pedidos que já existem, e uma forma ruim de descobrir quais pedidos deveriam existir em primeiro lugar. Uma contagem de votos só alcança usuários que já encontraram o pedido e acharam que valia um clique, o que significa que o total de votos de um roadmap público reflete visibilidade tanto quanto demanda: um pedido antigo perto do topo da lista continua acumulando votos em parte porque é fácil de achar, e um pedido mais novo, igualmente real, começa do zero. O artigo sobre roadmap público defende deixar os votos totalmente fora do roadmap. Trate votos como um sinal que precisa ser agrupado e ponderado por recência, não como um ranking a ser construído em ordem. Tickets de suporte vs. pedidos cobre o outro ponto cego nas contagens de votos: uma lacuna real pode gerar quase nenhum voto se as usuárias que a encontram nunca acharem o quadro, enquanto ainda assim aparece barulhenta no suporte.
Quando o cliente mais barulhento vence, e isso é um problema?
Às vezes, e só é um problema quando ninguém percebe. Um cliente que escala com frequência, escreve tickets detalhados ou tem uma linha direta com alguém do time vai ver os pedidos dele examinados mais rápido do que um cliente mais quieto com um pedido igualmente válido, e um processo de priorização que nunca verifica isso vai favorecer sistematicamente quem mais insiste, não quem tem o caso mais forte. Clientes barulhentos não são o problema a ser corrigido; os pedidos deles costumam ser genuinamente importantes. A correção é um hábito: passar pelo backlog periodicamente por origem e checar se o mesmo punhado de contas explica a maior parte do que foi lançado recentemente, e perguntar se isso bate com onde a demanda real de fato está.
Como uma decisão de priorização vira uma resposta?
Toda decisão aqui produz ganhadores e perdedores, e ambos merecem uma resposta que nomeie o raciocínio real, não só uma mudança de status sem explicação. Como recusar um pedido de funcionalidade cobre o que dizer a um pedido que perdeu, de um jeito que mantém a relação intacta em vez de soar como uma recusa genérica. O trabalho de agrupamento e etiquetagem que torna tudo isso possível desde o início está coberto em rastreamento de pedidos de funcionalidades; a priorização só funciona sobre pedidos já registrados e agrupados o suficiente para serem comparados.
FAQ
Qual é o melhor framework para priorizar pedidos de funcionalidades? Nenhum sozinho. Use contagens brutas para achar o sinal mais barulhento, RICE para comparar uma lista curta de candidatos sérios, e uma checagem de receita ou de conta para pegar casos em que uma demanda silenciosa de uma conta estratégica pesa mais do que um grupo mais barulhento, porém menos importante.
Pedidos de funcionalidades deveriam ser priorizados do mesmo jeito que ideias de roadmap? Não. Ideias de roadmap partem da estratégia; pedidos de funcionalidades partem de uma demanda que já existe. Pontuar os dois juntos faz uma aposta estratégica bem argumentada, mas com pouca demanda existente, perder consistentemente para um pedido que simplesmente teve mais gente pedindo.
Os votos em um roadmap público refletem a demanda com precisão? Só entre as pessoas que já encontraram o pedido. Pedidos mais antigos e mais visíveis acumulam votos mais rápido, independentemente de quanta demanda real existe por trás de um mais novo, então trate os totais de votos como um sinal, agrupado e ponderado por recência, não como um ranking a ser construído em ordem.
Com que frequência as prioridades de pedidos de funcionalidades deveriam ser reavaliadas? Em um ciclo fixo, não só quando alguém escala. Uma passada mensal ou trimestral que reagrupa pedidos e reconfere a ponderação pega desvios, como um punhado de contas dominando o que é lançado, que um processo puramente reativo nunca revela sozinho.
As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.