Коротко: грамотное ТЗ на маркетплейс сокращает количество правок на 40–60%, фиксирует бюджет и сроки, а также защищает заказчика при спорах с подрядчиком. Минимальный объём рабочего ТЗ — 25–40 страниц; для платформ с нестандартной логикой — от 60. Ниже — структура, которую мы используем в реальных проектах.
Зачем нужно ТЗ и что будет без него
Без технического задания разработка маркетплейса превращается в бесконечные «а я думал, это само собой разумеется». Продавец ожидает автоматические выплаты, покупатель — сохранённые адреса, администратор — гибкие комиссии. Каждый из них прав, но разработчик узнаёт об этом на третьем месяце работы.
Типичные последствия отсутствия ТЗ: переработка 30–50% уже написанного кода, рост бюджета в 1,5–2 раза, сдвиг сроков на 2–4 месяца. ТЗ — это не бюрократия, а страховка для обеих сторон.
Кто пишет ТЗ на маркетплейс
Есть три рабочих варианта:
- Заказчик самостоятельно — подходит, если в команде есть продуктовый менеджер или CTO. Риск: упустить технические детали.
- Подрядчик по итогам аналитики — наиболее надёжный путь. Хорошая команда по разработке маркетплейса под ключ проводит предпроектное исследование и сама формирует ТЗ, которое затем согласовывается с клиентом.
- Совместно — заказчик описывает бизнес-логику, разработчик переводит её в технические требования.
Оптимально: заказчик готовит бизнес-бриф (5–10 страниц), подрядчик разворачивает его в полноценное ТЗ.
Структура ТЗ на маркетплейс: 8 обязательных разделов
1. Общее описание проекта
Пишите так, чтобы разработчик понял суть без звонка. Укажите: тип маркетплейса (товары, услуги, аренда), целевую аудиторию, географию, планируемую нагрузку на старте и через год, монетизацию (комиссия, подписка, реклама).
2. Роли пользователей и их права
Маркетплейс всегда многоролевой. Минимальный набор ролей:
- Покупатель
- Продавец / поставщик
- Администратор платформы
- Модератор
Для каждой роли опишите: что видит, что может сделать, какие данные вводит. Если есть суб-роли (например, менеджер магазина продавца) — фиксируйте отдельно.
3. Функциональные требования
Это сердце ТЗ. Разбивайте по модулям:
- Каталог и поиск: фильтры, сортировка, полнотекстовый поиск, SEO-страницы категорий
- Карточка товара / услуги: атрибуты, фото, видео, варианты (размер, цвет), остатки
- Корзина и оформление заказа: адреса, промокоды, выбор доставки
- Оплата: эквайринг, сплит-платежи продавцам, возвраты
- Личный кабинет покупателя: история заказов, избранное, уведомления
- Кабинет продавца: управление товарами, аналитика продаж, вывод средств
- Административная панель: модерация, комиссии, баннеры, пользователи
- Отзывы и рейтинги
- Уведомления: email, SMS, push
Каждый пункт — это не слово, а описание поведения системы. Пример плохого требования: «должен быть поиск». Пример хорошего: «Поиск работает по названию, описанию и артикулу товара; результаты появляются при вводе от 3 символов; поддерживает опечатки (fuzzy search)».
4. Нефункциональные требования
Здесь фиксируют то, что влияет на архитектуру, но не видно пользователю:
- Производительность: время отклика страницы до 1,5 с при нагрузке X RPS
- Масштабируемость: горизонтальное масштабирование, микросервисы или монолит
- Безопасность: 152-ФЗ, PCI DSS при приёме карт, двухфакторная аутентификация
- Доступность: SLA 99,9%, план восстановления при сбое
- Поддержка мобильных: адаптивный веб или отдельные приложения iOS/Android
5. Интеграции
Укажите все внешние системы. Типичный список для маркетплейса:
| Тип интеграции | Примеры сервисов | Приоритет |
|---|---|---|
| Платёжный шлюз | ЮKassa, Тинькофф, Robokassa | Обязательно |
| Доставка | СДЭК, Boxberry, Почта России | Обязательно |
| SMS / Email | SMSC, SendPulse, UniSender | Обязательно |
| Аналитика | Яндекс Метрика, Google Analytics | Желательно |
| ERP / 1С | 1С:Управление торговлей | По потребности |
| Маркировка | Честный знак | По категории товара |
6. UX-требования и прототипы
ТЗ без прототипов — это половина ТЗ. Даже грубые вайрфреймы в Figma или Miro сокращают разночтения в разы. Опишите ключевые пользовательские сценарии (user stories) в формате: «Как покупатель, я хочу сохранить товар в избранное, чтобы вернуться к нему позже».
7. Технический стек и ограничения
Если у вас уже есть предпочтения или ограничения (например, хостинг только в России, обязательный PHP, существующая база на PostgreSQL) — фиксируйте здесь. Если ограничений нет — дайте подрядчику выбрать стек под задачу, это его зона ответственности.
8. Этапы, сроки и критерии приёмки
Разбейте разработку на спринты или фазы (MVP → расширенная версия → масштабирование). Для каждого этапа: что входит, срок, критерии «готово». Критерий «готово» — это не «выглядит нормально», а конкретная проверяемая функция.
Типичные ошибки в ТЗ на маркетплейс
- «Как у Wildberries, только своё» — это не требование. Wildberries — 10 лет разработки и тысячи функций.
- Описание интерфейса вместо поведения системы.
- Отсутствие граничных случаев: что происходит, если продавец удалил товар, который уже в корзине?
- Игнорирование прав доступа — потом выясняется, что модератор видит финансовые данные.
- Нет описания уведомлений: кому, когда, по какому триггеру.
- Не прописана логика комиссий: фиксированная, процент, смешанная, НДС.
Часто задаваемые вопросы
Сколько стоит составить ТЗ на маркетплейс?
Предпроектная аналитика и написание ТЗ у профессиональных команд стоит от 80 000 до 300 000 рублей в зависимости от сложности платформы. Эта сумма, как правило, входит в стоимость разработки или частично зачитывается при заключении основного договора. Попытка сэкономить на ТЗ и начать разработку «по беседе» обходится в 2–3 раза дороже на этапе правок.
Можно ли использовать готовый шаблон ТЗ на маркетплейс?
Шаблон — хорошая отправная точка, но не финальный документ. Каждый маркетплейс имеет уникальную бизнес-модель: разные роли, комиссии, логику выплат, категории товаров. Готовый шаблон покрывает 40–50% содержания; остальное нужно дописывать под конкретный проект. Используйте шаблон как чек-лист разделов, а не как текст, который можно сдать разработчику без изменений.
Как понять, что ТЗ готово к передаче разработчикам?
Проверьте по трём критериям: (1) любой разработчик из команды может оценить трудозатраты по каждому пункту без уточняющих вопросов; (2) для каждой функции описан happy path и хотя бы один граничный случай; (3) все роли, права доступа и интеграции перечислены явно. Если после прочтения ТЗ у разработчика возникает больше 10 вопросов — документ требует доработки.
Следующий шаг: обсудить проект
Если вы готовите ТЗ самостоятельно или хотите, чтобы команда провела предпроектную аналитику и собрала документ за вас — свяжитесь с Aris.Web. Мы специализируемся на разработке маркетплейса под ключ: от аналитики и ТЗ до запуска и поддержки. Расскажите о проекте на странице arisweb.ru/kontakty или позвоните по номеру +7 (977) 326-69-09 — разберём вашу задачу и оценим сроки на первом звонке.