El equipo tiene una idea para una aplicación y una lista larga de funciones. Cada persona añade algo que considera imprescindible. Si todo entra en la primera versión, el proyecto puede tardar en llegar a quienes deberían utilizarlo y aportar información para decidir.
Un producto mínimo viable, o MVP, es una primera propuesta que permite contrastar una hipótesis con usuarios y aprender antes de ampliar la inversión. Lo mínimo depende de la pregunta que quieras responder. Lo viable exige que la prueba tenga sentido y pueda utilizarse en las condiciones previstas.
Un MVP no es una excusa para entregar algo inseguro o imposible de evaluar. El alcance puede ser pequeño, pero los datos, los accesos y la operación necesitan unas condiciones claras.
Qué debería permitir aprender un MVP
La definición de Agile Alliance sobre producto mínimo viable relaciona el concepto con aprender de usuarios mediante una versión acotada. Antes de decidir funciones, conviene formular qué incertidumbre debe resolver la prueba.
En una aplicación interna, la pregunta puede ser si un equipo consigue tramitar una solicitud sin mantener una hoja paralela. En un portal de clientes, puede ser si las personas completan una gestión sin llamar por teléfono. Son hipótesis de ejemplo, no resultados obtenidos por Aceleris.
Una pregunta como «queremos comprobar si la aplicación gusta» resulta difícil de traducir en decisiones. Es preferible definir quién la utilizará, para qué tarea y qué evidencia permitirá continuar o cambiar el enfoque.
MVP, prototipo y prueba de concepto
Un prototipo puede ayudar a revisar pantallas y recorridos sin implementar toda la operación. Una prueba de concepto suele explorar una incertidumbre técnica. Un MVP busca aprender del uso de una propuesta acotada.
La terminología puede variar entre equipos. Por eso es importante describir qué se entregará y qué permitirá comprobar, en lugar de dar por hecho que todos entienden lo mismo cuando leen MVP.
Elige la prueba según la duda principal
Si no sabes si una API ofrece los datos necesarios, una prueba técnica puede resolver esa duda antes de desarrollar una interfaz. Si la incertidumbre está en el recorrido del usuario, un prototipo puede aportar información con menos trabajo.
Cuando necesites observar una tarea en condiciones de uso, habrá que concretar una versión operativa y sus límites. El orden de las pruebas depende del riesgo que convenga resolver primero.
Cómo reducir funciones sin romper el recorrido
Prioriza un recorrido completo para un grupo de usuarios definido. Una aplicación con muchas pantallas incompletas puede enseñar menos que una versión que resuelva una sola tarea de principio a fin.
Proponemos clasificar cada función según estas preguntas:
- ¿Es necesaria para poner a prueba la hipótesis?
- ¿Qué pasa si se deja fuera de esta versión?
- ¿Puede resolverse temporalmente con una tarea manual controlada?
- ¿Afecta a permisos, datos o integraciones que condicionan todo el sistema?
- ¿Cómo se comprobará que funciona para el usuario elegido?
Una operación manual temporal puede ser válida si está identificada y tiene un responsable. No debería ocultarse en la propuesta ni depender de que alguien improvise cada día.
Un ejemplo de alcance para una aplicación interna
Imagina un portal para solicitar material. Una primera versión podría permitir crear la solicitud, aprobarla o rechazarla y consultar el estado. El catálogo avanzado, las previsiones y nuevas áreas podrían quedar para después si no son necesarias para la prueba.
Antes de desarrollar, habría que definir quién puede solicitar, quién aprueba y qué ocurre con una solicitud incompleta. También habría que decidir cómo llega la información al sistema que gestiona el material.
Este ejemplo no determina un alcance universal. Sirve para ver que «mínimo» puede significar menos recorridos y menos usuarios, sin dejar ambiguas las reglas del recorrido elegido.
Qué acordar antes de comenzar el desarrollo
Deja por escrito la hipótesis, los participantes, las funciones incluidas y las que quedan fuera. Añade las dependencias, los datos de prueba y los criterios para aceptar la entrega.
La propuesta también debería explicar cómo se recogerán incidencias y observaciones durante el uso. Si nadie revisa esa información, el proyecto pierde su capacidad de enseñar algo antes de la siguiente inversión.
En un proyecto de aplicación a medida, delimitar esta primera versión ayuda a separar lo necesario para aprender de las mejoras posteriores.
No dejes la operación para el último día
Define quién dará acceso, resolverá una incidencia y actualizará la aplicación. El hecho de que el piloto tenga pocos usuarios no elimina esas tareas. El mantenimiento de software debería contemplarse desde la primera entrega operativa.
Cómo decidir qué hacer después del piloto
Revisa si los usuarios completan la tarea, dónde necesitan ayuda y qué trabajo siguen haciendo fuera de la aplicación. Contrasta esas observaciones con la hipótesis inicial.
La decisión puede ser ampliar, modificar el recorrido o detener el enfoque. No conviertas cada comentario en una función automática. Pregunta qué necesidad revela y si pertenece al objetivo de esta versión.
También conviene distinguir un problema de adopción de uno de funcionamiento. Si una persona no conoce el nuevo procedimiento, añadir una pantalla puede no resolverlo. Si la tarea falla, más formación tampoco sustituye una corrección.
Qué determina la inversión en un MVP
El coste depende de lo que deba comprobarse y de las condiciones necesarias para hacerlo. Integraciones, permisos, tratamiento de datos y pruebas pueden exigir más trabajo que el número de pantallas.
Pide que el presupuesto separe preparación, desarrollo, validación y soporte del piloto. Cada proyecto debe valorarse de forma independiente según su alcance. Una cifra genérica para cualquier MVP no permite comparar propuestas con criterio.
Preguntas frecuentes
¿Un MVP tiene que ser una aplicación completa?
No necesita resolver todos los usos previstos, pero debe permitir comprobar la hipótesis elegida. Aclara qué partes son operativas y cuáles son una simulación o un apoyo manual.
¿Cuánto debe durar la prueba?
El tiempo depende de la frecuencia de la tarea y de la evidencia necesaria. Acuerda un periodo que permita observar el recorrido sin prometer una duración universal.
¿Cómo empezamos si todavía tenemos demasiadas ideas?
Escoge una persona, una tarea y una incertidumbre importante. Cuéntanos qué aplicación estás valorando y podremos revisar qué primera versión permitiría decidir el siguiente paso con datos.
