Платформа «Витрина»

Каталог электронной коммерции нового поколения: объединение розничных сетей, локальных магазинов и производителей.

← Все документы

ПРОЕКТ «ВИТРИНА»

Технико-коммерческое описание

Версия документа: 1.2 Дата: Май 2026 г.

ПРЕДИСЛОВИЕ: РЫНОК И ВОЗМОЖНОСТЬ

Ситуация на рынке

Сегодня рынок электронной коммерции России захвачен большой тройкой: Wildberries, Ozon, Яндекс Маркет. Комиссии этих платформ составляют от 30% с каждого чека. Для сегмента общепита в столичных регионах расходы на агрегаторы достигают до 60% при использовании инструментов продвижения (базовые ставки продвижения — около 40%).

Попасть на прилавки в большой офлайн-ритейл также недоступно для большинства: - Нужно создать крупное производство - Это практически недостижимо при высокой ключевой ставке ЦБ (текущий уровень делает кредиты для малого бизнеса дорогими) - Барьеры входа слишком высоки для малого бизнеса

Ниша, которую можно занять

Между теми, кто «улетел в онлайн-космос» (федеральные агрегаторы), и теми, кто «наставил магазинов у дома и настроил гипермаркеты», — существует огромная незанятая ниша.

Платформа «Витрина» не исключает участия крупных игров — наоборот, включает их каталоги в единую витрину. Но при этом даёт возможность малым магазинам, производителям и локальным торговым точкам выйти на цифровой рынок без разорительных комиссий.

Экономика возможности

Для выхода на доход 10 млн рублей в месяц только по абонентской плате:

  • При абонентской плате 5 000 руб./мес нужно всего 2 000 продавцов
  • Это даёт ~300 млн руб. выручки в месяц при скромных показателях 4 800 руб./день на торговую точку
  • При добавлении 1% с чека — ещё 3 млн руб. дохода
  • Эти 3 млн руб. полностью окупают разработку новых функций и беспрерывную модернизацию платформы

Вывод

Витрина — это не конкурент существующим игрокам, а инфраструктура для всех: от крупных сетей до магазинов «у дома». Платформа создаёт условия, при которых каждый предприниматель может вести цифровую торговлю без кабальных комиссий и технических барьеров.

ОГЛАВЛЕНИЕ

  1. Общее описание проекта - 1.1. Назначение платформы - 1.2. Цель проекта - 1.3. Потенциал проекта - 1.4. Модель монетизации - 1.5. Модели работы платформы - 1.6. Целевая аудитория - 1.7. География
  2. Текущее состояние и цели трансформации
  3. Технологическая архитектура
  4. Структура проекта. Этапы и волны
  5. Этап 1. Фундамент и базовая функциональность (W1–W3)
  6. Этап 2. Маркетплейс и расширение ассортимента (W4–W6)
  7. Этап 3. Интеграция с ритейлом и партнёрская сеть (W7–W9)
  8. Этап 4. Масштабирование и федеральный запуск (W10–W12)
  9. Команда и роли
  10. Бюджет и финансирование
  11. Метрики успеха и критерии приёмки
  12. Риски и митигация
  13. График реализации
  14. FAQ: Часто задаваемые вопросы и ответы

1. ОБЩЕЕ ОПИСАНИЕ ПРОЕКТА

1.1. Назначение платформы

Платформа «Витрина» — это каталог электронной коммерции нового поколения, объединяющий розничные сети, локальные магазины и производителей.

1.2. Цель проекта

Создать современную витрину товаров и услуг, которая будет доступна в каждом городе России и содержать полный каталог торговли.

Видение: - Единая цифровая витрина для всех участников торговли — от крупных сетей до магазинов «у дома» - Полный каталог товаров и услуг в каждом регионе - Масштабирование без швов — запуск в новом регионе за 1–3 дня без изменений в коде - Доступность для предпринимателей без технических знаний и больших инвестиций

1.3. Потенциал проекта

Рыночный потенциал

  • Рынок e-commerce в России: сотни миллиардов рублей ежегодно, устойчивый рост
  • Адресуемый сегмент: города-миллионники + регионы с недостаточным присутствием федеральных агрегаторов
  • SOM (реалистично доступный рынок): от 1 млрд руб./год с региона (стартовый потенциал на текущей аудитории), при масштабировании на 15 городов — до 15 млрд руб./год

Конкурентные преимущества

  • Масштабирование без швов: конфигурационная архитектура позволяет запускать город за 1–3 дня
  • Белый ярлык: партнёры сохраняют свой бренд и клиентов (в отличие от агрегаторов)
  • Гибридная модель: DBS + маркетплейс создаёт сетевой эффект
  • Логистика: модуль с гео-привязкой, мобильные приложения для курьеров и сборщиков заказов, трекинг в реальном времени, точность ETA >95%

Масштабирование

  • Пилот: Санкт-Петербург
  • Год 1: 3–5 городов-миллионников
  • Год 2: федеральное покрытие

1.4. Модель монетизации

Платформа предлагает гибкую модель монетизации без высоких комиссий с продаж:

Основная модель 1: абонентская плата (для маркетплейса)

  • Абонентская плата — предсказуемые расходы для бизнеса
  • Базовый тариф: 5 000 руб./мес (дополнительные тарифы — по договорённости)
  • Подходит для магазинов с собственными кассами и логистикой

Основная модель 2: DBS (для ритейла)

  • Комиссия с чека: 4,5% (средняя по ритейлу)
  • Доставка осуществляется силами продавца (ритейл имеет собственную логистику)
  • Платформа выступает витриной и генератором лидов — комиссия является доходом платформы со всех ежедневных заказов

Опционально: комиссия с продаж (для маркетплейса)

  • % с продаж — только для тех партнёров, кому нужна онлайн-касса (54-ФЗ)
  • Интеграция с ФНС «из коробки»
  • Прозрачная комиссия без скрытых платежей

Опционально: доставка

  • Доставка — для партнёров, которые могут организовать логистику
  • Модуль доставки с гео-привязкой, интеграция с курьерскими службами, такси, ПВЗ
  • Оплата за использование модуля или % от заказа

