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

Привет! Сәлеметсіз бе! На связи Максим Кульгин, учредитель компании Нотиссимус. Мы более 8 лет разрабатываем мобильные приложения для бизнеса. На примере длительного проекта рассмотрим типичные вопросы желающих повторить наш путь. Расскажем о очень интересном проекте для сети магазинов Меломан.

«Меломан» — холдинг и одна из крупнейших торговых сетей Казахстана.

История компании начинается с 1987 года, когда основатели Игорь и Александр Дериглазовы решили превратить свое хобби в бизнес. Увлекаясь музыкой, они записывали кассеты и продавали их через маленький киоск в Усть-Каменогорске.

За 36 лет киоск вырос в крупную компанию со своими традициями. Через торговые сети холдинга покупателя находят производители всего мира: от российской «Эксмо» до Lego и Disney. Помимо этого, «Меломан» обладает правами на кинодистрибьюцию фильмов Disney и Sony, выпускает в прокат более 200 фильмов в год, имеет собственную сеть кинотеатров.

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

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

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

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

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

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

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

У заказчика было много пожеланий.

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

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

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

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

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

На успех работы влияет множество факторов. Один из важнейших элементов для детального изучения — job to be done, то есть как пользователи действовали бы при отсутствии приложения.

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

Выпуск MVP (minimum viable product, минимально жизнеспособная версия) — общепринятый подход при разработке сложных систем. Иногда приходится даже уговаривать заказчиков реализовывать не весь задуманный функционал сразу — это будет дешевле, даст первые отзывы и обратную связь, подкорректирует дальнейшее видение приложения. Такую стратегию развития приложения можно назвать пошаговой.

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

Каждое приложение в чем-то уникально по-своему. И всё же есть много общего в приложениях одного типа. Проекты для интернет-магазинов тоже не являются исключением и имеют примерно одинаковую структуру и особенности.

Одинаков и подход к созданию мобильного приложения.

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

Дотошность ко всем нюансам вначале — не потеря времени! Это беспроблемная разработка в дальнейшем!

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

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

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

Мы всё отразили в прототипе, сделали оценку стоимости работ по воплощению каждой отдельной функциональной возможности.

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

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

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

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

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

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

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

Все заказчики понимают важность дизайн-составляющей, уделяют ей повышенное внимание.

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

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

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

Встреча приложения с миром — момент всегда волнующий и переломный. С этого шага появляется обратная связь и пожелания пользователей начинают играть существенную роль в дальнейшем развитии.

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

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

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

Одна задача тянет за собой следующую. Чем больше товаров в каталоге, тем очевиднее: поиск товара — вот главная функция!

Программная инфраструктура «Меломана» использует различные сервисы, такие как Multisearch.

Сейчас поиск товара осуществляется на стороне приложения: пользователь получает ровно те данные, которые нашлись в товарной выгрузке.

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

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

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

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

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

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

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

Технически сервис предлагает множество механизмов, например, push-уведомления. Предстоит объемная интеграционная работа, но усилия того стоят! Ведь вокруг каждого пользователя формируется индивидуальное информационное пространство, а это значит, что отдача от приложения станет ещё больше!

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

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

Например, нужно сделать новый раздел «Избранное». На первый взгляд ничего сложного. Однако, если клиент добавил в избранное что-то в приложении, то изменения должны отразиться и на сайте — а значит, снова предстоит плотно поработать с API заказчика.

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

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

Сайт живет своей жизнью. Все изменения на сайте должны соответствующим образом перетекать и в мобильное приложение.

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

Изменилось количество картинок для товара: теперь их стало несколько — надо адаптировать приложение так, чтобы должным образом отображались все картинки, которые нам передают.

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

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

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

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

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

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

Случается ли так, что заказчики ставят невыполнимые задачи?

Конечно! В таких случаях мы находим компромиссное работающее решение.

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

Принудительное обновление приложения на смартфоне клиента — задача невыполнимая.

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

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

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

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

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

Сайт поддерживает два языка: казахский и русский. В приложении пока только русский.

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

Это тоже правильно. Лучшее — враг хорошего. Переделка старого кода потребует значительных ресурсов и принесет дополнительные риски. Отдельные сбои и несогласованности в работе систем иногда проще решить отдельно для каждого случая. Здесь бизнес сам принимает решения как лучше сделать.

Проект имеет и несколько архитектурных особенностей.

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

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

Такой подход вынудил принимать дополнительные меры для согласования данных.

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

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

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

К архитектурным особенностям можно отнести и необходимость работы с дублирующим сервером.

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

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

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

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

Приложение интуитивно понятное и сложностей в тестировании нет.

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

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

С появлением товарной части тестирование ещё упростилось. В случае неправильной работы возникал всего один вопрос: есть соответствующая информация в товарной выгрузке или нет.

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

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

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

Нам баг проще исправить, сделать следующую сборку — и вперед! Все критические ошибки при основном тестировании отлавливаются.

Организация тестирования зависит, в том числе, и от архитектуры проекта.

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

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

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

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

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

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

Сайты так или иначе ориентируются на десктоп, несмотря на кричащее отовсюду: «Mobile first!». Можно и даже нужно делать адаптивную верстку, но она не позволит работать с контентом так же, как мобильное приложение.

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

Что самое главное?

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

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

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

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

Напоминаю, что активно веду телеграм-канал «Русский ИТ-бизнес», где без прикрас рассказываю о наших буднях и отвечаю на вопросы в комментариях. Подписывайтесь!

P. S. Возможно, вам также будет интересно почитать:

• Как мы делали мобильное приложение для ФК «ЗЕНИТ» и нарвались на аудит
• Кейс: креативный редизайн мобильного приложения ХК «СКА» на 5 звезд от пользователей
• Кейс «Хлебная Усадьба»: разработка собственного мобильного приложения для сетевой пекарни
• Кейс сушишоп: непростая разработка мобильного приложения для сетевой компании