Подробный контекст проекта «Витрина»

1. Стратегические цели и описание проекта

Проект «Витрина» представляет собой платформу электронной торговли, предназначенную для полной замены монолитной системы и её федерального масштабирования. Платформа объединяет гипермаркеты, локальные магазины и производителей через две ключевые модели: DBS (Direct-to-Business) и маркетплейс-витрину для малых продавцов.

Основные стратегические цели проекта включают запуск нового клиентского приложения с перенесённым на 100% текущим функционалом оформления заказов в течение первых трёх месяцев, создание единой экосистемы для подключения партнёров, разработку продвинутого модуля логистики для оптимизации работы сборщиков, курьеров, таксистов и пунктов выдачи, а также снижение операционных затрат на инфраструктуру с обеспечением предсказуемой экономики роста стоимости обработки транзакций при федеральном масштабировании.

Ключевое конкурентное преимущество проекта — стоимость значительно снижена за счёт использования живой (работающей) legacy-системы как основы. Это позволяет перевести всю текущую аудиторию на новую платформу в кратчайший срок без потери функциональности и с минимизацией рисков миграции.

Срок реализации составляет 12 месяцев с поэтапным делением на волны W1–W12. Критическая веха М3 наступает на третий месяц — полноценный релиз версии 1.0 нового клиентского приложения с полным переносом рабочего функционала заказов из гипермаркетов и запуск пилотной эксплуатации в Санкт-Петербурге.

2. Участники и зоны ответственности

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

Выделенная продуктовая команда «Витрина» выполняет архитектурное проектирование, разработку нового ядра и клиентских приложений, реализацию модулей доставки и маркетплейса, настройку инфраструктуры, CI/CD и observability, проведение тестирования и обеспечение релизов. Внешние партнёры и вендоры поставляют платёжные шлюзы, агрегаторы доставки, ритейл-сети по модели DBS, при этом интеграция осуществляется через стандартизированные адаптеры с соблюдением контрактных обязательств и SLA.

3. Технологический стек и архитектура

Бэкенд платформы строится на двух языках: PHP 8.x (последняя стабильная версия) с совместимыми фреймворками для бизнес-логики, административных панелей, управления каталогом и витриной; Go 1.23+ (последняя стабильная версия) для высоконагруженных сервисов, модуля доставки, real-time вычислений и внешних интеграций. Фронтенд использует Vue.js 3 с сборщиком Vite, управлением состоянием Pinia и строгой типизацией TypeScript. Единая дизайн-система применяется для клиентского приложения и личных кабинетов.

Хранение данных осуществляется через PostgreSQL для горячих операционных транзакций и каталогов, Redis для кэширования сессий, очередей и частых запросов, ClickHouse или секционированный PostgreSQL для холодного хранения, аналитики, логов и исторических данных. Разделение OLTP и OLAP потоков исключает блокировку транзакций отчётными выборками.

Инфраструктура построена на контейнеризации Docker, оркестрации Kubernetes, инфраструктуре как код Terraform, GitOps-подходе и GitLab CI/CD. Событийная шина Kafka обеспечивает асинхронное взаимодействие микросервисов и интеграций. Наблюдаемость реализуется через Prometheus, Grafana, ELK, Sentry и OpenTelemetry.

Архитектурные границы определяются строгим разделением доменов, API-first подходом, отсутствием прямых зависимостей от legacy-кода. Все внешние подключения изолированы через адаптеры с circuit-breaker механизмами. Ядро системы не содержит жёстко закодированных бизнес-правил под конкретный регион или бренд — все региональные параметры вынесены в конфигурационные профили.

4. Детальная дорожная карта

Волна W1–W3 охватывает фундамент архитектуры, разработку клиентского канала, ядра заказов, миграцию данных и выпуск релиза. Этап W1 (Фундамент: реверс-инжиниринг и архитектура) направлен на формирование технического и аналитического фундамента: аудит legacy-кода, выявление бизнес-логики, проектирование архитектуры, развёртывание инфраструктуры, разработка стратегии миграции с двойной записью.

Этап W2 (Клиентский канал и ядро заказов) включает разработку нового клиентского приложения, перенос функционала оформления заказов, интеграцию с платёжными шлюзами, настройку взаимодействия с системами гипермаркетов.