Схема монетизации

Сервис Модель Для кого
Витрина (каталог, заказы) — Маркетплейс Абонентская плата (базовый тариф 5 000 руб./мес) Малые магазины, производители
Витрина (каталог, заказы) — DBS Комиссия 4,5% с чека Розничные сети
Онлайн-касса (54-ФЗ) % с продаж Кому нужна касса
Логистика и доставка Абонентская плата или % Кто организует доставку
API для партнёров Абонентская плата Для разработчиков интеграций

1.5. Модели работы платформы

Платформа работает по двум моделям:

  • DBS (Delivery by Seller) — платформа выступает витриной и генератором лидов для розничных сетей. Доставка осуществляется силами продавца (ритейл имеет собственную логистику). Комиссия платформы: 4-5% с чека как оплата за привлечённые заказы. Это делает платформу низкозатратным каналом лидогенерации для крупных сетей.

  • Маркетплейс — подключение малых магазинов и производителей. Оплата: абонентская плата или 1-3% с чека (для партнёров с онлайн-кассой).

1.6. Целевая аудитория

  • Конечные покупатели — физические лица, заказывающие продукты и товары повседневного спроса (текущая аудитория: ~8 000 уникальных покупателей, ~500 заказов в день)
  • Розничные сети (гипермаркеты) — существующие партнёры с собственной логистикой и ассортиментом
  • Локальные магазины «у дома» — малые торговые точки, производители
  • Партнёры по доставке — курьерские службы, такси, пункты выдачи заказов (ПВЗ)

1.7. География

Период Регион
Месяцы 1-3 (пилот) Санкт-Петербург
Месяцы 10-12 (масштабирование) 3-5 городов-миллионников
Год 2 Федеральное покрытие (15+ городов)

2. ТЕКУЩЕЕ СОСТОЯНИЕ И ЦЕЛИ ТРАНСФОРМАЦИИ

2.1. Существующая система

В настоящее время функционирует система доставки товаров из гипермаркетов. Система построена на монолитной архитектуре 2015 года разработки, обеспечивает полный цикл обработки заказов:

  • формирование корзины
  • расчёт стоимости
  • валидация остатков
  • процессинг оплаты
  • передача заказа на сборку
  • отслеживание доставки

Ключевой факт: система работает, имеет живую аудиторию и стабильный поток заказов. Это основа, на которой строится трансформация.

2.2. Ограничения текущей системы

  • Архитектура: монолитная, высокая связанность компонентов, размытые границы доменов
  • Технологический стек: устаревшие версии PHP, jQuery на фронтенде
  • Масштабирование: только вертикальное, ограниченное ресурсами сервера
  • Инфраструктура: фиксированные VM, ручное масштабирование, низкая утилизация (до 35%)
  • Интеграции: встроены в ядро приложения, отсутствует изоляция
  • Документация: устаревшая, не отражает текущее состояние

2.3. Цели трансформации

Создание новой платформы на базе существующей системы с целью:

  1. Сохранить текущую аудиторию — все существующие пользователи переводятся на новую платформу без потери функциональности
  2. Умножить показатели — увеличение количества магазинов-партнёров, расширение ассортимента, рост частоты заказов
  3. Снизить операционные затраты — оптимизация инфраструктуры, автоматизация процессов
  4. Обеспечить масштабирование — возможность запуска в новых регионах за 1–3 дня без изменения кода
  5. Создать партнёрскую экосистему — подключение розничных сетей и малых магазинов без технических барьеров

3. ТЕХНОЛОГИЧЕСКАЯ АРХИТЕКТУРА

3.1. Архитектурный подход

Платформа строится на принципах:

  • Микросервисная архитектура — разделение на независимые домены с чёткими контрактами взаимодействия
  • Событийно-ориентированная коммуникация — асинхронное взаимодействие через шину сообщений Kafka
  • API-first подход — все взаимодействия через документированные API
  • Конфигурационное управление — региональные параметры вынесены в конфигурационные профили

3.2. Технологический стек

Компонент Технология Версия
Бэкенд (бизнес-логика) PHP 8.x (последняя стабильная)
Бэкенд (высокие нагрузки) Go 1.23+
Фронтенд Vue.js 3, TypeScript, Vite, Pinia Актуальные
База данных (OLTP) PostgreSQL 16+
Кэш и сессии Redis 7+
Аналитика и логи ClickHouse 24+
Контейнеризация Docker Latest
Оркестрация Kubernetes 1.28+
CI/CD GitLab CI Latest
Инфраструктура Terraform Latest
Наблюдаемость Prometheus, Grafana, ELK, Sentry, OpenTelemetry Актуальные

3.3. Архитектура данных

  • Горячее хранилище: PostgreSQL — операционные транзакции, каталоги товаров, заказы
  • Кэш: Redis — сессии пользователей, очереди заданий, частые запросы
  • Холодное храниление: ClickHouse — логи, аналитика, исторические данные
  • Разделение потоков: OLTP и OLAP нагрузки не конкурируют друг с другом

3.4. Инфраструктура

  • Контейнеризация всех сервисов
  • Автоматическое горизонтальное и вертикальное масштабирование
  • Стратегия деплоя: Canary или Blue-Green с мгновенным откатом
  • Начальные затраты на инфраструктуру: 150–200 тыс. руб./мес.
  • Целевая утилизация: 68–85% (эффективное использование серверных ресурсов вместо текущих ~35%)

3.5. Безопасность

  • JWT-аутентификация
  • Защита от XSS, SQLi
  • Rate-limiting
  • Логирование всех операций
  • Регулярное резервное копирование
  • Аудит безопасности на этапе W6 и W12

4. СТРУКТУРА ПРОЕКТА. ЭТАПЫ И ВОЛНЫ

4.1. Общая структура

Проект разделён на 4 этапа по 3 волны (этапа) в каждом:

Этап Волны Период Ключевой результат
Этап 1: Фундамент W1–W3 Месяцы 1–3 Работающая v1.0, пилот в СПб
Этап 2: Маркетплейс W4–W6 Месяцы 4–6 Стабильная платформа, маркетплейс
Этап 3: Партнёрства W7–W9 Месяцы 7–9 Интеграция с ритейлом
Этап 4: Масштабирование W10–W12 Месяцы 10–12 Федеральный запуск

