Cómo acotar un MVP en fases con entrega comprobable

Qué es un MVP y en qué se diferencia de un prototipo

MVP son las siglas de minimum viable product, producto mínimo viable. Eric Ries, que popularizó el término con el método Lean Startup, lo define como la versión de un producto nuevo que permite aprender lo máximo posible sobre los clientes con el menor esfuerzo. Lo que pesa en esa definición es el aprendizaje: un MVP lo usan personas reales, con sus propios datos o tareas, y de ese uso sale la respuesta a una pregunta sobre el producto.

Un prototipo sirve para otra cosa. Una maqueta navegable o una demostración enseñan cómo podría funcionar una idea y ayudan a discutirla, pero no tienen por qué guardar datos, gestionar permisos ni aguantar el uso diario. Un MVP tiene menos funciones que el producto que imaginas, y las que tiene deben funcionar de verdad. Por eso cuesta más que un prototipo y conviene acotarlo bien, que es de lo que trata el resto de esta nota.

Qué hay que comprobar primero

Si vas a desarrollar un MVP para tu startup, antes de hablar de pantallas te pregunto qué tiene que ocurrir para que el producto merezca seguir adelante. Puede ser que un tipo de usuario complete una tarea sin ayuda, que acepte subir sus propios datos o que vuelva a entrar al cabo de unos días. Esa suposición es la que la primera versión tiene que poner a prueba. Las demás ideas se anotan para después.

Con la hipótesis escrita, repaso cada funcionalidad propuesta con una pregunta: si falta, ¿se puede comprobar lo mismo? El acceso con redes sociales, un panel de administración completo o varios idiomas suelen poder esperar. Un permiso mal resuelto o un dato que no se guarda bien, en cambio, estropean la prueba entera.

Qué entra en la fase y cómo se acepta

La propuesta de una fase enumera lo que voy a desarrollar y también lo que queda fuera, para que ninguno de los dos lo descubra al final. Cada funcionalidad lleva un criterio de aceptación que se pueda comprobar sin interpretarlo: qué hace el usuario, qué debe ver y qué ocurre si introduce un dato incorrecto.

• Recorridos completos que un usuario tiene que poder terminar sin ayuda.
• Datos que se guardan, quién puede verlos y quién puede modificarlos.
• Errores previstos y el mensaje que recibe el usuario en cada uno.
• Entorno en el que revisas la entrega y documentación que la acompaña.

Las pruebas con usuarios las puedes organizar tú o podemos prepararlas juntos. Trabajo en remoto, así que mi parte consiste en ayudarte a decidir qué tareas pedirles, qué observar y qué anotar, y después en separar un fallo del software de una funcionalidad que simplemente no se entiende. No puedo garantizar que la hipótesis salga confirmada. Saber que no se cumple también es un resultado de la fase.

Decisiones técnicas que pueden esperar y las que no

En una primera versión prefiero no cerrar lo que depende de un uso que todavía no existe: cómo atender a muchos usuarios a la vez, qué partes separar en servicios independientes o qué integraciones automatizar cuando aún pueden hacerse a mano. Decidirlo sin datos de uso suele añadir trabajo que luego hay que deshacer.

Otras decisiones conviene tomarlas desde el principio. El modelo de datos, porque cambiarlo cuando ya hay información de usuarios obliga a migrarla con cuidado. Los permisos, porque añadir más tarde quién ve qué en una aplicación con datos de clientes acaba afectando a casi todo el código. Y el despliegue: dónde se ejecuta la aplicación, a nombre de quién están las cuentas del proveedor y cómo se publica una versión nueva sin depender de una sola persona. Si el producto trata datos personales, también hay que decidir pronto qué se recoge y dónde se guarda.

Si la duda principal es qué arquitectura o qué proveedor elegir, puede tener sentido separarla del desarrollo y encargar antes una revisión de arquitectura independiente. Si ya tienes la oferta de otro proveedor, puedo darte una segunda opinión técnica sobre esa propuesta.

Si ya tienes un prototipo

Puede que ya exista algo: una maqueta navegable, una versión montada con herramientas sin código o un desarrollo que alguien dejó a medias. Antes de proponer rehacerlo, lo reviso. Compruebo si tengo acceso al código y a las cuentas, si la aplicación se puede instalar desde cero con lo que hay documentado, cómo guarda los datos y qué partes ya han usado personas reales.

A veces basta con corregir el modelo de datos y ordenar el despliegue. Otras veces mantener una parte costaría más que escribirla de nuevo. La revisión deja por escrito qué se conserva, qué se sustituye y por qué, y te sirve aunque después encargues el desarrollo a otra persona.

Código, documentación y la fase siguiente

Quién es propietario del código, en qué repositorio queda y a nombre de quién están las cuentas de infraestructura son condiciones que acordamos por escrito antes de empezar. Con la documentación ocurre algo parecido: la propuesta fija qué incluye la entrega para que otra persona pueda instalar, modificar y desplegar la aplicación. Si más adelante incorporas a alguien técnico o tienes que explicar a un tercero qué has construido, lo vas a necesitar.

Cada fase se presupuesta, se entrega y se acepta por separado. Al terminar decides con lo que has aprendido: plantearme otra fase, pasar el trabajo a tu equipo o detenerte ahí. No ofrezco una dedicación indefinida ni ocuparme de forma continuada de la dirección tecnológica de la empresa.

En la página de desarrollo de software a medida, automatización e IA aplicada explico cómo planteo el resto de desarrollos, las pruebas de aceptación y la entrega.