Что должно быть в ТЗ на интернет-магазин на 1С-Битрикс

01

ТЗ начинается с процесса продажи, а не с перечня страниц

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

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

Для каждого шага полезно назвать владельца процесса. Маркетинг отвечает за источники трафика и UTM-метки, контент-менеджер — за карточки, отдел продаж — за правила обработки, бухгалтерия — за чеки и статусы оплаты, техническая команда — за обмен и логи. Так требования не останутся предположением разработчика.

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

03

Что включить в ТЗ на сайт на 1С-Битрикс

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

В каталоге недостаточно написать «нужны фильтры». Укажите свойства для отбора, типы значений, логику «И» или «ИЛИ», сортировку, поведение пустой выдачи и SEO-страницы фильтров. Если в 1С существуют характеристики «размер» и «цвет», нужно решить, являются ли они свойствами товара или торговыми предложениями. От этого зависят остатки, цена, URL карточки и механизм обмена.

Для оформления заказа опишите доступные способы доставки и оплаты, условия показа, стоимость, минимальную сумму, регионы, текст ошибок и момент резервирования товара. В 1С-Битрикс эти правила обычно связаны с типами плательщиков, службами доставки и платёжными системами. Базовую логику можно сверять с документацией 1С-Битрикс по интернет-магазину, но правила конкретного бизнеса всё равно должны быть в ТЗ.

04

Интеграции: описывайте контракт данных и сбои

Формулировка «синхронизировать магазин с 1С» не является техническим заданием. Нужно определить, какие сущности обмениваются: каталог, свойства, изображения, цены, остатки, заказы, статусы, контрагенты. Также важны направление обмена, периодичность, система-источник и правило конфликта. Например, остаток приходит только из учётной системы, а SEO-описание карточки редактируется только на сайте.

Для CRM отдельно зафиксируйте, что именно создаётся после оформления: лид, сделка, контакт или заказ; как ищется дубль; какие поля передаются; кто получает уведомление. Не передавайте в CRM абстрактное поле «комментарий»: разнесите комментарий клиента, состав заказа, источник, рекламную кампанию и технический ID. Тогда отчётность не потребует ручной очистки данных.

В ТЗ нужен сценарий ошибки. Если API CRM отвечает с ошибкой или обмен с 1С остановлен, заказ на сайте должен сохраниться, а ответственному сотруднику — прийти сигнал. Укажите место лога, период хранения, правило повторной отправки и владельца инцидента. Это особенно важно для ночных обменов и массового обновления каталога.

05

Поля, статусы и аналитика нужно согласовать до дизайна

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

Зафиксируйте скрытые поля формы и заказа: utm_source, utm_medium, utm_campaign, utm_content, utm_term, referrer, landing_page, client_id и yclid или gclid, если они используются. Для каждого поля укажите источник, формат, срок хранения и место назначения. UTM лучше сохранять в заказе при первой сессии либо по утверждённой модели атрибуции, а не брать только параметры текущего URL.

Статусы должны иметь бизнес-смысл. «Новый», «Ожидает оплаты», «Оплачен», «Передан в доставку», «Отменён» — это не декоративные подписи, а события для уведомлений, CRM, склада и аналитики. Укажите, кто вправе изменить статус и какие действия выполняются автоматически.

06

Как оформить критерии приемки, чтобы не спорить после запуска

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

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

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

1. 1

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

2. 2

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

3. 3

   Оформить заказ. Выбрать регион, доставку и оплату; проверить обязательные поля, согласия и понятные сообщения об ошибках.

4. 4

   Проверить оплату. Провести тестовый успешный и неуспешный платёж, сверить статус заказа и отсутствие повторного списания.

5. 5

   Сверить контуры. Убедиться, что заказ, UTM-метки и товары дошли в CRM и учётную систему в согласованном виде.

07

Границы проекта, доступы и ответственность

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

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

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

08

Ошибки, из-за которых оценка ТЗ становится неточной

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

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

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

09

Что передать подрядчику перед стартом

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

Перед оценкой соберите каталог или пример выгрузки, правила работы с заказами, список внешних сервисов, карту полей CRM, доступные способы оплаты и доставки, требования к аналитике и список ответственных. Если часть решений ещё не принята, пометьте её как открытый вопрос с владельцем и сроком. Это честнее, чем скрывать неопределённость в общей формулировке.

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