Когда разработчик говорит «проект готов», это не финал — это начало приёмки. Сдача проекта маркетплейса без документации равносильна покупке автомобиля без ПТС и сервисной книжки: ехать можно, но при первой поломке вы окажетесь в тупике. В этой статье — конкретный перечень документов, которые подрядчик обязан передать, объяснение назначения каждого и чек-лист для самостоятельной проверки комплектности пакета.
Почему документация — часть продукта, а не бонус
Многие заказчики фокусируются на функциональности и дизайне и упускают документальную сторону. Это ошибка с долгосрочными последствиями. Без документации вы:
- не сможете нанять нового разработчика без болезненного аудита кода;
- потеряете время при любом масштабировании или интеграции;
- рискуете нарушить требования 152-ФЗ о персональных данных из-за отсутствия описания потоков данных;
- лишитесь рычага давления при гарантийных спорах с подрядчиком.
Профессиональная разработка маркетплейса под ключ всегда включает передачу полного пакета документов — это индикатор зрелости команды и уважения к заказчику.
Технические документы: что описывает архитектуру и код
Техническое задание (ТЗ) в финальной редакции
ТЗ, которое вы согласовали на старте, к моменту сдачи обычно меняется: добавляются фичи, корректируются бизнес-правила. Финальная версия ТЗ фиксирует, что именно было реализовано. Это базовый документ для любых будущих доработок и оценки соответствия результата договору.
Архитектурная схема системы
Схема показывает, из каких компонентов состоит маркетплейс: фронтенд, бэкенд, базы данных, очереди сообщений, CDN, сторонние сервисы (платёжный шлюз, SMS-провайдер, логистический API). Без неё новый разработчик тратит от одной до трёх недель только на понимание структуры.
Описание API (API Reference)
Если маркетплейс взаимодействует с мобильным приложением, внешними партнёрами или внутренними системами, документация API обязательна. Стандарт — OpenAPI/Swagger-файл с описанием всех эндпоинтов, параметров, форматов ответов и кодов ошибок.
ERD и схема базы данных
Entity-Relationship Diagram показывает структуру таблиц, связи между ними и ключевые индексы. Без неё любая миграция данных или оптимизация запросов превращается в угадайку.
Эксплуатационные документы: как управлять платформой
Руководство администратора
Пошаговые инструкции для команды, которая будет работать в административной панели: управление продавцами, категориями, комиссиями, акциями, модерацией товаров. Хороший документ содержит скриншоты и описание нестандартных сценариев — например, что делать при споре между покупателем и продавцом.
Руководство по развёртыванию и DevOps-документация
Описывает инфраструктуру: серверы, контейнеры (Docker/Kubernetes), CI/CD-пайплайны, переменные окружения, процедуры бэкапа и восстановления. Без этого документа вы не сможете самостоятельно развернуть копию на новом сервере или передать инфраструктуру другому подрядчику.
Описание процессов мониторинга и алертинга
Какие метрики отслеживаются, какие пороги настроены, куда приходят уведомления при сбоях. Если разработчик настроил Grafana или Datadog — должна быть передана документация по дашбордам и правилам алертов.
Юридические и compliance-документы
Маркетплейс работает с персональными данными продавцов и покупателей, проводит платежи и формирует налогооблагаемые операции. Поэтому в пакет сдачи входят:
- Политика конфиденциальности — адаптированная под конкретную платформу, а не скопированная с чужого сайта;
- Пользовательское соглашение для покупателей и оферта для продавцов;
- Описание потоков персональных данных (для выполнения требований 152-ФЗ и уведомления Роскомнадзора);
- Документы на права на исходный код — акт передачи исключительных прав или лицензионный договор.
Последний пункт критичен: без него вы юридически не являетесь владельцем кода, даже если заплатили за разработку.
Чек-лист приёмки: 12 пунктов
| № | Документ | Формат | Обязательность |
|---|---|---|---|
| 1 | Финальное ТЗ | PDF / Confluence | Обязательно |
| 2 | Архитектурная схема | Draw.io / PNG | Обязательно |
| 3 | API Reference (OpenAPI) | YAML / JSON | Если есть API |
| 4 | ERD базы данных | Draw.io / SQL DDL | Обязательно |
| 5 | Руководство администратора | PDF / Notion | Обязательно |
| 6 | DevOps-документация | Markdown / Confluence | Обязательно |
| 7 | Описание мониторинга | PDF / Notion | Рекомендуется |
| 8 | Политика конфиденциальности | DOCX / HTML | Обязательно |
| 9 | Пользовательское соглашение | DOCX / HTML | Обязательно |
| 10 | Оферта для продавцов | DOCX / HTML | Обязательно |
| 11 | Описание потоков персданных | Обязательно | |
| 12 | Акт передачи прав на код | DOCX с подписями | Обязательно |
Как зафиксировать требования к документации в договоре
Самый надёжный способ получить полный пакет — прописать его в договоре до начала работ. Включите в договор или приложение к нему:
- Исчерпывающий перечень документов (используйте чек-лист выше как основу).
- Формат каждого документа и требования к актуальности (документ должен соответствовать финальной версии продукта).
- Условие: финальный платёж или подписание акта выполненных работ производится только после передачи полного пакета.
- Ответственность за неполноту документации — например, обязанность подрядчика доработать документы в течение 10 рабочих дней.
Если вы уже в процессе сдачи и договор не содержит этих пунктов — фиксируйте требования письменно (email, мессенджер с историей) и не подписывайте акт до получения всех документов.
Часто задаваемые вопросы
Что делать, если разработчик отказывается передавать документацию?
Сначала — письменный запрос с ссылкой на договор и перечнем конкретных документов. Если реакции нет, привлекайте юриста: в большинстве договоров на разработку ПО передача документации входит в объём работ по умолчанию, даже если не перечислена явно. Параллельно можно заказать технический аудит у независимой компании — это ускоряет переговоры и даёт рычаг давления.
Можно ли восстановить документацию постфактум, если её не передали?
Да, но это дорого и долго. Реверс-инжиниринг архитектуры и написание документации по готовому коду занимает от двух до шести недель в зависимости от сложности платформы и обходится в 15–40% от стоимости первоначальной разработки. Именно поэтому требовать документацию нужно на этапе сдачи, а не после.
Нужна ли документация, если маркетплейс разработан на готовой платформе (SaaS или open-source)?
Да, но её состав меняется. Документация по ядру платформы (например, по Shopify или CS-Cart) уже существует и публична. Однако подрядчик обязан передать документацию по всем кастомным модулям, интеграциям и изменениям, внесённым в ядро, а также инструкции по администрированию именно вашей конфигурации. Без этого вы не сможете самостоятельно обслуживать систему.
Итог
Сдача проекта маркетплейса с документацией — не формальность, а защита вашего бизнеса. Полный пакет из 12 документов даёт независимость от конкретного подрядчика, ускоряет масштабирование и снижает риски при проверках. Требуйте его до подписания акта — это ваше законное право.
Если вы планируете запуск платформы и хотите сразу выстроить процесс правильно — обсудите проект с командой Aris.Web. Мы занимаемся разработкой маркетплейса под ключ и передаём полный пакет документации на каждом проекте. Свяжитесь с нами по телефону +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty — ответим в течение рабочего дня.