ТЗ на интернет-магазин: требования к каталогу, заказу и интеграциям

Что должно решать ТЗ на магазин

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

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

Шаблон строки ТЗ и комплект приёмки

Требование готово тогда, когда по нему можно оценить работу и воспроизвести проверку без устного объяснения автора.

• Пример: «Покупатель выбирает размер товара с независимым остатком. Если осталась одна единица, после добавления в корзину доступность пересчитывается по согласованному правилу резерва. При повторе запроса создаётся один заказ. Если остаток изменился, система показывает причину и сохраняет остальные позиции». Здесь указаны состояние, действие и исключение; числовые пороги бизнес утверждает отдельно.
• К каждому критическому требованию добавьте идентификатор, приоритет, владельца, источник данных, макет или схему и критерий проверки. Разделите «обязательно к запуску», «можно проверить пилотом» и «следующий этап». Функция без понятного владельца контента или внешнего доступа должна оставаться зависимостью, а не молчаливым обещанием подрядчика.
• Соберите тестовый набор: товар с несколькими вариантами, отсутствующий товар, скидка, разные регионы доставки, успешная и прерванная оплата, повтор callback, отмена и возврат. Для интеграций нужен контрольный заказ, который прослеживается от сайта до учётной системы и обратно. Приёмка проверяет не только интерфейс, но и следы обработки.
• В отдельном приложении зафиксируйте URL-структуру, миграцию со старого магазина, редиректы, canonical, индексируемость категорий и карточек, состояние удалённого товара, скорость и доступность. Google документирует разметку товара и торговых предложений; включайте её только для данных, которые действительно показаны покупателю, и проверяйте валидность после публикации.

Входные данные, без которых оценка условна

До описания экранов зафиксируйте торговые правила и владельцев данных. Иначе команда будет додумывать их в разработке.

• Опишите ассортимент: физические или цифровые товары, количество SKU, размеры и цвета, наборы, товары под заказ, признаки маркировки и ограничения по доставке. Укажите, кто создаёт карточки, фотографии, описания и характеристики и как проверяет полноту данных до импорта. Для варианта товара запишите собственный идентификатор и правило отображения остатков.
• Нарисуйте путь от источника трафика до подтверждения заказа: поиск, фильтр, карточка, корзина, контакты, способ доставки, оплата и уведомление. Для каждого шага запишите, какую информацию человек должен получить и что происходит при ошибке. Отдельно пройдите сценарий без регистрации, если он предусмотрен бизнесом.
• Определите владельца цены, остатка, резерва, статуса оплаты и статуса доставки. Это может быть учётная система, админка магазина или внешний сервис; два одновременных владельца одного поля создают конфликт. Зафиксируйте частоту обновления, допустимую задержку и действие при недоступности источника.
• Соберите ограничения: языки и регионы продаж, валюты, налоговые и договорные требования, возвраты, политика данных, доступы сотрудников, мобильный трафик, существующий домен и SEO-переезд. Юридические формулировки и платёжные договоры должен подтвердить уполномоченный специалист; ТЗ не заменяет такое согласование.
• Назначьте ответственных за решения и материалы: владелец продукта утверждает правила торговли, склад — резервы и отгрузку, бухгалтерия — документы, редактор — контент, интегратор — обмен, служба поддержки — обработку исключений. Открытые решения оформляйте списком с датой и владельцем, а не скрывайте в слове «уточнить».

Структура требований по покупательскому пути

Пишите каждый пункт как условие, действие и проверяемый результат. Ниже — каркас, который можно адаптировать к конкретной модели продаж.

