Как дагестанская IT-компания сделала приложение не хуже Сбермаркета

Меня зовут Шамиль Исаев, я ― основатель IT компании по разработке под названием Comrades Devs. Хочу поделиться с вами историей разработки одного из наших самых сильных проектов для крупной сети продуктовых магазинов Дагестана.

Заканчивался трудный 2022 год... За окном выли ветра холодного ноября. Весь отечественный рынок ранила международная ситуация, но выжившие были.

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

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

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

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

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

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

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

Да только конкурент оказался “не промах” ― еще не подписав с компанией договор, они приступили к разработке дизайна. Это был рисковый, но мощный рычаг давления на клиента. Он либо согласился бы в итоге сотрудничать именно с ними (А что? Работа-то уже начата), либо выслушал бы браваду о неоцененном героизме, где постскриптум звучит: “Ну заплатите хотя бы за дизайн, и используйте его дальше в работе”.

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

Переговоры затягивались. С одной стороны, клиент заинтересован в нашем предложении, с другой ― конкурент говорит с ним на более понятном языке: 1C-Битрикс (“О, его я знаю!”) против нашего фреймворка Laravel с уникальными технологиями; быстрый опрос против SWAT-анализа и графиков и так далее.

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

Что ж, получается, мы в итоге создали феномен.

Итак, месяц переговоров, и в декабре 2022 года контракт наш. Тот самый «сказочный» срок результата работы ― 8 месяцев. При том, что рыночный срок реализации обозначенного фронта работ ― минимум 2 года (и это мы при конкурентах лишь вершину айсберга обозначили).

Пожалели ли об этом мы сами или клиент? Ни капли. Именно тестовая версия приложения показала наглядно все косяки и фэйлы продукта. Естественно, в это время мы уже занимались не только его разработкой, но и сопровождением, а значит ― видели все моменты, которые нужно дополнить или изменить. За это отдельное спасибо активным пользователям, которые не стеснялись накинуть праведного гнева на вентилятор.

Вот такие комментарии были в августе

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

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

Также нужно понимать, что запуск MVP ― это движение бизнеса. Можно сделать готовый необкатанный продукт в срок, и еще полгода ждать первой прибыли с него, а тест позволяет все делать в моменте ― и испытывать/дорабатывать приложение, и прибыль получать.

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

Добрая классика: провести исследования

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

Изучили конкурентов, их практику и решения. Это 7 конкурентов в Республике Дагестан и 8 ― в Москве.

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

Следом мы провели опросы и интервью с клиентами заказчика и аудиторией конкурентов ― итого вышло почти 600 готовых исследований.

В результате мы придумали сразу несколько новых «фишек» приложения:

• ставить в карточку товара изображение флага страны производителя ― так получился быстрый доступ пользователя к информации в лучших традициях UI/UX дизайна;
• выводить пользователю автоматическую сборку продуктовых наборов ― тут я считаю, что мы даже Яндекс и Сбермаркет по уровню исследования обогнали. Об этом расскажу подробнее.

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

ПП-пример: примерно 45% нашей ЦА ― сторонники правильного питания. Мы создали наборы для правильного завтрака, которые можно собрать одним кликом и увидеть на сколько готовок и персон хватит продуктов.

Хайповый пример: в каждом городе есть свои знаменитости ― блогеры. Дагестан ― не исключение, особенно если говорить о фуд-блогерах. Мы сделали с некоторыми из них коллаборацию: взяли рецепт какого-то блюда из тех, что блогер готовил на Ютубе или в запрещенной соцсети, и сформировали под него набор продуктов.

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

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

Анализ включает 9 пунктов:

• Правовое понятие.
• Виды деятельности.
• Дополнительные виды деятельности.
• Недостающие виды деятельности.
• Правовое регулирование.
• Законодательные нормы.
• Судебная практика.
• Дополнения.
• Основные источники.

На основе всего этого появилось понимание, каким должен быть продукт и какие боли и задачи есть у покупателей. То есть, что именно нужно мамочкам в декрете или сторонникам ПП. Например, первых интересует четкое время доставки товара и подробная информация о производителе, вторых ― четкое количество БЖУ в продукте.

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

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

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

И да, конечно, я знаю, что для этого давно придумали ТСД-сканеры. Но разве каждый магазин может позволить себе купить это оборудование на всех сборщиков? Возникает вопрос: “А если мы в пиковые нагрузки захотим вывести 200 сборщиков? Придется закупать столько же ТСД на разовую сборку? А что потом делать с этими аппаратами?”

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

За кадром ― так сборщики видят приложение

Более того, приложение не дает сборщику пойти дальше, пока он не отсканирует все товары, указанные в заказе. Так что курьеру в руки попадает полностью собранный товар.

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

После того, как сборщик закончил работу, в дело вступает служба безопасности (СБ). Они проверяют весь ли товар собран. И только после этого заказ попадает в «руки» курьера, который также перепроверяет заказ на всякий случай ― это дополнительный пункт контроля. Все это позволяет «человеческому фактору» не влиять на качество работы.

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

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

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

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

С точки зрения разработки все вышеописанное ― 10 сложных микросервисных структур, одна из которых привязана к 1C, чтобы вести обмен данными в «прямом эфире». Например, если товар уже куплен пользователем, это отобразится в админпанели.

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

А вы пользуетесь приложениями магазинов в своем городе? Видите в них плюсы и минусы с точки зрения пользователя?