Una demo demuestra que una idea puede funcionar en un recorrido concreto. Te ayuda a explicar el producto y a comprobar si el flujo tiene sentido. Antes de que los clientes dependan de ella, también hay que entender qué pasa con usuarios distintos, datos reales e interrupciones.
Esto vale tanto si el prototipo salió de una plantilla como de una herramienta de IA, un equipo interno o un desarrollador anterior. Yo evaluaría lo que ya es útil, identificaría las carencias y planificaría el trabajo en torno a los riesgos que importan para este producto.
Anota qué es real y qué está simulado
Un prototipo puede mostrar registros de ejemplo, simular un pago o dar por hecho que todas las peticiones salen bien. Haz una lista de esos supuestos. Una pantalla que muestra una reserva correcta puede necesitar todavía reglas de disponibilidad, una conexión de pago y un registro fiable de la reserva.
Conserva las partes útiles de la demo. La revisión debería explicar qué puede quedarse, qué hay que cambiar y qué no se ha verificado todavía. Solo mirando las pantallas no se puede saber qué es cada cosa.
Comprueba qué puede hacer cada persona
Describe los roles de tu producto y qué puede ver o cambiar cada uno. Ocultar un botón de administración en la interfaz es solo una parte; las acciones y los datos protegidos también tienen que controlarse en el servidor.
En un portal de clientes, por ejemplo, comprueba que un cliente no puede ver los registros de otro y que retirar el acceso a un miembro del equipo tiene el efecto esperado. ElOWASP Application Security Verification Standard es una referencia para organizar la verificación de seguridad de una aplicación. Las comprobaciones que elijas para tu producto deberían reflejar sus datos y sus riesgos.
Repasa los fallos y las acciones repetidas
Un cliente puede perder la conexión, recargar una página, enviar algo dos veces o volver después de que una integración agote el tiempo de espera. Necesitamos un resultado acordado para esas situaciones, sobre todo cuando hay dinero, inventario o registros importantes de por medio.
¿Qué debería pasar si un pago queda pendiente o falla?
¿Puede alguien reintentar una petición sin riesgo de crear un duplicado?
¿Qué verá el usuario si falla una subida o una notificación?
¿Cómo encuentra y resuelve el equipo una operación incompleta?
En el ejemplo de reservas, varios clics seguidos no deberían crear varias reservas para una sola compra. La implementación adecuada depende del proveedor de pagos y de las reglas de reserva; ese comportamiento forma parte del alcance y de las pruebas.
Usa datos representativos y flujos realistas
Prueba nombres largos, listas vacías, historiales grandes, campos que faltan y los dispositivos que usará la gente. Un panel con cinco filas de ejemplo no muestra cómo alguien encuentra un registro entre miles. Usa datos de prueba adecuados en lugar de copiar información privada de clientes en una vista previa sin protección.
Si hay que migrar registros existentes al producto, planifica la correspondencia de campos, una importación de prueba y las comprobaciones. Decide cómo tratar los registros duplicados o incompletos y qué pasa con los cambios hechos durante la migración.
Deja explícito el plan de publicación y recuperación
Ten claro quién es el titular de las cuentas de hosting y de los servicios, qué configuración hace falta y cómo llega la versión al entorno correcto. Antes de que un cambio salga a producción, acordemos las comprobaciones y la forma de volver atrás si causa problemas.
Recuperarse puede implicar algo más que restaurar una versión anterior del código. Un cambio en los datos guardados necesita su propio enfoque. El equipo debería saber qué copias de seguridad existen, cómo restaurarlas y qué comprobaciones confirman que el producto funciona después.
Lanza para aprender, con alguien responsable del servicio
Un lanzamiento controlado para un grupo adecuado puede sacar a la luz problemas antes de abrir el acceso. Decide cómo se recogerán los comentarios y los errores, quién responde y qué te haría pausar o revertir el despliegue. Laguía de GOV.UK sobre la fase beta describe cómo usar un lanzamiento limitado para aprender y mejorar antes de abrir un servicio a más gente.
El recorrido principal lo ha comprobado: …
Los permisos y los fallos importantes los ha comprobado: …
Las limitaciones que quedan son: …
Los pasos de publicación y recuperación están documentados en: …
La persona que gestiona los comentarios y las incidencias es: …
Ampliaremos el acceso cuando: …
Son preguntas para planificar, no una certificación de seguridad. La cantidad de verificación debería ir en proporción al producto y a las consecuencias de un fallo. Si tienes un prototipo,cuéntame qué funciona ya y qué quieres lanzar. Podemos revisar juntos los siguientes pasos.