Cómo elegir un CMS autohospedado para un equipo editorial: prueba el ciclo editorial
Compara opciones de CMS autohospedados poniendo a prueba vuestro trabajo editorial real: desde el primer borrador y la aprobación hasta las correcciones, la exportación y el mantenimiento continuo.
Por qué la adecuación al flujo de trabajo importa más que una lista de funciones
Un CMS puede enumerar funciones que parecen adecuadas y, aun así, dificultar el trabajo editorial cotidiano. La pregunta útil no es solo si una plataforma ofrece borradores, roles o programación. La cuestión es si vuestro equipo puede completar su trabajo real con claridad, con la participación de las personas adecuadas y sin tener que recurrir a soluciones improvisadas evitables.
Considerad WordPress, Drupal, Ghost o cualquier otra opción como algo que hay que probar, no como una conclusión a la que se llega por su nombre o su lista de funciones. La información proporcionada no permite determinar qué plataforma es la mejor para un equipo editorial ni qué funciones admite una versión actual concreta. Verificad las capacidades en la versión y la configuración que utilizaríais realmente.
- Evaluad una tarea completa, no una función aislada.
- Usad el mismo contenido de prueba, las mismas personas y los mismos criterios de aceptación para cada opción.
- Anotad las soluciones improvisadas, los traspasos poco claros y la configuración necesaria, además de los resultados satisfactorios.
Trazad el ciclo de publicación, incluidas las excepciones
Antes de abrir una demostración, anotad cómo pasa por vuestro equipo una pieza representativa. Incluid tanto el recorrido habitual como las situaciones que lo interrumpen. Un mapa sencillo puede empezar con un encargo o una idea, continuar con la redacción y la revisión, y abarcar después la aprobación, la publicación y el mantenimiento posterior. Adaptad las etapas a vuestro proceso en lugar de dar por sentado que todos los equipos siguen la misma secuencia.
Pedid a cada persona que describa qué recibe, qué modifica, qué decide y cómo sabe que la siguiente persona ya puede actuar. Incluid excepciones como que una persona revisora no esté disponible, que llegue una corrección después de publicar, que haya que fijar una fecha posterior o que se pause un borrador. Son pruebas útiles precisamente porque una demostración ordenada quizá no las muestre.
- Indicad cada etapa, el rol responsable, el traspaso y el resultado esperado.
- Señalad qué pasos son obligatorios y cuáles dependen del tipo de contenido o del nivel de riesgo.
- Anotad las excepciones habituales, incluidos los borradores rechazados, las correcciones urgentes y los cambios en las fechas de publicación.
- Acordad qué aspecto tiene un traspaso satisfactorio antes de comparar sistemas.
Preparad un conjunto de pruebas representativo
Elegid material de prueba que refleje el trabajo que vuestro CMS debe admitir. Un solo artículo breve rara vez basta para mostrar cómo gestiona el sistema distintas estructuras, personas colaboradoras o necesidades de revisión. Utilizad contenido de ejemplo en lugar de material confidencial en uso, salvo que vuestra organización haya aprobado el entorno de pruebas para ese fin.
Mantened el conjunto de pruebas manejable, pero variado. Incluid los tipos de contenido que publica vuestro equipo, los tipos de recursos o enlaces que utiliza y cualquier contenido recurrente que deba aparecer en más de un lugar. Añadid usuarios de prueba que correspondan a responsabilidades reales, como autoría, edición, aprobación y administración. No deis por sentado que el nombre de un rol significa que la persona solo puede realizar las acciones previstas; comprobad directamente los permisos.
- Elegid una pieza habitual, una compleja y otra que requiera una corrección.
- Incluid a las personas colaboradoras y revisoras que representen vuestros traspasos reales.
- Cuando corresponda, utilizad ejemplos con distintos procesos de revisión o calendarios de publicación.
- Anotad los resultados esperados antes de empezar las pruebas para que el equipo pueda comparar de forma coherente.
Probad la redacción, la revisión, la aprobación y las vistas previas
Llevad a cabo un ejercicio completo, desde el borrador hasta la decisión. Pedid a una persona que cree o edite la pieza de prueba, a otra que la revise y a la persona correspondiente que decida si se publica. Observad si cada participante puede saber qué se espera a continuación y si el equipo distingue entre un borrador, una pieza pendiente de revisión y otra aprobada dentro de su flujo de trabajo real.
Probad las vistas previas con las personas que dependen de ellas. Comprobad si quienes revisan pueden evaluar el contenido en una presentación que les resulte útil para tomar decisiones y si el equipo puede identificar fácilmente los cambios realizados después de la revisión. Verificad el comportamiento en la versión y la configuración actuales de la opción evaluada; no deduzcáis las capacidades de vista previa o aprobación únicamente a partir de la descripción de un producto.
- ¿Puede quien redacta identificar a quién debe enviar la pieza para su revisión y qué falta por hacer?
- ¿Puede quien revisa tomar una decisión o enviar comentarios de la forma prevista?
- ¿Puede el equipo saber si se han aplicado los cambios solicitados?
- ¿La vista previa facilita la tarea de revisión, incluidos el diseño pertinente y el material enlazado?
- ¿Podéis explicar qué ocurre si una persona revisora rechaza, pausa o devuelve un borrador?
Probad las revisiones, la programación, las correcciones y la reutilización
El ciclo editorial continúa después de la aprobación. Probad cómo trabaja el equipo con los cambios a lo largo del tiempo: revisad una pieza, comparad la versión modificada con la anterior y determinad qué información puede utilizar el equipo para entender los cambios. Confirmad directamente el comportamiento disponible en lugar de dar por sentado que el historial de versiones o la comparación funcionan de una manera concreta.
Si vuestro equipo programa publicaciones, probad un caso que incluya fijar, cambiar y cancelar una publicación prevista. Comprobad cómo pueden confirmar las personas responsables la fecha prevista y qué hacen si cambia la programación. Para las correcciones, probad el recorrido completo desde la detección de un problema hasta la aprobación y publicación de la solución. En el caso del contenido reutilizado, identificad cuál es la fuente de referencia y probad cómo se gestiona una actualización en todos los lugares donde aparece ese contenido.
- ¿Puede el equipo revisar los cambios anteriores de una forma que respalde su proceso de corrección?
- ¿Puede la persona responsable verificar, cambiar o cancelar la publicación prevista según sea necesario?
- ¿Queda claramente asignada, revisada y confirmada una corrección posterior a la publicación?
- Cuando se reutiliza contenido, ¿puede el personal identificar dónde aparece y cómo se gestionan las actualizaciones?
- Anotad los pasos manuales, el contenido duplicado y los casos en que no está clara la responsabilidad.
Comprobad los roles y los traspasos según las responsabilidades reales
Empezad por las responsabilidades, no por los nombres de los roles del CMS. Preparad una matriz breve de permisos que indique quién puede crear, editar, revisar, aprobar, publicar y gestionar la configuración. Después, probad cada cuenta representativa con esa matriz. Confirmad tanto que las personas pueden realizar el trabajo que necesitan como que no pueden ejecutar acciones que vuestra política reserva a otras personas.
Incluid situaciones temporales y menos habituales, como la salida de una persona colaboradora, la sustitución de un colega por parte de quien revisa o la intervención de una persona administradora para resolver un bloqueo. Determinad quién solicitará, aprobará y retirará los permisos. Un flujo de trabajo que dependa de la cuenta de una sola persona o de conocimientos informales puede ser difícil de mantener, aunque funcione el recorrido principal.
- Anotad las responsabilidades laborales y las acciones necesarias antes de asignarlas a los roles del sistema.
- Comprobad los permisos con cuentas separadas, en lugar de basaros en la vista de una cuenta administradora.
- Comprobad si los traspasos siguen siendo claros cuando una persona no está disponible.
- Documentad quién se responsabiliza de los cambios de cuentas y de las decisiones sobre el flujo de trabajo.
Evaluad la migración, la exportación y la titularidad del contenido a largo plazo
Elegir un CMS afecta a mucho más que a la primera publicación. Antes de comprometeros, identificad qué puede necesitar trasladar o conservar el equipo: contenido, archivos multimedia, enlaces, estructura, metadatos y registros de decisiones editoriales. Consultad al proveedor o la documentación del proyecto para saber qué opciones de exportación existen y, después, realizad una prueba práctica pequeña con material representativo. No consideréis que un botón de exportación o una afirmación general sobre la portabilidad demuestran que el resultado cubrirá vuestras necesidades.
Definid qué significa para vuestra organización poder salir del sistema de forma satisfactoria. ¿Puede el equipo inspeccionar el material exportado? ¿Conserva la información que necesitáis? ¿Qué requeriría trabajo manual o un proceso aparte? Las respuestas dependen de vuestro contenido y de los requisitos de conservación, así que especificadlas en lugar de dar por sentado que todos los CMS gestionan la migración de la misma manera.
- Enumerad el contenido y la información relacionada que debéis conservar o trasladar.
- Probad la exportación con más de un tipo de contenido e incluid los archivos multimedia asociados cuando corresponda.
- Revisad el resultado con las personas responsables de futuras migraciones o de los registros.
- Documentad qué queda fuera, qué debe transformarse y quién se encargará de ese trabajo.
Incluid el alojamiento y el mantenimiento en la decisión
Un CMS autohospedado implica que la organización debe decidir quién se responsabiliza del servicio que lo rodea, además de la experiencia editorial. Aclarad quién gestiona el servidor y la aplicación, quién comprueba las copias de seguridad y los procedimientos de restauración, quién controla los accesos y quién decide cómo se gestionará el mantenimiento. Una plataforma que encaje con las necesidades del equipo editorial puede seguir siendo una mala opción si no se dispone de la responsabilidad operativa necesaria.
Un despliegue gestionado puede cambiar quién se ocupa de partes de la infraestructura, pero no elimina las responsabilidades del cliente sobre el contenido, las decisiones de acceso, la gobernanza ni la comprensión de las necesidades de recuperación. Por ejemplo, Airbip ofrece el despliegue gestionado de aplicaciones de catálogo como cargas de trabajo de Docker en servidores en la nube de Airbip, con el enrutamiento y los certificados TLS automatizados mediante Traefik y Let’s Encrypt. También ofrece comprobaciones de DNS, gestión del ciclo de vida de los servicios y copias de seguridad configurables diarias, semanales y mensuales. Consultad el sitio web vigente de Airbip para conocer los planes y las condiciones comerciales actuales, y estableced cómo se gestionarán los requisitos propios de datos, accesos y recuperación.
- Asignad antes del lanzamiento las responsabilidades relacionadas con la aplicación y la infraestructura.
- Preguntad cómo se configuran las copias de seguridad y cómo podría verificar el equipo una restauración.
- Acordad quién gestiona los accesos, los dominios, la gobernanza del contenido y las decisiones ante incidentes.
- Elegid un modelo de despliegue que se ajuste a la capacidad operativa y a los requisitos de control de vuestro equipo.
Preguntas frecuentes
¿Cómo debería comparar un equipo editorial las opciones de CMS autohospedado?
Trazad el ciclo de trabajo real del equipo y, después, realizad las mismas tareas representativas en cada opción. Incluid la publicación habitual y excepciones como borradores devueltos, cambios de programación y correcciones posteriores a la publicación. Anotad los resultados, las soluciones improvisadas, las necesidades de configuración y las preguntas sin respuesta.
¿Debería un equipo elegir WordPress, Drupal o Ghost para sus flujos editoriales?
La información proporcionada no permite establecer una clasificación de plataformas ni afirmar que una sea la mejor para un equipo concreto. Probad cada opción en la versión y configuración que utilizaríais, teniendo en cuenta vuestros tipos de contenido, roles, proceso de revisión y requisitos operativos.
¿Qué deberíamos probar en la vista previa de un CMS?
Comprobad si las personas responsables de la revisión pueden evaluar el contenido en una presentación útil, incluidos el diseño pertinente y el material enlazado. Probad los cambios realizados después de la revisión y confirmad cómo puede saber el equipo qué está listo para su aprobación.
¿Cómo podemos evaluar la exportación de contenido antes de elegir un CMS?
Enumerad el contenido y la información relacionada que necesitáis conservar y, después, realizad una pequeña prueba de exportación con material representativo. Revisad el resultado con las personas responsables de la migración o de los registros y documentad las omisiones, las transformaciones y el trabajo manual.
¿El alojamiento gestionado elimina la responsabilidad del equipo sobre un CMS autohospedado?
No. El despliegue gestionado puede encargarse de partes de la infraestructura, pero la organización sigue teniendo que tomar decisiones sobre sus datos, accesos, gobernanza y necesidades de recuperación. Aclarad las responsabilidades antes de elegir un modelo de despliegue.
Fuentes y lecturas adicionales
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group