Как составить техническое задание на разработку интернет-магазина

Почему без внятного ТЗ интернет-магазин превращается в долгострой

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

Бриф на одну страницу отвечает на вопрос «что нужно в общих чертах»: название проекта, тематика, пример конкурентов, примерный бюджет. Полноценное техническое задание на разработку фиксирует другое:

• какие разделы и страницы будут в магазине;
• как устроен каталог, категории и карточки товаров;
• какие способы оплаты и доставки поддерживаются;
• как работает корзина и оформление заказа;
• какие интеграции с учётными системами, CRM, службами доставки нужны;
• какие требования к скорости, безопасности, адаптивности, SEO-заготовке;
• как именно отображается функционал на разных устройствах и в разных браузерах.

Без этого интернет-магазин легко превращается в бесконечный долгострой. Типичные сценарии:

• «Сделайте как у конкурента Х». У конкурента десять лет развития, тьма скрытых сценариев и интеграций. Каждый участник проекта видит эту фразу по‑своему. В итоге разработчик пишет код исходя из своего опыта, заказчик сравнивает с ожиданиями, которых нигде нет в текстовом виде. Получаются постоянные переделки и вечная фраза «я думал, что тут будет по‑другому».
• «Давайте начнём, а по ходу разберёмся». Процесс разработки превращается в бесконечный поток задач «ещё чуть‑чуть доделаем». Сроки размываются, бюджет растёт, команда постоянно переключается между заданиями. Время выполнения каждой доработки измеряется не минутами, а неделями согласований, потому что нет общей рамки, к которой можно вернуться.
• «Мы думали, что это входит». В ТЗ нет ни слова про интеграцию с 1С или маркетплейсами, сложный расчёт скидок или оптовые цены. На этапе запуска выясняется, что без этого магазин не решает задачу бизнеса. Студия считает это новым объёмом, заказчик — обязательной частью проекта. Конфликт, дополнительные сметы, срыв планов по запуску маркетинга.

Грамотно составленное техническое задание разработку интернет-магазина закрывает эти риски за счёт конкретики. Оно:

• фиксирует объём работ: список страниц, блоков, интеграций и ограничений;
• показывает, как понимать «готовый» результат и что именно принимаю как заказчик;
• задаёт критерии качества: скорость загрузки, доступность, стабильность работы;
• даёт базу для оценки стоимости и сроков разными студиями по одной и той же структуре;
• помогает команде маркетинга заранее планировать контент, акции и промо‑механики.

Простой пример. Два проекта одинакового масштаба, 3–4 тысячи SKU, несколько вариантов оплаты и доставки, интеграция с 1С.

• Вариант без ТЗ. Сначала делают главную, потом «как‑то» каталог, затем вспоминают про оптовиков, потом — про интеграцию. Запуск сдвигается на 3–4 месяца, количество правок переваливает за сотню, бюджет вырастает на 40–60%.
• Вариант с чётким ТЗ. На старте есть прототипы страниц, описанные сценарии пользователей, список интеграций и критерии приёмки. Этапы идут по плану: прототипы → дизайн → разработка → тесты. Исправления есть, но они точечные. Запуск — в пределах исходного графика, отклонение по стоимости не критично и заранее согласовано.

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

Подготовка к ТЗ: какие вводные нужны от заказчика

Хорошее техническое задание на создание интернет-магазина начинается не с фразы «нужно сделать красивый сайт», а с понимания бизнес‑модели. Прежде чем садиться за текст, стоит ответить на несколько групп вопросов.

Во‑первых, базовые вводные о бизнесе и ассортименте:

• Что продаёте: физические товары, цифровые продукты, услуги с оплатой через корзину или всё сразу?
• Кому продаёте: частным клиентам (B2C), оптовикам и дилерам (B2B), смешанной аудитории?
• Сколько SKU планируется в каталоге: десятки, сотни, тысячи, десятки тысяч? От этого зависит выбор CMS, варианты хостинга и требования к производительности.
• Есть ли вариации: цвет, размер, комплекты, версии продукта, подписки на разные сроки?
• Какой средний чек и частота повторных покупок: раз в год или раз в неделю?