4.2. Принципы sequential workflow

Каждый этап является продолжением предыдущего:

  • W1 → W2 → W3: наращивание функционала от архитектуры до работающего продукта
  • W4 → W5 → W6: расширение от маркетплейса до стабильной платформы
  • W7 → W8 → W9: углубление от архитектуры интеграций до реальных партнёров
  • W10 → W11 → W12: масштабирование от подготовки профилей до федерального запуска

Выходные данные (artifacts) предыдущей волны являются входными для следующей.

5. ЭТАП 1. ФУНДАМЕНТ И БАЗОВАЯ ФУНКЦИОНАЛЬНОСТЬ (W1–W3)

Период: Месяцы 1–3 (недели 1–12)

Цель: Создать техническую основу платформы и перенести существующий функционал заказов.

Волна W1: Архитектура и инфраструктура

Период: Месяц 1 (недели 1–4)

Что делается

  1. Аудит существующей системы - Анализ исходного кода legacy-системы - Трассировка критичных транзакционных потоков (корзина, расчёт стоимости, валидация остатков, оплата, сборка) - Выявление скрытых бизнес-правил (ценообразование, зоны доставки, комиссии) - Фиксация журнала бизнес-правил с подтверждением от владельцев процессов

  2. Проектирование архитектуры - Определение границ ответственности: PHP для бизнес-логики, Go для высоконагруженных сервисов - Проектирование схем базы данных (PostgreSQL, Redis, ClickHouse) - Создание пакета архитектурных решений ADR

  3. Развёртывание инфраструктуры - Kubernetes-кластер - Terraform для управления инфраструктурой - GitLab CI/CD - Стек наблюдаемости (Prometheus, Grafana, ELK, Sentry)

  4. Стратегия миграции - Разработка подхода с двойной записью (одновременно в старую и новую систему) - Механизмы сверки данных - Процедура безопасного отката

Результат (deliverables)

  • Техническое задание версии 1.0 с детализацией доменных границ
  • Карта предметных областей
  • ADR-пакет в репозитории
  • Работающий Kubernetes-кластер с CI/CD
  • План миграции данных

Критерий приёмки

Архитектура утверждена техническим лидером, план миграции согласован с командой поддержки legacy-системы.

Волна W2: Клиентский канал и ядро заказов

Период: Месяц 2 (недели 5–8)

Что делается

  1. Клиентское приложение - Разработка нового пользовательского приложения на Vue.js 3 + TypeScript - Модуль корзины и формирования заказа - Процесс оформления заказа

  2. API ядра - REST API для создания, изменения, отмены заказов (PHP) - Валидация остатков и резервирование товаров

  3. Интеграция с гипермаркетами - Подключение к API существующих гипермаркетов - Получение каталога товаров, остатков, цен - Синхронизация данных в реальном времени

  4. Платёжный модуль - Интеграция с платёжными шлюзами - Обработка оплаты картами

  5. Событийная шина - Настройка Kafka для асинхронного взаимодействия сервисов

Результат (deliverables)

  • Работающее клиентское приложение
  • API ядра заказов
  • Интеграция с гипермаркетами
  • Модуль оплаты
  • Настроенная шина событий

Критерий приёмки

Полный цикл оформления заказа работает в тестовом окружении. Интеграция с гипермаркетами протестирована.

Волна W3: Релиз v1.0 и пилот в Санкт-Петербурге

Период: Месяц 3 (недели 9–12)

Что делается

  1. Миграция данных - Запуск двойной записи (одновременно в legacy и новую систему) - Синхронизация и сверка данных - Перенос исторических данных

  2. Тестирование - Интеграционное тестирование (новая система ↔ legacy) - Нагрузочное тестирование (цель: 10 000 запросов в секунду) - Пользовательское тестирование (UAT)

  3. Деплой - Развёртывание в production (стратегия Canary или Blue-Green) - Настройка мониторинга и алертов - Настройка SLO (целевой уровень: 99,5%)

  4. Пилотный запуск - Запуск в Санкт-Петербурге - Перевод существующих пользователей - Мониторинг и стабилизация

Результат (deliverables)

  • Работающая система версии 1.0 в production
  • 100% функционала заказов перенесено
  • Пилотная эксплуатация в Санкт-Петербурге
  • Мониторинг SLO 99,5%
  • Отчёты по нагрузочному тестированию

Критерий приёмки

Система работает в production, метрики SLO достигнуты, пользователи оформляют заказы без потери функциональности.

Итог Этапа 1

Что получено: Работающая платформа с полным функционалом заказов из гипермаркетов, запущенная в Санкт-Петербурге.

Ключевая метрика: 100% перенос существующей аудитории на новую платформу.

6. ЭТАП 2. МАРКЕТПЛЕЙС И РАСШИРЕНИЕ АССОРТИМЕНТА (W4–W6)

Период: Месяцы 4–6 (недели 13–24)

Цель: Добавить возможность подключения малых магазинов и производителей, создать витрину для них.

Волна W4: Витрина малых магазинов и производителей

Период: Месяц 4 (недели 13–16)

Что делается

  1. Маркетплейс-модуль - Проектирование архитектуры маркетплейса - Определение модели работы с продавцами

  2. Кабинет продавца - Регистрация и авторизация продавцов - Добавление и управление товарами - Обработка заказов - Финансовая отчётность

  3. Каталог товаров - Карточки товаров с изображениями и описанием - Поиск и фильтры - Категоризация

  4. Система отзывов - Рейтинги продавцов - Отзывы покупателей

  5. Интеграция с магазинами - Разработка API-адаптеров для подключения систем малых магазинов - Синхронизация остатков и цен

Результат (deliverables)

  • Архитектура маркетплейса
  • Личный кабинет продавца
  • Каталог товаров
  • Система рейтингов и отзывов
  • API-адаптеры для магазинов

Критерий приёмки

Продавец может зарегистрироваться, добавить товары и начать принимать заказы.

