¿Qué es un Producto Mínimo Viable?

Al pasar de 0 a 1, la sabiduría de la ingeniería nos dice que es importante comenzar con un MVP. Después de todo, crear un MVP le permite obtener comentarios tempranos, llegar antes a los clientes y descubrir incógnitas desconocidas. Compro este argumento: en mi experiencia, es muy fácil pasar mucho tiempo trabajando en cosas que terminan sin importar y los MVP mitigan esta preocupación. Pero, ¿qué es un MVP? ¿Reconoces uno cuando lo ves? ¿Un gusto cultivado con la experiencia? Vamos a desglosarlo.

¿Por qué construir un MVP?

Primero, recapitulemos, por qué queremos crear MVP.

La ingeniería se trata fundamentalmente de construir sistemas bajo restricciones. El objetivo número uno de un MVP es, en última instancia, entregar una fracción significativa de valor agregado con una pequeña fracción del esfuerzo. Esto le permite obtener comentarios tempranos para ayudarlo a priorizar el resto del trabajo. A menudo, le permite descartar grandes partes del trabajo y concentrarse en lo que importa.

En mi experiencia, también descubrí que esta mentalidad tiene un gran beneficio cultural y experiencial para el equipo de ingenieros que trabajan en el proyecto. Las limitaciones te obligan a trabajar en lo que importa. Llegar a mostrar el progreso es satisfactorio. Además, evitas construir piezas que al final no son tan útiles. Es una buena práctica no apegarse demasiado emocionalmente a su código, ya que es posible que deba desecharlo. A pesar de eso, todavía se siente muy bien ver que la mayor parte de su trabajo tiene un buen uso, y se siente triste tener que dejar algo que diseñó en exceso.

¿Qué es un MVP?

Como era de esperar, definir un MVP es más difícil que describir por qué quieres uno. Veamos la expansión de las siglas. Un MVP es un producto que tiene una complejidad mínima, una utilidad viable y un producto en el sentido de que debe ser utilizado por alguien representativo de su audiencia.

Estos objetivos a veces están en desacuerdo, entonces, ¿cómo navegamos realmente por esto?

Un MVP NO significa una experiencia rota. Si bien debe tener una complejidad mínima, debe ser completo en lo que intenta hacer. No tiene que tratar de hacer todo (no debería), pero debe ser completo en lo que intenta hacer. Todo el arte de un MVP es encontrar atajos para reducir la complejidad y mantener la viabilidad.

Cortar el alcance es una parte clave de esto. Por ejemplo, un MVP de S3 para usar en un sitio web básico puede querer get, puty delete. Probablemente no necesite URL prefirmadas, cargas de varias partes, y es mejor que no tenga ACL complejas.

Dicho esto, depende de usted como ingeniero y diseñador de productos elegir qué partes son las piezas fundamentales que está tratando de entregar. Si su producto no es viable sin ACL, elija un conjunto mínimo de ACL y ofrézcalos completamente sin complejidad y reduzca el alcance del resto.

Finalmente, un MVP tiene que salir con alguien. Tal vez sea para algunos de los primeros usuarios. Tal vez sea para tus amigos o tu jefe. Tal vez lo lances a todos con un descargo de responsabilidad "beta". Todos estos son geniales, pero ALGUIEN debería usarlo antes de que sigas trabajando en ello.

¿Cómo es un MVP exitoso?

Hay algunos escenarios exitosos posteriores al MVP.

• A la gente le encanta y anhela más. ¡Construye más características!
• A la gente le encanta como es. Déjalo como está. Guarde sus ideas de funciones archivadas para ese momento en el futuro en el que serán útiles. Al menos, será un artefacto divertido para mirar en uno o dos años con nostalgia. En el mejor de los casos, es su hoja de ruta.
• La gente no está emocionada. ¡Itera (o tíralo)!

¡Sigue lanzando código!