Во‑вторых, текущие процессы и системы:

• Как сейчас оформляется покупка: через звонок, мессенджеры, форму на сайте, маркетплейсы?
• Где ведёте учёт: 1С, МойСклад, Excel, своя CRM, вообще ничего системного?
• Какие каналы уже дают продажи: реклама в сетях, контекст, SEO, блог, офлайн‑точки?
• Кто занимается контентом: есть ли человек, который будет заполнять карточки товаров, публиковать новости и статьи?

В‑третьих, важно описать процессы работы с заказами:

• Как заказ проходит путь от оформления до доставки: какие статусы, какие документы, кто отвечает на каждом этапе?
• Как устроены скидки и акции: промокоды, накопительные программы, специальные цены для конкретных категорий клиентов?
• Какая политика возвратов и гарантий: сроки, условия, варианты обмена, нужен ли личный кабинет для отслеживания обращения?

На этом же этапе полезно определить ключевые пользовательские сценарии. Не просто «пользователь зашёл на сайт», а конкретные ситуации:

• «Быстрый заказ по артикулу»: клиент знает код товара из каталога или офлайн‑магазина и хочет найти его за пару секунд.
• «Подбор по фильтрам для сложного товара»: например, сантехника или автозапчасти. Пользователю нужно шаг за шагом уточнять параметры, а система — подсказывать подходящие варианты.
• «Оптовый клиент с заказом на 100+ позиций»: нужен быстрый импорт заказа из файла, сохранение черновиков, особые условия оплаты и доставки.

Мини‑чек‑лист, что собрать перед составлением ТЗ:

1. Краткое текстовое описание проекта: чем занимаетесь, чем новый магазин лучше текущих решений.
2. Список основных категорий товаров и пример 5–10 типичных карточек товаров с описаниями, фото, характеристиками.
3. Информация о текущих системах: CRM, учёт, склад, телефония, маркетплейсы, какие интеграции уже есть.
4. Процесс обработки заказа по шагам — лучше в виде списка статусов: «новый → подтверждён → оплачен → собран → отгружен → доставлен» и так далее.
5. Требования к доставке и оплате: с какими службами и платёжными системами точно будете работать.
6. Основные портреты целевой аудитории: кто ваши клиенты, что для них важно, как они принимают решение о покупке.

Если всё это собрано, составить техническое задание становится в разы удобнее. Вы опираетесь не на абстракции, а на конкретные данные: количество товаров, процессы, роли сотрудников, реальные ожидания клиентов.

Структура грамотного ТЗ на создание интернет-магазина

Ниже — каркас документа, по которому можно составить своё техническое задание на создание интернет-магазина или проверить проектное ТЗ подрядчика. Он не привязан к конкретной CMS и подходит и для готовых технологий, и для разработки интернет‑проекта на кастомном стеке.

1. Общие сведения

В этом разделе вы коротко описываете суть проекта и цели:

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

Полезно сразу указать ограничения: бюджетный диапазон, примерные сроки, особенности условий работы (например, «запуск обязателен до сезона»).

2. Целевая аудитория и сценарии

Опишите, кто будет пользоваться магазином и как:

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

3. Каталог и структура товаров

Каталог — сердце интернет-магазина. В ТЗ стоит подробно описать:

• иерархию категорий и подкатегорий, уровень вложенности, правила, по которым товар попадает в несколько разделов;
• характеристики для фильтров: бренд, материал, размеры, диапазон цены, наличие на складе, цвет и любые специфические параметры;
• правила отображения наличия: «в наличии», «под заказ», «ожидайте поставку», «нет в наличии, показать аналоги»;
• как будут выглядеть вариативные товары: единая карточка с выбором опций или отдельные товары для каждой модификации;
• поиск: где расположен, по каким полям ищет (название, артикул, описание, категории), нужны ли синонимы и подсказки.

4. Карточка товара

В разделе про карточки товаров опишите структуру страницы и необходимые блоки:

