Когда заказчик приходит с запросом «сделайте нам маркетплейс», первый вопрос разработчика — «а ТЗ есть?». И здесь начинается самое интересное: у 7 из 10 клиентов либо нет ничего, либо есть пара слайдов из презентации. Хорошее ТЗ на маркетплейс — это не бюрократия, а рабочий инструмент, который фиксирует ожидания обеих сторон, защищает бюджет и делает оценку проекта точной. В этой статье — практическая структура документа, которую мы используем в реальных проектах.
Зачем вообще нужно ТЗ: деньги и время
Разработка без ТЗ — это строительство дома без проекта. Подрядчик угадывает, заказчик переделывает, бюджет растёт. По нашей практике, проекты с детальным техническим заданием укладываются в смету в 80% случаев. Без ТЗ этот показатель падает до 35%.
Конкретные риски при отсутствии документа:
- Разногласия на этапе приёмки: «мы имели в виду другое».
- Scope creep — бесконечное расширение функционала без доплаты.
- Невозможность сменить подрядчика: новая команда не понимает, что уже сделано и зачем.
- Проблемы с инвесторами: без ТЗ нельзя обосновать бюджет.
Что входит в ТЗ на маркетплейс: обязательные разделы
Документ должен отвечать на три вопроса: что строим, для кого и как это должно работать. Вот минимальная структура.
1. Общее описание проекта
Пишите честно и коротко: что за площадка, какую проблему решает, кто целевая аудитория. Укажите бизнес-модель: комиссионная, подписочная, freemium. Это задаёт контекст для всех технических решений.
Пример формулировки: «Маркетплейс услуг для частных мастеров и клиентов в нише ремонта. Монетизация — 8% комиссия с каждой сделки. Запуск MVP — Москва и МО, затем масштабирование на регионы».
2. Роли и права доступа
Маркетплейс — многоролевая система. Как минимум три роли:
- Покупатель / заказчик — регистрация, поиск, заказ, оплата, отзывы.
- Продавец / исполнитель — личный кабинет, управление товарами/услугами, вывод средств.
- Администратор — модерация, аналитика, управление пользователями и комиссиями.
Если планируете суперадминов, менеджеров поддержки или партнёрские аккаунты — прописывайте отдельно. Каждая роль = отдельный набор экранов и логики.
3. Функциональные требования
Это самый объёмный раздел. Удобно разбить по модулям:
| Модуль | Ключевые функции |
|---|---|
| Каталог | Категории, фильтры, поиск, карточка товара/услуги |
| Личный кабинет продавца | Управление листингами, статистика, верификация |
| Корзина и оформление заказа | Мультипродавец, промокоды, адрес доставки |
| Оплата | Эквайринг, холдирование, сплит-платежи, возвраты |
| Чат / мессенджер | Диалог покупатель–продавец, уведомления |
| Отзывы и рейтинги | Модерация, ответы продавца, агрегированный рейтинг |
| Административная панель | Дашборд, управление пользователями, настройка комиссий |
Для каждой функции укажите: кто инициирует действие, что происходит в системе, какой результат видит пользователь. Это называется user story: «Как продавец, я хочу загрузить до 20 фото товара, чтобы покупатель видел полную картину».
4. Нефункциональные требования
Их часто забывают — и потом удивляются, почему сайт падает при нагрузке. Укажите:
- Ожидаемое число пользователей на старте и через год.
- Требования к скорости загрузки (например, LCP не более 2,5 с).
- Доступность: 99,9% uptime или достаточно 99%?
- Требования к безопасности: 152-ФЗ, PCI DSS для платежей.
- Поддержка браузеров и устройств.
5. Интеграции
Перечислите все внешние сервисы, с которыми должна работать платформа. Типичный список для маркетплейса:
- Платёжный шлюз (ЮКасса, Тинькофф, Сбер).
- SMS / email-уведомления (СМSC, Unisender, SendPulse).
- Карты (Яндекс Карты, 2GIS) — если нужна геолокация.
- Доставка (СДЭК, Boxberry, Почта России) — для товарных маркетплейсов.
- Аналитика (Яндекс Метрика, Google Analytics, внутренний BI).
- Антифрод и верификация личности — если платформа работает с самозанятыми или ИП.
6. UX/UI-требования и дизайн-система
Если у вас уже есть брендбук — приложите. Если нет — опишите референсы: «хотим как Авито, но строже» или «минималистично, в духе Notion». Укажите, нужна ли адаптивная вёрстка, мобильное приложение (iOS/Android) или PWA.
7. Этапы и MVP
Опишите, что входит в первую рабочую версию, а что откладывается на следующие итерации. MVP маркетплейса — это минимум, при котором можно провести первую реальную сделку. Всё остальное — фаза 2.
Типичные ошибки при составлении ТЗ на маркетплейс
За годы работы мы видели одни и те же грабли. Вот список, чтобы вы на них не наступили:
- «Как у Wildberries, но лучше» — без конкретики это не требование, а пожелание. Wildberries — 15 лет разработки и тысячи инженеров.
- Отсутствие приоритетов — когда всё «обязательно», разработчик не понимает, что делать первым.
- Игнорирование платёжной логики — сплит-платежи, холдирование, возвраты и комиссии — это сложная механика. Её нужно описывать отдельно и детально.
- Нет сценариев ошибок — что происходит, если оплата не прошла? Если продавец не подтвердил заказ? Если товар закончился?
- ТЗ пишет только заказчик — хороший подрядчик должен участвовать в формировании документа или хотя бы его рецензировать.
Кто должен писать ТЗ и сколько это стоит
Есть три варианта:
- Заказчик сам — подходит, если в команде есть продакт или технический директор. Риск: пропустить важные технические детали.
- Подрядчик по разработке — наиболее распространённый сценарий. Стоимость аналитики и составления ТЗ на маркетплейс — от 80 000 до 300 000 ₽ в зависимости от сложности. Эти деньги окупаются: точная смета экономит куда больше.
- Независимый бизнес-аналитик — хороший вариант, если хотите объективный взгляд перед тендером.
Если вы выбираете подрядчика на разработку маркетплейса под ключ, уточните сразу: входит ли составление ТЗ в стоимость или это отдельный этап. Лучшие команды всегда начинают с аналитики.
Чек-лист: ТЗ готово к передаче разработчику
Перед тем как отправить документ в работу, пройдитесь по этому списку:
- ☑ Описана бизнес-модель и монетизация.
- ☑ Все роли пользователей перечислены с правами доступа.
- ☑ Функции разбиты по модулям, каждая описана в формате user story.
- ☑ Указаны нефункциональные требования (нагрузка, безопасность, доступность).
- ☑ Список интеграций полный, с указанием конкретных сервисов.
- ☑ Описаны сценарии ошибок для критичных операций.
- ☑ Определён состав MVP и приоритеты фаз.
- ☑ Приложены референсы или брендбук.
- ☑ Документ согласован с техническим руководителем проекта.
Итог
Хорошее ТЗ на маркетплейс — это не фолиант на 200 страниц и не формальность для договора. Это живой документ, который даёт команде общий язык и снимает 80% спорных вопросов ещё до написания первой строки кода. Потратьте на него время в начале — сэкономите деньги и нервы в середине проекта.
Если вам нужна помощь с аналитикой или полноценная разработка маркетплейса под ключ — команда Aris.Web готова обсудить ваш проект. Позвоните по номеру +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty — разберём задачу и предложим оптимальный формат сотрудничества.