Un MVP no es excusa para entregar algo malo

Hay quien trata el MVP como un permiso para lanzar algo roto, con la promesa de que «ya lo arreglaremos más adelante». Reducir el alcance no es lo mismo que bajar el nivel de lo que entregas.

El objetivo principal de un MVP es poner a prueba una idea con el mínimo esfuerzo posible. No hace falta pasarse meses construyendo sistemas que quizá nadie quiera usar.

Esto se ve muy claro en los videojuegos. Es posible crear un mapa enorme, un montón de personajes, combate, construcción, inventario y una historia detallada. Pero, si la experiencia principal no engancha, nada de lo demás puede salvar el juego.

Un juego con una sola mecánica puede ser divertido. También se pueden pasar años añadiendo funciones para descubrir al final que el juego en sí no es tan interesante como parecía al principio.

Otro problema habitual es añadir cosas nuevas antes de terminar lo que ya estaba previsto. Surge una idea y se apunta en la lista de tareas. Luego aparece otra. Cuando te quieres dar cuenta, estás trabajando en cinco sistemas a la vez y ninguno está realmente listo.

En Bomb-Survive, por ejemplo, están previstas la exploración, la supervivencia, la construcción y el combate. No hace falta desarrollar todo para saber si el ciclo principal funciona. Hay que comprobar si lo que ya existe consigue mantener el interés lo suficiente como para justificar el resto.

Para eso no hacen falta gráficos bonitos, animaciones pulidas ni el contenido definitivo del juego. Las mecánicas principales tienen que funcionar, los errores no deben estropear la experiencia y el jugador debe entender qué propone el juego.

Tampoco significa que haya que publicar de inmediato. A veces, probar el juego con unas pocas personas revela más que lanzar una versión a medio hacer a un público mucho más amplio.

El MVP sirve para descubrir si merece la pena continuar con el proyecto; no para enseñar todo lo que podría llegar a ser algún día.

Una cosa pequeña y bien hecha suele aportar más que un proyecto enorme con varios sistemas a medio terminar.

Lo «mínimo» es lo que necesitas para validar la idea. No el cuidado que pones en lo que entregas.