Волна W5: Модуль доставки и логистика

Период: Месяц 5 (недели 17–20)

Что делается

  1. Алгоритмы роутинга - Разработка алгоритмов маршрутизации (Go) - Расчёт ETA (время прибытия) с точностью >95% - Оптимизация маршрутов

  2. Интеграция с доставкой - Подключение курьерских служб - Интеграция с такси-сервисами для экспресс-доставки - Интеграция с пунктами выдачи заказов (ПВЗ)

  3. Система сборки - Модуль для сборщиков заказов - Маршруты сборки - Трекинг в реальном времени

  4. Last-mile оптимизация - Оптимизация последней мили доставки - Снижение стоимости доставки

Результат (deliverables)

  • Алгоритмы роутинга и ETA
  • Интеграция с курьерскими службами, такси, ПВЗ
  • Система сборки заказов
  • Трекинг доставки в реальном времени

Критерий приёмки

Точность ETA >95%, пользователь видит актуальный статус доставки.

Волна W6: Стабилизация и подготовка к интеграциям

Период: Месяц 6 (недели 21–24)

Что делается

  1. Стабилизация - Оптимизация производительности (время отклика <200 мс) - Исправление выявленных проблем

  2. Настройка SLO - Внедрение SLI (показателей уровня обслуживания) - Настройка error budget

  3. Аудит безопасности - Внешний pentest - Исправление уязвимостей

  4. Подготовка интеграций - Внедрение circuit-breaker для внешних интеграций - Разработка шаблонов адаптеров для ритейлеров - Документирование API для интеграторов

Результат (deliverables)

  • Стабильная платформа
  • Отчёт по безопасности
  • Шаблоны для DBS-интеграций
  • Документация API
  • SLO 99,5% достигнут

Критерий приёмки

Аудит безопасности пройден, платформа готова к подключению внешних партнёров.

Итог Этапа 2

Что получено: Стабильная платформа с маркетплейсом для малых магазинов и полноценным модулем доставки.

Ключевые метрики: ETA >95%, SLO 99,5%, время отклика <200 мс.

7. ЭТАП 3. ИНТЕГРАЦИЯ С РИТЕЙЛОМ И ПАРТНЁРСКАЯ СЕТЬ (W7–W9)

Период: Месяцы 7–9 (недели 25–36)

Цель: Подключить розничные сети по модели DBS, обеспечить работу с несколькими брендами.

Волна W7: Архитектура интеграций и мок-адаптеры

Период: Месяц 7 (недели 25–28)

Что делается

  1. Проектирование интеграционного слоя - Архитектура изолированных интеграций - Принципы изоляции доменов - Контракты взаимодействия

  2. Мок-адаптеры - Разработка симуляторов API ритейлеров - Тестовые данные для отладки

  3. Контрактные тесты - Определение API-контрактов - Написание контрактных тестов

  4. Устойчивость к отказам - Реализация circuit-breaker - Retry-механизмы

Результат (deliverables)

  • Архитектура интеграционного слоя
  • Мок-сервисы для ритейлеров
  • Контрактные тесты
  • Механизмы устойчивости к отказам

Критерий приёмки

Артектура интеграций задокументирована, мок-адаптеры готовы для тестирования.

Волна W8: Синхронизация данных и нагрузочное тестирование

Период: Месяц 8 (недели 29–32)

Что делается

  1. Синхронизация каталогов - Интеграция с системами ритейлеров - Синхронизация товаров, цен, остатков

  2. Синхронизация заказов - Обмен заказами между платформой и ритейлерами - Синхронизация статусов

  3. Нагрузочное тестирование - Тестирование интеграционного слоя (10 000 RPS) - Stress-тесты - Тесты отказоустойчивости

  4. Оптимизация - Оптимизация производительности адаптеров

Результат (deliverables)

  • Синхронизированные каталоги с ритейлерами
  • Протокол нагрузочного тестирования
  • Оптимизированные адаптеры

Критерий приёмки

10 000 RPS достигнуто, система выдерживает пиковые нагрузки.

Волна W9: Подключение реальных брендов

Период: Месяц 9 (недели 33–36)

Что делается

  1. Подключение партнёров - Интеграция с 2–3 розничными сетями по модели DBS - Настройка конфигурации для каждого партнёра

  2. Мониторинг SLA - Настройка мониторинга доступности и времени отклика - Дашборды SLA

  3. Обработка edge-cases - Выявление и исправление проблемных сценариев - Адаптация под реальные данные

  4. UAT с партнёрами - Совместное тестирование с ритейл-партнёрами - Финальная настройка

Результат (deliverables)

  • 2–3 ритейл-партнёра подключены
  • Мониторинг SLA настроен
  • Протокол UAT подписан
  • Подтверждённые SLA

Критерий приёмки

Пилот с реальными партнёрами работает, SLA соблюдаются.

Итог Этапа 3

Что получено: Платформа с работающими интеграциями с розничными сетями, мультибрендовый пилот.

Ключевые метрики: 2–3 партнёра, подтверждённые SLA.

8. ЭТАП 4. МАСШТАБИРОВАНИЕ И ФЕДЕРАЛЬНЫЙ ЗАПУСК (W10–W12)

Период: Месяцы 10–12 (недели 37–48)

Цель: Запустить платформу в нескольких городах, подготовить федеральное масштабирование.

Волна W10: Масштабирование на города-миллионники

Период: Месяц 10 (недели 37–40)

Что делается

  1. Подготовка профилей городов - Создание конфигурационных профилей для новых городов - Настройка тарифных зон, логистических хабов, налоговых ставок

  2. Развёртывание - Использование готовых Helm-чартов для быстрого развёртывания - Развёртывание в 3–5 городах

  3. Интеграция логистики - Подключение локальных логистических партнёров в каждом городе

  4. Мониторинг - Настройка мониторинга для каждого региона - Адаптация под региональные особенности

Результат (deliverables)

  • Конфигурационные профили городов
  • Платформа развёрнута в 3–5 городах
  • Логистика интегрирована

Критерий приёмки

3–5 городов работают, пользователи могут делать заказы.

