Una demostración es un camino elegido. Se enseña la pantalla que funciona, con datos que alguien preparó, en el navegador donde se probó. Producción es lo contrario: son todos los caminos a la vez, con datos que nadie preparó y en el móvil de un usuario que tiene prisa.
Casi todo lo que hay entre una cosa y la otra es invisible para quien ve la aplicación por primera vez, y es justo lo que decide cómo va a envejecer el proyecto.
Los datos, antes que las pantallas
Lo primero que revisamos no es la interfaz. Es qué pasa cuando llega un dato que nadie esperaba: un campo vacío que debería ser obligatorio, un importe con coma en lugar de punto, una fecha en formato americano, un nombre con apóstrofo, el mismo formulario enviado dos veces porque el usuario no vio el aviso.
Una validación floja no se nota el primer día. Se nota tres meses después, cuando hay que limpiar la base a mano y nadie sabe qué registros son buenos.
Aquí entra también una pregunta que conviene hacerse antes y no después de una incidencia: qué datos personales se están guardando y si hacen falta todos. Los que no hacen falta son riesgo sin contrapartida.
Permisos: lo que la interfaz esconde y la ruta enseña
Después van los accesos. Quién ve cada pantalla, quién puede modificar, qué ocurre si alguien escribe a mano la dirección de una página del panel de administración.
Es más habitual de lo que parece: la interfaz oculta el botón y la ruta sigue abierta por detrás. Un usuario normal nunca lo encontrará; cualquiera que mire el código del navegador, sí.
En el mismo bloque miramos cabeceras de seguridad, caducidad de sesión y el trato de los ficheros que sube el usuario, que es uno de los sitios clásicos por donde entra un problema serio.
Errores: que se vean, pero solo quien debe verlos
Un proyecto listo para producción no es uno que no falla. Es uno que cuenta lo que falla. Los errores tienen que quedar registrados con información suficiente para reproducirlos, y el visitante tiene que ver una página decente, no una traza con rutas del servidor.
Con esa base, revisar el registro una vez por semana deja de ser una tarea pesada y ayuda a encontrar problemas antes de que los cuente un cliente. Los registros permiten investigar problemas que una demostración no revela.
Rendimiento, accesibilidad y SEO técnico van juntos
Los tratamos como criterios de entrega: si se dejan para un repaso indefinido, pueden quedar fuera del trabajo.
Imágenes servidas en el tamaño que toca, carga razonable en móvil con datos reales y no con tres registros de prueba, estructura de encabezados coherente, contraste suficiente, foco visible, navegación con teclado, metadatos y contenido indexable.
Son criterios de entrega, no un repaso final. En eso no hemos cambiado de opinión desde que lo contamos en SEO técnico y accesibilidad, y sigue siendo la parte que más deuda genera cuando se aplaza.
Publicar es una operación, no un botón
Antes de publicar conviene tener respuesta a cuatro preguntas: hay copia de seguridad reciente y probada, en qué orden suben los cambios, quién mira qué durante la primera hora y cómo se vuelve atrás.
Si la vuelta atrás no está pensada, no hay plan de despliegue. Hay un deseo.
Y un detalle pequeño que dice mucho de cómo se ha trabajado: ningún dato de prueba debería sobrevivir al estreno. Ni el usuario «test», ni la reserva de las 9:00 que alguien creó para comprobar el formulario.
Lo que cambia cuando alguien revisa el trabajo
Una revisión útil necesita distinguir un detalle que puede esperar de una condición que impide publicar. Un texto mejorable y un permiso que deja acceder a información ajena no tienen el mismo peso. Si todo se presenta como una urgencia, el equipo pierde el criterio justo cuando más lo necesita.
Por eso, al revisar conviene explicar qué comportamiento falta, cómo se ha comprobado y qué consecuencia tiene. El comentario que dice «esto está mal» obliga a adivinar. El que describe cómo se reproduce el problema permite corregirlo y volver a comprobarlo. Esa forma de conversar aporta tanto al proyecto como al aprendizaje de quien está haciendo la tarea.
Es una conexión directa con cómo planteamos las prácticas. El alumno necesita aprender a entender la petición, preparar un cambio y responder a una revisión. El cliente necesita que la entrega haya pasado por ese mismo recorrido con responsabilidad. La formación y la calidad del servicio comparten una exigencia: explicar qué se ha hecho y qué se ha verificado.
Una tarea pequeña permite aprender ese ciclo sin asumir un alcance que todavía no se domina. Una tarea grande sigue necesitando límites, revisión y pruebas. El tamaño del cambio no es un permiso para saltarse el método.
Qué recibe el cliente además de una aplicación
Quien contrata un desarrollo debería saber qué se ha comprobado y qué límites conserva la entrega. Una revisión no equivale a prometer que el software nunca tendrá un fallo. Sirve para reducir problemas previsibles, identificar lo que sigue abierto y preparar la respuesta cuando aparezca una incidencia.
Eso cambia el cierre de un proyecto. En lugar de limitarse a mirar si la pantalla se parece a la propuesta, se puede comprobar si el usuario realiza su trabajo, si la información queda bien guardada y si cada persona accede a lo que le corresponde. También se puede explicar cómo pedir ayuda y qué parte de la operación necesita seguimiento.
En nuestra metodología de entregas con alcance acordado, terminar implica poder enseñar el resultado y contrastarlo con el objetivo. La revisión aporta una base concreta para esa conversación. No sustituye el criterio de negocio del cliente; ayuda a que ese criterio tenga una aplicación que se pueda utilizar.
Una lista corta para mirar tu próxima entrega
Antes de aceptar la publicación, prueba un recorrido real con información que se parezca a la de tu empresa. Comprueba qué sucede cuando un dato falta, si alguien repite una acción y qué ve una persona con menos permisos. Pide que se explique cómo se sabe que una operación ha terminado correctamente.
Después pregunta quién atiende un error, dónde queda registrado y cómo se revierte un despliegue que sale mal. Si esas respuestas no existen, conviene completar el trabajo antes de que una incidencia obligue a improvisarlo. Que la demostración haya funcionado es una buena señal, pero no responde a esas preguntas.
No necesitas convertirte en especialista en todas las tecnologías del proyecto. Sí necesitas una explicación comprensible de lo que se entrega y de las condiciones que lo hacen usable. Esa explicación forma parte del trabajo de un equipo que asume la revisión.
¿Tu aplicación está a punto de salir o ya te está dando problemas?
En AbacoQD podemos ayudarte a revisar la base de una aplicación y decidir qué necesita para publicarse o seguir evolucionando. El trabajo puede estar en permisos, datos, rendimiento, funcionamiento del proceso o preparación del despliegue; el alcance se concreta a partir del sistema real.
Reserva una conversación y cuéntanos qué hace la aplicación, quién depende de ella y qué te preocupa de la próxima entrega. Si prefieres escribirnos, contacta sobre la mejora de tu software. Podemos empezar revisando lo que ya tienes y ordenar el siguiente paso con criterio.