Фронтенд и бэкенд: с чего же начинается мобильное ecommerce-приложение

В этой статье расскажем, что такое бэкенд мобильного приложения и почему все его особенности важно учесть ещё на этапе планирования нового продукта.

• Что такое бэкенд, и какую роль он играет в e-commerce приложении
• Зачем на e-commerce проекте архитектор
• Сколько сервисов нужно подключить, чтобы всё заработало
• Кому доверить разработку бэкенда

Мы давно и плотно работаем с ритейлом, реализовали более 20 проектов с крупными игроками рынка: Ригла, Рив Гош, Лабиринт, Бетховен и другие. И заметили определённые закономерности, которые повторяются на старте многих проектов.

В большинстве случаев, уже на этапе планирования своего e-commerce продукта, многие компании понимают, какие фичи хотят видеть в мобильном приложении. У них даже есть UI-kit, который определяет его внешний вид. Но довольно часто на начальных этапах из виду ускользает кое-что очень важное — это «мозги» сервиса.

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

Такой бэкенд позволит:

• гибко добавлять новые возможности и развивать приложение;
• масштабировать проект;
• оперативно исправлять ошибки.

• Распределить функциональную ответственность.

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

Как это можно реализовать:

1 способ — сделать всё в разрабатываемом решении;

2 способ — вынести в сторонние специализированные системы.

Пример: в приложении нужно реализовать программу лояльности. Её можно разработать самостоятельно с нуля, а можно реализовать при помощи специализированной CRM. От выбранного пути будет кардинально зависеть оценка и план работ.

О том, как мы оцифровали программу лояльности для «Магнита», читайте в кейсе.

Какие подводные камни у каждого способа? У первого — придётся делать большой объём кастомной разработки, как следствие, это увеличит срок и стоимость проекта. Второй способ потребует интеграции с существующим решением. Сам этот способ нужно продумать и учесть уже на этапе планирования работ.

• Составить поэтапный план реализации, с проверкой гипотез между этапами:

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

Как можно реализовать? На этом этапе важна роль архитектора. Он обсуждает проект с владельцем продукта или менеджером. Исходя из ответов, составляет план развития проекта с разбивкой на укрупнённые этапы и более мелкие шаги. В результате, клиент получает роадмап технического развития своего проекта, а команда разработки понимает, что и в какой последовательности реализовывать.

Пример. В приложении нужно реализовать несколько фич:

• простой каталог товаров и офлайн оплату;
• систему сборки и трекинга заказов;
• добавить онлайн-оплату;
• внедрить систему лояльности.

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

• Предусмотреть изменения в бизнес-процессах при входе в e-commerce.

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

Как можно реализовать? Архитектор поможет спланировать, описать и внедрить новые процессы, а также предложит инструменты, которые помогут реализовать e-commerce проект с крепким фундаментом и возможностями для развития и масштабирования.

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

Что делает архитектор?

• Строит верхнеуровневый облик (концепт) приложения.
• Оценивает риски и возможные внеплановые изменения.
• Планирует необходимые интеграции.

Что это даёт проекту?

Понятный план развития проекта — Project Scope Statement. Этот документ описывает концепт решения, периметр работ, риски (и план их нивелирования), подход к ведению проекта и проектную команду.

Архитектор на этапе планирования проекта поможет:

• максимально переиспользовать существующую инфраструктуру. Это сэкономит ресурсы, и быстро выведет систему в работу. Как следствие, проект быстрее начнёт приносить прибыль.
• вынести типовой функционал в специализированные системы: настроить взаимодействие с контактами, программу лояльности и чат вынести в готовую систему CRM, управление контентом — в CMS, управление ресурсами — в ERP. Это сократит time-to-market проекта и стоимость, так как потребуется меньше кастомной разработки
• определить этапы внедрения: все компоненты нужно внедрять постепенно — когда в них возникает реальная потребность, а компания готова встроить их в свои бизнес-процессы. К примеру, нужно ли заказывать функцию сбора обратной связи от клиентов, если некому обрабатывать поток сообщений? Архитектор поможет определить первоначальный скоуп работ и составить роадмап развития проекта.

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

• Негатив от клиента из-за общепринятых подходов. Например, зачем с первых секунд запрашивать номер телефона, если пользователь просто хотел посмотреть каталог?

Как можно исправить? Мы в Surf придерживаемся подхода «инкрементального обогащения профиля». Пользователь становится клиентом сразу и автоматически, без регистрации и указания данных, какое-то время мы не знаем его телефон, имя и другие данные. Но как только объективно требуются его личные данные — телефон для подтверждения заказа, адрес для доставки, e-mail для получения спецпредложений и купонов — эти данные сохраняются в профиле. Так постепенно система «узнаёт» клиента, не вызывая у него раздражения ненужными вопросами. Его цифровой профиль пополняется постепенно за счёт информации, которая необходима для покупки.

• Не учитываются все возможные интеграции, которые будут нужны в приложении.

Как можно исправить? Разложить свой проект «по полочкам» с помощью Project Scope Statement, который поможет составить архитектор. Начиная с главной цели — увеличение прибыли или удержания клиентов, заканчивая самыми смелыми планами роста. Чем раньше разработчики узнают о планах и возможностях роста проекта, тем лучше. Это позволит им спланировать количество и способы интеграций с сервисами.

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