Волна W11: Аналитика и оптимизация

Период: Месяц 11 (недели 41–44)

Что делается

  1. Аналитические дашборды - Внедрение дашбордов с бизнес-метриками - Метрики по городам, партнёрам, пользователям

  2. Сбор и анализ метрик - Анализ использования платформы - Выявление точек роста

  3. Оптимизация процессов - Оптимизация на основе данных - Улучшение конверсии и retention

  4. A/B тестирование - Тестирование изменений UX - Внедрение улучшений

Результат (deliverables)

  • Аналитические дашборды
  • Оптимизированные процессы
  • Рост конверсии и retention

Критерий приёмки

Метрики собраны, оптимизации внедрены, рост показателей подтверждён.

Волна W12: Партнёрский API и федеральный запуск

Период: Месяц 12 (недели 45–48)

Что делается

  1. Партнёрский API - Разработка публичного API для подключения новых партнёров - Swagger/OpenAPI документация

  2. Финальный аудит - Аудит безопасности - Аудит производительности

  3. Подготовка к масштабированию - Playbook для запуска новых городов - Процедура подключения новых партнёров

  4. Итоговое тестирование - Комплексное тестирование всей платформы

  5. Документация - Полная техническая документация - Документация для партнёров

Результат (deliverables)

  • Партнёрский API с документацией
  • Итоговый аудит пройден
  • Playbook масштабирования
  • Полная документация

Критерий приёмки

Платформа готова к федеральному запуску, документация передана.

Итог Этапа 4

Что получено: Платформа работает в нескольких городах, готова к федеральному масштабированию.

Ключевые метрики: 3–5 городов запущено, партнёрский API готов.

9. КОМАНДА И РОЛИ

9.1. Структура команды

На старте: 10–12 человек

Роль Кол-во Зона ответственности
Технический лидер 1 Архитектурное проектирование, координация технических решений
Старший разработчик Go 2 Высоконагруженные сервисы, модуль доставки, интеграции
Старший разработчик PHP 2 Бизнес-логика, API, админ-панель
Frontend-разработчик 2 Клиентское приложение, личные кабинеты
DevOps-инженер 2 Инфраструктура, CI/CD, мониторинг
Бизнес-аналитик 1 Реверс-инжиниринг требований, фиксация бизнес-правил
QA-инженер / автоматизатор 2 Тестирование, контрактные тесты
Product-менеджер 1 Управление продуктом, приоритизация

Динамика расходов

Расходы на команду регрессирующие по мере реализации проекта:

  • Этапы 1–3 (W1–W3): Максимальные расходы на разработку, основной фокус на создании платформы
  • Этапы 4–6 (W4–W6): Баланс между разработкой и стабилизацией
  • Этапы 7–9 (W7–W9): Снижение расходов на разработку, рост расходов на интеграции
  • Этапы 10–12 (W10–W12): Минимум на разработку, основной фокус на поддержку и мониторинг

К концу проекта часть разработчиков завершает работу, но появляется потребность в расширении поддержки и мониторинга для растущей платформы.

9.2. Взаимодействие с заказчиком

Заказчик (инвестор) участвует в:

  • Утверждении стратегии и приоритетов
  • Контроле бюджета
  • Приёмке ключевых вех (Milestones M1, M3, M6, M9, M12)
  • Согласовании изменений скоупа (Change Request Board)

9.3. Взаимодействие с командой поддержки

Команда Аксиома (поддержка legacy-системы) обеспечивает:

  • Предоставление доступа к текущей системе
  • Экспертизу по бизнес-логике
  • Параллельную работу legacy и новой платформы
  • Валидацию корректности переноса функционала

10. БЮДЖЕТ И ФИНАНСИРОВАНИЕ

10.1. Общий бюджет

52 000 000 рублей (фиксированный CAPEX)

10.2. Распределение по статьям

Статья Доля Сумма (руб.)
Команда разработки 61,8% 32 136 000
Инфраструктура и лицензии 10,0% 5 200 000
Интеграции и адаптеры 8,2% 4 264 000
QA, безопасность, аудит 5,9% 3 068 000
UX, документация, передача знаний 4,7% 2 444 000
Резерв на риски 9,4% 4 888 000

Назначение резерва: покрытие задержек оргпроцессов по подключению партнёров, непредвиденных технических проблем, замены специалистов при выбытии. Ключевой принцип — резерв позволяет удержать команду при задержках, не связанных с качеством работы.

10.2.1. Распределение по этапам (регрессионная модель)

Период Этапы Доля Сумма (руб.) Среднее в месяц Описание
Месяцы 1-3 W1–W3 40% 20 800 000 6 933 333 Максимум ресурсов — архитектура, разработка, инфраструктура
Месяцы 4-6 W4–W6 30% 15 600 000 5 200 000 Активная разработка — маркетплейс, доставка, стабилизация
Месяцы 7-9 W7–W9 20% 10 400 000 3 466 667 Снижение разработки — интеграции с ритейлом
Месяцы 10-12 W10–W12 10% 5 200 000 1 733 333 Минимум — только поддержка и масштабирование

Итого: 52 000 000 руб.

Принцип: - W1-W3: 10-12 человек (полный состав) - W4-W6: 8-10 человек (снижение после стабилизации) - W7-W9: 6-8 человек (интеграции, оптимизация) - W10-W12: 4-6 человек (поддержка)

10.3. Принципы контроля

  • Еженедельный трекинг burn-down rate
  • Ежемесячный финансовый ревью с заказчиком
  • Stage-gate финансирование (привязка к acceptance criteria этапов)
  • Автоматические алерты при отклонении расходов >10% от плана
  • Изменение скоупа — только через формализованный процесс с пересчётом влияния на бюджет

10.4. Ожидаемая экономика

  • Снижение операционных расходов на инфраструктуру: >50% (с ~500 тыс. до 150–200 тыс. руб./мес.)
  • Снижение стоимости транзакции: 40–60% по сравнению с legacy

11. МЕТРИКИ УСПЕХА И КРИТЕРИИ ПРИЁМКИ

11.1. Технические метрики

