Как за 2,5 месяца запустить масштабируемый e‑commerce MVP без ТЗ: технические и организационные лайфхаки

Запустить e‑commerce MVP за 2,5 месяца без технического задания — амбициозная задача. Особенно если проект масштабируемый, с интеграциями, каталогом и реальными пользователями. В этом материале — разбор реального кейса от Altо: как команда справилась с отсутствием ТЗ, синхронизировала 50 человек и за 10 недель вывела на рынок работающий сервис. Мы разберём, какие технические решения ускорили запуск, а какие могли его сорвать — и какие уроки можно применить в других проектах.

Скорость запуска — критический фактор для стартапов, особенно предлагающих уникальные решения без аналогов. Долгая разработка увеличивает риск упустить нишу и проиграть конкурентам.

Smarta — как работает подписка на смартфоны и почему это сложно

Подписка на смартфон — это не рассрочка и не trade‑in. В сервисе Smarta пользователь платит 60–70% стоимости устройства сразу, пользуется им 1–2 года, а по окончании срока решает: доплатить остаток и оставить телефон или вернуть его, не переплачивая. Это гибрид владения и аренды — удобно, но сложнее с точки зрения логики, чем классический e‑commerce. При этом сервис «наследует» логику интернет‑магазина, в нем есть каталог, фильтры, оформление заказа, личный кабинет.

Главная инженерная задача — точно оценивать и управлять остаточной стоимостью устройства. Она зависит от:

• срока использования;
• состояния телефона (по данным диагностики);
• рыночного спроса на конкретную модель;
• сезонных колебаний цен.

Эта логика должна быть заложена в систему учёта (в данном случае — 1С), а также синхронизирована с интернет‑магазином, личным кабинетом и CRM. При возврате устройства система автоматически рассчитывает, сколько пользователь уже «амортизировал», и предлагает следующие шаги: доплата, замена на новый или выход из подписки.

Как управлять 50 разработчиками без ТЗ: принципы координации в условиях неопределённости

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

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

Инфраструктура до первой строчки кода: как подготовились к разработке, чтобы её ускорить

Автоматизация поможет сэкономить время и силы в дальнейшей работе, поэтому мы начали подготовку заранее. Сделали подготовительные работы, подключили необходимые библиотеки и собрали докер.

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

Swagger — это документация, которая показывает, какие функции есть у сервиса, как с ним взаимодействовать и какие данные он принимает и возвращает.

Мы договорились, что Swagger будет автоматически собираться прямо из комментариев в коде. То есть разработчик пишет код и сразу указывает, как его использовать — и всё это сразу появляется в интерфейсной документации.

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

Pipeline — это автоматическая цепочка шагов, которые выполняются каждый раз, когда кто‑то вносит изменения в код. Мы добавили в эту цепочку проверку того, что Swagger собирается.

Эти шаги помогли ускорить процесс разработки и минимизировать количество ошибок на ранних этапах.

Ключевые технические решения: как внедряли сложные интеграции, когда сроки были ограничены

Чтобы система работала стабильно и могла расти, мы выбрали несколько ключевых решений. Решения были выбраны так, чтобы минимизировать нагрузку на фронтенд, ускорить работу с данными и гарантировать точность информации о товарах.

Интеграция с мастер‑системой через REST API. В качестве мастер‑системы использовалась 1С — центральный источник данных о товарах, ценах и остатках. Именно она выступала основой для всех остальных сервисов, включая интернет‑магазин.

Задача состояла в том, чтобы обеспечить быстрый и надежный механизм получения изменений. Для этого мы спроектировали REST API, который позволяет обмениваться данными между сервисом и 1С. Вся контентная часть товаров, цены и остатки полностью управляются на стороне 1С, а наша задача — корректно их получать и использовать.

Еще одной деталью стало группирование товаров по наличию и приоритету («склейки» и «полусклейки»). Это позволило сделать каталог более понятным и удобным для пользователя: посетитель видел возможные варианты определенного девайса и сразу понимал, доступен ли он.

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

Мы хотели, чтобы интерфейс реагировал мгновенно, без лишних запросов к серверу. Чтобы достичь этого, мы подготовили данные на стороне сервера. Backend формирует полный список доступных опций для переключателей, что позволяет Frontend не делать лишние запросы.

Для хранения характеристик товара мы структурировали в парадигме бесконечного ENUM, то есть расширяемый список значений — например, цвет, память, модель. У каждой опции список представляет собой динамически наполняемый справочник. Это решило проблему реализации фильтров в каталоге и упростило отображение доступных комбинаций опций в карточке товара.

Так, пользователь может выбрать нужные параметры мгновенно, без задержек. Алгоритм строится на предварительном формировании всех возможных комбинаций торговых предложений, из которых фронтенд «понимает», какое предложение подходит, и какие опции доступны.

Не все каталоги подходят для такого решения. Этот подход хорошо работает, когда: количество комбинаций характеристик ограничено (например, цвет + память) и все возможные варианты можно заранее загрузить целиком на фронтенд. Но если у товара десятки или сотни параметров, то это сильно замедлит загрузку страницы.

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

Такое решение не универсально, плюс требует согласованности между фронтендом и бэкендом. Чтобы механизм работал, нужно:

• подготовить данные на бэкенде в нужной структуре;
• убедиться, что фронтенд умеет их корректно интерпретировать;
• постоянно синхронизировать логику между частями системы.

Это требует высокой слаженности команд, чего часто нет в больших проектах или при работе с legacy‑системами. Если применять его бездумно, оно может усложнить систему вместо упрощения.

Другие решения: опыт в создании удобного интерфейса для пользователя

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

Личный кабинет: всё в одном месте. Личный кабинет был спроектирован так, чтобы все ключевые действия были доступны в один клик. Информация о статусах договоров, платежей и доставок собрана в одном разделе. Такой подход упростил навигацию и сократил время на выполнение задач.

Использование экосистемы Ensi

Для ускорения разработки использовали open‑source экосистему Ensi — платформу для e‑commerce, где уже реализованы типовые решения по каталогам, интеграциям и управлению товарами. Это позволило избежать изобретения велосипеда и сосредоточиться на уникальной логике подписки.

Результат

MVP Smarta запустили за 2,5 месяца — амбициозный срок для e‑commerce с интеграциями, каталогом и бизнес‑логикой подписки. Сервис выдерживает нагрузку до 200 пользователей в секунду, что достаточно для старта. Ключевая сложность — не в интерфейсе, а в системе управления активами: каждый смартфон имеет остаточную стоимость, зависит от срока использования и рыночной ситуации. Чтобы модель работала, нужно наладить обмен данными между магазином, учётом и личным кабинетом.

Что помогло уложиться в сроки и избежать срыва сроков и ошибок:

1. Swagger как живая документация: API автоматически генерировались из кода, что позволило командам согласовывать интерфейсы до начала разработки.
2. Подготовка данных на бэкенде: в карточке товара все возможные комбинации (цвет, память) загружались целиком — это исключило задержки при переключении опций.
3. Автоматизация с первого дня разработки: Docker для локальной разработки, проверка документации и тестов.
4. Чёткие границы ответственности: каждая команда работала автономно, но по согласованным контрактам. Техлиды встречались регулярно, чтобы избежать дублирования.
5. Использование готовых решений: для ускорения разработки были использованы наработки из open‑source экосистемы Ensi, которые были адаптированы под конкретные задачи проекта.

Проект реализован силами нескольких внешних команд и внутренней команды заказчика. Главное — удалось выстроить прозрачную коммуникацию и общее понимание целей. Сейчас сервис работает, а команда собирает данные для его масштабирования.