{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Как разработать приложение доставки in-house: опыт экспресс-доставки Перекрёстка

Доставка «Перекрёстка» за 60 минут работает с 2020 года. За это время мы прошли путь от маленького продукта внутри foodtech-экосистемы до сервиса, который обработал уже 15 миллионов заказов. В новой статье раскроем закулисье работы IT-команды: как реализуется продуктовый подход на деле и какие вызовы диктует отрасль.

Пара слов о приложении

Для приложения экспресс-доставки мы выбрали нативную, а не кросс-платформенную разработку, то есть работали отдельно над запуском на платформах iOS и Android. Этот подход требует много времени, но позволяет реализовать весь технологический потенциал разных операционных систем. Благодаря этому, мы смогли предложить пользователям больше инструментов внутри приложения.

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

Мы делали особый акцент на мобильных версиях экспресс-доставки. По статистике, бизнес-показатели вроде конверсии и повторных покупок у пользователей приложений выше, чем у пользователей сайтов. Чем проще и удобнее интерфейсы, тем больше это привязывает потребителя и влияет на возвратность. В работе придерживались (и продолжаем придерживаться) продуктового подхода — то есть ориентировались прежде всего на конечного пользователя и то, как он взаимодействует с продуктом.

Работа команды строится на трех китах: люди, процессы и технологии. Эти составляющие едины для всех технологичных продуктов внутри Х5. Так, к примеру, в структуру сервиса мы интегрировали и дополнительные фичи, например, экспресс скан Х5 и Х5 ID, который упрощает клиентам авторизацию во всех личных кабинетах группы и партнёров (Пятёрочка, Перекрёсток, Карусель, ОКОЛО, 5Post, Vprok. ru и других).

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

Чтобы сайт и приложение отвечали всем бизнес-задачам, команда изучает всю предоставленную аналитику и ТЗ о требуемой функциональности, дизайне и даже референсы. Далее подбираются нужные технические решения, и мы разрабатываем системную архитектуру для разработки.

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

Как делать можно, но осторожно

На первом этапе мы работали в формате стартапа, не по спринтам, а по задачам. Задачи формулировались в процессе тестирований, запусков. Это сложно, но интересно.

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

Как точно не нужно делать

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

Потратив некоторое количество времени и нервов, мы с проблемой справились, но на будущее себе зарубку сделали: «Настраивайте аналитику непосредственно в процессе разработки фичи». Всем остальным рекомендуем поступать также.

Кто работает в команде экспресс-доставки?

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

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

В целом, для работы над таким объемом задач и функционала чаще всего требуется большая команда, разделение по платформам и блокам задач, привлечение сотрудников на аутсорсе.

Изначально коллектив легко мог уместиться в одно такси: специалист по iOS, специалист по Android, и, в компанию к ним — ответственный за backend-процессы

По мере появления дополнительных задач, состав команды увеличивался. Сегодня за разработку на Android отвечают 4 человека, над IOS работают 3 специалиста, а на backend-е 2 члена команды. Такси «выросло» до маршрутного, но мы по-прежнему можем легко в него уместиться!

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

Сейчас над продуктом сервиса экспресс-доставки работают несколько команд: маркетинг, аналитика, команда продукта (App и Web), техническая команда, клиентская поддержка и команда по управлению операционными процессами (сборка, доставка).

0
3 комментария
Алексей

Чтобы разгрузить свою команду, на поодержку можно нанять аутсорных разработчиков, чтобы высвободить ресурс https://gmi-group.ru/

Ответить
Развернуть ветку
Aimee Korinek

спасибо за статью!

Ответить
Развернуть ветку
Бип-блоп

«Для приложения экспресс-доставки мы выбрали нативную, а не кросс-платформенную разработку, то есть работали отдельно над запуском на платформах iOS и Android. Этот подход требует много времени, но позволяет реализовать весь технологический потенциал разных операционных систем»
Какие плюсы у нативной разработки сервиса доставки перед кроссплатформой?

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда