Por Thomas Cohen, fundador de Maestro
Prototipo, MVP o aplicación: ¿cuándo está lista para usuarios reales?
Un prototipo explora una idea; un MVP prueba un uso limitado. Antes de incorporar usuarios reales, comprueba el recorrido y reúne pruebas para autorizar un piloto.
Tu página muestra horarios disponibles. Una persona elige uno, pulsa «Reservar» y ve una confirmación. Ya tienes algo que enseñar. Para decidir si puedes recibir las citas del lunes, queda otra pregunta: ¿qué ha ocurrido realmente después de ese clic?
Esta guía trata sobre prototipos de aplicaciones, no sobre objetos físicos. Seguiremos a Élise, que organiza sesiones de fotografía en un ejemplo ficticio. Su página de reservas explora primero un recorrido, después un uso limitado y finalmente un funcionamiento habitual. Los resultados descritos son ejemplos didácticos, no pruebas realizadas con un cliente.
Cuatro términos que implican compromisos diferentes
Los equipos no siempre utilizan estas palabras de la misma manera. Estas son nuestras referencias para concretar tus expectativas con quien construye la aplicación. No son definiciones universales.
- Prototipo: una representación o versión para examinar una idea y un recorrido, con operaciones que pueden estar simuladas.
- MVP: una primera versión limitada para aprender si un uso aporta el valor esperado. Son las siglas inglesas de producto mínimo viable.
- Aplicación utilizable: una versión que completa el recorrido previsto en condiciones definidas y comprobadas.
- Producto en funcionamiento: una aplicación de uso habitual con seguimiento, ayuda a los usuarios y responsables identificados.
El método Lean Startup presenta el MVP como una forma de aprender a partir de un primer producto. «Mínimo» describe el alcance de la prueba, no un permiso para ignorar lo que la hace fiable.
Estos términos pueden solaparse. Un MVP puede ser utilizable por unas pocas personas; un prototipo puede contener código real. Aclara el compromiso: ¿qué puede hacer el usuario, con qué datos y quién interviene si el resultado es incorrecto?
Una reserva, tres etapas que observar
En la primera etapa del ejemplo, Élise muestra horarios inventados. Pulsar «Reservar» abre una página de confirmación, pero no guarda ninguna reserva. El prototipo permite comentar el vocabulario, el orden de los pasos y la información solicitada. No sirve para llenar su agenda real.
En la segunda etapa, prepara un MVP para un solo tipo de sesión y unas pocas personas. Elegir una hora crea una reserva guardada que Élise puede consultar. Los pagos siguen gestionándose como antes y esa limitación se explica. Quiere saber si las personas terminan la reserva sin tener que llamarla.
En la tercera etapa prevista, la reserva se convierte en un servicio de uso habitual. Hay que saber quién abre los horarios, vigila los problemas, gestiona una cancelación y recupera la información después de una avería. No se llega a esta etapa simplemente añadiendo un botón «Publicar».
Distingue lo simulado de lo guardado
Antes de una demostración, enumera las operaciones: qué cambia, dónde se guarda y cómo recuperarlo. Puede aparecer una animación de carga o un mensaje verde sin que el trabajo anunciado se haya realizado.
En la página de Élise, separa los horarios mostrados, la creación de la reserva, el envío del mensaje y la actualización del calendario. Una operación puede funcionar mientras la siguiente sigue simulada. Explicarlo evita sacar una conclusión general de una sola pantalla convincente.
El Service Manual de GOV.UK explica que un prototipo con código puede parecer un servicio real sin cumplir los mismos requisitos. Su apariencia no basta para justificar su uso en producción.
- Hora mostrada: ¿procede de una lista inventada o de la disponibilidad guardada?
- Reserva confirmada: ¿existe después de cerrar y volver a abrir el navegador?
- Mensaje enviado: ¿se ha recibido realmente en la dirección de prueba?
- Calendario actualizado: ¿Élise encuentra la misma reserva desde su cuenta?
Empieza con nombres y direcciones de prueba. Distingue lo observado, lo pendiente de comprobar y lo simulado. «No probado» es útil; «debería funcionar» convierte una incógnita en una falsa seguridad.
Describe una acción completa, de la necesidad al resultado
Para decidir si el MVP es utilizable, elige una acción que la persona deba poder terminar. En el ejemplo: encontrar una hora libre, reservar una sesión y recuperar la confirmación. Élise también debe poder consultar esa reserva para preparar la cita.
Define el resultado esperado antes de probar. Por ejemplo: existe una sola reserva para la hora elegida, la persona encuentra la fecha correcta y Élise ve la misma cita. «El botón funciona» no dice nada sobre esos tres resultados. Una comprobación escrita ayuda a hablar de lo mismo.
Prueba también en las condiciones previstas: móvil si los clientes reservarán desde el móvil, acceso de Élise para gestionar el calendario y una cuenta de prueba distinta para el participante. Una demostración realizada únicamente con una cuenta que puede modificarlo todo no representa esos usos diferentes.
No cambies el criterio sin decirlo después de ver el resultado. Si falta el envío de confirmaciones, puedes decidir enviarlas manualmente durante el piloto. Escribe ese funcionamiento, su responsable y sus límites. Será una decisión explícita de alcance, no un éxito inventado de la automatización.
Prueba los fallos que cambian la decisión
Un recorrido correcto no cubre las situaciones que hacen ambigua una reserva. En la versión ficticia de Élise, las comprobaciones decisivas incluyen una hora ya ocupada, un clic repetido y dos personas intentando reservar a la vez. Cada caso necesita una respuesta esperada y una observación precisas.
Para las solicitudes simultáneas, prepara dos cuentas y la misma hora libre. Activa las peticiones al mismo tiempo, con ayuda de quien desarrolla la aplicación si hace falta. Después comprueba los registros, no solo los mensajes. Según nuestra regla ficticia, únicamente debe aceptarse una reserva para esa hora.
Con el clic repetido, comprueba que la impaciencia no genera dos citas. Con información incorrecta, observa si la persona entiende cómo corregirla. Para una cancelación, revisa tanto la confirmación recibida como el estado del calendario. Cada comprobación responde a una consecuencia real del recorrido.
Esta lista no sustituye una revisión técnica completa. La guía de riesgos de una aplicación creada con IA profundiza en accesos, datos y cambios. Aquí buscamos identificar las pruebas que faltan antes del siguiente ensayo con usuarios.
Prepara la recuperación antes de confiar citas a la herramienta
La recuperación plantea dos preguntas distintas: recuperar un funcionamiento utilizable y recuperar la información. Volver a una versión anterior del código no restaura necesariamente las reservas. Una copia de datos no hace que el servicio vuelva a funcionar por sí sola. Pide una explicación concreta de ambas cosas.
En el ejemplo, Élise quiere saber dónde encontrar las citas confirmadas si la página deja de estar disponible. Una persona designada prepara la recuperación y la prueba con datos ficticios. El informe indica qué vuelve, qué falta y qué intervenciones siguen siendo manuales, sin prometer un plazo nunca medido.
Prepara también el tratamiento de las reservas recibidas después de la copia utilizada para restaurar. De lo contrario, podrías recuperar un calendario aparentemente normal y perder las últimas solicitudes. El expediente para autorizar el piloto debe identificar quién detectará y recuperará esas diferencias.
Prepara un registro sencillo de pruebas
Puede bastar un documento compartido. Reúne las comprobaciones que justifican una prueba o su ampliación. Una captura no siempre es suficiente: para una reserva, anota también el registro guardado, el mensaje recibido y la versión examinada.
Para cada comprobación, copia esta plantilla y rellena los corchetes. No es un certificado de calidad: permite entender los hechos y las responsabilidades, incluso a alguien que no presenció la prueba.
- Versión y fecha: [versión examinada, fecha y entorno de prueba].
- Situación inicial: [usuario, datos de prueba, estado del calendario].
- Acción realizada: [gesto exacto o secuencia de acciones].
- Resultado esperado: [qué debe ocurrir y qué debe mantenerse].
- Resultado observado: [hechos constatados, incluidas las diferencias].
- Evidencia conservada: [captura, mensaje, registro o informe que se pueda encontrar].
- Responsabilidad: [persona que comprueba y persona que corrige si hace falta].
- Decisión: [corregir, continuar la prueba prevista o suspender].
- Siguiente paso y límite: [próxima acción, responsable y condición para revisar la decisión].
Conserva pruebas sin información sensible, en lugar de difundir los datos de contacto de los participantes. Una fila sin resultado observado sigue siendo una comprobación pendiente, aunque el resultado esperado esté muy claro.
Dos ejemplos completos para decidir con pruebas
Ejemplo ficticio: una reserva normal
Versión: prueba A, 26 de septiembre, entorno de prueba. Situación: una cuenta ficticia de participante, una hora libre y el calendario de Élise abierto por separado. Acción: reservar, cerrar y volver a abrir la confirmación. Resultado esperado: una reserva única que siga disponible, con la misma hora en el calendario.
Resultado observado en este ejemplo inventado: la reserva sigue visible al volver a abrir y ambas vistas muestran la misma hora. Evidencias: referencia de la reserva de prueba, capturas de ambas vistas e informe. Responsable de comprobación: Élise. Decisión: continuar las comprobaciones previstas; este resultado por sí solo todavía no autoriza el piloto.
Ejemplo ficticio: dos personas eligen la misma hora
Versión: la misma prueba A. Situación: dos cuentas ficticias y una sola hora libre. Acción: confirmar ambas solicitudes a la vez. Resultado esperado: una sola reserva aceptada; la otra persona recibe una explicación y puede elegir otro horario. Resultado observado inventado: ambas peticiones muestran «confirmado» y existen dos reservas.
Decisión: suspender el inicio del piloto y corregir el fallo. Responsable: quien desarrolla la aplicación; Élise comprobará después el resultado con esa persona. Evidencias: las dos referencias y el informe de simultaneidad. Condición para reanudar: repetir este caso tras corregirlo y después la reserva normal para comprobar que sigue funcionando.
Evita el resumen «una prueba superada de dos». El segundo resultado impide el uso previsto aunque el primero sea correcto. Decide según las consecuencias del fallo, no según un promedio que asigne el mismo peso a cada comprobación.
Inicia un piloto con límites comprensibles
Una vez corregidos y comprobados los bloqueos, concreta participantes, alcance y fecha de revisión. El Service Manual de GOV.UK describe una beta privada limitada antes de una apertura más amplia. Aquí adaptamos esa progresión a un proyecto pequeño.
En el piloto ficticio, Élise invita a unas pocas personas para un solo tipo de sesión. Explica cómo comunicar un problema y otra forma de contactar con ella. Sabe qué lista de citas es la referencia. Si mantiene un registro paralelo, asigna quién conciliará ambas listas y cuándo.
Escribe qué detendrá la prueba: una reserva perdida, un duplicado sin resolver o la imposibilidad de identificar a las personas afectadas, según los riesgos del recorrido. Decide quién puede suspenderla y cómo se informará a los participantes. «Ya veremos si ocurre» no prepara la decisión.
Un piloto no necesita convertirse en un gran proyecto organizativo. Necesita reglas comprensibles y una persona a la que contactar. Para repartir responsabilidades entre compañeros, la guía de aplicaciones internas para equipos pequeños explica el trabajo conjunto.
Decide si corregir, continuar o suspender
En la fecha acordada, revisa las pruebas y los problemas comunicados durante el piloto. Corregir significa resolver una diferencia antes del siguiente paso. Continuar significa autorizar un alcance concreto. Suspender significa detener la prueba afectada y volver al procedimiento alternativo previsto. Ninguna decisión autoriza todos los usos futuros.
Si las reservas son coherentes pero los participantes siguen llamando para entender cuánto duran las sesiones, la prueba ha revelado un problema de comprensión. Si terminan la reserva pero Élise vuelve a introducir todo en otra herramienta para trabajar, el recorrido sigue incompleto para ella. Estas observaciones indican qué modificar después.
Para un uso habitual, identifica quién vigila las incidencias, mantiene la aplicación y revisa las comprobaciones después de los cambios. Conserva los límites conocidos. «Utilizable para este recorrido» es una conclusión acotada, no una promesa de que nunca habrá errores.
Prepara tu próxima versión
Empieza con una frase: «Esta versión debe permitir que [persona] termine [acción]; decidiremos los siguientes pasos a partir de [pruebas]». Después enumera lo simulado, elige la primera comprobación pendiente y nombra a su responsable. Tendrás un siguiente paso verificable en lugar de una estimación vaga de lo que falta.
Si vas a pedir un presupuesto, la guía de costes de un MVP ayuda a calcular el alcance elegido. Pregunta por separado por preparación, pruebas y seguimiento necesario. Pasar al piloto depende de ese trabajo, aunque construir la primera demostración haya sido rápido.
Maestro ayuda a organizar el desarrollo con agentes de IA; no convierte automáticamente una demostración en una aplicación lista para usar. Su beta por invitación está disponible para Mac, con la aplicación gratuita y el uso de IA aparte. La presentación de Maestro explica ese proceso. Las pruebas y la decisión de uso deben establecerse para tu proyecto.