• минимальный набор: название, галерея фото, цена, наличие, кнопка «в корзину», краткое и полное описание, характеристики, отзывы;
• связанный функционал: «похожие товары», «с этим покупают», «вы недавно смотрели»;
• специфические элементы: калькуляторы (например, расход материала), конфигураторы, выбор комплектации, ссылки на документацию и сертификаты.

Здесь же стоит указать требования к качеству контента: какое количество фото, минимальное разрешение, нужен ли 3D‑просмотр, видеообзоры, скачиваемые файлы.

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

Корзина и форма оформления заказа сильно влияют на конверсию. В ТЗ важно описать:

• модель: одностраничное оформление (one‑page checkout) или многошаговый процесс;
• какие действия доступны в корзине: изменить количество, удалить товар, отложить, применить промокод, выбрать вариант доставки и оплаты;
• нужна ли «корзина‑мини» в шапке сайта и как она работает;
• какие поля формы обязательны, а какие опциональны, нужна ли проверка по маскам и подсказки;
• поддерживается ли заказ без регистрации и что при этом сохраняется для повторной покупки.

Хорошая практика — прописать сценарий: пользователь добавляет товар, за 3–4 шага доходит до подтверждения, видит финальную стоимость с учётом доставки и скидок, получает понятное сообщение об успешном оформлении.

6. Оплата, доставка, возвраты

Раздел с описанием оплаты и доставки обычно даёт много конкретных задач разработчику:

• какие платёжные системы используются: ЮKassa, CloudPayments, PayPal, банковские карты, рассрочка, СБП;
• какие службы доставки планируются: СДЭК, Boxberry, Почта России, курьер, самовывоз, интеграции с их калькуляторами стоимости;
• логика расчёта: ручной тариф или автоматический расчёт по API с учётом веса, габаритов, региона;
• как и где пользователь знакомится с политикой доставки и возвратов: отдельная страница, блок на странице оформления, чекбокс согласия;
• варианты возвратов: через личный кабинет, по телефону, через форму на сайте.

7. Интеграции: учёт, CRM, маркетплейсы

Если у вас есть внешние системы, техническое задание разработку должно подробно описывать интеграцию:

• какая учётная система используется: 1С (конкретная конфигурация), МойСклад, другое ПО;
• что именно синхронизируется: цены, остатки, заказы, статусы, клиенты, скидки, промокоды;
• как часто происходит обмен данными: онлайн, раз в 5 минут, раз в час, по расписанию ночью;
• нужна ли выгрузка каталога в маркетплейсы и прайс‑агрегаторы, в каком формате (YML, API), какие поля обязательны.

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

8. Админ‑панель и управление контентом

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

• какие сущности можно редактировать в админке: товары, категории, страницы блога, баннеры, акции, отзывы;
• нужен ли массовый импорт и экспорт товаров, в каких форматах, с какими полями;
• как менеджеры будут работать с заказами: смена статусов, добавление комментариев, просмотр истории клиента;
• уровни доступа: администратор, контент‑менеджер, оператор, маркетолог, их права;
• возможность настраивать без разработчика базовые вещи: тексты писем, формы, статические страницы с информацией о компании, доставке и оплате.

9. Требования к дизайну и UX

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

• бренд‑гайд: логотип, фирменные цвета, шрифты, типографика, примеры уже существующего дизайна;
• общие принципы: лаконичность, упор на фото товара, минимум отвлекающих элементов, акцентные блоки для спецпредложений;
• адаптивность: как должны вести себя ключевые блоки (меню, корзина, фильтры, карточки товаров) на мобильных устройствах;
• особые требования: например, обязательно сравнение товаров, фиксированная панель с кнопкой «Купить» при скролле, кастомные анимации.

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

10. Технические требования

Здесь фиксируются параметры, которые напрямую влияют на стабильность и масштабируемость проекта:

• предпочтения по стеку: готовая CMS (например, Bitrix, Shopify, OpenCart) или кастомная разработка на фреймворке;
• требования к скорости: время загрузки страниц, объём кода на странице, оптимизация картинок, работа кэша;
• SEO‑основа: ЧПУ‑адреса, метатеги, микроразметка, карта сайта, robots.txt, редиректы;
• безопасность: обязательный HTTPS, защита данных пользователей, политика паролей, защита от ботов и основных атак;
• совместимость с браузерами и устройствами: список версий, которые нужно официально поддерживать.

