Админ-панель веб-приложения: что в ней должно быть, чтобы сотрудники не просили программиста «поправить в базе»

Короткий ответ: в админке заказного сервиса с первого релиза нужны справочники, поиск и фильтры, карточка записи, журнал изменений, мягкое удаление и экспорт. Импорт, массовые действия и настройки без программиста добавляют, когда данных и правок становится много. Дашборды и красивую аналитику можно отложить. У нас таблицы с фильтрами, поиском и экспортом и разграничение прав по ролям входят в тариф «Веб-приложение / SaaS» — от 160 000 ₽, от 10 дней.

Зачем админка, если есть доступ к базе?

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

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

Что даёт админка вместо прямого доступа:

• Проверки при сохранении. Нельзя поставить отрицательную цену, закрыть заказ без оплаты или оставить клиента без телефона.
• Связи учитываются автоматически. При смене тарифа пересчитываются зависимые суммы, при архивации клиента его заказы не теряются.
• След изменений. Видно, кто и когда изменил запись, и можно вернуть прежнее значение.
• Права по ролям. Менеджер правит свои заявки, бухгалтер видит оплаты, но не меняет цены.

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

Что в ней обязательно с первого релиза?

Шесть вещей: справочники, список записей с поиском и фильтрами, карточка записи, журнал изменений, мягкое удаление и экспорт. Без них сервис формально работает, но каждая нестандартная ситуация превращается в задачу программисту. Остальное можно добавить по мере роста.

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

2. Список с поиском и фильтрами. Поиск по тому, что сотрудник реально знает в момент звонка: телефон, номер заказа, ИНН, фамилия, почта. Фильтры — по статусу, дате, ответственному, сумме. Хорошая проверка на этапе прототипа: попросите сотрудника найти клиента по последним цифрам телефона и посчитайте клики.

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

4. Журнал изменений. Подробнее о нём — в следующем разделе. Здесь важно одно: добавить журнал задним числом можно, но историю за прошедшие месяцы уже не восстановить.

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

6. Экспорт. Выгрузка текущего списка с применёнными фильтрами в Excel или CSV. Это первое, что попросит бухгалтер и руководитель, и одна из самых дешёвых функций, если заложить её сразу.

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

Функция	Когда нужна	Чем рискуете без неё
Справочники (тарифы, категории, статусы, города)	С первого релиза, если значения меняются чаще раза в квартал	Каждое изменение цены или статуса — заявка программисту и ожидание
Поиск и фильтры по ключевым полям	С первого релиза	Сотрудники ищут клиента пролистыванием и выгружают всё в Excel
Карточка записи со связанными данными	С первого релиза	Чтобы понять историю клиента, открывают пять разных экранов
Журнал изменений	С первого релиза, если правят деньги, цены или статусы	Спор «кто поменял цену» решается по памяти, ошибку не откатить
Мягкое удаление (корзина)	С первого релиза	Случайное удаление стирает заказы и платежи вместе со связями
Экспорт в Excel/CSV	С первого релиза: отчёты и сверки	Бухгалтер просит выгрузку у разработчика каждую неделю
Импорт из Excel/CSV	Когда данные приходят пачками: прайсы, остатки, списки клиентов	Ручной ввод сотен строк и опечатки
Массовые действия	Когда записей больше нескольких сотен	Смена статуса у 200 заказов — 200 кликов
Настройки без программиста (тексты писем, лимиты, реквизиты)	Когда тексты и параметры меняются по ходу работы	Мелкая правка текста превращается в выкладку новой версии
Дашборд с цифрами дня	Можно во второй версии	Руководитель собирает показатели вручную

Журнал действий: кто что изменил

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

Что должно попадать в журнал:

• создание, изменение, удаление и восстановление записей;
• для изменений — старое и новое значение каждого поля, а не только «запись изменена»;
• вход в админку, неудачные попытки входа, смена ролей и паролей;
• импорт и массовые операции — одной строкой с числом затронутых записей и ссылкой на файл.

Что важно для заказчика:

• Журнал только на запись. Даже администратор не должен иметь кнопки «очистить журнал» — иначе в нём нет смысла.
• Журнал видно из карточки. История конкретного заказа — во вкладке на его странице, а не в отдельном разделе, где нужно знать идентификатор записи.
• Откат — по одному полю. Удобно, когда из журнала можно вернуть прежнее значение кнопкой. Это не обязательно в первой версии, но журнал стоит хранить в таком виде, чтобы откат можно было добавить.
• Срок хранения. Журнал растёт быстрее основной базы. Решите заранее, сколько хранить подробную историю — год, три, без ограничения — и что делать со старыми записями.

Журнал — не замена резервным копиям. Копия спасает, когда пропала вся база; журнал — когда кто-то в среду поменял одну цену, а заметили в пятницу.

Импорт и экспорт данных

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

Хороший импорт работает в три шага:

1. Загрузка и сопоставление колонок. Система показывает, какая колонка файла в какое поле пойдёт, и даёт поправить.
2. Предпросмотр. «Будет создано 120 записей, обновлено 340, с ошибками 7» — и список ошибок с номерами строк до того, как что-то изменится в базе.
3. Применение и отчёт. Импорт попадает в журнал одной операцией, и его можно отменить целиком.

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

У экспорта своя ловушка. Если пользователи сервиса могут вводить текст, а сотрудники потом открывают выгрузку в Excel, ячейка, начинающаяся со знаков «=», «+», «-» или «@», может выполниться как формула. Это известный класс уязвимостей — CSV Injection по классификации OWASP. Защита простая — экранировать такие значения при выгрузке, но о ней нужно помнить.