Как можно исправить? Отрефлексировать, какие цели стоят перед проектом: если приложение создаётся для изучения рынка или проверки гипотезы, интеграция с сервисами может быть избыточной. Протестировать новый канал продаж можно с минимальным набором функциональности или даже при помощи коробочного решения. В каких случаях достаточно «коробки», а когда не обойтись без кастомного решения читайте тут.

Чек-лист вопросов, которые вам точно задаст архитектор:

• Кто будет ответственным за использование разрабатываемой системы?
• Есть ли специалист, представляющий текущий ИТ-ландшафт проекта?
• Есть ли специалист, отвечающий за информационную безопасность?
• Есть ли системный администратор?
• Необходим ли перенос существующих данных из старых систем в новые?
• Как планируется реализовать сервисы уведомлений (SMS, Push, e-mail, и др.)?
• Предполагается ли использовать электронную цифровую подпись?
• Требуется ли сбор логов — записей о событиях в хронологическом порядке о работе системы?
• Какова предполагаемая номинальная/пиковая нагрузка на систему и динамика её роста?
• Есть ли существующая сетевая инфраструктура, которая отвечает за маршрутизацию и балансировку (включая отказоустойчивость), которую можно использовать для разрабатываемой системы?
• Какие есть ограничения на хранение и обработку персональных данных?
• Как планируется создавать линии технической поддержки?

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

• Группа №1. Сервисы аутентификации: к ним относятся все способы авторизации: Apple ID, учётная запись Google, возможность входа через соцсети.
• Группа №2. Сервисы уведомлений. APNS от Apple, GCM от Android, службы отправки через SMS и электронную почту.
• Группа №3. Платёжные сервисы: Apple и Google Pay, PayKeeper, ЮКасса, СБПей.
• Группа №4. Интеграция со службами доставки: например, ApiShip.
• Группа №5. Информационные сервисы для проверки адресов и загрузки чеков для аналитики (DaData и R_keeper).
• Группа №6. Системы для управления ресурсами компании (ERP), отношениями с клиентами (CRM), контентом (CMS).
• Группа №7. Системы взаимодействия с клиентами: интеграция программ лояльности, персональные предложения, геймификация.
• Группа №8. Системы пользовательской аналитики и отчётов: AppMetrica и Firebase.

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

• архитектору — для понимания перспектив проекта и помощи с возможными интеграциями;
• разработчикам — для прогнозирования и планирования скоупа работ;
• владельцу бизнеса — для понимания объёма работ.

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

Часто у компании, планирующей запустить своё мобильное приложение, уже есть интернет-магазин на сайте. Он интегрирован с программами складского учёта, в нём может быть реализована программа лояльности. А значит, уже есть команда бэкенда, которая этим занимается. В этом случае для интеграции мобильного приложения с имеющимся бэком мы используем middleware — связующее программное обеспечение, которое помогает приложению и серверу обмениваться запросами. С его помощью можно также реализовать интеграцию с любыми внутренними системами. Читайте подробнее о том, как это работает в нашей статье.

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

Какие плюсы у такого подхода?

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

За 12 лет мы не только поработали не с одним десятком успешных проектов, но и реализовали несколько проектов под ключ: мобильное приложение и бэкенд для него. Были и челленджи: например, когда мы реализовали бэкенд для высоконагруженного стримингового сервиса The Hole или для кастомной ERP-системы для KFC.

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

• Важен последовательный подход: выдвижение бизнес-требований → составление технического задания → реализация технического решения. После проектирования мы получаем скоуп работ и список фичей, который расставляем по приоритетам и воплощаем, начиная с самых востребованных.
• Помогает классика итерационного подхода — Agile. Берём фичу с самым высоким приоритетом и работаем по всем фронтам — от дизайна до бэкенда. При этом проектирование новой функционости также может продолжаться параллельно с разработкой. В конце спринта демонстрируем результат и корректируем дальнейшую работу.
• Удобна модель Time&Material — подход, при котором заказчик платит за часы работы занятых на проекте специалистов, а не фиксированную стоимость. Так он может гибко менять приоритеты и вносить изменения в функциональность, но в пределах спринта. Обычно мы планируем 2-х недельные спринты: планирование объёма работ → реализация → демонстрация результатов.
• Документация важна. В реализации проекта задействовано много специалистов разных компетенций. Замкнуть все процессы в рамках одной компании-разработчика — это оптимум, так как команды работают слаженно по единой документации. Также подробная документация позволяет потом быстро подобрать новую команды поддержки и заонбордить их в проект или забрать его развивать инхаус.
• Передаём проект инхаус и готовим специалистов на поддержку. Если вы решили развивать проект собственными силами, мы поможем сформировать команду, проведём ряд технических собеседований с будущими специалистами, ответственными за проект. Погрузим их в проект, проконтролируем качество работы и выйдем из проекта, когда будем уверены, что разработку можно продолжить без потерь в качестве. Читайте подробнее о том, как мы бесшовно передаем проекты в инхаус-команду.

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

Перед тем, как приступить к проектированию приложения:

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