Админка сайта: что нетехнический человек сделает сам, а что через разработчика

Админка сайта — это экран, на который человек заходит в понедельник утром, чтобы поставить новость, и больше ни для чего. Он не программист и учиться им не собирается: у него юридическая практика, отчётный период или сезон продаж. Вопрос у маркетолога фирмы и у помощника партнёра одинаковый: «Я смогу вести этот сайт сам или буду писать подрядчику за каждой запятой?»

Ответ «вы сможете всё менять сами» ничего не значит: «всё» у подрядчика и у заказчика — разные множества. Ниже работа с сайтом разложена на конкретные задачи, и для каждой названы исполнитель и порядок времени: что делается за пять минут, что потребует получаса и короткой инструкции, а что всегда уходит к разработчику — и почему это не недостаток админки, а её устройство.

Кажется, что сложность задачи для админки совпадает с её сложностью для человека. На деле наоборот. Заменить абзац и поменять адрес страницы — для редактора одинаковые действия, два поля в форме. Для сайта это разные события: в первом случае обновляется содержимое, во втором рвутся ссылки, ведущие на страницу извне и изнутри.

Задачи делятся не на «простые и сложные», а по тому, что меняется под капотом. Первый уровень — содержимое внутри готовой сущности: текст, фотография, дата, файл. Второй — сборка страницы из блоков и заведение новой сущности того типа, который уже есть: ещё один юрист, ещё один материал, ещё одна практика. Третий — структура, адреса, формы, обмен данными и оформление. Первые два уровня — работа сотрудника, третий — работа разработчика, даже если в интерфейсе для него нарисована кнопка.

Этот список стоит проговорить с тем сотрудником, который будет вести сайт, — до запуска, а не после. Обычно выясняется, что две-три задачи его недели в перечень не попали: выгрузить участников семинара, поменять телефон в одном офисе из трёх, снять материал с ошибкой. Каждая решается просто, если названа заранее, и становится отдельной работой, если всплывает после приёмки.

VERBA LEGAL мы запускали с расчётом на рост: фирма шла с пятидесяти человек к ста пятидесяти и с десятка практик к двадцати пяти. Админка там собственная, команда фирмы сама добавляет юристов, практики, новости и публикации. Проверка решения — не интерфейс, а факт: новые практики и партнёры появляются на сайте в день анонса, а структура выдержала рост без переработки разделов.

У LEVEL Legal Services двенадцать практик и большой поток экспертных материалов. Сайт сделан так, чтобы команда вела новости, публикации и карточки юристов самостоятельно, а материал был связан с автором и с практикой. Связи и превращают админку из текстового редактора в рабочий инструмент: ставя публикацию, сотрудник пополняет страницу практики и карточку юриста, хотя заходил только за новостью.

В рознице ответ на вопрос «удобно ли» даёт не подрядчик, а сотрудник. Интернет-маркетолог Grande Boutique Ульяна Оржеховская участвовала во всех этапах работ и сформулировала так: «Лично для меня огромный плюс, что стало удобно пользоваться админкой. Она легчайшая, простейшая, просто подарок для маркетолога — двигаешь что хочешь и куда хочешь».

Это не комплимент, а формулировка критерия. «Двигаешь что хочешь и куда хочешь» — ровно второй уровень из перечня выше. Заметьте, чего в оценке нет: слов «настраиваешь шрифты» и «меняешь цвета». Маркетологу это не нужно — ему нужно быстро переставить акценты под сезон.

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

Доступ к оформлению не выдаётся никому из редакторов — и это освобождает: сотрудник думает про смысл блоков, а не про их высоту.

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

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

Отдельно про закрытые части. Если у компании есть не только сайт, но и сервис для клиентов, его служебная часть к работе редактора не относится вообще. В приложении ЦСБ, которое распространяется через App Store и Google Play по закрытой ссылке, у сотрудников собственный административный контур: чаты с клиентами, обмен файлами, комментарии, назначение ответственных за задачу. Это рабочее место специалиста, а не экран для правки текстов, и цена ошибки там другая.

Сначала ничего не происходит: сотрудник аккуратен и повторяет то, что показали на обучении. Через несколько месяцев появляется первая страница «немного по-своему» — другой отступ, заголовок покрупнее, потому что так заметнее. Потом приходит второй редактор и ориентируется уже на эту страницу.

Дальше набор повторяется от проекта к проекту: разнобой между разделами, который на внутреннем обсуждении называют «сайт устарел», хотя ему полтора года; сломанный вид на телефоне; тексты, вставленные картинкой, — их не найти поиском и не перевести; дубли страниц, которые делали «на время» и забыли снять; фотографии прямо с камеры, из-за которых страница открывается заметно дольше. Ни одна из этих поломок не выглядит как авария, и поэтому их замечают поздно — обычно когда новый сайт уже обсуждают всерьёз.

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

Не нужно составлять техническое задание на админку. Выпишите три задачи, которые вы делали на сайте чаще всего, — своими словами, как они звучат в вашей переписке: «поставить разбор новой судебной практики», «добавить юриста, который вышел из декрета», «собрать страницу под конференцию». Пришлите этот список — ответим по каждому пункту, кто его делает в нашей админке, сколько это занимает и что нужно спроектировать заранее, чтобы он остался работой сотрудника, а не задачей разработчику.

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