GUÍA DE PLANIFICACIÓN · SAAS Y APLICACIONES WEB
Definir el alcance de un MVP SaaS
Un MVP no es una versión pequeña de todo. Es un recorrido completo que un usuario real puede terminar, con los roles, los datos y la entrega que ese recorrido necesita.
Hablar del alcance de tu productoJiangmen, China. Trabajando globalmente.
Empezar por un recorrido, de principio a fin
Describe el recorrido con las palabras del usuario: qué trae al entrar, qué hace y qué se lleva. Si un paso necesita a otra persona u otro sistema, forma parte del alcance.
Un portal de clientes que recibe una solicitud, la asigna a un miembro del equipo y muestra el avance es un recorrido completo. Un panel con seis módulos a medias no lo es.
Roles y permisos se deciden pronto
¿Quién puede crear, editar, aprobar y eliminar? ¿Qué datos ve cada rol? Decidir permisos después de construir la interfaz suele obligar a rehacer pantallas.
Escribe cada rol en una frase y recorre el camino principal con cada uno. Los huecos detectados aquí cuestan mucho menos que los que aparecen en las pruebas.
Datos e integraciones definen el presupuesto
Enumera los sistemas que el producto debe leer o escribir y qué ocurre cuando uno no está disponible. Incluye límites: cuotas de llamadas, paginación, autenticación y qué se muestra al usuario si falla una sincronización.
Si tienes hojas de cálculo o una base antigua, describe su estructura con ejemplos anonimizados. El trabajo de migración suele subestimarse porque los datos actuales nunca se documentaron.
Dejar cosas fuera a propósito
Facturación, informes, apps nativas, inicio de sesión único y búsqueda avanzada suelen ser de segunda fase. Nombrarlas fuera de alcance no es una debilidad: mantiene la primera versión verificable.
Acuerda por escrito qué no hará la primera versión para que nadie descubra el límite durante la aceptación.
Criterios de aceptación que se pueden probar
Para cada paso, escribe el comportamiento esperado y el comportamiento ante un fallo. Después decide quién aprueba y qué evidencia cuenta: una grabación, una cuenta de prueba o una lista de comprobación.
Redactados así, los criterios convierten un «parece terminado» en una decisión que ambas partes toman en una hora.
Preguntas frecuentes
¿Cuántas funciones debe tener un MVP?
Las suficientes para que cada rol implicado complete un recorrido, y ninguna más. Si una función no sirve a ese recorrido ni a un requisito legal, pertenece a una versión posterior.
¿Hace falta un sistema de diseño primero?
No uno completo. Acuerda el diseño base, los patrones de formulario y los estados de componente del primer recorrido, y amplía el sistema a medida que crece el producto.
¿Qué pasa después de publicar el MVP?
Planifica la entrega a la vez que el alcance: quién lo opera, quién corrige defectos, cómo se respaldan los datos y cómo se prioriza la siguiente fase. Las condiciones de soporte se acuerdan mejor antes del lanzamiento.
¿Qué pasa después?
- Revisar los objetivos, los usuarios y las funciones esenciales.
- Confirmar los entregables, la estimación en dólares estadounidenses y los hitos principales.
- Acordar las responsabilidades y los criterios de aceptación antes de empezar.