Доработка интернет-магазина на Битриксе: как передать проект новой команде

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

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

Сначала отделите аварии от очереди улучшений

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

Не начинайте передачу с массового обновления модулей «заодно». Сначала сохраните исходное состояние и воспроизведите проблему. Иначе исчезнет возможность понять, что сломалось раньше, а что изменилось в ходе работ.

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

Передайте управление проектом, а не один пароль от админки

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

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

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

Резервную копию нужно один раз восстановить

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

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

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

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

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

Аудит должен объяснять ограничения бизнеса

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

На стороне разработчика проверяются версии платформы и модулей, окружение, пользовательский код, фоновые задания, обмены, журнал ошибок и процедура выпуска. Штатная «Проверка системы» Битрикс проверяет соответствие окружения требованиям продукта. Она не заменяет проверку покупки: совместимый сервер тоже может обслуживать магазин с неверным расчётом скидки.

Для собственных доработок в Bitrix Framework предусмотрена папка /local. При приёмке важно узнать, где находятся именно ваши изменения, были ли изменены файлы продукта и какие последствия это имеет для обновлений. Наличие папки /local само по себе не доказывает качество кода.

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

У каждой находки полезно видеть степень уверенности. «Воспроизведено на копии», «подтверждено журналом» и «требуется проверить при доступе к 1С» обозначают разный объём сделанной работы. Это защищает и заказчика, и исполнителя от оценки на предположениях.

Зафиксируйте путь одного заказа через все системы

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

У цепочки должны быть идентификаторы. Фразы «заказ пришёл в 1С» недостаточно: нужно сопоставить номер на сайте, внешний идентификатор обмена и документ в учёте. Затем проверить состав, сумму, доставку, скидку и статус. Подробно обмен разобран в материале об интеграции интернет-магазина с 1С.

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

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

Журналы нужны, чтобы восстанавливать события

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

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

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

Выберите небольшую первую доработку

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

Пример постановки: «При самовывозе поле адреса не обязательно; при доставке оно обязательно. Выбранный пункт самовывоза сохраняется в заказе и передаётся в учёт. При переключении способов доставки итог пересчитывается. Старые заказы открываются без ошибки».

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

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

Что должно остаться после выпуска

Владелец не обязан читать PHP, но может требовать прослеживаемость: номер задачи, описание результата, перечень изменённых частей, версия релиза и доказательства проверки. Исходники должны попадать в репозиторий, доступный компании.

В GitHub изменения можно просматривать по файлам в разделе Files changed; другие системы контроля версий дают аналогичный способ сравнения. Экран из документации иллюстрирует такой просмотр. Само наличие сравнения ещё не означает, что код проверен и задача принята.

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

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

Проверьте приёмку по девяти сценариям

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

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

Заявка в Метрике и заявка у менеджера проверяются отдельно

Метрика позволяет настроить целевое событие и передавать его через reachGoal. Название цели не определяет, в какой момент она сработает: это зависит от реализации на сайте. Экран из справки Яндекса показывает настройку идентификатора события.

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

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

Когда дорабатывать, а когда обсуждать замену магазина

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

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

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

Чтобы обсудить доработку с CAPS, подготовьте адрес магазина, три наиболее болезненные задачи и один пример заказа или сбоя без данных покупателя. Этого достаточно для первого разговора о границах работы. Доступы и подробные данные передаются уже по согласованному рабочему каналу; окончательная оценка зависит от обследования проекта.