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