Метрика Целевое значение Этап
SLO (уровень доступности) 99,5% W3
Время отклика <200 мс W6
Нагрузочная способность 10 000 RPS W3, W8
Точность ETA доставки >95% W5
Время подключения нового города 1–3 дня W10

11.2. Бизнес-метрики

Метрика Целевое значение Этап
Количество ритейл-партнёров 2–3 W9
Количество городов 3–5 W10
Перенос существующей аудитории 100% W3
Снижение стоимости транзакции 40–60% W6

11.3. Критерии приёмки по этапам

Milestone Срок Критерий
M1 Конец W1 Архитектура утверждена, план миграции согласован
M2 Конец W2 Клиент и ядро работают в тестовом окружении
M3 Конец W3 v1.0 в production, SLO 99,5%, пользователи оформляют заказы
M4 Конец W4 Маркетплейс готов, продавцы могут добавлять товары
M5 Конец W5 Модуль доставки работает, ETA >95%
M6 Конец W6 Аудит безопасности пройден, платформа стабильна
M7 Конец W7 Архитектура интеграций готова
M8 Конец W8 10 000 RPS достигнуто
M9 Конец W9 2–3 партнёра подключены, SLA подтверждены
M10 Конец W10 3–5 городов работают
M11 Конец W11 Оптимизации внедрены, рост метрик подтверждён
M12 Конец W12 Федеральный запуск готов

12. РИСКИ И МИТИГАЦИЯ

12.1. Технические риски

Риск Вероятность Влияние Митигация
Сложность миграции данных Высокая Высокая Двойная запись, механизмы сверки, откат
Задержки интеграции с гипермаркетами Средняя Высокая Раннее согласование API, мок-тесты
Деградация под нагрузкой Средняя Высокая Нагрузочное тестирование, автоматическое масштабирование
Уязвимости безопасности Средняя Высокая Аудит безопасности, pentest

12.2. Бизнес-риски

Риск Вероятность Влияние Митигация
Задержка согласования требований Средняя Средняя Формализованный процесс, SLA на согласование
Изменение скоупа Средняя Средняя Change Request Board, пересчёт бюджета
Зависимость от внешних API Средняя Средняя Circuit-breaker, изоляция

12.3. Допущения

  1. Заказчик предоставляет доступы к тестовым контурам и API гипермаркетов до начала W2
  2. Команда Аксиома обеспечивает поддержку legacy-системы на протяжении всей миграции
  3. Согласование макетов и требований — в течение 1 рабочего дня
  4. При задержке согласования >2 рабочих дней срок сдачи может быть сдвинут

13. ГРАФИК РЕАЛИЗАЦИИ

13.1. Общий таймлайн

Этап Период Длительность
Этап 1: Фундамент Месяцы 1–3 12 недель
Этап 2: Маркетплейс Месяцы 4–6 12 недель
Этап 3: Партнёрства Месяцы 7–9 12 недель
Этап 4: Масштабирование Месяцы 10–12 12 недель

Общая длительность: 12 месяцев (48 недель)

13.2. Ключевые даты (Milestones)

Milestone Описание Дата
M1 Архитектура и план миграции утверждены Конец месяца 1
M3 Релиз v1.0, старт пилота в СПб Конец месяца 3
M6 Стабильная платформа, аудит пройден Конец месяца 6
M9 Пилот DBS с партнёрами Конец месяца 9
M12 Федеральный запуск готов Конец месяца 12

13.3. Методология

  • Agile-спринты по 2 недели
  • Stage-Gate ревью на границах этапов (W3, W6, W9, W12)
  • Еженедельные статусные встречи
  • Ежемесячное финансовое ревью с заказчиком

14. FAQ: ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ И ОТВЕТЫ

14.1. Вопросы по бюджету

Почему бюджет 52 млн, а не 85 млн (например)?

Ответ: Бюджет 52 млн — это расходы на модернизацию и разработку платформы. Расходы распределены с регрессией — к концу запланированных этапов (W12) затраты на разработку снижаются, и далее следует переход на обслуживание и развитие с новыми приоритетами (операционные расходы).

Бюджет взят с запасом на риски (резерв 4,9 млн руб.), что позволяет покрыть: - Задержки оргпроцессов по подключению партнёров - Непредвиденные технические проблемы - Замену специалистов при выбытии

Стоимость снижена за счёт использования живой legacy-системы как основы. Мы не строим с нуля, а трансформируем существующее: - Используем существующую инфраструктуру и наработки - Миграция вместо пересоздания — подход с двойной записью - Команда Аксиомы уже знает систему — не требуется время на погружение - Снижены риски за счёт работы с проверенной системой

Как меняются расходы по мере реализации проекта?

Ответ: Расходы идут по регрессии:

  • Этапы 1–3 (W1–W3): Основной фокус на разработке, максимальные расходы на команду
  • Этапы 4–6 (W4–W6): Баланс между разработкой и стабилизацией
  • Этапы 7–9 (W7–W9): Снижение расходов на разработку, рост расходов на интеграции
  • Этапы 10–12 (W10–W12): Минимум на разработку, основной фокус на поддержку, мониторинг, масштабирование

К концу проекта часть разработчиков завершает работу, но появляется потребность в расширении поддержки и мониторинга для растущей платформы.

На что именно идёт резерв на риски (4,9 млн)?

Ответ: Резерв предназначен для покрытия:

  • Задержек оргпроцессов по подключению партнёров и гипермаркетов
  • Увеличения сроков из-за согласований и бюрократических процедур
  • Непредвиденных технических проблем, требующих дополнительных ресурсов
  • Замены подрядчиков или специалистов при выбытии
  • Необходимости удержания команды при задержках финансирования

Ключевой принцип: резерв позволяет не потерять специалистов раньше времени, если проект затянется по независящим от команды причинам.

Какой порог входа для запуска нового города?

Ответ: Подключение нового города занимает 1–3 дня через готовый Helm-чарт и загрузку конфигурационного профиля.

Экономика: - Базовая инфраструктура (СПб пилот): ~150–200 тыс. руб./мес - Дополнительный город: +100–150 тыс. руб./мес - При масштабировании на 10 городов: ~1,5–2 млн руб./мес

