Техническое задание на маркетплейс — это не формальность и не «бумажка для договора». Это единственный документ, который синхронизирует ожидания заказчика и команды разработки. Без него проект либо выходит за бюджет в 2–3 раза, либо превращается в бесконечный спор о том, что именно имелось в виду. В этой статье разберём готовый пример структуры ТЗ с комментариями по каждому разделу — так, чтобы вы могли адаптировать его под свой проект прямо сейчас.
Зачем маркетплейсу отдельное ТЗ, а не стандартный бриф
Маркетплейс — это не интернет-магазин с расширенным функционалом. Здесь одновременно работают три типа пользователей: покупатель, продавец и администратор. У каждого своя логика, свои права, свои сценарии. Добавьте сюда финансовые потоки, комиссионные модели, систему рейтингов и модерацию — и вы получите продукт, где любая недосказанность в ТЗ обходится в десятки часов переработок.
Стандартный бриф фиксирует «что хочу». ТЗ фиксирует «как именно это должно работать». Разница принципиальная: первое — это пожелание, второе — техническое обязательство.
Структура технического задания на маркетплейс: пример по разделам
Ниже — проверенная структура, которую мы используем в работе. Каждый раздел снабжён комментарием о том, что туда писать и чего избегать.
1. Общее описание проекта
Здесь — не маркетинговый текст, а сухая суть: что за платформа, какую проблему решает, кто целевая аудитория, какая бизнес-модель (комиссия с продаж, подписка для продавцов, freemium и т.д.). Укажите географию и языки интерфейса. Пример формулировки: «B2C-маркетплейс товаров для ремонта, Россия, русский язык, монетизация — комиссия 8% с каждой сделки».
2. Роли и права пользователей
Это один из самых важных разделов. Опишите каждую роль отдельно и перечислите, что она может делать. Типичный набор для маркетплейса:
- Покупатель — регистрация, поиск, корзина, оформление заказа, оплата, отзывы, возвраты.
- Продавец — личный кабинет, управление каталогом, обработка заказов, аналитика продаж, вывод средств.
- Администратор — модерация товаров и продавцов, управление комиссиями, работа с жалобами, финансовые отчёты.
- Менеджер поддержки (если нужен) — доступ к тикетам, история переписки, без доступа к финансам.
Не пишите «администратор управляет всем» — это гарантия конфликтов при разработке. Расписывайте конкретные действия.
3. Функциональные требования
Самый объёмный раздел. Структурируйте по модулям:
- Каталог товаров: фильтры, поиск (полнотекстовый или по атрибутам), карточка товара, вариации (размер, цвет).
- Корзина и оформление заказа: мультипродавцовая корзина, расчёт доставки, промокоды.
- Платёжный модуль: какие шлюзы (ЮKassa, Тинькофф, СБП), split-платежи между продавцами.
- Личный кабинет продавца: загрузка товаров (вручную и через Excel/XML), статистика, баланс и вывод средств.
- Система отзывов и рейтингов: модерация, ответ продавца, влияние на позицию в выдаче.
- Уведомления: email, push, SMS — для каких событий и по каким триггерам.
Для каждого модуля укажите приоритет: MVP (нужно на старте) или Phase 2 (можно добавить позже). Это напрямую влияет на смету.
4. Нефункциональные требования
Раздел, который часто пропускают — и потом жалеют. Здесь фиксируют:
| Параметр | Пример значения |
|---|---|
| Нагрузка | до 5 000 одновременных пользователей |
| Время отклика страницы | не более 1,5 сек при нагрузке |
| Доступность (uptime) | 99,5% в месяц |
| Совместимость браузеров | Chrome, Safari, Firefox — последние 2 версии |
| Мобильная версия | адаптив или отдельное приложение |
| Хранение данных | серверы в РФ, соответствие 152-ФЗ |
5. Интеграции
Перечислите все внешние системы: платёжные шлюзы, службы доставки (СДЭК, Почта России, DHL), CRM, 1С, системы аналитики (Яндекс.Метрика, BI), сервисы верификации (ЕСИА, SMS-коды). Для каждой интеграции укажите: есть ли готовое API, кто предоставляет документацию, нужен ли тестовый стенд.
6. Дизайн и UX-требования
Если у вас есть брендбук — приложите. Если нет — опишите референсы (ссылки на платформы, которые нравятся визуально или функционально). Укажите количество уникальных экранов, которые нужно разработать с нуля, и какие можно взять из UI-кита. Это сильно влияет на сроки дизайна.
7. Технический стек и инфраструктура
Если у вас уже есть предпочтения по технологиям — зафиксируйте. Если нет — оставьте этот раздел на усмотрение подрядчика, но укажите ограничения: например, «только open-source решения» или «деплой в Яндекс.Облако». Также опишите требования к документации кода и передаче исходников.
Типичные ошибки в ТЗ, которые дорого обходятся
- «Как у Wildberries, только проще» — это не требование. Wildberries — это 10 лет разработки и тысячи функций. Опишите конкретно, какие именно функции нужны.
- Отсутствие приоритетов — когда всё помечено как «обязательное», команда не может оптимизировать смету под бюджет.
- Игнорирование сценариев ошибок — что происходит, если платёж не прошёл? Если продавец не подтвердил заказ за 48 часов? Эти сценарии нужно описать явно.
- Размытые формулировки — «удобный интерфейс», «быстрая загрузка», «гибкая система» не несут смысла. Замените на измеримые критерии.
- ТЗ без макетов — текстовое описание интерфейса без wireframe-схем приводит к тому, что разработчик и заказчик представляют разные вещи.
Как объём ТЗ влияет на бюджет и сроки
Хорошо проработанное ТЗ сокращает итоговую стоимость разработки на 20–35%. Причина простая: команда тратит меньше времени на уточнения, переделки и согласования. Маркетплейс с MVP-функционалом (каталог, корзина, один платёжный шлюз, личные кабинеты покупателя и продавца) при наличии детального ТЗ разрабатывается за 3–5 месяцев. Без ТЗ тот же проект растягивается на 6–9 месяцев и выходит за бюджет.
Если вы хотите получить точную оценку своего проекта, обратитесь за разработкой маркетплейса под ключ — на этапе пресейла мы помогаем структурировать требования и формируем предварительную смету без обязательств.
Часто задаваемые вопросы
Кто должен писать техническое задание — заказчик или подрядчик?
На практике ТЗ пишет подрядчик на основе интервью с заказчиком. Заказчик знает бизнес-логику и цели, разработчик знает, как это технически реализовать. Попытка написать ТЗ самостоятельно без технической экспертизы часто приводит к документу, который невозможно использовать как основу для оценки. Оптимальный формат — совместные рабочие сессии с аналитиком подрядчика, итоговый документ согласовывается и подписывается обеими сторонами.
Сколько страниц должно быть в ТЗ на маркетплейс?
Для MVP-маркетплейса — от 40 до 80 страниц с учётом wireframe-схем и описания API-интеграций. Полнофункциональная платформа с мобильным приложением, развитой аналитикой и несколькими типами продавцов — от 120 страниц. Объём сам по себе не является критерием качества: документ на 30 страниц с чёткими сценариями лучше, чем 100 страниц размытых описаний.
Можно ли начать разработку маркетплейса без готового ТЗ?
Можно, если вы используете гибкую методологию (Agile/Scrum) и готовы к итеративному уточнению требований. В этом случае вместо полного ТЗ достаточно детального описания первого спринта и высокоуровневого roadmap. Однако для фиксированного бюджета и сроков (Fixed Price контракт) полное ТЗ обязательно — иначе любые изменения в процессе будут оформляться как дополнительные работы и увеличат итоговую стоимость.
С чего начать прямо сейчас
Возьмите структуру из этой статьи и заполните хотя бы разделы 1–3: описание проекта, роли пользователей и ключевые функциональные модули. Этого достаточно для первичной оценки трудоёмкости и предметного разговора с командой разработки. Если хотите получить профессиональную помощь в составлении ТЗ и оценку стоимости проекта — мы занимаемся разработкой маркетплейса под ключ и готовы обсудить ваш проект без обязательств. Свяжитесь с нами по телефону +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty — ответим в течение рабочего дня.