Выбор CMS начинается с того, кто и как будет обновлять сайт. Название системы не объясняет, сможет ли маркетолог создать услугу, связать её с проектом, проверить черновик и опубликовать материал без участия разработчика.
Сначала составьте список операций и данных, затем попросите показать их в предлагаемом решении. Ниже — методика выбора, а не рейтинг продуктов. Возможности конкретной CMS нужно проверять в выбранной версии, конфигурации и составе проекта.
Кто будет редактировать сайт
Опишите участников процесса и частоту работы. Один сотрудник может готовить материалы и публиковать их самостоятельно; в другой компании текст проходит проверку перед выпуском. Роли обозначают ответственность, а не обязательное число людей.
Выясните, какие действия выполняются регулярно: обновление условий услуги, загрузка проекта, замена документа, добавление товара или подготовка перевода. Уточните, кто помогает, когда обычных возможностей редактора недостаточно.
Не выбирайте систему только по демонстрации администраторского аккаунта. Нужно увидеть нужные действия под той ролью, которой будет пользоваться сотрудник.
Перечислите виды контента и связи
Страница и запись в CMS — не всегда одно и то же. Запись услуги может использоваться на собственной странице, в списке направления и в связанном проекте. Если одну связь приходится вручную повторять в нескольких местах, обсудите, как будут предотвращаться расхождения.
| Материал | Пример полей | Что проверить |
|---|---|---|
| Услуга | Название, описание, ограничения, изображение | Создание из согласованного шаблона и появление в списке |
| Проект | Задача, участие, материалы, связанные услуги | Связи не теряются при обновлении |
| Товар | Код, характеристики, документы, категория | Импорт и ручная правка сохраняют соответствие данных |
| Статья | Заголовок, текст, дата, метаданные | Черновик, предпросмотр и публикация |
| Перевод | Связанная версия, язык, состояние готовности | Обновления исходника не остаются незамеченными |
Это учебный набор. Вашему сайту могут потребоваться другие сущности или меньше возможностей. Для начала используйте карту корпоративного сайта, чтобы не проектировать редактор для неопределённых страниц.
Отделите редактирование материалов от изменения дизайна
Возможность заменить текст не означает возможность перестроить страницу. Уточните, какие блоки можно добавлять и переставлять, какие поля обязательны и кто создаёт новый тип шаблона.
Свободный редактор и ограниченный набор блоков решают разные задачи. Свобода может быть полезна для часто меняющихся промостраниц, а предсказуемый шаблон — для большого набора услуг. Выбор зависит от процесса и требований к единообразию, а не от универсального правила «больше настроек лучше».
Попросите показать длинный заголовок, отсутствие необязательного изображения и несколько связанных материалов. Демонстрация на одной идеально заполненной записи не показывает границы интерфейса.
Проверьте черновики и предпросмотр
Опишите, что происходит между сохранением и публикацией. Черновик не должен случайно появляться в публичной навигации или открытых данных, если по требованиям он закрыт. Для предпросмотра определите доступ: кто может открыть страницу и можно ли передать ссылку проверяющему.
Проверка проводится с реальным черновиком в тестовом окружении. Покажите его редактору, затем откройте публичную часть без авторизации и убедитесь, что материал недоступен там, где должен быть закрыт. Скрытая ссылка в меню сама по себе не доказывает закрытость данных.
Если предусмотрена отложенная публикация, история версий или возврат предыдущего содержания, проверяйте каждое действие отдельно. Эти функции не следует считать включёнными только потому, что в предложении написано «CMS».
Согласуйте роли и публикацию
Определите, кто может создавать, изменять, проверять, публиковать и удалять материалы. Права должны соответствовать рабочим задачам. Возможность входа в систему не равна разрешению выпускать любой контент.
Учебный сценарий: автор готовит услугу, проверяющий согласует содержание, редактор публикует. В небольшой компании эти действия может выполнять один человек. Если требуется отдельное согласование внутри CMS, его состояния и уведомления нужно включить в состав явно.
Проверьте также ошибочное действие: может ли пользователь без права публикации обойти ограничение другим экраном или способом сохранения? Это требование к готовому решению, а не обещание о любой выбранной системе.
Интеграции и перенос влияют на выбор
Для обмена данными нужны источник, получатель, соответствие полей и правила обновления. Например, если каталог получает характеристики из другой системы, важно определить, какие поля редактор может менять вручную и что произойдёт при следующем импорте.
Попросите разобрать недоступность источника, неполную запись и повторный импорт. Должно быть понятно, что сохраняется, что отклоняется и кто узнаёт об ошибке. Наличие API ещё не доказывает, что нужный обмен реализован.
Для существующего сайта проверьте пробный перенос: тексты, изображения, документы, связи и адреса. Сверьте разные типы материалов, а не только общее количество записей. Отдельно определите, как перенести изменения, внесённые после первого пробного импорта.
Задания для демонстрации
Передайте одинаковые задания каждому кандидату. Используйте синтетические материалы и тестовые аккаунты, не реальные контакты клиентов.
- Новая услуга. Создать запись, заполнить обязательные поля, добавить изображение и связанную работу. Показать результат в списке.
- Черновик. Сохранить материал и открыть предпросмотр. Проверить доступность без авторизации по согласованным правилам.
- Публикация. Выпустить материал нужной ролью; показать, что пользователь без этого права не может сделать то же действие.
- Изменение. Обновить текст, проверить публичный результат и объяснить возможности возврата, если он требуется.
- Связь. Изменить связанную услугу или проект и проверить зависимые страницы.
- Перевод. Подготовить языковую версию и показать процесс обновления при изменении исходника, если языки входят в проект.
- Перенос. Загрузить небольшой набор разных записей и сверить поля, документы и связи.
- Передача. Показать инструкцию типовой операции и объяснить, что потребуется для дальнейшего сопровождения другим исполнителем.
Демонстрация стандартной возможности продукта не означает, что она уже включена в вашу смету. После показа сверьте задания с составом предлагаемой реализации.
Карточка решения
| Сценарий | Результат демонстрации | Что включено в предложение | Открытый вопрос |
|---|---|---|---|
| Создать услугу | Подтверждено / частично / не проверено | Поля, блоки, связи | Что требует разработчика |
| Проверить черновик | Кто и как получил доступ | Предпросмотр и ограничения | Как исключена случайная публикация |
| Опубликовать | Под какой ролью проверено | Права и согласование | Какие действия ещё не проверены |
| Обновить данные | Что произошло после импорта | Источник и правила обновления | Что будет при ошибке |
| Передать проект | Какие материалы показаны | Доступы, инструкция, данные | Какие зависимости сохраняются |
Не заменяйте открытые вопросы общей оценкой «удобно». Запишите, какие действия обязательны к запуску и какие можно отложить. Если критичное действие не проверено, определите отдельный шаг проверки до окончательного выбора.
Учтите эксплуатацию
Выясните, где размещается система, кто обновляет её и зависимости, как выполняются резервное копирование и восстановление, кому принадлежат аккаунты и где доступны условия лицензий или подписок. Не все расходы применимы к каждому проекту; конкретный состав и суммы зависят от решения.
Для оценки бюджета используйте разбор состава стоимости. Если сравниваете разные подходы, прочитайте Nuxt или WordPress для сайта бизнеса: выбор технологии не заменяет проверку готовых редакторских сценариев.
Как зафиксировать выбор
Перенесите обязательные действия, ограничения и результаты демонстрации в техническое задание. Отдельно перечислите то, что осталось исследовать. Решение должно объяснять, почему предложенная CMS подходит вашему процессу и что именно будет реализовано.
CoreWeb может помочь определить редакторские сценарии в рамках корпоративного сайта. Начать можно с подготовки брифа; краткое определение системы есть в глоссарии CMS.
Подготовьте собственный показ по уроку о требованиях к CMS: пять операций, тестовые материалы и протокол с открытыми вопросами.
После выбора сценария пройдите практику создания и проверки записи. Она поможет проверить сохранение правок, предпросмотр и редакторские ограничения на одном учебном материале.
Если предлагается разделить CMS и отображение, проверьте что означает headless CMS: какие каналы используют данные, как устроены предпросмотр, обновление и поддержка.