Этап W3 (Релиз v1.0 и запуск в Санкт-Петербурге) обеспечивает миграцию данных, финальное тестирование, развёртывание в production, запуск пилотной эксплуатации.

Волна W4–W6 охватывает витрину продавцов и производителей, продвинутый модуль доставки, стабилизацию, аудит безопасности, подготовку интеграционных шаблонов. Этап W4 добавляет маркетплейс-модуль для малых магазинов и производителей. Этап W5 реализует продвинутый модуль логистики с алгоритмами роутинга, интеграцию с курьерскими службами и пунктами выдачи. Этап W6 проводит стабилизацию, аудит безопасности, оптимизацию производительности, подготовку к интеграциям.

Волна W7–W9 фокусируется на подключении ритейл-партнёров по модели DBS, нагрузочной валидации адаптеров, запуске мультибрендового пилота. Волна W10–W12 обеспечивает масштабирование на города-миллионники, аналитическую оптимизацию, развитие партнёрского API, итоговую оценку готовности к федеральному тиражированию.

5. Инфраструктура и экономика

Текущие затраты на инфраструктуру составляют около 500 000 рублей в месяц с утилизацией не более 35% и высокой стоимостью обработки транзакций. Целевая инфраструктура на контейнеризированной оркестрации снижает начальные затраты до 150–200 тысяч рублей в месяц, обеспечивает автоматическое горизонтальное и вертикальное масштабирование, нулевое время простоя при релизах через Canary или Blue-Green стратегию, линейную модель роста затрат при увеличении трафика.

Ожидаемый экономический эффект включает сокращение операционных расходов более чем в два раза на стартовом этапе, снижение удельной стоимости обработки заказа на 40–60% при федеральном масштабе, предсказуемую аналитику стоимости единицы транзакции.

6. Конкурентные преимущества и рыночная возможность

Платформа формирует защищённую бизнес-модель через три ключевых фактора. Первый — гибридная модель DBS плюс маркетплейс малых магазинов создаёт многостороннюю сеть эффекта: чем больше продавцов подключено к витрине, тем шире ассортимент и выше частота заказов пользователей. Второй — конфигурационно-управляемая архитектура позволяет запускать город за 1–3 дня без изменения ядра системы. Третий — продвинутый модуль логистики с собственными алгоритмами роутинга и ETA формирует операционное преимущество с точностью прогнозов выше 95%.

Рынок онлайн-доставки продуктов в РФ демонстрирует устойчивый рост. TAM (общий объём рынка) оценивается в сотни миллиардов рублей ежегодно. SAM (адресуемый сегмент) для модели DBS и маркетплейса составляет десятки миллиардов рублей в год. SOM (реалистично доступный рынок) на горизонте двух лет оценивается в 900 миллионов — 1,5 миллиарда рублей в пиковый сезон при федеральном масштабировании на 15 городов.

7. Бюджет и финансовая модель

Общий бюджет проекта составляет 52 000 000 рублей (фиксированный CAPEX). Распределение: команда разработки — 61,8%, инфраструктура и лицензии — 10,0%, интеграции и адаптеры — 8,2%, QA, безопасность и аудит — 5,9%, UX, документация и передача знаний — 4,7%, резерв на риски — 9,4%.

Принципы контроля включают еженедельный трекинг burn-down rate, ежемесячный финансовый ревью с заказчиком, stage-gate финансирование, автоматические алерты при отклонении cloud-расходов более 10% от плана. Изменение скоупа допускается только через формализованный процесс с пересчётом влияния на бюджет и сроки.

8. Метрики успеха и критерии приёмки

Технические метрики: SLO 99,5%, 10 000 RPS при нагрузочных тестах, время отклика менее 200 мс, снижение стоимости транзакции на 40–60% vs legacy, успешные fallback-механизмы интеграций, отсутствие критических уязвимостей после внешнего аудита.

Бизнес-метрики: подключение нового города за 1–3 дня, захват существующей клиентской базы в Санкт-Петербурге, конверсия новых пользователей через расширение ассортимента и улучшение UX, линейный рост затрат при увеличении географии.

Методология: Agile-спринты по две недели с обязательными Stage-Gate ревью на границах волн. Любое изменение сроков или скоупа требует согласования через Change Request Board.