Техническое задание на маркетплейс и его согласование — это не формальность перед стартом разработки, а главный инструмент защиты бюджета. По нашей практике, около 60% споров между заказчиком и подрядчиком возникают именно из-за того, что ТЗ было принято «на словах» или написано слишком размыто. В этой статье разберём, где именно рвётся понимание, как выстроить процесс согласования и что должно быть в документе, чтобы обе стороны говорили на одном языке.
Почему ТЗ на маркетплейс сложнее, чем на обычный сайт
Маркетплейс — многоролевая система: покупатель, продавец, администратор, служба поддержки, логистический оператор. Каждая роль имеет свой интерфейс, права доступа и бизнес-логику. Это означает, что одна размытая фраза в ТЗ — например, «продавец управляет своими товарами» — может скрывать за собой десятки экранов и сотни часов работы.
Типичные зоны неопределённости в ТЗ на маркетплейс:
- Модерация товаров: автоматическая или ручная, кто принимает решение, какие триггеры блокировки.
- Комиссионная модель: фиксированный процент, ступенчатая шкала, абонентская плата — каждый вариант требует отдельной логики расчётов.
- Логистика: маркетплейс только сводит стороны или участвует в доставке и возвратах.
- Финансовые расчёты: сроки выплат продавцам, холдирование средств, работа с налоговыми чеками.
- Рейтинги и отзывы: кто может оставлять, можно ли редактировать, как влияют на выдачу.
Если эти пункты не прописаны до старта, разработчик реализует «своё видение», а заказчик получит не то, что ожидал.
Три самых частых конфликта при согласовании ТЗ
Конфликт 1: «Это же очевидно»
Заказчик считает, что некоторые функции подразумеваются сами собой. Разработчик — что в объём входит только то, что явно написано. Результат: заказчик платит за доработки, которые, по его мнению, должны были быть изначально. Решение простое — в ТЗ нет места «очевидному». Каждый сценарий работы пользователя описывается явно, даже если он кажется банальным.
Конфликт 2: Изменения «на ходу»
В процессе разработки заказчик хочет добавить функцию или изменить логику. Без зафиксированного ТЗ разработчик либо отказывает, либо включает изменения без пересмотра бюджета — и накапливает скрытый долг, который выходит боком в конце проекта. Решение: ТЗ должно содержать раздел «Управление изменениями» — формальный процесс, как фиксируются правки, кто их согласует и как пересчитывается смета.
Конфликт 3: Разные трактовки одного термина
«Личный кабинет продавца», «витрина», «каталог» — в разных командах эти слова означают разное. Один разработчик под «витриной продавца» понимает страницу с логотипом и описанием, другой — полноценный мини-магазин с баннерами, акциями и отдельной аналитикой. Решение: глоссарий терминов в начале ТЗ. Это занимает полчаса, но экономит недели разногласий.
Структура ТЗ, которое реально работает
Хорошее техническое задание на маркетплейс — не академический документ на 200 страниц, а рабочий инструмент. Вот минимально достаточная структура:
- Цели и метрики успеха. Что считается результатом: количество продавцов, GMV, конверсия? Без этого невозможно расставить приоритеты.
- Роли и права доступа. Таблица: роль → список действий → ограничения.
- Пользовательские сценарии (User Stories). Формат: «Как [роль], я хочу [действие], чтобы [цель]». Минимум для MVP — 40–60 историй.
- Функциональные требования. Разбиты по модулям: каталог, корзина, оплата, личные кабинеты, уведомления, аналитика.
- Нефункциональные требования. Нагрузка (сколько одновременных пользователей), время отклика, браузеры и устройства, требования к безопасности.
- Интеграции. Платёжные шлюзы, службы доставки, CRM, 1С, SMS/email-сервисы — каждая интеграция описывается отдельно.
- Глоссарий. Определения всех специфических терминов проекта.
- Управление изменениями. Процедура внесения правок после подписания.
Процесс согласования: пошагово
Согласование ТЗ — итеративный процесс, а не одна встреча. Вот рабочая схема из пяти шагов:
| Шаг | Что происходит | Результат |
|---|---|---|
| 1. Брифинг | Заказчик описывает бизнес-модель, аудиторию, конкурентов | Бриф на 2–3 страницы |
| 2. Черновик ТЗ | Разработчик или аналитик формирует первую версию документа | ТЗ v0.1 |
| 3. Ревью заказчика | Заказчик проверяет каждый раздел, помечает вопросы и несоответствия | Список правок |
| 4. Совместная сессия | Онлайн или офлайн встреча: разбор спорных мест, уточнение приоритетов | Протокол разногласий |
| 5. Финальная версия | Правки внесены, документ подписан обеими сторонами | ТЗ v1.0 — юридически значимый документ |
Обычно цикл «черновик → правки → финал» проходит 2–3 итерации. Если итераций больше пяти — это сигнал, что на этапе брифинга не были выяснены ключевые бизнес-требования.
Чек-лист: ТЗ готово к подписанию?
Перед финальным согласованием проверьте каждый пункт:
- ☑ Все роли пользователей описаны и перечислены их права.
- ☑ Для каждого модуля есть пользовательские сценарии (happy path + edge cases).
- ☑ Интеграции со сторонними сервисами перечислены с указанием API или метода обмена данными.
- ☑ Прописана комиссионная модель и логика финансовых расчётов.
- ☑ Указаны нефункциональные требования: нагрузка, SLA, поддерживаемые устройства.
- ☑ Есть глоссарий терминов.
- ☑ Зафиксирован процесс управления изменениями.
- ☑ Документ подписан или согласован в трекере задач обеими сторонами.
Если хотя бы три пункта не отмечены — возвращайтесь к доработке. Подписывать неполное ТЗ дороже, чем потратить ещё неделю на уточнения.
Часто задаваемые вопросы
Кто должен писать ТЗ на маркетплейс — заказчик или разработчик?
На практике лучший результат даёт совместная работа: заказчик описывает бизнес-логику и цели, аналитик или технический менеджер со стороны разработчика переводит это в функциональные требования. Если заказчик пишет ТЗ самостоятельно без технической экспертизы, документ часто оказывается либо слишком абстрактным, либо, наоборот, содержит технические решения, которые ограничивают разработчика в выборе оптимального подхода.
Сколько времени занимает согласование технического задания на маркетплейс?
Для MVP-маркетплейса с базовым набором функций — от двух до четырёх недель. Для полноценной платформы с несколькими типами продавцов, сложной логистикой и интеграциями — от четырёх до восьми недель. Попытки сократить этот срок вдвое, как правило, приводят к тому, что недопонимание «переезжает» в разработку и обходится в 3–5 раз дороже.
Что делать, если после подписания ТЗ нужно изменить логику работы маркетплейса?
Изменения после подписания — нормальная ситуация, если она управляется через формальный процесс. Заказчик подаёт запрос на изменение (Change Request), разработчик оценивает трудозатраты и влияние на сроки, стороны согласуют новую редакцию ТЗ или дополнительное соглашение. Главное — не вносить изменения устно или в мессенджерах: только письменно, с оценкой и подписью.
Итог: согласованное ТЗ — это не бюрократия, а экономия
Потратить две-три недели на детальное техническое задание и его согласование — значит застраховать себя от переделок, которые в среднем обходятся в 20–40% сверх бюджета. Чёткий документ защищает и заказчика, и разработчика: первый получает именно то, что заказал, второй — понятный объём работ без бесплатных доработок.
Если вы планируете запуск платформы и хотите пройти этот путь без лишних потерь, изучите, как устроена разработка маркетплейса под ключ в нашем агентстве — от аналитики и ТЗ до запуска и поддержки. Готовы обсудить ваш проект и помочь структурировать требования ещё до старта: звоните по номеру +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty.