Cómo definir un MVP de aplicación con criterios de aceptación

La respuesta corta: elige una hipótesis y un flujo completo

Formula primero la duda que justifica construir: “¿puede el equipo aprobar solicitudes sin reconciliar tres archivos?” es más útil que “necesitamos digitalizarnos”. Elige un usuario principal, un desencadenante y un resultado observable. El MVP incluye lo necesario para recorrer ese camino con seguridad básica y datos reales o representativos; aplaza funciones que no cambian la respuesta a la hipótesis. Esa frontera permite presupuestar, desarrollar y aceptar con menos interpretación.

Atlassian define el producto mínimo viable como una versión con funciones suficientes para atraer a primeros usuarios y validar una idea. En una aplicación interna, “atraer” puede significar que el grupo piloto pueda completar su trabajo y dar evidencia. Antes de delimitarlo, la comparación entre página web y aplicación a medida ayuda a confirmar el tipo de solución; si el origen es una hoja desbordada, revisa también cuándo sustituir Excel por una aplicación.

Rellena una ficha de alcance de una página

Describe el flujo con verbos de negocio. “Responsable revisa la solicitud y la devuelve con un motivo” informa más que “pantalla de detalle”. Añade la fuente de cada dato, quién puede modificarlo y el estado resultante. Después dibuja el camino feliz en seis u ocho pasos y marca las decisiones. El propósito no es diseñar toda la solución: es descubrir dependencias, como el identificador que llega de otro sistema o la persona que debe resolver una excepción.

Recorta por casos, perfiles y profundidad

Un corte vertical mantiene una capacidad pequeña de extremo a extremo. Puede incluir un tipo de solicitud, dos roles y una delegación manual, mientras aplaza plantillas múltiples, personalización avanzada y automatizaciones secundarias. Un corte horizontal —construir todos los menús y ninguna operación completa— produce una demo vistosa, pero apenas comprueba si el proceso funciona. Conserva siempre accesibilidad razonable, protección de datos, recuperación de errores y observabilidad necesarias para el piloto.

Crea tres listas: ahora, después y fuera. “Después” necesita una condición, como alcanzar veinte casos válidos o confirmar que el equipo usa el flujo semanalmente; sin ella se convierte en un almacén infinito. “Fuera” evita que una expectativa vuelva disfrazada de detalle. Los elementos técnicos invisibles también cuentan en el alcance: entornos, migración mínima, copias, registro de fallos, soporte y una forma controlada de exportar los datos.

Escribe criterios de aceptación que se puedan demostrar

Un criterio debe indicar contexto, acción y resultado sin imponer una implementación innecesaria. Por ejemplo: “Dada una solicitud pendiente asignada a Ana, cuando Ana la aprueba, cambia a aprobada, registra fecha y persona, y deja de ofrecer aprobar”. Añade casos de permiso, dato inválido, reintento y concurrencia cuando cambien el resultado. Evita “funciona correctamente”, “es intuitivo” o “carga rápido”: sustitúyelos por comportamientos o umbrales que dos personas puedan observar igual.

Azure Boards permite asociar criterios de aceptación a elementos de trabajo y los presenta como condiciones que deben cumplirse para considerar terminado el trabajo. La herramienta es secundaria; una tabla puede bastar. Lo esencial es que cada criterio tenga un identificador, ejemplos y resultado esperado, y que producto y desarrollo lo revisen antes de construir. Los criterios no reemplazan pruebas exploratorias, pero evitan que la aceptación dependa de memoria o impresiones.

Separa aceptación, terminado y lanzamiento

Aceptar una historia confirma su comportamiento; considerar una entrega terminada añade calidad común: revisión, pruebas relevantes, accesibilidad, seguridad, documentación operativa y despliegue. Lanzar implica además datos preparados, usuarios formados, soporte y un plan de vuelta atrás. Si se mezclan, una función aprobada en una demo puede aparecer como lista para uso real aunque falten permisos, migración o seguimiento de errores.

La Guía Scrum explica que la Definición de Terminado crea una comprensión compartida de la calidad exigida al incremento. Puedes aplicar esa idea sin adoptar todo Scrum: redacta entre cinco y diez condiciones comunes y mantenlas separadas de los criterios específicos. Para un piloto, incluye al menos registro de incidencias, dueño operativo, recuperación y tratamiento de datos coherente con el uso previsto.

Acuerda cómo medir y qué decisión seguirá

Relaciona la hipótesis con una métrica de resultado y otra de protección. Ejemplo hipotético: reducir de dos días a cuatro horas el tiempo mediano de aprobación, sin aumentar solicitudes devueltas por datos incompletos. Define línea base, muestra mínima razonable, periodo y fuente. Las visitas o registros solo prueban exposición; para una herramienta de trabajo interesan finalización, tiempo, errores, excepciones y ayuda necesaria.

Cierra la ficha con tres decisiones posibles: ampliar, corregir y repetir, o detener. Pon fecha y responsable. Así el MVP deja de ser una primera versión que acumula funciones indefinidamente. Si necesitas transformar la ficha, los criterios y el piloto en una entrega, el servicio de aplicaciones a medida ofrece el marco adecuado para trabajar el proceso completo. La conversación inicial debería terminar con preguntas explícitas y pruebas previstas, no con un catálogo cerrado de pantallas.

Acepta también el cambio de uso y de alcance

El producto no termina cuando una prueba técnica pasa. Define responsables, formación y señales de uso con la guía de adopción de software en la empresa. Para solicitudes posteriores, aplica un proceso explícito de cambios de alcance y presupuesto que proteja la línea base sin bloquear decisiones útiles.