Что входит в техническое задание на интернет-магазин

Проект стартовал на словах: «сделаем как у конкурента, только удобнее и с выгрузкой из 1С». Через два месяца выясняется, что заказчик имел в виду одно, подрядчик сделал другое, а обмен с 1С «почему-то» не учитывает резервирование остатков. Знакомо? Почти все провальные проекты интернет-магазинов начинаются одинаково — с отсутствия внятного технического задания.

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

Зачем вообще нужно ТЗ

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

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

Цели, аудитория и границы проекта

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

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

• Цели и метрики. Ради чего делается магазин и как измерим успех.
• Аудитория. Розница, опт, дилеры — от этого зависит вся логика.
• Что в проекте. Перечень модулей и функций первой очереди.
• Что вне проекта. То, что сознательно откладывается или не делается, чтобы не спорить потом.

Отдельно стоит определиться с типом проекта: розничный магазин, оптовый портал или гибрид. B2B-требования (цены по группам, оформление по договору, кабинеты) сильно меняют ТЗ, и решать это надо на старте, а не в середине.

Структура каталога и карточка товара

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

• Дерево разделов. Как устроены категории, вложенность, где товар может быть в нескольких разделах.
• Свойства товаров. Полный список характеристик, их типы, какие приходят из 1С, какие ведутся на сайте.
• Торговые предложения (SKU). Есть ли варианты (размер, цвет), как они устроены и отображаются.
• Карточка товара. Состав блоков: галерея, цены, наличие, характеристики, сопутствующие товары.
• Цены и остатки. Какие типы цен, как считается наличие по складам, что видит какая группа.

Именно свойства товара — то место, где ТЗ чаще всего «недокручивают». А ведь от них зависят фильтр, сравнение, выгрузки и SEO. Стоит один раз спроектировать набор свойств правильно, чем переделывать каталог после наполнения.

Поиск, фильтр и навигация

Как посетитель находит товар — отдельный раздел ТЗ. Здесь описывают умный фильтр (на 1С-Битрикс это компонент catalog.smart.filter), логику поиска и вспомогательную навигацию.

Что важно зафиксировать:

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

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

Корзина и оформление заказа

Оформление заказа — процесс, где магазин зарабатывает, и его сценарий описывают пошагово. На 1С-Битрикс это модуль «Интернет-магазин» и его оформление (sale.order), которое настраивается под ваши правила.

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

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

Обмен с 1С — ядро ТЗ

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

Стандартный механизм — обмен по протоколу CommerceML 2.x, но его надо описать под ваши данные: какие свойства выгружаются, как сопоставляются склады и типы цен, что происходит при обновлении статуса заказа. Чем детальнее эта часть, тем меньше сюрпризов на запуске. Смежные вопросы стабильности интеграций мы разбираем в статьях про REST и вебхуки в Битрикс и разработку модулей для Маркетплейса.

Интеграции: оплата, доставка, сервисы

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

• Платёжные системы. Какие подключаем, для каких способов оплаты, как обрабатываем статусы и возвраты.
• Службы доставки. Расчёт стоимости и сроков, выбор пунктов выдачи, трек-номера.
• Аналитика. Веб-аналитика Битрикса, Яндекс Метрика, электронная коммерция, цели.
• CRM и уведомления. Передача лидов и заказов, email/SMS/мессенджеры.

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

Роли, кабинеты и права доступа

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

• Группы пользователей. Розница, опт, дилеры — и что видит каждая (цены, наличие, способы оплаты).
• Личный кабинет. История заказов, повторный заказ, документы, для B2B — согласования и лимиты.
• Администрирование. Роли контент-менеджера и оператора, что они могут менять.
• Права доступа. Разграничение по разделам и действиям, чтобы каждый видел только своё.

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

Нефункциональные требования

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

• Производительность. Целевая скорость страниц, Core Web Vitals, поведение на большом каталоге.
• Нагрузка. Ожидаемый трафик, пиковые нагрузки в акции, требования к хостингу.
• Безопасность. Защита данных, доступов, платежей, требования к обновлениям.
• SEO. ЧПУ, микроразметка, метатеги, карта сайта, требования к скорости индексации.
• Совместимость. Браузеры, мобильные устройства, адаптивность.

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

Критерии приёмки и управление изменениями

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

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

Частые ошибки при составлении ТЗ

• «Сделать удобно и красиво». Общие формулировки без проверяемых критериев ведут к спорам на приёмке.
• Расплывчатый обмен с 1С. «Настроить обмен» без состава данных, направления и правил конфликтов — главная причина провалов.
• Забыли нефункциональные требования. Нет требований к скорости и нагрузке — магазин тормозит и падает в акции.
• Нет границ проекта. Не прописано, что вне работ, — объём бесконтрольно растёт.
• Игнор B2B-специфики. Цены по группам и оформление по договору всплывают в середине проекта.
• Нет критериев приёмки. Готовность оценивают на глаз, а не по проверяемым условиям.
• Нет процедуры изменений. Правки принимаются на словах и рушат сроки и бюджет.

Чек-лист готового ТЗ

1. Цели и границы. Описаны бизнес-цели, аудитория, что в проекте и что вне его.
2. Каталог спроектирован. Дерево разделов, свойства, торговые предложения, цены и остатки.
3. Поиск и фильтр. Умный фильтр, поиск (для опта — по артикулу), сортировки и навигация.
4. Оформление заказа. Корзина, шаги, доставка, оплата и правила для розницы и опта.
5. Обмен с 1С детализирован. Источник истины, состав, направление, частота, идентификаторы, конфликты.
6. Интеграции описаны. Оплата, доставка, аналитика, CRM с контрактами и обработкой ошибок.
7. Роли и кабинеты. Группы пользователей, личный кабинет, права доступа и B2B-сценарии.
8. Нефункциональные требования. Скорость, нагрузка, безопасность, SEO, совместимость.
9. Приёмка и изменения. Проверяемые критерии приёмки и процедура управления изменениями.

Вывод

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

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