MVP não é desculpa para entregar algo ruim

Alguns tratam o MVP como permissão para lançar algo quebrado, com a promessa de que “depois a gente arruma isso”. Reduzir o escopo não é o mesmo que diminuir o padrão do que você entrega.

O ponto principal do MVP é testar a ideia com o mínimo de esforço possível. Você não precisa passar meses construindo sistemas que talvez ninguém queira usar.

Isso fica bem claro em jogos. É possível criar um mapa enorme, vários personagens, combate, construção, inventário e história detalhada. Só que se a experiência central não prender, o resto não consegue salvar o jogo.

É possível fazer um jogo com uma única mecânica e ele ser divertido. Também é possível passar anos adicionando funcionalidades e descobrir, no final, que o jogo em si não é tão interessante quanto parecia no começo.

Outro problema comum é adicionar coisas novas antes de terminar o que já está no planejamento. Uma ideia surge, entra no backlog. Depois outra. Quando percebe, está mexendo em cinco sistemas ao mesmo tempo e nenhum deles está realmente pronto.

No jogo Bomb-Survive, por exemplo, há exploração, sobrevivência, construção e combate planejados. Não é necessário fazer todos para saber se o ciclo principal funciona. É preciso ver se o que já existe segura a atenção o suficiente para justificar o restante.

Isso não exige gráficos bonitos, animações refinadas ou conteúdo final do jogo. Exige que as mecânicas principais funcionem, que os bugs não estraguem a experiência e que o jogador entenda o que o jogo está propondo.

Também não significa que precisa publicar de imediato. Às vezes testar com poucas pessoas revela mais do que lançar uma versão meio-boca para muita gente.

O MVP serve para descobrir se vale a pena continuar, não para mostrar tudo que o projeto pode vir a ser um dia.

Uma coisa pequena e bem feita costuma entregar mais do que um projeto grande com vários sistemas pela metade.

O “mínimo” está no que você precisa para validar a ideia. Não no cuidado com o que você entrega.