Mucho se habla sobre el Producto Mínimo Viable a la hora de construir software. Esta técnica dice que a la hora de crear software no debemos enfocarnos en una gran entrega al final de un lapso sino pensar la creación de forma iterativa, ciclos cortos donde se aprenda sobre el producto.
Sin embargo, muchos fundadores, emprendedores o negocios deciden tomar la definición a su conveniencia o ignorarla del todo. Claro, como es tan fácil meter más y más características, creen que esa es la forma ideal. Peor aún, creen que sin todas las características no hay software.
A continuación, voy a comentar porque eso está mal y cuál es la verdadera forma de adoptar el desarrollo de software pensando en un Producto Mínimo Viable.
Construir Software Implica Riesgos
Cuando alguien quiere hacer software y busca a una empresa o desarrollador freelancer para que trabaje en ello, el precio es un factor que detiene la idea. Hacer software es costoso. Es una labor que implica esfuerzo físico y mental, además de compromisos para lograr la idea lo más fiel posible a como se pensó.
Esos costos van asociados a plazos. Entre más complejo y elaborado sea el software más tiempo y dinero costará. Más riesgo habrá.
Si queremos invertir 100 millones de pesos en un software que podría tardar un año en estar listo, vamos a necesitar una forma para minimizar el riesgo de que el proyecto fracase.
Para ayudarnos a minimizar riesgos están las metodologías ágiles pero antes de ir a algo tan elaborado nos podemos valer de una técnica más sencilla aún: un Producto Mínimo Viable(MVP).
El Famoso MVP: Iterar y Aprender
El MVP es una forma de definir una primera versión del software a construir de tal forma que el consumidor final lo pueda utilizar de manera satisfactoria (que cumpla con su tarea) sin necesidad de esperar mucho tiempo ni gastar mucho dinero.
Los objetivos de un MVP son:
- Probar que hay un mercado para el software a construir
- Aprender directamente del usuario final
- Conseguir retroalimentación temprana
- Probar la idea «en el campo» con usuarios reales
- Demostrar que hay un problema a solucionar
Lo más importante es poder comprobar que en verdad hay gente que tiene un problema y que tu producto lo soluciona para así poder aprender en el camino y eliminar toda suposición previamente planteada.
Crear software implica eliminar muchos supuestos, sacar lo ambiguo y volverlo concreto. Cuando definimos y evolucionamos a partir de un MVP todo lo anterior se vuelve más sencillo y se reduce el riesgo de manera drástica.
Fundadores Demasiado Entusiasmados
Los fundadores se emocionan muy rápido con sus ideas e intereses y quieren que el software esté completo ya y no quieren planificar de manera iterativa. En su mayoría, asumen que la forma en que ellos piensan la solución de un problema es la que el público objetivo quiere y pasa muchas veces que cuando lanzan al mercado se estrellan con la realidad.
Características que nadie usa o entiende, elementos innecesarios, el problema que dice resolver el software no lo resuelve en realidad. Los usuarios quedan insatisfechos con ese producto que prometía cielo y tierra y que demoró un año en estar listo para llegar a sus manos.
Cuando definimos un MVP, no quiere decir que el proyecto no va a demorar un año. Quiere decir que a ese año llegamos habiendo creado un producto de manera iterativa donde el usuario final fue tenido en cuenta, donde el equipo y el fundador se retroalimenta de los usuarios y el producto en verdad es construido pensando en el problema a resolver y no en las suposiciones del fundador.
Al crear software, una forma de lograr convencer a los futuros consumidores es definiendo la Propuesta de Valor. Esta Propuesta de Valor, es la definición de lo que tu software hará y cómo hará la vida de los usuarios más fácil.
Cuando los fundadores solo se enfocan en características y olvidan la Propuesta de Valor, el producto final puede que no sea el esperado ni el comentado. Habrá personas insatisfechas e indispuestas a usarlo o pagar por este.
Incluso, con dos o tres características puede que simplifiques las labores de quien usa tu software. A veces los usuarios quieren simpleza y efectividad. No cientos de características que no usan ni usarán que pueden afectar al mismo software, inclusive.
Por ejemplo, Dropbox Paper vs Google Docs. Para cierto tipo de documento Dropbox Paper es superior. Cuando quiero tomar notas de aprendizajes mientras trabajo en algo, prefiero hacerlo en Dropbox Paper. Una interfaz sencilla, ligera y con atajos de teclado para darle formato al texto. Para notas sencillas la interfaz de Google Docs es muy cargada y lenta, además de que hay muchas cosas que no necesito.
Sin embargo, cuando quiero elaborar documentos más formales, con normas internacionales, con márgenes, justificado y otros, ahí prefiero Google Docs. Sería un error por parte de Dropbox Paper querer agregar características más avanzadas como indentación o espaciado. Si quisiera eso, usaría Google Docs.
Malas Experiencias
Definir un MVP no es tarea sencilla pero tampoco imposible. Si tal vez tuviste una mala experiencia, la culpa no es del MVP o de la metodología ágil. Estos conceptos están para ayudarnos y son directrices pero debemos adoptarlas al software que construimos.
El MVP es una forma de poder confirmar que lo que hacemos tiene cabida en el mundo. Si en alguna experiencia el MVP fue un fracaso o una tortura, hay que revisar y replantear cómo se hizo. En muchos proyectos le llaman MVP a trabajar un año y luego lanzar el producto a recibir retroalimentación. Eso no es un MVP. O le llaman ágil a trabajar en etapas de dos semanas pero nunca mostrar avances. Eso no es ágil.
El trasfondo real de un MVP (y de ágil) es iterar y aprender. Solo iterando y aprendiendo se eliminan los supuestos, las ambigüedades, los riesgos.
—
Definitivamente, hacer software no es tarea sencilla y debemos aprovechar y usar las herramientas que facilitan la eliminación de riesgos para poder crear algo de utilidad y que pueda ser rentable. El MVP es una de las herramientas que tenemos a disposición que ayuda con esta tarea. Úsala.
Artículos relacionados:
El Camino del Pro 
3 comentarios sobre “El Verdadero Producto Mínimo Viable”