Конфигурационные профили уже включают тарифные зоны, логистические хабы, налоговые ставки — дополнительные затраты только на инфраструктуру.

14.2. Вопросы от инвестора

Когда проект начнёт приносить прибыль?

Ответ: Первые признаки выхода на прибыль ожидаются после запуска пилота в Санкт-Петербурге (этап W3, месяц 3). При достижении 2 000 активных продавцов с абонентской платой 5 000 руб./мес, платформа выходит на 10 млн руб./мес дохода только от подписки.

Полная окупаемость инвестиций (ROI) ожидается к концу года (этап W12), когда будет достигнуто федеральное масштабирование и максимальная экономия на инфраструктуре.

Какой ожидаемый ROI?

Ответ: Ожидаемый ROI превышает 100% к концу 12-месячного цикла развития. Ключевые факторы:

  • При 2 000 продавцов × 5 000 руб. = 10 млн руб./мес доход
  • При 300 млн руб. выручки продавцов + 1% с чека = 3 млн руб./мес дополнительный доход
  • Совокупный доход полностью покрывает операционные расходы и обеспечивает рост
  • Экономия на инфраструктуре: снижение с ~500 тыс. до 150–200 тыс. руб./мес

Точный ROI зависит от скорости привлечения продавцов и географического масштабирования.

Сколько пользователей планируется привлечь? Какой retention?

Ответ:

Конечные покупатели: - Пилот (СПб): перенос существующей аудитории legacy-системы — 100% - Год 1 (3–5 городов): рост до 100–200 тыс активных покупателей - Год 2 (федеральный запуск): 500+ тыс. покупателей

Продавцы: - Год 1: 2 000–5 000 активных продавцов - Год 2: 10 000+ продавцов

Retention (удержание): - Покупатели: целевой показатель — 60% повторных покупок в месяц - Продавцы: целевой показатель — 80% продления подписки через 12 месяцев

Как будет монетизироваться платформа?

Ответ: Три модели монетизации:

  1. Абонентская плата (основная) - 5 000–15 000 руб./мес в зависимости от тарифа - Включает: витрину, каталог, управление заказами, аналитику - Подходит для продавцов с собственной онлайн-кассой и логистикой

  2. Процент с чека (опционально) - 1–3% от чека для тех, кому нужна онлайн-касса «под ключ» (54-ФЗ) - Интеграция с ФНС включена

  3. Доставка (опционально) - Абонентская плата или % от заказа для использования модуля логистики - Интеграция с курьерскими службами, такси, ПВЗ

Экономика: При 2 000 продавцов → 10 млн руб./мес от подписки + 3 млн руб./мес от чека = 13 млн руб./мес потенциальный доход.

Чем вы отличаетесь от конкурентов (Яндекс Лавка, СберМаркет)?

Ответ: Ключевые отличия:

Параметр Яндекс Лавка, СберМаркет Витрина
Комиссия 15–30%+ с чека Абонентская плата (без % с продаж)
Бренд продавца Продвигается платформа Продавец сохраняет свой бренд (white-label)
Барьер входа Высокий (нужны объёмы) Низкий (5000 руб./мес)
Масштабирование Долгое развёртывание 1–3 дня на новый город
Модель Только агрегатор DBS + маркетплейс
Фокус Федеральный Региональный с федеральным охватом

Главное отличие: Мы не конкурируем — мы даём возможность маленьким игрокам exist на рынке, при этом включаем крупные сети в каталог.

Сколько городов планируется запустить за год?

Ответ:

  • Месяцы 1–3: Пилот — Санкт-Петербург
  • Месяцы 4–6: Стабилизация, подготовка к масштабированию
  • Месяцы 7–9: Тестирование интеграций
  • Месяцы 10–12 (год 1): Запуск в 3–5 городах-миллионниках

Горизонт: - Год 1: 3–5 городов - Год 2: федеральное покрытие (15+ городов)

Подключение нового города занимает 1–3 дня благодаря конфигурационной архитектуре.

Какая текущая выручка у legacy-системы? Сколько заказов в день?

Ответ:

Текущие показатели legacy-системы:

Показатель Значение
Заказов в день ~500
Средний чек ~5 000 руб.
Выручка в день (GMV) ~2 500 000 руб.
Выручка в месяц (GMV) ~75 000 000 руб.
Выручка в год (GMV) ~900 000 000 руб.

Эти данные критически важны для: - Планирования миграции — нужно перенести всех пользователей без потери - Расчёта базовых метрик для оценки роста - Определения точек масштабирования

Как финансируется проект — сразу 52 млн рублей или поэтапно?

Ответ: Проект использует регрессионную систему финансирования. Средства выделяются поэтапно, в соответствии с планом работ:

Этапы с максимальными расходами (W1–W6): - Максимальное количество параллельных работ и ресурсов - Активная разработка, тестирование, развёртывание инфраструктуры - Основные затраты на команду разработки

Этапы со снижением расходов (W7–W12): - Постепенное сокращение команды разработки - Переход на операционное обслуживание - К W12 остаётся минимальный состав для поддержки системы

Распределение бюджета:

Период Этапы Доля Сумма
Месяцы 1-3 W1–W3 40% 20,8 млн руб.
Месяцы 4-6 W4–W6 30% 15,6 млн руб.
Месяцы 7-9 W7–W9 20% 10,4 млн руб.
Месяцы 10-12 W10–W12 10% 5,2 млн руб.

Итого: 52 млн руб.

Это позволяет оптимизировать расходы и не переплачивать за простой ресурсов после завершения активной разработки.

14.3. Вопросы от владельца сервиса

Что произойдёт с текущими пользователями во время миграции?

Ответ: Миграция пользователей осуществляется без перерыва сервиса:

  • Подход двойной записи: новые заказы пишутся одновременно в старую и новую системы
  • Пользователи не замечают перехода: интерфейс нового клиента идентичен или улучшен
  • Постепенный перенос: сначала 10% трафика на новую систему, затем 100%
  • Механизм отката: при проблемах — мгновенное переключение обратно на legacy
  • Сохранение данных: вся история заказов, избранное, адреса доставки переносятся в новую систему

