Тендеры и лиды
Информация
Честная история проекта Фри Тайм: почему мы начали с базы данных, когда макетов ещё не было, как держали в связке бэкенд и фронтенд и успели в жёсткий дедлайн.
В идеальной картине мира разработка идёт по цепочке: аналитика, прототипы, дизайн, код, тесты, запуск. Всё размеренно, шаг за шагом, с запасом по времени. Но реальность почти всегда другая. Особенно когда речь не о стартапе с чистого листа, а о срочной переделке уже работающего бизнеса.
В этом материале — откровенный разбор одного из наших проектов: создание коммерческого сайта для сети ресторанов Фри Тайм. Мы попали в ситуацию, где бэкенд пришлось поднимать до того, как дизайн был утверждён. Расскажем, как так получилось, на какие риски мы пошли и как выстроили процессы, чтобы за два месяца выдать результат без потери качества.
Фри Тайм — это сеть из трёх ресторанов в Благовещенске. Старая платформа на PHP/Laravel работала плохо: меню между точками путалось, онлайн-заказ клиенты оформить не могли и просто звонили операторам. Бизнесу требовалась не косметика, а полная пересборка каталога и автоматизация приёма заказов. И всё это в очень сжатые сроки — около двух месяцев.
Если бы мы сидели и ждали готового дизайна, проект растянулся бы куда дольше. Поэтому решили действовать иначе: бэкенд запускаем сразу, а дизайн с фронтендом идут параллельно, чуть позади.
Схема нестандартная и несёт понятные опасности:
Интерфейсы могут не сойтись. Бэкенд рискует сделать API, которым на фронтенде пользоваться неудобно или попросту невозможно.
Модель данных может не попасть в задачу. Без визуальной картины легко пропустить нужные поля или наоборот — заложить лишнее.
Вероятность переделок. Если дизайн по ходу поменяет ключевые сценарии, часть бэкенда придётся переписывать.
Сложнее договариваться. Когда две команды пилят разные слои одновременно, цена недопонимания сильно возрастает.
Мы не прятались от этих рисков, а приняли их осознанно и построили процессы так, чтобы держать всё под контролем.
1. Модель данных стала фундаментом
Мы не стали дожидаться макетов, а оттолкнулись от бизнес-логики. У нас был старый сайт — кривоватый, но он описывал предметную область: рестораны, категории, блюда, добавки, корзина, зоны доставки.
Бэкенд-команда начала с проектирования данных. Мы не думали про кнопки и формы, а описывали сущности и их связи:
У ресторана есть категории меню.
В категории лежат блюда.
У блюда могут быть модификаторы — добавить или убрать ингредиент.
Заказ привязан к конкретному ресторану и способу получения: доставка или самовывоз.
Такой фундамент не зависел от итогового дизайна. Когда макеты были готовы, фронтенду оставалось просто «надеть» интерфейс на уже живую логику.
2. Чёткие договорённости по API
Пока бэкенд проектировал модели, мы вместе составили предварительный контракт API — список эндпоинтов и структуры данных, которые понадобятся фронтенду. Дизайнер и фронтенд-разработчик могли стартовать без готового бэка, просто ориентируясь на эти контракты.
Например, заранее договорились:
Эндпоинт /api/restaurants/{id}/menu отдаёт список категорий с блюдами.
Ответ содержит поля id, name, price, modifiers.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13507 тендеров
проведено за восемь лет работы нашего сайта.
Модификаторы бывают двух видов: exclude и add.
Когда бэкенд реализовал эти точки, фронтенд уже был готов их подхватить с минимумом правок.
3. Постоянная синхронизация вместо водопада
Мы не ждали, пока бэкенд будет готов целиком. Как только появлялся первый работающий эндпоинт, фронтенд сразу к нему подключался и начинал отрисовку. Это помогало ловить нестыковки на ранних этапах и править либо API, либо вёрстку без глобальных перекроек.
Пример: при реализации кастомизации блюд выяснилось, что для модификаторов типа «добавить ингредиент» мало названия и цены — нужно ещё ограничение по максимуму. Нельзя же добавить бесконечный сыр. Бэкенд быстро дополнил модель, и фронтенд тут же это забрал.
4. Менеджер как связующее звено
В таких проектах на первый план выходит проджект-менеджер, который понимает и бизнес, и технику. У нас менеджер работал как буфер и синхронизатор:
● Переводил бизнес-требования на язык разработки для бэкенда.
● Объяснял дизайнеру технические рамки, чтобы макеты не шли вразрез с уже заложенной моделью.
● Следил, чтобы у команд не расходилось понимание ключевых сценариев.
Вот как сама Наталья Жосан, менеджер проекта, описывает этот опыт:
«Когда бэкенд ушёл вперёд, моей главной задачей было не дать командам разойтись в понимании того, что мы вообще строим. Мы не могли себе позволить ситуацию, когда дизайнер нарисовал красиво, а разработчик ответил: "У меня в API такого поля нет". Поэтому я фактически жила в двух контекстах: утром обсуждала с бэком структуру модификаторов, днём объясняла дизайнеру, почему нельзя просто так добавить анимацию, которая ломает всю логику добавления ингредиентов. Когда все понимают не только "что делать", но и "зачем", даже параллельная работа без макетов становится управляемой».
Благодаря такому подходу мы уложились в два месяца — срок, который поначалу казался заказчику нереальным. Что получили на выходе:
● Каталог полностью пересобран и готов к росту: новые рестораны добавляются через админку.
● Онлайн-заказы автоматизированы.
● Внедрены механики кросс-сейла и кастомизации блюд для увеличения среднего чека.
Заказчик остался доволен. На момент сдачи он ещё наполнял сайт контентом, а платформа уже работала как часы.
Многие студии любят рассказывать только про гладкие проекты, где всё шло по учебнику. Мы считаем иначе. Работать в условиях ограничений, осознанно принимать риски и выстраивать параллельные процессы — это и есть настоящий профессионализм.
Опыт Фри Тайм подтвердил: если архитектуру данных строить от бизнес-логики, а не от макетов, она получается крепкой и легко расширяемой. А прозрачные контракты по API плюс постоянная синхронизация позволяют фронтенду и бэкенду идти параллельно без потерь в качестве.
Мы применяем этот подход в разработке сайтов со сложной начинкой — будь то сеть ресторанов, маркетплейс или корпоративный портал. Потому что живой бизнес редко ждёт идеальных условий.
