Кейс «Хлебная Усадьба»: разработка собственного мобильного приложения для сетевой пекарни

Привет! Меня зовут Максим Кульгин, учредитель компании Нотиссимус. Мы более 8 лет разрабатываем мобильные приложения для бизнеса. Поделюсь с вами опытом разработки мобильного приложения для региональной сети пекарен. Мы часто слышим про «интегрированные высокие технологии», AI, ChatGPT, голосовых помощников… Но ощутимую пользу бизнесу в действительности приносит другое.

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

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

Этот неразрешимый рой вопросов:

• будет ли понятен процесс разработки?
• не возникнет ли у команды неясностей в вопросах бизнеса?
• нужно ли проводить всестороннюю аналитику рынка?
• не будут ли приняты неверные технические решения?
• не возникнет ли зависимость от разработчика?
• насколько заботливым будет отношение к задачам?

Это и про деньги, конечно же:

• корректно ли исполнитель оценит стоимость разработки?
• какими договорами и формулировками подстраховаться?
• не будет ли срыва сроков и дополнительных трат?

Но всё намного проще. Вот пример.

«Хлебная Усадьба» — пекарня с непрерывным производственным циклом, собственным автопарком и более чем двадцатью точками розничной торговли в Санкт-Петербурге и области.

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

Иными словами: вся боль, страхи и выбор решений — наше.

Это не хорошо и не плохо: когда встречаются заказчики, у которых есть свой IT-отдел, то с такими иногда проще, а иногда и наоборот.

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

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

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

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

Система автоматизации, которая уже используется заказчиком для решения кассовых задач — iiko.

Заказчик подготовился, и его представители пришли на встречу с уже продуманным списком функций: что-то придумали сами, что-то подсмотрели в похожих приложениях.

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

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

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

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

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

Договорились, что мобильное приложение на первом этапе должно уметь выводить ассортимент товаров (без возможности доставки, просто показать что есть) и программу лояльности (накопительные баллы, которые можно списывать при покупке) .

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

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

Авторизация по номеру телефона — теперь ещё один общепринятый стандарт: проще ввести код из SMS, чем запоминать пароль. Однако, мы просим и электронную почту, («кризис бумаги» снова ввел её в обиход) — клиент расплатился на кассе, а на e-mail отправился чек — очень удобно для всех.

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

Главная страница состояла из бонусной карты и отображения действующих акций. Когда клиент нажимает бонусную карту — появляется QR-код и начисляются баллы за покупки. Другие вкладки содержат каталог, адреса на карте и так далее.

Мы постарались, чтобы приложение было максимально полезным для пользователя: уведомления, новости, акции, подарки, отзывы и предложения — всё вовремя и всё в одном месте!

Заказчик особо отметил, что обязательно должна быть история баллов, которую клиент может видеть.

Прототип всегда делается долго (в этот раз работа заняла два месяца) : согласовываются и внешний вид мобильного приложения, и сторонние сервисы, которые должны быть задействованы (к примеру, выбор провайдера для валидации телефонного номера при регистрации) и тому подобное.

Вообще, когда начинается разработка прототипа, всегда оказывается, что приложение «чуть сложнее», чем все предполагали.

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

У заказчика был свой бренд-бук (что встречается далеко не всегда) , а значит, существенная часть работы по дизайну уже сделана. Со стороны представителей заказчика других особых предложений не было, они лишь обозначили предпочтения и в большей степени хотели отталкиваться от наших идей.

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

После выбора дизайн-концепции дорисовываются и все остальные экраны приложения.

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

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

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

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

К примеру, таб-бар состоит из иконок и сепаратора — их дизайн создается независимо и отражается в общей картине. Создание дизайн-системы — ещё один отраслевой стандарт, не мы его придумали.

Преимущество дизайн-системы в том, что она делает заказчика независимым от разработчика, не «привязывает» к нему. Мы передаем заказчику все материалы, и другому дизайнеру легко будет вносить правки, не опасаясь всё испортить или утонуть в изменениях.

Далее начинается рутинная работа по разработке той самой «минимально жизнеспособной версии». Есть прототип, есть дизайн — заказчик понимает, как будет выглядеть и работать его приложение. После всех этих итераций и согласований становится понятен бюджет и можно приступить к реализации согласованного функционала.

Между заказчиком и исполнителем наступает некоторый «период тишины» — первое время попросту нечего показывать. Чтобы «интервал тишины» не был так очевиден и не смущал заказчика, мы практикуем вот что.

Периодически, раз в неделю, информируем заказчика о проведении работ: сделаны такие-то экраны, подключены такие-то сервисы. Когда заказчик получает вот такую обратную связь, он понимает, что работа идет по плану и не беспокоится.

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

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

Здесь главный вопрос: кто разрабатывает API?

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

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

В этот раз всё было несколько иначе — предстояла интеграция с iiko, которая имела API, разобраться в котором совершенно невозможно в разумные сроки. «Хлебная Усадьба» договорилась с iiko, что те выделят специалиста для консультации.

Возможностей API много, документация необъятная: авторизация, регистрация, ассортимент, остаток по бонусным баллам, история накоплений, кассовая задача… Заказчик просто оплатил услуги специалиста iiko, и тот «взял за руку и провел по всем вехам».

Проделанную работу можно условно разделить на две части:

• интеграция с уже отработанной системой заказчика (основанной на iiko) , которая реализует существующий функционал: от кассовой задачи до ассортимента и бонусной системы;
• разработка «с нуля», а уже затем интеграция возможностей, которых нет в iiko: прокси-сервер (необходим, чтобы приложение не подключалось к сети iiko напрямую) , административная панель, уведомления и тому подобное.

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

Мы использовали Xamarin — систему для кросс-платформенной разработки. (Сейчас Xamarin выкуплена Microsoft и является её частью.)

Что это дает заказчику?

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

Во-вторых, заказчик остается независимым в выборе подрядчика. При желании он может нанять даже одного человека, и тот за несколько месяцев разберется в архитектуре проекта и приложение может дальше развиваться лишь силами заказчика. У нас, кстати, такие кейсы были. Для мелкого и иногда среднего бизнеса — это отличный подход!

Здесь может возникнуть резонный вопрос: ведь Xamarin — не единственное решение для кросс-платформенной разработки, есть и аналоги: React, Flutter…

Ответ прост.

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

Несколько слов о том, на что обратить внимание тем, кто однажды окажется в роли заказчика или исполнителя.

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

Например, подошла очередь «доставки» — и она реализуется в приложении в кратчайшие сроки: к карточкам товара добавилась возможность купить, появилась корзина, категории переехали на главную страницу — вот и всё!

Всегда надо быть готовым к сложностям.

В этом проекте тоже не всё было гладко. Мы как-то не утвердили несколько второстепенных экранов — видимо забыли — и представители заказчика довольно строго отреагировали.

Хорошие отношения с менеджментом — основа благополучия проекта.

Степень участия заказчика может быть разной.

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

Надо любить заказчика — и успех обеспечен: ) В общем, «капитан очевидность»: ) Удачи!