El documento de requisitos para la renovación del sitio web debe convertir «por qué se renueva, hasta qué punto y cómo se realizará la entrega» en acuerdos aplicables. Tanto si el documento se denomina documento de requisitos para la renovación del sitio web como cahier des charges refonte site internet en francés, debe permitir que todas las partes determinen el alcance, el presupuesto, el calendario y los criterios de aceptación basándose en el mismo material. Al redactarlo, primero confirme los problemas actuales y los objetivos; después, concrete por separado las páginas, las funciones, la migración de datos y las responsabilidades de la puesta en marcha.
Los objetivos de la renovación deben estar vinculados a acciones empresariales concretas, como aumentar las consultas cualificadas, permitir la publicación de contenido en varios idiomas o reducir las dificultades para completar formularios en dispositivos móviles. Para cada objetivo, especifique la situación actual, el cambio esperado y cómo se medirá. Por ejemplo, para el objetivo de consultas, puede acordar que se contabilicen los contactos cualificados enviados mediante formularios y definir claramente cómo se excluyen los envíos de prueba y el spam. Si no hay datos históricos fiables, acuerde establecer una línea de base y un periodo de observación después de la puesta en marcha, en lugar de inventar porcentajes de crecimiento.
En la descripción de la situación actual, registre la dirección del sitio web existente, la arquitectura técnica, las versiones lingüísticas, el número de páginas y los principales problemas; adjunte también el mapa del sitio actual, los datos de tráfico y capturas de pantalla de páginas representativas. Aunque tanto la caída de las visitas como la reducción de consultas parezcan motivos para renovar el sitio, sus causas pueden ser distintas: en el primer caso, hay que revisar la indexación y las fuentes de tráfico; en el segundo, también hay que comprobar los formularios, la información de los productos y el proceso de seguimiento. Separe los problemas confirmados de los aspectos pendientes de investigación para evitar que el proveedor trate una hipótesis como un requisito establecido.
Prepare una lista de páginas que incluya la página de inicio, las categorías de productos, las fichas de producto, la página «Quiénes somos» y la página de contacto, e indique cuáles se conservarán, rediseñarán, combinarán o eliminarán. En sitios con muchos productos, especifique qué páginas utilizarán una misma plantilla y cuáles requerirán un diseño propio. Indique también los tipos y la cantidad estimada de contenido que se migrará, así como qué parte se encargará de preparar las imágenes y los textos. Si el contenido aún no está listo, especifique la fecha de entrega y cómo se gestionarán los retrasos en el calendario.
Los requisitos funcionales deben describir las condiciones que activan una función y el resultado esperado, en lugar de limitarse a decir «añadir una función de consulta». Por ejemplo: cuando un visitante envíe una consulta sobre un producto, el sistema enviará una notificación a la dirección de correo electrónico indicada, conservará el registro del envío en el panel de administración y mostrará en la página si el envío se ha realizado correctamente o ha fallado. También deben confirmarse los campos obligatorios, las restricciones de los archivos adjuntos, el tratamiento del spam y los destinatarios de las notificaciones. Si se integra un sistema de gestión de clientes, especifique asimismo el método de integración, la correspondencia entre campos, el entorno de pruebas y quién se responsabiliza del mantenimiento de la interfaz.
En una renovación multilingüe, indique por separado los idiomas de destino, las páginas correspondientes y el origen de las traducciones. La traducción automática puede servir como borrador, pero los parámetros de los productos, la terminología del sector y los datos de contacto deben revisarse manualmente. También deben incluirse en los requisitos de permisos del panel de administración cuestiones como si los distintos idiomas compartirán un catálogo de productos y si se podrá modificar el contenido por separado. De lo contrario, la forma de mantener el contenido podría dar lugar a trabajo adicional incluso después de completar el diseño visual.
Si tiene previsto utilizar una plataforma SaaS para crear el sitio web, el documento de requisitos también debe especificar el grado de personalización de las plantillas, las opciones de exportación de contenido, los permisos de las cuentas y el tratamiento de los datos cuando venza el servicio. Por ejemplo, al evaluar el sistema de creación inteligente de sitios web y marketing SaaS de 易营宝, puede comprobar uno por uno los requisitos de edición multilingüe, adaptación a dispositivos móviles y gestión desde el panel de administración. El alcance concreto de la entrega se regirá por lo acordado para el proyecto.

