Como decidir o que entra na versão um

Todo projeto de aplicativo começa com mais ideias do que um primeiro lançamento consegue comportar. Isso é saudável. O problema começa quando todas entram na versão um, a data de lançamento é adiada e a parte mais importante recebe menos atenção do que precisa. Definir o escopo é o trabalho de escolher, de propósito, o que lançar primeiro.

Comece pela tarefa principal

Escreva a única tarefa que o app precisa fazer bem. Em seguida, percorra o caminho mais curto para realizá-la: abrir o app, entrar na conta se for preciso, concluir a tarefa, ver que funcionou. Cada tela nesse caminho faz parte do escopo. Todo o resto precisa de uma justificativa.

Divida as ideias em três pilhas

Pegue cada ideia de funcionalidade e coloque em uma de três pilhas:

• Indispensável: a tarefa principal não funciona sem isso.
• Importante: torna a tarefa principal visivelmente melhor e é simples.
• Mais tarde: todo o restante, por melhor que seja a ideia.

Seja rigoroso com a primeira pilha. Uma funcionalidade que “os usuários vão esperar” não é indispensável, a menos que o app fique quebrado sem ela. A segunda pilha é onde as negociações acontecem, e não há problema se algo ficar de fora.

Conte o trabalho que ninguém vê

Algumas coisas nunca aparecem em uma lista de funcionalidades, mas ainda precisam ser entregues: login e redefinição de senha, exclusão de conta, política de privacidade, telas de erro e de estado vazio, configurações, relatórios de falhas, analytics e a página nas lojas. Juntas, elas podem representar uma grande parte do primeiro lançamento. Coloque essas tarefas no plano desde o início, para não se surpreender nas últimas duas semanas.

Comece de forma manual onde for possível

Algumas funcionalidades podem começar como um processo manual nos bastidores. A aprovação de novas contas pode começar com alguém conferindo uma lista toda manhã. Um relatório semanal pode começar com uma consulta feita à mão. Automatize quando souber que o recurso é usado e como é usado. É uma forma econômica de aprender o que as pessoas realmente precisam antes de construir tudo formalmente.

Dê um destino ao “mais tarde”

Ideias que ficam em espera precisam de um destino, senão elas voltam sorrateiramente. Mantenha uma lista simples para a próxima versão e revise-a após o lançamento, com o uso real para guiar você. Alguns itens da lista vão se mostrar irrelevantes. Outros serão mais importantes do que qualquer coisa na lista original, e você nunca saberia disso sem lançar primeiro.

Fixe a data, flexibilize o escopo

Uma data de lançamento fixa com escopo flexível é mais fácil de cumprir do que o contrário. Quando o prazo apertar, transfira funcionalidades para a próxima versão em vez de adiar a data. Isso mantém o lançamento enxuto e coloca o app nas mãos de pessoas reais mais rápido, que é onde começa o feedback útil.

Em resumo

Uma tarefa principal, uma lista rigorosa de itens indispensáveis, o trabalho invisível contabilizado desde o primeiro dia e um destino para todo o resto. Uma primeira versão que faz menos, mas bem-feito, dá uma base real de aprendizado. Uma primeira versão que tenta fazer tudo raramente é lançada.