Hoy echamos un vistazo prudente a nuestra cocina mágica. Me gustaría mostrar cómo abordamos los nuevos proyectos de desarrollo. Para nosotros existen dos enfoques distintos.
Sencillamente construimos la app
Cuando el alcance de una nueva app es muy manejable, resulta fácil evaluar el riesgo del desarrollo. El coste es bajo porque, por ejemplo, solo un desarrollador trabaja en ella durante un período corto (menos de un mes). En ese caso, definimos un conjunto de funcionalidades, construimos la app y la lanzamos al público. Así fue con Phone Memos, Meeting Cards y también con Herein.
El alcance funcional es demasiado grande para "construir sin más"
A veces, durante las primeras conversaciones sobre una nueva app, se puede ver de inmediato que el alcance superará el límite de persona-mes. O, como ocurre con Merlin Project, el producto tiene una importancia estratégica. En ese caso hablamos de una inversión de riesgo y, por supuesto, procedemos con la cautela correspondiente.
En la primera fase construimos mockups (imágenes en Apple Keynote de cómo imaginamos la app) con los que simulamos mentalmente el funcionamiento y los flujos de la futura app. De vez en cuando, sin embargo, alcanzamos los límites de nuestra imaginación y necesitamos otra técnica: un prototipo.
Un prototipo es para nosotros un programa pequeño que ilustra una técnica concreta, un flujo de trabajo o simplemente un concepto. De este modo construimos muchas apps pequeñas. Como estas apps de prueba tienen una vida muy corta, intentamos llegar al objetivo con rapidez. No nos preocupamos por la elegancia ni por la limpieza del código.
Durante esta fase sigue siendo en su mayor parte tarea mía revisar las cifras financieras de la futura app: qué nos costará desarrollarla y qué podríamos ganar con ella. Como siempre suelo decir: "Los setenta ya pasaron. Por desgracia no podemos vivir solo del amor al arte."
Con el tiempo habremos explorado (esperemos) todos los aspectos de la nueva app. Dispondremos entonces de un conjunto de diapositivas que muestran el aspecto visual. Y siempre que fue necesario, las técnicas nuevas o críticas se probaron en un prototipo hasta quedar satisfechos con el resultado. Además, existe un desglose detallado de los costes previstos y los ingresos esperados. Entonces nos reunimos (en remoto por Zoom, por supuesto) y debatimos nuestras conclusiones.
En este punto, ya han fracasado muchas ideas de nuevas apps, ya sea por una idea base deficiente, una barrera técnica demasiado baja o incluso demasiado alta. Y si el número de usuarios estimado es insuficiente, la app tampoco se desarrolla. Naturalmente, soy consciente de que estas valoraciones, aunque se tomen en equipo, son muy subjetivas y no tienen por qué coincidir con la realidad futura. Pero en algún momento hay que tomar una decisión.
El pistoletazo de salida para el MVP
Cuando nuestra confianza en la nueva app y la motivación para construirla alcanzan un nivel suficientemente alto, iniciamos el desarrollo.
Pero también aquí hay que ser prudente. No quiero poner en riesgo el futuro del equipo con un paso en falso. Y precisamente aquí entra en juego otro mecanismo de gestión de riesgos: crear un producto mínimo viable.
Según Wikipedia, el término MVP fue acuñado por primera vez por Frank Robinson y popularizado por Steve Blank y Eric Ries. La idea que hay detrás es de una claridad intuitiva: se construye un nuevo producto equipado únicamente con las funcionalidades básicas más importantes. Con ese producto se puede comprobar, dentro del equipo, con socios estratégicos y también con representantes de posibles grupos de clientes, si existe interés por él y si el mercado estimado es suficientemente grande. Por supuesto, también se prueba si el manejo de la app cumple las suposiciones planteadas.
En ProjectWizards se lleva muchos años trabajando con un enfoque iterativo en el desarrollo:
- Se desarrolla siguiendo los mockups creados.
- Revisamos el resultado en un grupo reducido y decidimos si funciona bien.
- Si no estamos satisfechos, iteramos: en problemas menores directamente en el software; en problemas fundamentales, volvemos al mockup.
Siempre bajo el lema: el camino más rápido y sencillo dicta el procedimiento.
Así se van ensamblando poco a poco todos los bloques del MVP. A partir de cierto momento, alguien, normalmente yo, empieza a jugar con el nuevo software.
Primeras pruebas durante la fase de desarrollo del MVP
Por muy costoso y a veces frustrante que sea, los conceptos y las hipótesis deben comprobarse una y otra vez. Eso significa trabajar con datos de ejemplo en la nueva app. Al principio, claro, falla por todos lados. Pero con el tiempo la situación mejora.
En algún momento surge la pregunta de cuánto tiempo se debe o se tiene que invertir en un MVP. No existe ninguna regla al respecto. El proceso dura hasta que uno mismo puede responder si el nuevo programa es viable en el mundo real.
Diferencia respecto al Minimum Marketable Product (MMP)
El producto mínimo comercializable (o vendible) va un paso significativo más allá, al menos en mi definición.
Mientras que el MVP está concebido solo para uso interno (incluidas algunas personas clave) y aún no genera ingresos, el MMP da un paso esencial más: esta versión ya se puede vender.
A diferencia de las convenciones del mundo del código abierto, un MMP necesita como mínimo:
- un número de versión 1.0
- documentación
- un sitio web
- un socio de venta (App Store, Paddle, etc.)
- y más
Por este motivo no usamos el término MMP, sino versión 1 o 1.0.
¿Cuándo se produce la transición del MVP a la versión 1?
Para nosotros es una transición fluida. Fijamos una fecha para la finalización del MVP, que a su vez marca el inicio del desarrollo de las funcionalidades restantes de la versión 1.0.
Como se puede ver en el gráfico, está planificado como un proceso secuencial. En la práctica, sin embargo, los límites a veces se difuminan bastante.
¿Cuándo está listo un MVP?
No existe una fecha fija para esto. Si decidimos que no estamos contentos con la calidad o el conjunto de funcionalidades, seguimos trabajando en la app, aunque sea una versión interna.
Visítenos regularmente por aquí, síganos en LinkedIn o en Twitter y será de los primeros en conocer todas las novedades ;-)
Si tiene alguna pregunta sobre este artículo del blog o desea debatirlo, esperamos su contribución en nuestro foro.
