Как составить техническое задание на интернет-магазин: каталог, товарные данные, интеграции, оплата, доставка, SEO и критерии приёмки.
Техническое задание на интернет-магазин — это не перечень экранов и не ссылка на сайт конкурента. Это документ, который связывает бизнес-задачу, путь покупателя, данные о товарах и техническую реализацию. Он нужен, чтобы не обнаружить после дизайна, что цены не обновляются, заказ не попадает в CRM, а каталог нельзя нормально развивать.
В проектах интернет-магазинов прослеживается повторяющаяся закономерность: самые дорогие переделки возникают не из-за кода, а из-за неоговорённых требований. Магазин может выглядеть законченным, но не учитывать опт, возвраты, варианты товара, региональную доставку или работу менеджеров. Ниже — практический каркас ТЗ, который я использую перед запуском e-commerce-проектов.
Сначала фиксирую контекст, в котором магазин будет работать:
Это определяет архитектуру. Магазину косметики нужны состав, объём, назначение и линейка; магазину техники — совместимость, характеристики и аксессуары; B2B-проекту часто важнее запрос КП и документы, чем мгновенная оплата.
Если на эти вопросы нет ответа, не стоит прятать их под формулировку «сделаем потом». Именно такие решения чаще всего влияют на бюджет и сроки.
У каталога есть визуальная часть, но сначала нужна модель данных. В ТЗ я прошу подготовить хотя бы черновой список полей товара, категории и вариации.
Для каждой товарной группы полезно определить:
1. обязательные поля: бренд, артикул, цена, наличие, фото, описание;
2. характеристики для сравнения и фильтрации;
3. варианты: цвет, размер, объём, комплектация;
4. документы: инструкция, сертификат, гарантия;
5. связи: аналоги, аксессуары, совместимые товары, наборы;
6. правила для отсутствующего товара, предзаказа и цены по запросу.
Не нужно переносить все фильтры конкурентов. Фильтр оправдан, когда помогает выбрать из реального ассортимента. Избыточная фильтрация создаёт лишние URL, ухудшает сценарий пользователя и усложняет SEO.
За архитектуру категорий, посадочных фильтров и индексацию отвечает отдельный слой. Его я подробно разобрал в статье «SEO-структура каталога: категории, подкатегории, фильтры и посадочные страницы». В ТЗ магазина достаточно зафиксировать правила: какие разделы создаются вручную, какие параметры доступны покупателю и какие страницы не должны попадать в поиск.
У магазина несколько пользователей, и у каждого свой путь. В ТЗ перечисляются не только экраны, но и действия.
Поиск или реклама → категория → фильтр → карточка → корзина → оформление → уведомление → повторная покупка. На каждом шаге надо определить, что снимает сомнение: наличие, срок доставки, состав, совместимость, реальные фото, возврат или способ оплаты.
Для них могут понадобиться личный кабинет, персональные цены, минимальная партия, запрос счёта, загрузка заказа из файла, отсрочка и документы. Это не одна дополнительная кнопка, а отдельный процесс с ролями и правилами доступа.
Нужно определить, как заказ попадает в работу, какие данные видит менеджер, кто меняет статус, где хранится история и что происходит, если часть данных не пришла из сайта. Если этого нет в ТЗ, сайт и CRM начинают жить отдельно.
Покупатель не должен узнавать на последнем шаге, что товар не доставляется в его город или способ оплаты недоступен. В техническом задании фиксирую:
Такие условия важны и для доверия, и для представления магазина в поиске. В официальной документации Google для торговых сайтов отдельно рассматриваются актуальные данные о наличии, цене, доставке и правилах возврата — но указывать их в разметке можно только тогда, когда они совпадают с тем, что видит пользователь.
Самая частая ошибка — подключать CRM, склад или учётную систему, когда дизайн уже утверждён. В этот момент обычно обнаруживаются разные артикулы, статусы и правила обновления.
В ТЗ обязательно описывается реакция на ошибку: что увидит пользователь, куда попадёт заказ и кто узнает о сбое. Нет универсальной схемы, но «разберёмся после запуска» почти всегда превращается в потерю заказов.
Фраза «сайт должен быть быстрым» не является требованием. Я формулирую проверяемые критерии:
Если каталог использует бесконечную прокрутку, это не должно делать товары недоступными для роботов. У разделов и карточек должны оставаться понятные URL и обычные HTML-ссылки. Это помогает пользователю, поиску и дальнейшему развитию магазина.
SEO в ТЗ — не список ключевых слов. Это набор решений, которые дорого переделывать после запуска:
Требования к товарной странице я отдельно разобрал в статье «Карточка товара для поиска и нейросетей». Здесь задача другая: назначить обязательные поля и ответственного за качество этих данных.
Интернет-магазин стоит принимать по конкретным действиям.
Проверку нужно проводить на тестовых данных и реальных устройствах. Если проект принимает только дизайнер или разработчик, можно пропустить проблему, с которой столкнётся первый покупатель или менеджер.
На стоимость сильнее всего влияют не блоки на главной, а сложность ассортимента, количество вариаций, интеграции, личный кабинет, персональные цены, нестандартная логистика, миграция данных и объём контента.
Я обычно делю запуск на этапы:
1. MVP: каталог, карточки, корзина, базовые оплата и доставка, приём заказов.
2. Операционный слой: CRM, учёт, статусы, кабинет и уведомления.
3. Рост: персонализация, рекомендации, программы лояльности, новые каналы продаж.
Так бизнес быстрее получает работающую точку продаж, а команда не пытается одновременно решить все задачи.
Если у проекта сложный каталог, есть 1С/CRM, оптовые цены или перенос со старого сайта, ТЗ лучше готовить вместе с командой разработки. Это позволяет оценить риски интеграций до того, как они станут дорогой доработкой.
Обсудить разработку интернет-магазина
Google Search Central: архитектура и навигация интернет-магазина
Google Search Central: Product и merchant listing structured data