Подхват админ-панели от другого подрядчика

С короткой стартовой сессии и заявки на аудит. Обсуждаем, что за админка или backoffice, какие команды в ней работают (операторы, менеджеры, склад, поддержка, бухгалтерия, контент), какие операции критичны для бизнеса (статусы заказов, отмены, возвраты, документы, тарифы), какие связки с CRM, 1С, сайтом и продуктом подключены, что произошло с прошлой командой, какие доступы уже на вашей стороне. По запросу подписываем NDA. Дальше — аудит ролей, операций над данными, audit log, импортов, ручных правок и интеграций. Условия подхвата обсуждаем после отчёта.

Да. Аудит админ-панели — отдельный формат. По итогам у вас остаётся письменный отчёт, схема ролей и операций по командам, карта рисков по данным, правам, audit log и интеграциям, список доступов и план стабилизации. Дальше вы выбираете: возвращаетесь к подрядчику с конкретным списком, ищете другую команду, передаёте отчёт внутренней команде или продолжаете работу с нами.

В первый месяц не запускаем массовые операции и импорты без бэкапа, плана отката и ответственного со стороны заказчика, не меняем модель ролей и опасные кнопки без тестового сценария, не правим боевые данные «руками» без записи в audit log. Опасные кнопки временно закрываем подтверждениями и preview. Гарантию «без ошибок в данных» не даём — это нечестно, но всё, что зависит от подрядчика, делаем именно с этим приоритетом.

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

Да, если у админки есть чёткие границы ответственности и понятный контракт с продуктовым backend, CRM и 1С. Часто берём frontend и серверную часть админки, а основной продукт остаётся у другой команды — или наоборот, забираем серверную часть с интеграциями, оставляя UI. Аудит в этом случае фокусируется на админке, но обязательно описывает контракт со смежными системами и риски на стыках. Без понимания этих стыков подхват одной части быстро ломает соседнюю.

На аудите смотрим обе стороны обмена. Часто «админка показывает неверный статус» или «оператор не может сохранить заказ» — это сломанный webhook, расхождение с CRM, рассинхронизация с 1С или потерянный ретрай во внешней очереди. В отчёте отделяем часть, которая живёт в админке, от смежных систем и предлагаем план по каждой. По CRM, 1С и backend есть отдельные страницы кластера — подхват CRM-системы, подхват 1С-проекта и подхват Python-проекта. При необходимости подхватим и смежные части отдельным форматом.

Заходим в проекты на стеках, с которыми работают наши команды: Django Admin и FastAPI на Python, Laravel и Symfony на PHP, Express и NestJS на Node.js, Go там, где он уместен. Frontend — React, Vue, Angular или legacy jQuery поверх серверного рендеринга. Самописные админки и кастомные backoffice разбираем на тех же принципах: роли, операции, audit log, валидация. На стартовой сессии уточняем стек и какие части сделаны кастомно.

Это типовая ситуация после длительной эксплуатации: часть сценариев в админке не предусмотрена и закрывается прямыми SQL-командами или Excel-выгрузками с последующим импортом. На аудите фиксируем эти обходы и отделяем те, что можно перенести в управляемую операцию админки, от тех, что должны остаться за пределами интерфейса по бизнес-причинам. В план стабилизации попадают опасные ручные операции, у которых нет аудита и проверки прав — на них в первую очередь нужны кнопки с подтверждением, валидация и audit log.

По итогам подхвата готовим чек-лист для внутренней команды: репозитории и CI/CD, env и секреты, схема ролей и прав по разделам, описание критичных операций, формат и хранение audit log, обработчики импортов и интеграций, регламент изменений. Audit log и правила валидации передаём как обязательный артефакт — это то, что нельзя терять при смене команды. Можем сопровождать первые недели работы внутренней команды.

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