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

Что такое бэкенд в e-commerce, и как к нему подступиться

Мы в Surf занимаемся мобильной разработкой и ритейл — одна из наших фокусных отраслей. На нашем счету уже более 20 проектов с крупными игроками рынка: Ригла, Рив Гош, Лабиринт, Бетховен и другие. 

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

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

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

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

Чаще всего между желанием заказчика увидеть приложение уровня OZON и готовностью инфраструктуры работать с ним — гигантская пропасть. А между тем, очень важно понимать, что у крупных игроков, приложениями которых мы пользуемся ежедневно, флоу оформления заказа доведено до совершенства, а вся инфраструктура заточена под приём и обработку интернет-заказов.

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

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

Что стоит сделать на этапе планирования проекта? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем на e-commerce проекте архитектор

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

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

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

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

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

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

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

Каких ошибок поможет избежать архитектор?

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

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

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

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

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

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

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

1. Кто будет ответственным за использование разрабатываемой системы? 
2. Есть ли специалист, представляющий текущий ИТ-ландшафт проекта?
3. Есть ли специалист, отвечающий за информационную безопасность?
4. Есть ли системный администратор?
5. Необходим ли перенос существующих данных из старых систем в новые?
6. Как планируется реализовать сервисы уведомлений (SMS, Push, e-mail, и др.)?
7. Предполагается ли использовать электронную цифровую подпись?
8. Требуется ли сбор логов — записей о событиях в хронологическом порядке о работе системы?
9. Какова предполагаемая номинальная/пиковая нагрузка на систему и динамика её роста?
10. Есть ли существующая сетевая инфраструктура, которая отвечает за маршрутизацию и балансировку (включая отказоустойчивость), которую можно использовать для разрабатываемой системы?
11. Какие есть ограничения на хранение и обработку персональных данных?
12. Как планируется создавать линии технической поддержки?

Как архитектор поможет в интеграциях с сервисами

Все сервисы, с которыми, возможно, предстоит интегрировать ваше приложение, можно разделить на 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 стратегией.

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

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

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

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

Как мы работаем?

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

Итог

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

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

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