• Каталог и поиск. Опишите иерархию категорий, атрибуты фильтров, сортировку, пустые результаты и синонимы. Для каждой категории укажите, какие свойства доступны для фильтрации и кто их заполняет. Критерий приёмки: контрольные товары находятся по названию и ключевым характеристикам, а фильтр не показывает отсутствующий вариант как доступный без объяснения.
• Карточка товара. Зафиксируйте название, фотографии, варианты, состав или спецификацию, цену, наличие, срок поставки, доставку и возврат. Если размер или цвет меняет цену либо остаток, выбор варианта должен обновлять все связанные условия. Укажите состояния «нет в наличии», «под заказ» и «снято с продажи», включая поведение уже проиндексированного URL.
• Корзина и оформление. Опишите сохранение корзины, изменение количества, промокод, расчет доставки, согласие и минимальный набор контактных данных. Покупатель видит итоговую сумму до подтверждения. Проверьте изменение цены или остатка между добавлением и оплатой: система должна объяснить конфликт и предложить исправление, а не молча удалить позицию.
• Оплата и заказ. Запишите поддерживаемые способы оплаты, момент создания заказа, связь платежа с заказом и состояния «ожидает», «оплачен», «ошибка», «возврат». Повторное нажатие или callback платежного сервиса не должны создавать второй заказ. При разрыве связи покупатель получает честный статус, а оператор — задачу сверить платеж, прежде чем просить оплатить повторно.
• Доставка и коммуникация. Для каждого региона опишите способы, цену, интервалы и ограничения товара. Укажите, кто отправляет уведомление об изменении статуса и где покупатель видит актуальную информацию. Не обещайте автоматический трекинг, если перевозчик не передает события; предусмотрите ручной путь и ответственного.
• Администрирование. Разделите права на публикацию товара, изменение цены, возврат и просмотр персональных данных. Потребуйте журнал значимых изменений и возможность найти конкретный заказ по устойчивому идентификатору. Опишите массовый импорт и проверки ошибок: неверный файл не должен частично испортить каталог без отчёта.
• Интеграции и аналитика. Для 1С, CRM, оплаты, доставки и почты укажите поля, направление, частоту, идентификаторы и реакцию на недоступность. События аналитики привяжите к реально завершённым шагам, а не к загрузке страницы. Если передаёте выручку и состав заказа, проверьте согласие и отсутствие персональных данных в аналитических параметрах.

Как оценивать готовность требований

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

• Доля критических сценариев с критериями приёмки, владельцем и тестовыми данными; отдельно учитывайте ошибки оплаты и изменения остатка.
• Число открытых решений по цене, резерву, доставке, возврату и персональным данным до фиксации объёма.
• Доля интеграций с описанным владельцем данных, идентификатором, повтором события и маршрутом устранения ошибки.
• Количество изменений объёма после согласования; разбирайте, вызваны ли они новым решением бизнеса или пропущенным исходным правилом.

Формулировки, которые нужно переписать

Слишком общие пункты размывают объём и переводят важные решения в спор после запуска.

• «Современный магазин с удобной корзиной» не определяет состояние при изменении цены, сбое оплаты или повторе заказа. Перепишите как последовательность шагов и ожидаемых результатов.
• «Синхронизация с 1С» без списка сущностей, направления и владельцев полей не даёт оценить объём. Название системы не заменяет модель обмена и контроль расхождений.
• «SEO как у лидеров рынка» не описывает шаблоны title, индексацию, редиректы и товарные данные. Зафиксируйте конкретный набор страниц и правила публикации.
• «Адаптивная версия» без проверяемого пути покупки на мобильном оставляет кнопку оплаты, фильтры и поля ввода без приёмки. Укажите устройства и сценарии, а не только ширину макета.

Минимальный результат до старта разработки

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

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

Проверка, которую стоит провести лично

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

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

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

Для SEO-приложения к ТЗ перечислите типы индексируемых страниц и их владельцев: категории, карточки, информационные материалы. Опишите, что произойдёт с URL исчезнувшего товара, фильтрованной выдачей и старой страницей при переезде. Canonical и редиректы не стоит откладывать на день релиза: к этому моменту новая структура уже окажется привязана к шаблонам. Товарная структурированная разметка должна соответствовать видимой цене и наличию; несоответствие лучше обнаруживать автоматической проверкой после обновления каталога.

В финальной ведомости приёмки рядом с каждым критическим требованием оставьте поля для сценария теста, фактического результата, ссылки на доказательство и владельца решения. Отдельно помечайте спорные допущения: кто оплачивает возврат, можно ли заменить отсутствующий товар, как долго живёт резерв. Если предположение изменилось, укажите влияние на срок и объём. Это защищает и клиента, и подрядчика: становится видно, что именно было принято, а какая функция ещё ждёт бизнес-решения.