Оглавление

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

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

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

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

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

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

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

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

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

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

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

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

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

    Директор по продажам в Surf

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

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

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

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

    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 для получения спецпредложений и купонов — эти данные сохраняются в профиле. Так постепенно система «узнаёт» клиента, не вызывая у него раздражения ненужными вопросами. Его цифровой профиль пополняется постепенно за счёт информации, которая необходима для покупки.

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

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

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

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

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

    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 часов еженедельно.