Как выбрать CMS: админка, которой действительно будут пользоваться

Выбирают разработчики, а пользуетесь вы

Систему управления сайтом почти всегда выбирает тот, кто будет её ставить, а не тот, кто будет в ней работать каждый день. Отсюда большая часть последующих претензий.

Разработчик выбирает по знакомости и скорости сборки — и это разумно с его стороны. Но ему потом не заводить сто товаров, не выкладывать статью в пятницу вечером и не менять цену на всех страницах разом.

В итоге получается сайт, который технически хорош и в котором владелец боится что-либо трогать. Через полгода он перестаёт трогать совсем, и сайт устаревает.

Ниже — как выбирать так, чтобы обе стороны остались довольны, и что проверить до того, как решение принято.

Что такое система управления и что ей не является

Система управления — это то, через что содержимое сайта меняют без разработчика. Тексты, изображения, товары, цены, страницы.

Ею не является дизайн: одна и та же система может выглядеть как угодно, и красивый сайт не означает удобной админки. Это ровно то, что путают на демонстрации.

Ею не является и набор функций сайта. Каталог с фильтрами, оплата, кабинет — это то, что построено поверх, и оно может быть построено поверх чего угодно.

Практически вопрос стоит так: что именно вы должны уметь менять сами, без письма подрядчику. Ответ на него и определяет выбор.

И ещё одно: система управления не обязана быть одна на весь сайт. Часто разумно, чтобы каталог тянулся из учётной системы, а тексты правились в отдельной админке.

Три подхода

Различаются они не возможностями, а тем, кто отвечает за обновления и насколько далеко можно уйти от стандартного поведения.

Готовая система с открытым кодом. Устанавливается, дополняется расширениями, знакома множеству разработчиков. Дёшево на старте, много специалистов на рынке, но обновления и безопасность на вашей стороне.

Облачный сервис. Всё обслуживание на стороне поставщика, обновляется само, ломается редко. Взамен вы живёте внутри его правил и платите ежемесячно.

Собственная админка поверх своего кода. Ровно те поля, которые нужны, ничего лишнего, полный контроль. Дороже в разработке и требует, чтобы кто-то её поддерживал.

Наш сайт устроен третьим способом, и главная причина не в гибкости, а в редакционных правилах: материал не выходит в поиск, пока не выполнит около двадцати пяти условий по объёму, источникам и структуре. Такую проверку в готовую систему не встроить.

Главный критерий: кто будет вносить изменения

Ответьте честно, потому что от этого зависит всё остальное.

Если менять содержимое будет человек без технического образования — админка должна быть простой до скучности, и ради этого стоит пожертвовать гибкостью.

Если у вас есть разработчик или агентство на сопровождении — можно брать более мощный инструмент, потому что сложность им не мешает.

Если менять почти ничего не придётся, а обновления раз в год — вопрос вообще не важен, и спорить о нём не стоит.

И отдельно: если содержимое будут вносить несколько человек с разными ролями, это отдельное требование, которое надо проговорить заранее. Задним числом права доступа прикручиваются плохо.

Пять задач, на которых проверяют админку

Не смотрите демонстрацию — попросите доступ и сделайте пять вещей руками.

Заведите новую страницу или товар с нуля, с фотографией и описанием. Засеките время.

Измените текст на существующей странице и посмотрите, как быстро он появится на сайте и не сломается ли вёрстка.

Загрузите фотографию неправильного размера и посмотрите, что произойдёт. Хорошая система обрежет и сожмёт сама; плохая покажет как есть и растянет макет.

Найдите способ поменять что-то на двадцати страницах разом. Если такого способа нет, вы будете делать это руками всю жизнь сайта.

И попробуйте откатить свою же правку. Возможность вернуть предыдущую версию текста — то, о чём вспоминают ровно один раз, и в этот раз она нужна очень.

Чего не видно на демонстрации

Демонстрацию показывают на пустом сайте с тремя товарами. Проблемы начинаются на трёхстах.

Скорость админки при большом объёме. Список из тысячи позиций, который открывается двадцать секунд, — обычное дело, и на демонстрации этого не увидеть.