Результат: 100% существующих пользователей переводятся на новую платформу без потери функциональности.

Нужно ли обучать персонал? Сколько времени?

Ответ: Обучение минимальное благодаря сохранению UX:

  • Конечные пользователи (покупатели): обучение не требуется — интерфейс интуитивно понятен
  • Операторы колл-центра: 1–2 часа — знакомство с новым интерфейсом
  • Менеджеры по работе с партнёрами: 2–4 часа — новые функции кабинетов продавцов
  • Администраторы: 1 день — новые возможности админ-панели

Документация и видео-инструкции предоставляются в рамках этапа W6.

Сколько сейчас тратится на инфраструктуру? Снизятся ли расходы?

Ответ:

Показатель Сейчас (legacy) После (Витрина)
Инфраструктура в месяц ~500 000 руб. ~150–200 000 руб.
Утилизация ресурсов ~35% 68–85%
Масштабирование Ручное Автоматическое
Время простоя при релизах Часы 0 (Canary/Blue-Green)

Экономия: более 50% на инфраструктуре ежемесячно.

При масштабировании затраты растут нелинейно — платформа работает как SaaS с горизонтальным масштабированием. Затраты зависят от притока новых покупателей, а не от количества магазинов в каталоге. Рост составляет несколько процентов от базовых затрат на каждые 10 000 новых пользователей.

Гипермаркеты уже согласны на подключение?

Ответ: В текущей legacy-системе уже работают гипермаркеты-партнёры. Модель предполагает:

  • Существующие гипермаркеты переходят на новую платформу автоматически при миграции
  • Дополнительные гипермаркеты подключаются через модель DBS на этапах W7–W9
  • Процесс подключения нового партнёра: 2–4 недели (контрактирование + техническая интеграция)

Точный список и статус согласований — требует уточнения у заказчика.

Нужны ли новые сотрудники для новой платформы?

Ответ: Штатное расписание не требует кардинального расширения:

  • Существующая команда Аксиомы продолжает поддержку (не требуется найм)
  • DevOps/SRE — возможно потребуется 1 специалист для масштабирования
  • Support — рост обращений пропорционален росту платформы (найм по необходимости)

Основной рост команды происходит в рамках проекта (10–12 человек), после завершения этапов W1–W3 команда сокращается до поддерживающего состава (4–6 человек).

14.4. Вопросы от госструктур

Где хранятся данные пользователей? Соответствие 152-ФЗ?

Ответ: Да, соответствует 152-ФЗ «О персональных данных»:

  • Хранение данных: сервера на территории РФ (возможно использование Yandex Cloud, SberCloud или собственные дата-центры)
  • Локализация: все персональные данные граждан РФ хранятся в РФ
  • Обработка: согласие на обработку получено при регистрации, политика конфиденциальности размещена на сайте
  • Шифрование: данные в покое (at rest) и в транзите (in transit) шифруются
  • Права субъектов: реализована возможность удаления, изменения данных по запросу

Для соответствия проводится оценка соответствия и регистрация в Роскомнадзоре.

Как интегрированы с ФНС? Онлайн-кассы?

Ответ: Интеграция с онлайн-кассами реализуется двумя способами:

  1. Для партнёров с собственной кассой: - API для передачи данных о чеке в свою ККТ - Партнёр самостоятельно заключает договор с ОФД

  2. Для партнёров без кассы (опционально): - Встроенная интеграция с облачными ККТ (54-ФЗ) - Автоматическая генерация и отправка чеков в ОФД - Подключение через партнёрские решения (например, СберКасса, Эвотор)

Передача данных в ФНС соответствует требованиям 54-ФЗ.

Курьеры — сотрудники или подрядчики?

Ответ: Платформа не является работодателем курьеров:

  • Курьеры — это сотрудники или подрядчики партнёров (ритейлеров, служб доставки)
  • Платформа выступает агрегатором (в соответствии с 272-ФЗ о агрегаторах)
  • Ответственность за трудовые отношения несёт партнёр (служба доставки, ритейлер)

Для заказчика: - При использовании собственной службы доставки — курьеры в штате или подрядчики заказчика - При подключении внешних служб (СДЭК, Яндекс, такси) — их сотрудники

Какой налоговый режим применяется?

Ответ: Налоговый режим определяется организационно-правовой формой заказчика:

  • Возможные режимы: ОСНО, УСН, НПД (самозанятость для ИП)
  • НДС: при ОСНО — 20%, при УСН — не облагается
  • Налог на прибыль: 20% (ОСНО) или 15% (УСН «Доходы минус расходы»)

Для партнёров-продавцов платформа может работать как: - Агрегатор (272-ФЗ) — без обязанности удерживать НДФЛ - Маркетплейс — в зависимости от условий договора

Точная схема требует юридического проектирования под конкретную структуру.

Интеграция с системой Честный ЗНАК (маркировка)?

Ответ: Да, интеграция предусмотрена:

  • Для маркированных товаров (обувь, лекарства, табак и др.):
  • Проверка маркировки при сканировании
  • Выбытие из оборота в системе

  • Отправка данных в Честный ЗНАК

  • Реализация:

  • API-интеграция с ГИС МТ
  • Обработка ошибок (недействительные коды, повторный ввод)

  • Логирование для проверок

  • Для партнёров: при подключении маркированного товара — обязательная интеграция с Честный ЗНАК

Какие лицензии нужны для работы платформы?

Ответ: Основные лицензии и разрешения:

Лицензия/разрешение Для чего Статус
Лицензия на телематические услуги хостинг При необходимости
Регистрация в Роскомнадзоре обработка ПДн Требуется регистрация
Договор с ОФД онлайн-кассы Для партнёров с кассой
Лицензия ФСБ (КриптоПро) шифрование Опционально
ЭЦП документооборот Требуется для отчётности

Торговля без лицензий: собственно платформа не осуществляет торговлю — она предоставляет инфраструктуру партнёрам. Лицензии на торговлю требуются партнёрам-продавцам.

Версия: 1.1 Дата: Май 2026 г.