Priorizar funcionalidades: MoSCoW e RICE

Você tem mais ideias de features do que tempo para implementá-las. Isso não é um defeito seu, é a condição normal de todo desenvolvedor indie. O caderninho (ou o board do Trello) enche de "seria legal ter", e cada item parece essencial quando você imagina o jogo pronto. O problema aparece quando você senta para trabalhar e não sabe por onde começar. Saber priorizar funcionalidades é justamente a habilidade de olhar essa lista inchada e decidir, com critério, o que entra no escopo agora e o que fica esperando a vez.

Vou deixar uma distinção clara logo de cara, porque ela confunde muita gente. Priorizar não é a mesma coisa que segurar o tamanho do projeto e evitar scope creep. Controlar escopo é decidir o que fica de fora do jogo, é dizer não. Priorizar é ordenar o que ficou dentro, é decidir a sequência. Você faz as duas coisas, mas são movimentos diferentes. Aqui o foco é o segundo: o método de colocar as features em fila.

Existem dois frameworks simples e testados que resolvem isso sem virar planilha de gestor corporativo: MoSCoW e RICE. Um é rápido e qualitativo, o outro é numérico e serve para desempatar. Vou explicar os dois com exemplos de jogo de verdade e terminar com um passo a passo que você aplica hoje na sua lista.

Por que priorizar funcionalidades muda o seu jogo

Sem priorização, o indie cai em dois buracos. O primeiro é trabalhar naquilo que é mais divertido de programar, não no que o jogo precisa. É comum ver alguém com um sistema de crafting elaboradíssimo e nenhum menu de save funcionando. O segundo buraco é o oposto: paralisia. A lista é tão grande que a pessoa não começa nada, ou pula de feature em feature sem terminar nenhuma.

Priorizar resolve os dois porque força uma pergunta desconfortável em cada item: isso é necessário agora, ou só desejável? Quando você responde essa pergunta de forma honesta, a lista de trinta ideias vira uma sequência de cinco coisas para fazer neste mês. E é essa sequência que te faz avançar.

Repare que priorizar também é uma decisão sobre risco. As features mais incertas, aquelas que você nunca fez e não sabe se vão funcionar, muitas vezes merecem atenção cedo justamente para você descobrir logo se são viáveis. Deixar o multiplayer para o fim do projeto, por exemplo, é uma forma clássica de tomar um susto tarde demais.

MoSCoW: quatro baldes para a sua lista

MoSCoW é um acrônimo meio torto (as vogais são só para o nome soar como a cidade) que separa toda feature em quatro categorias.

• Must Have (precisa ter): sem isso o jogo não funciona ou não faz sentido. Se ficar de fora, você não tem produto. Num jogo de plataforma, o pulo é Must. Num RPG, o sistema de combate é Must.
• Should Have (deveria ter): importante, agrega muito valor, mas o jogo ainda existe sem. Você faria de tudo para incluir, mas dá para lançar sem e adicionar depois.
• Could Have (poderia ter): legal de ter, melhora a experiência, mas o impacto é pequeno perto do custo. Entra se sobrar tempo.
• Won't Have (não vai ter agora): ficou de fora desta rodada. Não é lixo, é "não neste momento". Registrar aqui evita que a ideia volte assombrando toda semana.

Vamos aplicar num exemplo. Imagine que você faz um metroidvania solo. A lista bruta tem: sistema de save, tutorial inicial, conquistas (achievements), chefes opcionais, mapa navegável, suporte a controle, multiplayer cooperativo, skins alternativas para o personagem.

Uma classificação MoSCoW razoável ficaria assim: save e mapa navegável são Must (um metroidvania sem mapa e sem save é injogável). Suporte a controle e tutorial viram Should (fortíssimos, mas o jogo roda no teclado e o jogador esperto aprende sem tutorial). Conquistas e chefes opcionais são Could (agregam, mas não quebram nada se faltarem no início). Multiplayer e skins vão para Won't Have desta versão, porque o custo é altíssimo e o retorno para um metroidvania de exploração é duvidoso.

O poder do MoSCoW está na conversa que ele obriga. No instante em que você tenta colocar oito coisas em Must, percebe que está confundindo vontade com necessidade. Uma disciplina saudável é manter os Must Have somando menos da metade do esforço total. O resto é folga para o inesperado, porque sempre aparece o inesperado.

RICE: quando o balde não resolve

O MoSCoW é ótimo, mas tem um limite: dentro de um mesmo balde, ele não te diz o que fazer primeiro. Se você tem cinco features em Should Have e tempo para três, precisa de um critério mais fino. É aí que entra o RICE, que transforma cada feature numa nota numérica a partir de quatro fatores.

• Reach (alcance): quantos jogadores essa feature afeta num período. Uma tela de configurações de acessibilidade toca todo mundo. Um chefe secreto no fim do jogo toca só quem chega lá.
• Impact (impacto): o quanto ela melhora a experiência de quem é afetado. Use uma escala simples, tipo 3 para impacto alto, 2 para médio, 1 para baixo, 0,5 para mínimo (esses números são só um exemplo ilustrativo de escala, adapte).
• Confidence (confiança): o quanto você acredita nas suas próprias estimativas, em porcentagem. Se é um chute total, 50%. Se você já testou algo parecido, 100%.
• Effort (esforço): quanto trabalho custa, em dias, semanas ou pessoas-mês. É o único fator que fica embaixo na fórmula, porque esforço alto derruba a prioridade.

A fórmula é: (Reach × Impact × Confidence) ÷ Effort. O número que sai não tem significado absoluto, ele só serve para comparar features entre si. Maior é melhor.