Una cotización de MVP debe describir el recorrido que se entregará, sus usuarios, datos, integraciones y criterios de aceptación. Contar pantallas no basta. Define qué hipótesis valida la primera versión y qué queda fuera, conservando los controles necesarios para operar con seguridad y recuperar fallos.
APLICABILIDAD
¿Dónde importa esta decisión?
- Empresas de servicios
- Equipos de marketing y operaciones
Define una primera entrega completa y limitada
Describe quién realiza qué tarea y cómo se confirma su resultado. Una primera versión puede cubrir un único proceso, pero debe contemplar sus excepciones esenciales. Por ejemplo, registrar una solicitud requiere saber quién puede verla, cómo se modifica y qué ocurre si faltan datos. El alcance no termina cuando una pantalla guarda información.
Distingue funciones necesarias para validar la hipótesis de mejoras que pueden esperar. No uses “MVP” para justificar ausencia de permisos o pérdida de datos. Seguridad y continuidad deben ser proporcionales al riesgo del uso previsto. Una demostración con datos ficticios y una aplicación utilizada por clientes tienen criterios de aceptación distintos.
Haz comparables las propuestas
Entrega a los proveedores el mismo proceso, integraciones y condiciones. Solicita supuestos, exclusiones y dependencias: disponibilidad de API, acceso a entornos, migración y decisiones pendientes. Si una propuesta incluye soporte y otra no, sus importes no son directamente comparables. Revisa costos de terceros y operación posterior por separado del desarrollo inicial.
Ejemplo de criterio: un usuario autorizado crea una solicitud, otro rol la revisa y queda un historial del cambio; un usuario sin permiso no puede acceder mediante una URL directa. OWASP recomienda validar autorizaciones en cada solicitud. Una prueba así permite verificar una entrega mejor que expresiones generales como “panel completo y seguro”.
Acuerda cambios, transferencia y puesta en marcha
Define cómo se estimarán cambios de alcance y quién los aprobará antes de implementarlos. Conserva un registro de decisiones para evitar que una conversación informal sustituya requisitos. Pide entregables de transferencia: código según acuerdo, documentación, accesos, despliegue y procedimientos de recuperación. Aclara propiedad y licencias con los responsables contractuales correspondientes.
La aceptación debe incluir pruebas del recorrido crítico y una operación posterior conocida. No declares terminado un MVP porque compile o porque funcione en la computadora de quien lo desarrolló. Verifica el entorno acordado, registros de errores y capacidad del equipo para utilizarlo. Si una dependencia impide validar, déjala explícitamente pendiente en lugar de convertirla en una aprobación ficticia.
ENTIDADES ANALIZADAS
FUENTES
Referencias utilizadas.
- Diseño y validación de autorizacionesOWASP Cheat Sheet Series
PREGUNTAS FRECUENTES
Respuestas breves para decidir.
¿Puedo cotizar solo con una lista de pantallas?
Sirve como inicio, pero faltan reglas, permisos, datos e integraciones. Describe recorridos y excepciones para que las propuestas cubran un alcance comparable.
¿Qué puede quedar fuera del MVP?
Funciones que no sean necesarias para validar el recorrido acordado. Los controles esenciales de seguridad y continuidad deben mantenerse según el riesgo del uso real.
¿Cómo se aceptará la entrega?
Con pruebas y criterios definidos previamente: usuarios, acciones, resultados y excepciones. Incluye entorno, transferencia y operación, no únicamente una demostración visual.