Пример из нашей практики — админка прайса для шинного центра «Зелёная дорога»: одна таблица на все позиции (в каталоге 34 позиции шин и 1 182 диска), остатки и цены по ступеням, импорт и экспорт Excel, резервные копии с восстановлением и кнопка «Сохранить и опубликовать» — цены на сайте обновляются без программиста. Если данные приходят не файлом, а с сайтов поставщиков, это уже задача парсера — о ней в статье «Парсер и импорт каталога на заказ».

Массовые действия и настройки без программиста

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

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

В настройки обычно выносят:

• тексты писем, уведомлений и сообщений об ошибках для клиентов;
• реквизиты компании, контакты, часы работы;
• лимиты и сроки: сколько дней на оплату, через сколько дней напомнить, максимальная скидка менеджера;
• включение и выключение отдельных функций без выкладки новой версии.

Так устроена, например, админка сайта проката LENCAR: весь парк из 12 автомобилей, цены, фото, тексты главной, контакты и SEO-поля владелец правит сам, а заявки с сайта сразу попадают в админку со счётчиком новых.

Граница здесь тоже есть: не всё стоит выносить в настройки. Логику расчёта цены или порядок статусов разумнее менять через разработчика с тестами — ошибка в такой «настройке» ломает процесс целиком.

Что можно отложить?

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

Что откладывать безопасно, а что нет:

• Можно отложить: графики и дашборды, сохранённые фильтры, перетаскивание колонок, тёмную тему, мобильную версию админки (если сотрудники работают за компьютером), откат кнопкой, импорт из нескольких источников.
• Нельзя откладывать: журнал изменений, мягкое удаление, роли и проверки при сохранении. Их сложно и дорого добавлять, когда в базе уже есть живые данные: прошлую историю не восстановить, а удалённое физически не вернуть.

Как выбирать, что оставить в первой версии всего сервиса, а не только админки, разобрано в статье «MVP или полная версия».

Какие ошибки чаще всего делают при заказе админки?

Главная ошибка — проектировать админку в последнюю очередь, «когда клиентская часть будет готова». Тогда в смете на неё не остаётся времени, и сотрудники получают сырые таблицы базы. Админку описывают в ТЗ так же подробно, как экраны для клиентов.

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

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

Когда отдельная админка вам не нужна?

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

• Сайт-визитка или лендинг: тексты меняются редко, достаточно правки через поддержку или простого редактора страниц.
• Сервис-надстройка над CRM или 1С: заказы и клиенты живут там, админка нужна только для настроек самого сервиса.
• Прототип для проверки спроса на десяти пользователях: несколько недель можно обойтись ручными правками, если это сознательное решение с датой окончания.

Сколько стоит админка?

Отдельной цены у админки нет: она часть веб-приложения. Таблицы с фильтрами, поиском и экспортом, личные кабинеты и разграничение прав по ролям входят в тариф «Веб-приложение / SaaS» — от 160 000 ₽, от 10 дней. Сложный импорт, журнал с откатом и нестандартные массовые операции считаем после брифа.

Что влияет на цену админки сильнее всего:

• Число сущностей и связей. Пять справочников и одна главная таблица — одно, двадцать связанных сущностей — другое.
• Импорт. Простая загрузка одного формата заметно дешевле, чем сопоставление колонок, предпросмотр, отчёт об ошибках и отмена.
• Журнал. Запись изменений с полями «было — стало» и откат кнопкой — разный объём работы.
• Права. Роли на уровне разделов проще, чем права на отдельные записи и поля.

Если админка нужна для магазина, а не для сервиса, «админка для управления» входит в тариф «Интернет-магазин» от 104 000 ₽. По веб-приложению после запуска 14 дней бесплатной поддержки (мелкие правки), гарантия по договору — 30 календарных дней с даты акта, дальше новые экраны админки добавляем в рамках поддержки и развития от 7 900 ₽/мес. Из чего складывается цена первой версии сервиса целиком — в статье «Сколько стоит MVP».

Что подготовить к брифу на админку?

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

1. Кто работает в админке: роли и примерное число людей в каждой.
2. Пять-десять операций, которые каждый делает ежедневно.
3. Примеры Excel-файлов для импорта и отчётов, которые нужны на выходе.
4. Что сейчас просят «поправить в базе» — список за последний месяц.
5. Какие данные влияют на деньги и требуют журнала.

Короткие ответы на частые вопросы

Админка — это отдельная программа или часть веб-приложения?

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

Можно ли взять готовую админ-панель вместо заказной?

Можно, если нужен просто редактор таблиц для одного-двух сотрудников. Как только появляются свои статусы, связи между записями, проверки при сохранении и роли, готовую панель всё равно приходится дописывать, и выгода по срокам пропадает.

Сколько стоит админка для веб-приложения?

Отдельной цены у нас нет: таблицы с фильтрами, поиском и экспортом, роли и разграничение прав входят в тариф «Веб-приложение / SaaS» от 160 000 ₽. Импорт сложных файлов, журнал с откатом и массовые операции сверх базовых считаем после брифа и записываем в спецификацию.

Зачем журнал изменений, если есть резервные копии базы?

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

Что делать, если сотрудники до сих пор правят данные прямо в базе?

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

Услуги и кейсы по теме: веб-приложения и SaaS · поддержка сайта от 7 900 ₽/мес · кейс «Зелёная дорога» · цены и сроки