Все блоги
Когда в голову приходит идея создать мобильное приложение (вообще любое, но сейчас речь про общепит), кажется, что это просто: создай корзину, в которую можно добавлять товары, и принимай заказы — что тут сложного? Постараюсь использовать поменьше профессиональных терминов и объяснить это простым языком на примере приложения «Кофемашины», заодно ответив на другой вопрос — зачем создавать такие сложности?
Приложение можно написать (создать с нуля) и за два часа
Оно будет открываться — на этом всё. Можно сделать его за неделю — и в нём можно будет сделать заказ. Но придётся потратить месяцы или даже годы (мы начали работу над приложением примерно три года назад и продолжаем всё это время), чтобы «научить» его работать со множеством систем, отладить бизнес-процессы, понять, какой интерфейс удобнее для пользователя.
Пример: у «Кофемашины» много кофеен, большое меню, есть модификаторы продуктов (ингредиенты, которые гость может добавлять в некоторые блюда). Всю эту информацию система iiko, автоматизирующая все процессы в заведении, выгружает в приложение одним гигантским файлом.
Большая часть блюд есть во всех кофейнях, но некоторые уникальны, а некоторых может не быть в наличии в определённой кофейне в определённый момент, поэтому есть стоп-листы. Модификаторы тоже могут быть разными. И нам пришлось прописать целую логику, которая структурирует все данные, раскладывает по полочкам и позволяет мозгам приложения понимать, какие позиции есть в конкретной кофейне, а каких нет. За последний год мы провели большую работу по оптимизации этого функционала, что позволило нам значительно ускорить взаимодействие пользователей с меню в приложении.
Зачем вообще что-то писать, если есть готовые решения?
Это распространенное заблуждение. Да, существуют конструкторы — типовые приложения, которые заведения (если мы говорим об общепите) «собирают» под себя из шаблонов, подгружают меню и получают заказы на доставку. Такие приложения используют кроссплатформенные технологии (могут запускаться на iOS и Android), которые позволяют удешевить разработку. И это крутой инструмент, например, для маленького или начинающего бизнеса, который хочет попробовать и понять, нужно ли ему вообще приложение, не потратив миллионы рублей.
Но когда ты поймёшь, что это круто для твоей компании, ты захочешь какую-нибудь фичу (интеграцию с аналитикой, систему лояльности, онлайн-оплату и т.д.) — тебе скажут, что это можно сделать только за дополнительную плату или невозможно реализовать вовсе (что будет скорее всего). В итоге почти все хотелки, которые появятся в дальнейшем (а если у тебя есть амбиции, то и хотелки обязательно появятся), либо будут сложнее в разработке, потому что изначально приложение предназначалось не для этого, либо — невыполнимы. Конструктор не сможет реализовать все твои желания.
Зато нативное приложение сможет, оно «пишется» специально для тебя. Помимо уже перечисленных плюсов, нативные приложения позволяют использовать разные фишки операционных систем (ОС). Например, у iOS или Android вышло обновление с крутой тёмной темой — пожалуйста, интеграция происходит быстро. ОС постоянно повышают безопасность, добавляют новые анимации, ускоряют всякие процессы — и нативные приложения используют всю мощность обновлений.
Есть ещё веб-приложения, по факту — сайты, открывающиеся в веб-браузерах. Это тоже крутые штуки до поры до времени. Но и в них много ограничений, которые пользователи начнут замечать и говорить: «Вы что, пожалели денег на нормальное приложение?»
Думаю, на данный момент времени, если ты хочешь развивать и масштабировать свой бизнес, ты должен иметь нативное мобильное приложение, даже несмотря на то что технологии кроссплатформенной разработки не стоят на месте и с каждым годом становятся всё сильнее и привлекательнее.
Итак, приложение — это не просто
И степень сложности главным образом зависит от желаний и потребностей компании. Обычно сначала ты видишь одну картинку, а потом погружаешься глубже в процесс, находишь подводные камни, о которых не думал или даже не подозревал, — и складывается другая.
Пример: вначале мы использовали iiko как мозг для всего — в ней обрабатывались заказы, отзывы и так далее. Когда заказ закрывался, приложение предлагало пользователю оценить его звёздочками (от одной до пяти) и по желанию оставить комментарий (а это обычно делают только те, кому уж очень сильно не понравилось) — это всё, что позволяла система отзывов в iiko. Казалось бы — что ещё нужно? На самом деле эта система совсем не информативна, а потому бессмысленна. Можно узнать только, понравилось гостю или нет, а компании важно понимать, что именно не понравилось, найти проблемные зоны.
Мы создали свою систему. Когда гость оценивает заказ, программа выдаёт ему разные критерии: что понравилось — вкусная еда, вежливый персонал, скорость приготовления? И так же с тем, что не понравилось. Это отличный инструмент для работы отдела контроля качества и большой объём данных для маркетинговых исследований.
Аппетит растет во время еды
Когда ты создаёшь систему и она начинает работать — у тебя загораются глаза. В прошлом году мы внедрили много фишек, к примеру, NPS-опросник — гость по шкале от 1 до 10 выбирает, насколько вероятно, что он порекомендует нашу компанию друзьям. Этот инструмент работает и позволяет нашим маркетологам определить уровень лояльности гостей к бренду, создаются крутые графики аналитики. В этом году реализовали онлайн-оплату через приложение (Apple Pay, Google Pay), что позволило гостям не доставать каждый раз карту или телефон на кассе, а в период пандемии это было не только удобнее, но и безопаснее, ведь сократилось количество взаимодействий с кассиром через окошко. Все довольны и хотят еще.
Показываешь руководству результат тестирования одного функционала, а на доске задач уже висят четыре дополнительные. Задачи порождают задачи — это постоянный процесс.
У меня есть и «законсервированные» проекты для других компаний — они доведены до такого состояния, которое устраивает заказчика, ему не хочется ничего менять, и нет смысла его переубеждать, можно только поддерживать их жизнедеятельность. Но когда ты видишь, что проект живёт, дышит и у него большое будущее — тебе интересно работать над ним и улучшать его. Именно такая история у меня с «Кофемашиной».
Пример: в конце 2019 года я пришел к Дмитрию и сказал, что могу сделать серверную часть лучше. Объяснил целесообразность и получил добро на усовершенствование системы. Для пользователя это невидимая работа, но для нас это очень крупные изменения.
Раньше сервер представлял собой одну программу, запущенную на компьютере. При сбое он тушился на несколько секунд, чтобы перезагрузиться, и в этот момент приложение было недоступно. Процент людей, которые хотели сделать заказ в этот промежуток времени, очень мал — 2-3 человека за год, но они есть. Поэтому я предложил разбить сервер на кластеры.
Представьте, у вас была однокомнатная квартира, вы жили в ней вместе с мамой, папой, бабушкой и дедушкой, было тесно. А потом вы купили 5-комнатную квартиру — у вас своя комната и свои законы, вы сделали ремонт, повесили плакат. Родители просят помыть посуду — вы выполняете свою работу и возвращаетесь в свою комнату. Всем хорошо. Так же будет работать наш сервер.
Мы разделим большую программу на множество маленьких подпрограмм (отдельно для заказа, для пользователя, для уведомлений), которые будут работать в своей узкой специализации. Сбой одной из программ не повлияет на работу остальных. Если папа приболел, то он отдохнёт в своей комнате, пока остальные продолжат жить обычной жизнью. Папа выздоровеет и присоединится к остальным.
И это крупное изменение будет способствовать крутому скачку в разных функционалах. Когда вы приходите на почту, вас не интересует происходящее на складе, главное, что сотрудник уходит за вашей посылкой и возвращается с ней. Так же и разные блоки не будут знать о том, что происходит внутри каждого из них, они будут ждать друг от друга только результат. Это так называемый уровень абстракции. Ты определяешь методы взаимодействия блоков (прописываешь для них общий язык), и это гарантирует тебе, что ошибки могут быть только внутри конкретного блока.
С таким подходом разработка становится сложнее и дороже (но плюсы перевешивают минусы). На мой взгляд, он нужен только крупным компаниям, it-составляющая которых давно вырвалась за пределы своих возможностей, поэтому нужно создавать условия для её роста.
Можно создать технологию и использовать её до конца жизни
Многие не понимают, зачем лезть выше, если всё и так хорошо работает. А мне нравится изучать что-то новое (инструмент, язык программирования, фреймворк и так далее), и когда я вижу, что есть ступенька выше, то не понимаю, как можно оставаться на той же.
Я уверен, что компания, которая хочет идти в ногу со временем, обязана совершать эти шаги. Вышла фича — нужно её изучить, если она крутая — внедрить. Нет предела совершенству — это всем известно. Но можно к нему приблизиться, думаю, мы уже близки.
Какой потенциал у нашего приложения?
Думаю, что хотелки будут появляться всегда. Я хоть сейчас могу накидать семь дополнительных фич. Всё зависит от желания компании улучшать свой продукт. Может ли наступить момент, когда всё уже придумано и больше ничего нельзя внедрить? Конечно, может. Но, я в это не верю.