Просьба добавить поле в карточку товара выглядит небольшой задачей. Но сначала нужно выяснить, кто заполняет это поле, где оно используется и что произойдет после следующей загрузки данных. При доработке сайта на Битрикс объем определяет не только видимое изменение, но и его связи с существующей системой.
Задача начинается с ожидаемого действия
Вместо «переделать каталог» опишите, что должен сделать посетитель или сотрудник. Укажите исходную страницу, действие и ожидаемый результат: какие данные человек увидит, что сможет отправить, где появится запись. Такой сценарий дает исполнителю основание для оценки, а вам — для приемки.
Отдельно перечислите условия, при которых результат меняется: заполнено ли поле, есть ли товар в наличии, какая роль у пользователя. Не нужно заранее выбирать техническое решение. В разработке сайта полезнее сначала зафиксировать нужное поведение, а затем выбирать способ его получить.
За страницей стоят компоненты и шаблоны
В Битрикс компонент работает с данными, а его шаблон выводит их на страницу — это разделение описано в официальной документации. Поэтому изменение внешнего вида и изменение правил обработки данных могут затрагивать разные части сайта. По одному макету нельзя определить весь объем работ.
Перед оценкой стоит попросить исполнителя установить, что используется в нужном сценарии: стандартный компонент, измененный шаблон или собственная разработка. Важно понять и границу правки: только вывод информации или еще ее получение и сохранение. Название платформы само по себе этого не объясняет.
Собственная логика требует карты зависимостей
Полезный результат предварительного разбора — короткое описание связей: откуда приходят данные, какие части сайта их меняют и кто получает результат. Это не пересказ всей истории разработки. Для конкретной задачи достаточно установить зависимости, которые могут повлиять на ее выполнение и проверку.
В исходные сведения включают редакцию и установленную версию системы, используемые модули, известные изменения и ограничения окружения. Неизвестные сведения лучше так и обозначить. Сторонний модуль или старый код — повод проверить совместимость, а не готовое объяснение любой ошибки; медленная страница тоже требует отдельной диагностики скорости.
Отдельно уточняют состояние лицензии. Обновления платформы приходят, пока оплачен период технической поддержки; после его окончания сайт продолжает работать, но обновлений, в том числе касающихся безопасности, больше не получает. Для доработки это практический вопрос: часть решений требует свежей версии, и если обновления недоступны, выбор способа сужается. Выяснить это до оценки дешевле, чем после.
Правка в файлах платформы не переживет обновления
Платформа обновляется регулярно, и обновление затрагивает ее собственные файлы. Изменение, внесенное прямо в них, при очередном обновлении исчезает, а вместе с ним возвращается прежнее поведение, которое к тому времени все считают исправленным.
Поэтому для оценки важно знать, где исполнитель собирается разместить изменение: в шаблоне сайта, в скопированном шаблоне компонента, в собственном модуле или в обработчике события. Разбираться в этих способах заказчику не нужно, нужен ответ на простой вопрос: что случится с правкой при следующем обновлении.
Тот же вопрос стоит задать про решения из каталога. Их обновления выпускает не ваш исполнитель, и изменения внутри такого решения теряются по тому же сценарию. Если правка туда все-таки необходима, это отдельная договоренность с понятными последствиями.
Обмены продолжаются после правки страницы
В Битрикс предусмотрены компоненты импорта и экспорта каталога с 1С. Если нужное поле участвует в обмене, важно выяснить, какая система им управляет. Иначе проверка ручного редактирования не ответит на вопрос, сохранится ли результат после очередной загрузки.
Для изменяемых данных согласуйте источник, направление передачи и поведение при повторном обмене. Эти решения стоит обсудить с ответственным за учетную систему; состав вопросов разобран в материале про обмен с 1С. Проверять нужно не только появление значения на странице, но и его дальнейшую судьбу.
Отдельного внимания требуют автоматические операции. В платформе есть агенты для задач по расписанию и фоновые задачи, выполняемые после отправки ответа пользователю, — их различает документация 1С-Битрикс. Поэтому успешное открытие страницы еще не означает, что связанные с изменением процессы завершились правильно.
Тестовая версия и проверка соседних сценариев
До внедрения согласуйте проверку на тестовой копии. Для нее нужно отдельно определить, куда уходят уведомления, заказы и запросы к внешним системам. Тест не должен создавать рабочие операции, которые сотрудники примут за настоящие.
Критерий готовности включает новый сценарий и связанные с ним действия, которые уже работали. Для поля каталога это могут быть отображение, редактирование и повторный обмен, если он затрагивает поле. Набор проверок выбирают по найденным зависимостям, а не по длине списка возможных функций сайта.
Проверять результат стоит под разными ролями. Изменение, заметное администратору, может быть недоступно менеджеру или посетителю без входа: права задаются группами пользователей, и видимость поля или раздела зависит от них. Приемка одним человеком под одной учетной записью регулярно пропускает именно это.
Сохраненные страницы мешают принимать работу
Платформа сохраняет результат работы компонентов, чтобы не считать его при каждом открытии страницы. Для приемки отсюда следует практическое неудобство: после правки страница какое-то время показывает прежнее содержимое, и это не говорит ни об успехе, ни о неудаче.
Договоритесь, как проверять результат: после сброса сохраненных данных, в чистом браузере, а при необходимости на странице с временно отключенным сохранением. Иначе приемка превращается в спор о том, у кого что отображается.
Обратная сторона та же. Если изменение видно сразу, стоит убедиться, что оно сохранится и после штатного обновления сохраненных данных. Проверка сразу после сброса и проверка на следующий день отвечают на разные вопросы.
Границы оценки и внедрения
В оценке полезно разделить понятную доработку и вопросы, для которых еще нужен разбор кода. Попросите указать, что входит в работу, какие сведения пока неизвестны и при каких находках объем придется пересмотреть. Это делает предварительную оценку понятной без обещаний, не подтвержденных исследованием сайта.
Перед переносом изменения договоритесь о резервной копии, порядке возврата и проверке на рабочем сайте. Отдельно определите, кто принимает результат и кто наблюдает следующий запуск затронутого обмена или автоматической операции. Завершение работы должно подтверждаться согласованными проверками.
Для оценки пришлите адрес сайта, описание нужного изменения и ожидаемый результат. Добавьте известные сведения о версии системы, собственных доработках и обменах, а также ограничения: что нельзя менять и с кем согласовывать связанные процессы.