Поиск внутри админки. Когда позиций много, единственный способ найти нужную — поиск, и он бывает удивительно плохим.

Массовые операции. Изменить категорию у сорока товаров, поднять цены на пять процентов, снять с публикации всё, что не продаётся. Без этого работа превращается в перебор.

И поведение при одновременной работе двух человек. Кто выигрывает, если оба открыли одну страницу и сохранили. Правильный ответ — предупреждение; частый ответ — молча затирается тот, кто сохранил раньше.

Расширения: сила и главная опасность

У готовых систем есть каталог расширений на любую задачу, и это их главное преимущество. Оно же и главный риск.

Каждое расширение — это чужой код внутри вашего сайта. Он может замедлять страницы, конфликтовать с другими расширениями и содержать уязвимости, которые вы не увидите.

Заброшенное расширение опаснее всего: оно работает, но перестаёт обновляться, и через год становится дырой, через которую заходят.

Практические правила простые. Перед установкой смотрите дату последнего обновления и число установок. Не ставьте два расширения, делающих одно и то же. Раз в полгода удаляйте то, чем не пользуетесь, — отключённое расширение всё равно остаётся кодом на сервере.

И держите список: что установлено, зачем и кто это решил. Через два года никто не вспомнит.

Обновления: Демонстрацию показывают на трёх товарах, а проблемы…

Самая скучная часть и самая частая причина взлома.

Обновления выходят не ради новых кнопок, а чаще всего ради закрытия уязвимостей. Про уязвимость становится известно публично, и с этого дня начинается автоматический перебор сайтов, где обновление не поставили.

Не ставят их по понятной причине: обновление иногда ломает сайт. Отсюда логика «работает — не трогай», и она понятна ровно до первого взлома.

Правильный порядок один: тестовая площадка, обновление на ней, проверка ключевых сценариев, потом боевой сайт. Занимает полчаса и снимает почти весь риск.

И договоритесь заранее, кто это делает. Обновления — регулярная работа, у неё должен быть ответственный и место в бюджете. Хостинг за вас их не поставит.

Права доступа

Пункт, который выясняется в неудобный момент.

Если содержимое ведут несколько человек, у каждого должна быть своя учётная запись с ролью. Не одна общая на всех, пароль от которой знает и бывший сотрудник.

Минимальный набор ролей: тот, кто пишет и не может публиковать; тот, кто публикует; тот, кто меняет настройки. Этого хватает большинству.

Отдельно продумайте, что происходит при увольнении. Учётная запись отключается, а не удаляется — иначе вместе с ней исчезнет история, кто что менял.

И проверьте, видно ли вообще эту историю. Журнал изменений отвечает на вопрос «кто убрал этот блок» за секунду, а без него это неразрешимый спор.

Что спросить у подрядчика: Обновления ставят через тестовую площадку, а не сразу на…

Шесть вопросов, которые задают до подписания, а не после.

Кто будет обновлять систему и расширения после запуска и входит ли это в цену.

Есть ли тестовая площадка, на которой обновления проверяются до боевого сайта.

Можно ли выгрузить всё содержимое в переносимом виде, если мы уйдём к другому подрядчику.

Сколько человек на рынке умеют работать с этой системой. Ответ «только мы» — это не преимущество.

И покажите, как в этой админке сделать массовое изменение на сорока страницах. Не расскажите — покажите.

Как проверить перед решением

Короткая процедура на один вечер.

Возьмите список того, что вы будете менять на сайте в течение года: тексты, цены, товары, статьи, акции.

Напротив каждого пункта отметьте, кто это будет делать и как часто.

Попросите доступ к демонстрационной версии и выполните три самых частых пункта руками, засекая время.

Умножьте это время на частоту за год. Полученное число часов — реальная цена админки, и она обычно больше разницы в стоимости разработки.

Если считать некогда, есть короткое правило: выбирайте самое простое, что закрывает ваши задачи. Недостаток возможностей заметен сразу и решается доработкой. Избыток сложности замечают через год, и он уже не решается ничем.