Cómo definir un MVP antes de desarrollarlo
Empieza con un usuario, un flujo útil y una forma clara de aprender del primer lanzamiento.
Un MVP debe permitir que un grupo concreto de personas complete una tarea útil y darte evidencia para decidir qué construir después. No es el producto completo con pantallas a medio terminar. Antes de estimar el desarrollo, define qué necesitas aprender del primer lanzamiento.
Esta guía sirve como brief para esa conversación. Los ejemplos son ilustrativos, no resultados de un proyecto contratado a CodeRoasters.
Elige un usuario y un problema
“Pequeñas empresas” es demasiado amplio para orientar el primer flujo. Identifica a una persona en una situación: un administrador que necesita aprobar accesos o un supervisor que revisa un reporte de campo. Describe cómo trabaja hoy y qué le impide terminar bien la tarea.
No supongas que quien compra el software es su único usuario. Identifica quién captura información, quién la revisa y quién actúa a partir de ella. Puedes enfocar el primer lanzamiento sin ignorar a quienes hacen posible el proceso.
Identifica el supuesto que necesitas comprobar
Pregunta qué debe ser cierto para que la idea funcione. ¿Las personas utilizarán ese flujo? ¿Se puede obtener la información necesaria? ¿El proceso propuesto resuelve el problema sin generar otro?
Un prototipo puede responder preguntas de uso antes de necesitar software en producción. El manual de servicios de GOV.UK explica cómo probar supuestos de riesgo mediante prototipos. Aquí tomamos ese principio, no la obligación de adoptar todo su proceso.
Elige el experimento más pequeño que responda la pregunta actual. Un prototipo navegable permite explorar una interfaz; no demuestra que una integración operativa maneje correctamente datos reales.
Dibuja el flujo principal completo
Ejemplo ilustrativo: un residente anuncia una visita, la caseta comprueba la autorización y registra el ingreso. La primera versión necesita un inicio claro y un resultado útil. Un generador de reportes puede ser menos importante que explicar correctamente una autorización vencida.
Escribe el recorrido habitual y dos o tres excepciones probables. Para cada paso, identifica usuario, información necesaria y resultado. Esto suele mostrar trabajo que una lista de pantallas deja fuera.
Haz visible el límite
| Incluir en el primer lanzamiento | Dejar para cuando exista una razón |
|---|---|
| Una tarea completa de principio a fin | Varios casos de uso apenas conectados |
| Permisos y errores necesarios | Todas las configuraciones posibles de roles |
| Una forma de revisar si funcionó | Un sistema de reportes personalizado |
| Un camino de soporte y corrección | Automatizar cada excepción |
Posponer una funcionalidad no significa olvidarla. Conserva una lista breve de lo que queda fuera y su motivo. Revísala después de observar el uso real, en lugar de permitir que entre al desarrollo sin una decisión explícita.
Define la evidencia antes del lanzamiento
Selecciona pocas preguntas: ¿el usuario termina sin ayuda?, ¿dónde se detiene?, ¿qué registros necesitan correcciones?, ¿el flujo funciona en el entorno donde se utilizará?
Define metas después de entender el proceso actual. No elijas cifras porque se vean bien en un dashboard. Combina observación y comentarios, y deja claro lo que el primer lanzamiento todavía no puede demostrar.
Lleva este brief a la conversación
- ¿Quién será el primer usuario?
- ¿Qué trabajo intenta completar?
- ¿Qué utiliza actualmente?
- ¿Cuál supuesto necesita probarse primero?
- ¿Cuál es el flujo completo más pequeño?
- ¿Qué queda fuera del alcance inicial?
- ¿Qué evidencia orientará la siguiente decisión?
Este brief ayuda a comenzar un proyecto de diseño y desarrollo de producto. Si una herramienta existente podría resolverlo, consulta primero la guía sobre SaaS y software a medida.