Gestiona la web como un sistema empresarial.
Sistemas de gestión de contenidos
Un método neutral para comparar CMS mediante tareas de publicación propias, resultados observables, fallos previstos y evidencias verificables.
WebChorus Editorial Team8 min de lectura
Utilice los requisitos para cribar el mercado y decida entre los CMS finalistas haciendo que usuarios representativos ejecuten los mismos escenarios de publicación. Una demostración pulida puede enseñar que una plataforma publica una página, pero no necesariamente qué sucede cuando cambia el original de una traducción, se aprueba la revisión equivocada o falla un lanzamiento programado. Fije de antemano contenido, actores, estado inicial, resultado esperado, excepción y evidencias; después distinga lo demostrado del trabajo necesario para conseguirlo.
Criterios esenciales
El proceso debe empezar con puertas de entrada obligatorias y continuar con pruebas comparables entre los productos que las superen. Arquitectura, seguridad, accesibilidad, datos, condiciones legales, modelo comercial y soporte sirven para reducir la lista; no hace falta escenificar una opción que incumple una condición irrenunciable. La guía del Government Digital Service recomienda comprender el contexto y utilizar prototipos para comprobar necesidades, interfaces, datos, seguridad, cumplimiento y restricciones técnicas antes de un compromiso duradero.
A continuación, entregue a cada candidato la misma versión de las muestras, los mismos roles y el mismo estado inicial. Deben coincidir también el resultado esperado, la excepción y la condición de fallo. Las diez familias propuestas aquí forman un marco editorial adaptable, no una norma oficial. Su valor reside en impedir que cada proveedor elija el recorrido más favorable y en convertir una afirmación funcional en observaciones que el equipo comprador pueda comparar.
Cada ficha debe fijar la pregunta operativa, una muestra propiedad del comprador, los actores, el estado inicial exacto, la tarea normal, una variación significativa y el resultado observable. Incluya lo que no debe ocurrir. Defina además qué capturará el equipo: pantallas, páginas renderizadas, registros de auditoría, respuestas de API, exportaciones, marcas de tiempo, avisos y observaciones de los participantes. Así, la prueba conserva condiciones repetibles y no depende del relato posterior.
La ficha no pretende imponer un estándar de evaluación. Es un mecanismo práctico para que el comprador pueda reconstruir lo sucedido y separar capacidad de esfuerzo. La intervención del proveedor sigue siendo útil para explicar la configuración, pero conviene dejar que el usuario representativo intente primero el recorrido predeterminado. De ese modo quedan visibles las indicaciones necesarias, los pasos manuales y las diferencias entre una posibilidad técnica y una operación sostenible.
Una función promete que el CMS puede hacerlo; un escenario representativo muestra qué debe hacer su organización para lograrlo.
Los escenarios de autoría y revisión deben demostrar cómo trabajan personas reales y qué versión acaba publicada. Pida a un autor frecuente y a otro ocasional que creen el mismo artículo estructurado con encabezados, enlaces, imagen, texto alternativo, metadatos y contenido relacionado. Ambos deben previsualizarlo en tamaños relevantes. Añada un recorrido crítico solo con teclado y un error de validación o accesibilidad que deban detectar y corregir.
ATAG contempla tanto la accesibilidad de la herramienta para autores con discapacidad como su ayuda para producir contenido accesible, aunque este ejercicio limitado no acredita conformidad con ATAG o WCAG. Para la revisión, mantenga pública la versión vigente mientras el autor envía otra, el revisor comenta y devuelve, y un publicador autorizado libera la revisión prevista. Cree entretanto un borrador más reciente: el historial debe mostrar qué revisión se aprobó, quién realizó cada transición y qué podía hacer cada rol.
Las pruebas deben mostrar si cada edición localizada conserva un estado comprensible e independiente cuando cambia el original. Cree, revise, previsualice y publique una edición secundaria; después modifique la fuente mientras la traducción está en curso. Observe si se señala que ha quedado desactualizada, de qué versión parte, quién puede aprobarla y si se publica de forma independiente. Drupal documenta, por ejemplo, traducciones moderadas por separado que pueden comenzar desde la versión publicada y no desde el último borrador.
Deje también un campo localizado vacío y compruebe la respuesta entregada. Algunos modelos permiten recurrir al idioma solicitado, al predeterminado o a sustituciones configuradas; no presuma que esa combinación es segura para estados no publicados. Para probar la reutilización, referencie un dato gobernado desde varios destinos, actualícelo una vez y revise impacto, vistas previas, orden de publicación, cachés y reversión. Introduzca una excepción contextual en un destino y verifique que permanece explícita, sin divergencia silenciosa.
Estos escenarios deben probar acciones permitidas y prohibidas en los límites donde realmente opera el CMS. Asigne privilegios mínimos a autor, revisor, traductor, publicador y administrador; después restrinja un tipo de contenido, idioma, campo, unidad o transición. Pruebe controles visibles, rutas directas y API pertinentes. WordPress ilustra por qué el nombre del rol no basta: sus capacidades diferencian lectura, edición propia o ajena, publicación, importación, exportación y administración.
Programe una publicación coordinada y su retirada posterior en una zona horaria identificada, incluyendo activos y contenido referenciado. Introduzca un fallo de validación o cambie la hora al final; capture alcance, comprobaciones previas, marcas de ejecución, avisos, estado público, publicación parcial y recuperación. Finalmente, corrija un error material en producción, verifique todos los canales y cachés, y restaure la revisión aprobada anterior. Un registro de revisiones ayuda, pero no demuestra por sí solo una reversión segura ni una auditoría completa.
Primero hay que definir el resultado exacto que significa «archivar»: conservar la página con una explicación, despublicarla y redirigir, restringirla, eliminarla o aplicar otro estado acordado. La guía de GOV.UK distingue, como ejemplo de plataforma, entre mantener una URL retirada con explicación y despublicar el contenido con una posible redirección. Invierta después la decisión y revise respuestas de URL, enlaces, buscador, feeds, API, adjuntos, permisos, historial, analítica y efectos posteriores.
En integración, cree o actualice contenido realista mediante la API o el conector previsto; pruebe además entrada inválida, petición repetida, consumidor retrasado o fallido, detalle del error, repetición, orden, duplicados, registros y recuperación manual. Una API disponible —o incluso un estándar como CMIS— no demuestra todas las capacidades ni la resiliencia de la solución. Exporte contenido, activos, modelos, relaciones, identificadores, redirecciones y estados acordados; restaure una muestra aislada y registre lagunas y esfuerzo. Según NIST, la recuperación exige planes, procedimientos y medidas coordinadas, por lo que esta prueba no certifica continuidad.
| Familia y tarea del comprador | Resultado observable | Evidencia decisiva | Fallo o excepción |
|---|---|---|---|
| Autoría: crear y previsualizar contenido estructurado | Estructura y campos conservados | Entrada, vista previa, pasos y ayuda | Error corregido usando solo el teclado |
| Revisión: someter, devolver, corregir y publicar | Se publica la revisión aprobada | Identidad, comentarios, transiciones e historial | Aparece un borrador paralelo |
| Localización: publicar una edición secundaria | Estado y entrega independientes | Idioma, metadatos, permisos y respuesta | Cambia el original y falta un campo |
| Reutilización: actualizar un elemento compartido | Propagación limitada a los destinos previstos | Dependencias, vistas previas, cachés y reversión | Un destino necesita una excepción |
| Permisos: ejecutar acciones permitidas y prohibidas | Los límites efectivos coinciden con el diseño | Interfaz, rutas directas, API y auditoría | Se restringe un campo, idioma o transición |
| Programación: coordinar publicación y retirada | Ejecución correcta en la zona acordada | Preflight, marcas horarias, avisos y estado público | Falla la validación o cambia la hora |
| Corrección: reparar y revertir contenido publicado | Todos los canales convergen | Comparación, aprobación, cachés y auditoría | La corrección resulta equivocada |
| Archivo: retirar contenido con un estado definido | URL y descubrimiento responden según lo acordado | Respuesta, redirección, buscador e historial | Se revierte la retirada |
| Integración: intercambiar contenido realista | Datos, identificadores y estados se reconcilian | Solicitudes, eventos, errores, registros y duplicados | Entrada inválida o consumidor fallido |
| Recuperación: exportar y restaurar una muestra | Relaciones y activos acordados vuelven a funcionar | Exportación, procedimiento, tiempo y lagunas | Borrado, corrupción o indisponibilidad simulada |
La decisión debe separar puertas obligatorias, resultados observados, esfuerzo operativo, dependencias y riesgos abiertos. Registre cada resultado imprescindible individualmente para que una puntuación agregada no oculte un fallo excluyente. Atribuya lo logrado a capacidad nativa, configuración, plan contratado, complemento, extensión, código a medida, servicio de un socio, sistema externo o promesa de hoja de ruta. Cada organización debe fijar sus propios pesos y umbrales antes de comparar productos.
Convierta formación, migración, configuración, integración, controles manuales y pruebas pendientes en alcance de implantación, coste, términos contractuales, riesgo explícito o rechazo. Conserve fichas versionadas, muestras, observaciones, marcas horarias, capturas, registros de API, exportaciones, roles participantes, supuestos y el diario de decisión. Cuando hagan falta conclusiones sobre conformidad, amenazas, privacidad, obligaciones legales, resiliencia o recuperación, incorpore especialistas cualificados: un escenario acotado orienta una compra, pero no sustituye esas evaluaciones.
Primero se descartan las opciones que incumplen restricciones obligatorias de arquitectura, seguridad, accesibilidad, datos, condiciones comerciales o soporte. Después, los CMS finalistas ejecutan los mismos escenarios de publicación, con muestras, actores, estados iniciales y resultados definidos por el comprador. La decisión compara evidencias, esfuerzo, dependencias y riesgos pendientes.
Debe incluir contenido realista, usuarios representativos, una tarea normal y una excepción o fallo. Cada ficha fija propósito, actores, estado inicial, resultado esperado, evidencias y criterio de fallo. También registra tiempo, pasos, ayuda, configuración, extensiones, código a medida, plan contratado y dependencias externas.
Debe respaldar escenarios propiedad del comprador, no limitarse a un recorrido preparado por el proveedor. Conviene que los usuarios representativos intenten primero el camino predeterminado y que el proveedor explique después la configuración o las alternativas. Así se distinguen la capacidad observada, la asistencia requerida y el trabajo pendiente.
Un conjunto adaptable puede cubrir autoría, revisión, localización, reutilización, permisos, programación, corrección, archivo, integración y recuperación. No todas las organizaciones necesitan idénticos estados o excepciones. Lo importante es seleccionar tareas representativas y ejecutarlas con las mismas condiciones en cada candidato.
Registre por separado las puertas obligatorias, los resultados observados, el esfuerzo, las dependencias y los riesgos abiertos. No permita que una media compense el incumplimiento de una condición imprescindible. Los pesos y umbrales deben acordarse antes de la prueba según el contexto de la organización, no adoptarse como una fórmula universal.
Este artículo se ha elaborado a partir de las siguientes fuentes:
Aprende a validar la necesidad, el papel, las pruebas y el mantenimiento de una página con un brief de propósito de nueve campos antes de redactar.
Crea una matriz adaptable de ocho ámbitos que define quién decide, hasta dónde llega su autoridad, qué aportaciones necesita y cuándo escalar.
Arquitectura de la información
Método práctico para auditar tareas y rutas, diagnosticar problemas de encontrabilidad y justificar reparaciones o un rediseño con evidencias.