11. Сроки, этапы и приёмка

Финальный блок, который определяет, как вы будете оценивать выполнение работ и стоимость изменений:

• этапы: аналитика, прототипы, дизайн, вёрстка, разработка, интеграции, тестирование, запуск;
• формат приёмки: по чек‑листам, по сценариям пользователей, по конкретным разделам ТЗ;
• что считается завершённым функционалом: не просто «сделана корзина», а «корзина реализована в соответствии с пунктами 5.1–5.5 ТЗ, проверена на тестовых данных, принята заказчиком без критичных замечаний».

Такой каркас легко адаптировать под любой проект: меняется CMS, меняются детали, но структура остаётся. За счёт неё проще контролировать и сам процесс, и качество результата.

Как описывать требования понятным языком: примеры формулировок

Фразы вроде «хочу современный продающий интернет-магазин», «нужна удобная корзина» и «сделайте быстрый поиск» в ТЗ бесполезны. Они описывают ожидания, но не дают разработчику чётких критериев.

Как не надо формулировать:

• «Сделать удобную корзину» — что считается удобством, непонятно;
• «Сделать красивую главную страницу» — для кого красивую, по каким примерам;
• «Сделать быстрый поиск» — сколько миллисекунд, по каким полям, с какими подсказками.

Как можно лучше:

• «Корзина должна сохранять добавленные товары между сессиями пользователя в течение 14 дней, позволять менять количество, удалять товары, применять промокод и пересчитывать итоговую стоимость без перезагрузки страницы».
• «Поиск расположен в шапке сайта, работает по названию, артикулу и ключевым словам из описаний. При вводе от трёх символов показывает выпадающий список из максимум 10 подсказок».
• «Главная страница содержит блоки: баннер с текущей акцией, подборка популярных категорий, блок новинки, блок хиты продаж, блок отзывов клиентов и ссылку на блог с полезными материалами».

Если хотите ориентироваться на чужой сайт, используйте приём «пример + уточнение»:

• вместо «сделайте как у сайта Х» — «Страница категории по структуре похожа на сайт Х: фильтры слева, сетка товаров 3 в ряд на десктопе, 2 в ряд на планшете, один товар в ряд на мобильном. Без онлайн‑чата, с нашим брендингом и собственным набором фильтров»;
• вместо «нам нужна похожая корзина» — «В корзине, как на сайте Х, отображается список товаров с фото, названием, ценой, количеством. Отличие: нам не нужна рекомендация доптоваров, вместо неё — блок с итоговой суммой по заказу и расчётом доставки».

Где слова заканчиваются, лучше подключить прототипы. Если структура сложная (например, конфигуратор или многоуровневая форма), сделайте простые прототипы страниц: расположение блоков, форма, шаги процесса, список полей. Даже чёрно‑белые макеты с подписью элементов часто понятнее длинного текстового описания.

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

Типичные ошибки в ТЗ и чем они оборачиваются

Ошибки в ТЗ редко видны в первые недели. Они проявляются ближе к запуску, когда изменения становятся дорогими. Вот наиболее частые проблемы.

• Нет раздела про интеграции. Про 1С, CRM или маркетплейсы вспоминают в последний момент. Оказывается, что выбранная CMS не тянет нужный обмен или требует существенной доработки. Стоимость проекта растёт, сроки уезжают.
• Игнорируется мобильная версия. В ТЗ нет ни слова про то, как будут выглядеть категории, карточки товаров и корзина на мобильных устройствах. Потом аналитика показывает, что 60–70% трафика — с телефонов, а конверсия там в разы ниже. Приходится отдельно переделывать вёрстку и логику.
• Не прописаны роли пользователей. В результате оптовые и розничные клиенты видят один и тот же интерфейс, нет отдельных цен и условий. Через полгода появляется задание разработку «сделать кабинет оптовика», но под это не заложены ни архитектура, ни бюджет.
• Отсутствуют критерии приёмки. Каждый спор по доработкам сводится к фразам «мы так понимали» и «мы думали, что это входит». Проект эмоционально выматывает обе стороны.

