CMS выбирают не по витрине шаблонов. Через полгода после запуска редактору нужно заменить материал, маркетингу — добавить посадочную страницу, а IT — понять, можно ли подключить CRM без ручных выгрузок. Если эти сценарии не описаны заранее, недорогой старт превращается в серию разрозненных доработок.
Начинают с операций, а не с названия платформы
Список требований лучше собирать вокруг регулярной работы: кто публикует новости, кто согласует юридические документы, кто меняет карточки услуг и кто отвечает за форму заявки. Для каждой операции важны частота, роль исполнителя, проверка перед публикацией и возможность вернуть предыдущую версию.
Конструктор подходит, когда структура небольшая и команда готова работать в рамках его редактора. Типовая CMS даёт больше контроля над шаблонами и интеграциями. Заказная система оправдана, если процесс нельзя свести к стандартным сущностям и он действительно повторяется.
Что зафиксировать:
- перечень ролей и разделов
- сценарии изменения контента
- критичные интеграции и владельцы данных
Редакторы и права доступа
Удобный редактор не заменяет права. Контент-менеджер может готовить черновик, руководитель направления — утверждать, а технический администратор — менять шаблоны и настройки. В приёмке проверяют именно эти роли, а не только вход под общей учётной записью.
Нужны журнал изменений, понятное восстановление версии и правило для медиафайлов. Иначе через несколько месяцев никто не сможет объяснить, почему на странице появился старый договор или исчезло изображение.
Что зафиксировать:
- черновик и публикация
- ограничение доступа к настройкам
- порядок удаления и восстановления
Интеграции и границы системы
Форма сайта, CRM, каталог, сервис рассылок и аналитика должны иметь назначенных владельцев. До разработки фиксируют источник каждого поля, направление обмена, момент обновления и действие при ошибке.
Не стоит обещать синхронизацию всего со всем. Иногда достаточно передать заявку с источником, выбранной услугой и согласием; цены и остатки лучше оставить в учётной системе до появления доказанной потребности на сайте.
Что зафиксировать:
- карта полей формы
- обработка дублей
- уведомление об ошибке обмена
Стоимость развития после запуска
Лицензия и первичная разработка — только часть расходов. В оценке нужны обновления, резервные копии, тестовая среда, поддержка интеграций, новые страницы и время владельцев контента.
Сравнивать платформы полезно по двум горизонтам: что требуется для первого релиза и какие изменения ожидаются в ближайший год. Тогда небольшая экономия на старте не маскирует дорогие ограничения позже.
Приёмка выбранной CMS
До запуска команда создаёт тестовую страницу, меняет изображение, отправляет форму, проверяет права и восстанавливает предыдущую версию. Такой сценарий выявляет проблемы редактора раньше, чем их заметят посетители.
В документации оставляют не общую инструкцию, а короткие действия для конкретных ролей. Если действие требует разработчика, это тоже фиксируют: так не возникает ложного ожидания самостоятельного редактирования.
Как принять решение
К выбору возвращаются после короткой проверки на реальных ролях. Контент-менеджер собирает черновик и отправляет на согласование, маркетолог меняет посадочную страницу, технический специалист проверяет интеграцию формы и восстановление резервной копии. Для каждого сценария фиксируют, что получилось без доработки, что требует настройки и кто будет это поддерживать.
В итоговой таблице полезны не оценки «удобно» или «сложно», а наблюдаемые условия: роль, действие, ограничение, владелец, стоимость сопровождения. Если подрядчик показывает функцию в демо, а сотрудник не может повторить её под своей учётной записью, пункт не засчитывают как закрытый.
После встречи остаётся карта редакционных операций: публикация новости, правка услуги, замена файла, согласование материала, обработка заявки. Рядом с каждой операцией указывают требуемый доступ, место хранения данных и способ проверки. Эта карта становится основой для сметы доработок и регламента поддержки.
Top comments (0)