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

В этой статье — честный разбор одного из наших проектов: разработка коммерческого сайта для сети ресторанов Фри Тайм. Мы оказались в ситуации, когда бэкенд пришлось запускать до утверждения дизайн-макетов. Рассказываем, почему так вышло, какие риски мы осознавали и как выстроили процесс, чтобы уложиться в два месяца и не потерять в качестве.

Полный кейс можно прочитать по ссылке: Кейс Фри Тайм: разработка коммерческого сайта для сети ресторанов с пересборкой архитектуры и автоматизацией заказов

Фри Тайм — сеть из трёх ресторанов в Благовещенске. Старый сайт на PHP/Laravel путал меню между точками, клиенты не могли оформить заказ онлайн и звонили операторам. Бизнесу требовалось не «освежить дизайн», а пересобрать архитектуру каталога и автоматизировать приём заказов. Срок — максимально сжатый — около двух месяцев. Если бы мы ждали готовности дизайна, проект растянулся бы на гораздо больший срок.

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

Такой подход нестандартен и несёт очевидные угрозы:

• Рассогласование интерфейсов. Бэкенд может спроектировать API, которое неудобно или невозможно использовать на фронтенде.
• Избыточная или недостаточная модель данных. Без понимания визуальной логики можно упустить важные поля или, наоборот, заложить лишнее.
• Двойная работа. Если дизайн в процессе изменит ключевые сценарии, часть бэкенда придётся переписывать.
• Сложность коммуникации. Когда две команды работают параллельно над разными слоями, цена ошибки взаимопонимания возрастает.

Мы не закрывали глаза на эти риски. Мы осознанно приняли их и выстроили процесс так, чтобы ими управлять.

1. Архитектура данных как источник истины

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

Бэкенд-команда начала с проектирования модели данных. Мы не привязывались к конкретным кнопкам и формам, а описывали сущности и связи между ними:

• Ресторан имеет множество категорий меню.
• Категория содержит блюда.
• Блюдо может иметь модификаторы (добавление/исключение ингредиентов).
• Заказ привязан к ресторану и способу получения (доставка или самовывоз).

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

Позже эта же модель данных позволила нам добавить гибкое управление зонами доставки: владелец сам рисует полигоны на карте и назначает цены в админ-панели. Как именно это работает, читайте в статье «Зоны доставки полигонами: почему Яндекс.Карты в админке выгоднее, чем фиксированный радиус»

2. Чёткое разделение зон ответственности и контрактов API

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

Например, было заранее согласовано:

• Эндпоинт /api/restaurants/{id}/menu вернёт список категорий с блюдами.
• Структура ответа будет содержать поля id, name, price, modifiers.
• Модификаторы делятся на два типа: exclude и add.

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

3. Итеративная синхронизация, а не «водопад»

Мы не ждали полной готовности бэкенда, чтобы начать фронтенд. Как только появлялся первый рабочий эндпоинт, фронтенд сразу подключался к нему и начинал отрисовку. Это позволило выявлять несоответствия на ранних этапах и корректировать либо API, либо вёрстку без глобальных переделок.

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

4. Роль менеджера как «переводчика» между слоями

В таких проектах критически важна роль проджект-менеджера, который понимает и бизнес-логику, и технические ограничения. В АЙТИФОКС менеджер проекта выступал буфером и синхронизатором:

• Транслировал бэкенду бизнес-требования, извлечённые из старых процессов и обсуждений с заказчиком.
• Объяснял дизайнеру технические ограничения, чтобы макеты не противоречили уже заложенной модели данных.
• Следил за тем, чтобы команды не «разъезжались» в понимании ключевых сценариев.

«Когда бэкенд ушёл вперёд, моей главной задачей стало не дать командам разойтись в понимании того, что мы вообще строим. Мы не могли себе позволить ситуацию, когда дизайнер нарисовал красиво, а разработчик ответил: "У меня в API такого поля нет". Поэтому я фактически жила в двух контекстах: утром обсуждала с бэком структуру модификаторов, днём объясняла дизайнеру, почему нельзя просто так добавить анимацию, которая ломает всю логику добавления ингредиентов. Когда все понимают не только "что делать", но и "зачем", даже параллельная работа без макетов становится управляемой» - Наталья Жосан, менеджер проекта АЙТИФОКС

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

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

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

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

Многие агентства предпочитают рассказывать только о «гладких» проектах, где всё шло по плану. Мы в АЙТИФОКС считаем иначе. Умение работать в условиях ограничений, принимать взвешенные риски и выстраивать параллельные процессы — это и есть зрелость команды.

Опыт Фри Тайм подтвердил: архитектура данных, спроектированная от бизнес-логики, а не от макетов, оказывается устойчивой и масштабируемой. А чёткие контракты API и итеративная синхронизация позволяют фронтенду и бэкенду работать параллельно без потери качества.

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