Краткие кейсы:

• «Забыли про оптовиков». Магазин запустили только под розницу. Через пару месяцев подключили крупного партнёра, понадобились особые прайс‑листы, закрытый раздел, быстрое оформление заказов на сотни позиций. Пришлось фактически перепроектировать личный кабинет и ценовую логику.
• «Не описали статусы заказа». В ТЗ есть только «новый» и «завершён». В реальности процесс сложнее: согласование наличия, предоплата, сборка, отгрузка, доставка. Без статусов менеджеры ведут всё в Excel и по телефону, клиенты не понимают, где их заказ, растёт нагрузка на поддержку.

Как понять, что черновик ТЗ опасно сырой:

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

В таком случае лучше потратить время на доработку ТЗ до конкретики, чем пытаться «разруливать по ходу». Каждая недосказанность в документе превращается в спор и дополнительные часы разработки.

Чем ТЗ на интернет-магазин отличается от ТЗ на обычный сайт

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

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

• корзина с логикой пересчёта цен и скидок;
• оформление заказа, интеграция с платёжными системами;
• личный кабинет покупателя: история заказов, повторные покупки, данные профиля, настройки рассылок;
• связка с учётными системами и складом;
• сложные сценарии отображения каталога и карточек товаров.

Готовые шаблоны часто не задают вопросов про:

• количество SKU и особенности ассортимента;
• роли пользователей: гость, зарегистрированный клиент, оптовый покупатель, менеджер;
• логику ценообразования, акции, промокоды, накопительные скидки;
• процессы «после продажи»: повторные покупки, рекомендации, e‑mail‑маркетинг.

Когда базовый шаблон всё‑таки можно взять за основу? Например, если вы планируете небольшой магазин из нескольких десятков товаров без сложных интеграций. В таком случае шаблон поможет быстро составить общий список страниц, а затем вы дополните его разделами про каталог, корзину, оплату, доставку и интеграции.

Главное — не ограничиваться общими пунктами. Даже для маленького магазина стоит отдельно описать функционал корзины, способы оплаты и доставки, требования к CMS и админ‑панели. Тогда переход от простого сайта к полноценной системе продаж пройдёт значительно мягче.

Как согласовывать и обновлять ТЗ, чтобы не утонуть в правках

ТЗ — не высеченный в камне документ, а рабочий инструмент. Но чтобы изменения не разрушили сроки и бюджет, нужно договориться о формате работы с ним.

Варианты представления ТЗ:

• текстовый документ + таблицы: основной текст и отдельные таблицы с перечнем страниц, полей форм, интеграций;
• ТЗ + прототипы в Figma или аналогах: текст описывает требования, прототипы показывают структуру и блоки;
• набор пользовательских историй («как пользователь, я хочу…») с техническими комментариями от студии.

Процесс согласования обычно выглядит так:

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

Что делать, если по ходу проекта появляются новые идеи? Любой живой проект так или иначе растёт. Чтобы это не превратилось в хаос, используется подход change request:

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

Мини‑чек‑лист, что обязательно должно быть не «на словах», а в документах:

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

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

Когда стоит поручить подготовку ТЗ студии и как это влияет на проект

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

Есть ситуации, когда разумнее сразу поручить подготовку ТЗ профессиональной команде:

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

Как обычно выглядит проект, если студия берёт на себя подготовку ТЗ:

1. Интервью с заказчиком: погружаемся в бизнес‑модель, целевую аудиторию, процессы, анализируем текущие каналы продаж.
2. Совместная проработка сценариев: описываем путь пользователя от первого касания до покупки и повторного заказа, обсуждаем маркетинг и точки контакта.
3. Прототипы ключевых страниц: главная, каталог, карточки товаров, корзина, оформление заказа, личный кабинет.
4. Детализированное ТЗ: текст + схемы + прототипы, понятные и бизнесу, и разработчикам.

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

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