Разработка сервиса "Экспресс-меню" Азбуки Вкуса

Цель — запустить в Москве и Санкт-Петербурге сервис доставки готовой еды от "Азбуки Вкуса". У "Азбуки Вкуса" своя кухня высокого качества, блюда перед запуском сервиса продавались только офлайн. Требовалось создать новые процессы и интерфейс к запуску продаж в онлайне, а еще интегрировать эти процессы в основные бизнес-системы компании.

AIC спроектировали UX и дизайн, Trinity собрали мобильное приложение, коллеги из Азбуки Вкуса занялись анализом и проектированием процессов, а мы в wpp.digital взялись за всю техническую часть проекта — платформа, REST-API, сайт, интеграции, тестирование, мониторинг, тестирование отказоустойчивости etc.

Для управления проектом мы выбрали комбинированный подход — взяли одну часть из методологий PMI, другую — от Agile Scrum. Дальше сделали план из ~500 высокоуровневых задач, где отразили основные вехи, сроки.

Мы принимали и до сих пор принимаем как аксиому тот факт, что первые, а часто любые версии плана — гипотеза. Реальный ход развития всегда вносит корректировки, и это хорошо. Как раз это и отличает разработку софта от возведения мостов. План — опора в принятии решений. Из него понятно, как изменения будут влиять на сроки/стоимость/объем.

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

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

1. задачу никто не решил;

2. ее решили все одновременно и по-разному.

Мы выбрали подходы тонкого клиента на front-end-е и бизнес-логики на back-end-е. Это значит, что:

> сайт и мобильные приложения только отображают данные, а не принимают бизнес-решения;

> API — это транспорт для интеграций;

> платформа — это логика и интеграции.

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

Теперь посмотрим под капот. Внутри сервис спроектирован из разных узлов — веб-серверы, система поиска, базы данных, планировщики, кеши etc. И для каждого нужно:

> резервирование — когда выходит из строя основной сервер, нужно прозрачно переключиться на резервный;

> бекап и быстрое восстановление.

В обязательном порядке заложили возможность мониторинга узлов проекта и логирование всех событий. Теперь мы могли понимать, что происходит в каждом узле большой системы: обнаруживать неисправности, понимать, где они, и оперативно их исправлять. Подключили систему мониторинга, которая в реальном времени сообщала, когда что-то на проекте идет не так. Например, вызов API отвечает дольше, чем мы определили в SLA, или заказы отгружаются в систему учета более положенного времени.

Для удобства разделили мониторинг технических показателей серверов и мониторинг бизнес-активности проекта, чтобы ошибки сразу распределялись по релевантным отделам. Так статусы резервного копирования, метрики баз данных и веб-серверов оказались на плечах команды админов, а вся информация о бизнес-показателях на команде поддержки проекта. Последние получали оповещения по E-mail и СМС-каналам.

Так каждое бизнес-событие стало логироваться. Каждую проблему пользователя мы могли детально изучить и после решить.

Быстрые, полезные и вкусные блюда, заказать которые можно через разные каналы. Мы  создали платформу, сайт, интегрировали нужные системы, а после тестировали, мониторили, а потом еще раз тестировали.

Для партнерский сервисов Delivery Club и "Яндекс.Еда" разработали интеграционные API. Теперь партнеры работают с реальными остатками и ценами.