La renovación de un sitio web suele implicar cambios en las URL. El documento de requisitos debe exigir la preparación de una tabla de correspondencias entre las URL antiguas y las nuevas, especificar las reglas para conservar, combinar o eliminar páginas y, cuando corresponda, establecer redirecciones permanentes. Si una página antigua tiene una página nueva claramente equivalente, no conviene redirigirla directamente a la página de inicio. Si no hay contenido de sustitución, debe acordarse por separado cómo se tratará. Antes de la puesta en marcha, también hay que verificar los títulos y las descripciones de las páginas, el mapa del sitio, las URL canónicas y la configuración de rastreo de los motores de búsqueda, para evitar que las restricciones del entorno de pruebas se mantengan en el sitio en producción.
Las herramientas de analítica existentes, los códigos de conversión publicitaria y la información de verificación de las plataformas de búsqueda también deben incluirse en la lista de migración. Para eventos como el envío correcto de un formulario o los clics en un número de teléfono, especifique las condiciones de activación y el método de aceptación, y distinga los datos de prueba de los datos reales. Si el sitio antiguo no ofrece un registro completo de la implementación del seguimiento, primero hay que confirmar los permisos de administración de las cuentas existentes y, después, organizar una revisión. La apariencia de una página por sí sola no permite determinar si el seguimiento de conversiones funciona correctamente.
Los requisitos de rendimiento también deben especificar las condiciones de las pruebas: las páginas, los tipos de dispositivos, el entorno de red, las herramientas utilizadas y los resultados aceptables. La velocidad de carga de la página de inicio no representa necesariamente el rendimiento de las fichas de producto ni de las páginas multilingües; las páginas con muchas imágenes o vídeos deben incluirse en una muestra específica. Si el sitio está dirigido a usuarios de todo el mundo, también hay que acordar las regiones y los horarios de las pruebas: no se debe evaluar la experiencia general basándose en un único resultado.
Divida el calendario en etapas definidas por resultados que puedan confirmarse, como la aprobación de requisitos, el diseño de páginas, el desarrollo y la migración de contenido, las pruebas y la puesta en marcha. Para cada hito, indique los entregables, la persona responsable de aprobarlos y el plazo para enviar comentarios. Si, una vez aprobado el diseño, se añaden páginas o cambia la lógica de una función, registre los cambios y vuelva a evaluar el calendario y los costes para evitar que las modificaciones verbales se acumulen continuamente.
Los criterios de aceptación deben poder comprobarse mediante acciones concretas. Puede acordarse revisar la disposición de las páginas en navegadores y dispositivos móviles determinados, enviar formularios con una dirección de correo electrónico de prueba y verificar los registros en el panel de administración, así como comprobar mediante muestreo las páginas migradas y las redirecciones. Registre los defectos según su impacto: los problemas que impidan recibir consultas o acceder a una página deben tratarse por separado de los problemas de presentación, como el espaciado del texto; especifique también cómo se repetirán las pruebas después de las correcciones. La aceptación debe cubrir todas las versiones lingüísticas acordadas, no solo la página de inicio en el idioma principal.
Además del sitio web en producción, la lista de entrega debe incluir los permisos del dominio y de las cuentas relacionadas, la documentación de uso del panel de administración, las listas de páginas y funciones, la tabla de redirecciones, los registros de pruebas y la documentación de configuración necesaria. Si se utilizan sistemas de terceros, acuerde el alcance real de la entrega del código fuente o los datos, sin incluir por defecto entregables que no puedan proporcionarse.
Antes de la puesta en marcha, confirme la configuración DNS del dominio, los certificados, las copias de seguridad y la ventana de publicación, y asigne las responsabilidades de ejecución y aprobación de cada etapa. Especifique dónde se guardará la copia de seguridad del sitio antiguo, cómo se restaurará y cómo se verificará que puede utilizarse. Si después de la puesta en marcha deja de funcionar un formulario o una página clave queda inaccesible, acuerde las condiciones que activarán la suspensión de la publicación, la corrección o la reversión, así como los datos de contacto.
Después de la puesta en marcha, establezca un periodo de observación para comprobar el acceso a las páginas principales, las notificaciones de consultas, el rastreo de los motores de búsqueda y los eventos de conversión. Las condiciones de mantenimiento deben diferenciar la corrección de defectos de entrega de las nuevas solicitudes y especificar los canales de comunicación, el proceso de gestión y los plazos de respuesta. Una vez aprobado por ambas partes, el documento de requisitos debe conservar un historial de versiones; cualquier cambio posterior se regirá por el acuerdo actualizado.
Artículos relacionados
Productos relacionados


