Prototipo, MVP o prueba de concepto

Empieza por la decisión, no por el nombre

Pregunta qué incertidumbre bloquea la siguiente decisión responsable. Si el equipo no entiende el recorrido, puede necesitar un prototipo. Si el producto depende de una API, cálculo o interacción física incierta, puede necesitar una prueba de concepto. Si problema, camino y frontera operativa están suficientemente claros y hace falta evidencia de uso real, puede necesitar un MVP. La pregunta selecciona el artefacto, no la etiqueta que parezca más avanzada.

Escribe la decisión en una frase. Nombra quién usará o inspeccionará el artefacto, dónde se ejecutará, qué datos podrá tocar y qué resultado cambiaría el plan. Añade lo que no podrá demostrar. Así una demostración no se convierte en compromiso de producción accidental y un éxito técnico acotado no se presenta como validación de todo el negocio.

Usa un prototipo para aprender sobre la experiencia

Un prototipo puede ir de un dibujo a un flujo interactivo realista. Su función es hacer visible una idea, facilitar conversación y comprobar cómo se entiende o recorre una experiencia. La fidelidad debe corresponder a la pregunta. Un artefacto sencillo puede servir mejor para comparar estructura, mientras una interacción más realista puede ser necesaria para observar una tarea compleja. El equipo debe poder modificarlo o descartarlo.

Protege sus límites. Etiqueta el prototipo, controla el acceso cuando pueda confundirse con un servicio real y evita credenciales activas o datos de producción. Su código puede omitir seguridad, rendimiento, recuperación y mantenimiento necesarios para publicar. La guía oficial de GOV.UK separa explícitamente herramientas de prototipado y servicios reales. Reutilizar código requiere una nueva revisión de ingeniería, no una copia automática.

Usa una prueba de concepto para aislar viabilidad técnica

Una prueba de concepto comprueba una afirmación estrecha: si una integración intercambia datos representativos, un cálculo cumple una restricción o una arquitectura tolera un fallo relevante. Define entrada, entorno, condición de éxito y exclusiones. El alcance debe hacer que el éxito tenga un significado claro y que el fracaso también produzca información para la decisión siguiente.

La prueba no establece que las personas quieran el producto, que el recorrido completo sea usable o que la implementación pueda operarse con seguridad. Puede usar datos sintéticos, infraestructura temporal o permisos simplificados. Registra esas diferencias. Si el código continúa, revisa dependencias, secretos, datos, fallos, licencias, rendimiento y propiedad como material nuevo. La viabilidad es una capa de evidencia, no una aprobación de lanzamiento.

Usa el MVP para un recorrido real completo y acotado

Un MVP debe conservar un resultado significativo de principio a fin para el usuario previsto. Puede tener pocas funciones, pero el camino elegido debe ser coherente para generar evidencia interpretable. Define acceso, soporte, medición y decisión que usarán los resultados. Reducir hasta dejar pantallas incapaces de completar la tarea produce un instrumento de aprendizaje débil aunque sea pequeño técnicamente.

Como el MVP se publica y no solo se demuestra, puede requerir autenticación, autorización, privacidad, accesibilidad, errores, observabilidad y recuperación según el contexto. Mínimo no significa exento de salvaguardas importantes. Un despliegue correcto prueba entrega a un entorno en un momento. No prueba por sí solo uso repetido, satisfacción, ingresos ni un mercado duradero.

Encadena solo los artefactos que reduzcan incertidumbre

No es obligatorio construir los tres en un orden fijo. Un equipo puede pasar de un prototipo en papel al MVP cuando la viabilidad es conocida, o probar primero una dependencia capaz de invalidar la idea. También puede detenerse si la evidencia muestra un problema débil o una carga operativa injustificada. Saltar un artefacto innecesario es disciplinado cuando el registro explica la decisión.

En cada transición registra aprendizaje, supuestos pendientes, código o datos reutilizables y quién aprueba el siguiente nivel de exposición. La metodología de IVRYN separa implementación, entrega pública y resultados externos. Aplica la misma separación. Prototipo, prueba de concepto y MVP ayudan cuando cada uno tiene una afirmación acotada y una decisión nombrada, no cuando forman una escalera de éxito implícito.

Criterios de decisión

Aplica las mismas preguntas a cada opción antes de elegir.