Как понять, нужно ли вашей компании мобильное приложение
Первые хотят «залезть в телефон» клиента и быть всегда на виду и бесконечно пушить для апсейлов. Конечно, когда интернет-магазин предлагает клиенту скачать приложение, то мотивирует тем, что клиент будет отслеживать свои заказы, видеть статистику покупок и бонусов, но фактически мобильное приложение нужно для роста продаж и постоянного напоминания о себе.
Вторая категория заказчиков хочет с помощью мобильных приложений автоматизировать бизнес-процессы. Например, это может быть приложение для водителей, в котором видны маршрутные листы и контактные данные контрагентов, приложение для сотрудников склада для комплектования заказов, приложение для менеджеров, которым нужно оперативно передавать какие-либо данные во внутреннюю систему или получать их оттуда.
Требования
Требования к технологическому стеку, к интерфейсу, к дизайну разные и, опять же, зависят от типа приложений. Если говорить в общем, то есть два типа приложений.
-
Нативные приложения: для Android и iOS разрабатываются разные приложения. Каждое пишется на языке, соответствующем этим платформам: Android на Java, iOS — на Objective C и Swift. И это будут на самом деле независимые приложения с разными командами разработки, разными релизами. И работа над ними редко ведется параллельно. Например, для iOS уже может появиться новый функционал, а для Android еще нет. Самое главное — такая разработка стоит очень дорого именно из-за описанных особенностей. Плюс нативных приложений в том, что они работают существенно быстрее и имеют больше доступа к телефонному «железу».
-
Кросc-платформенное приложение, то есть одно приложение, работающее сразу на обеих платформах. Они обычно разрабатываются на базе Flutter, React Native. Такие приложения гораздо дешевле сделать, но у них есть недостатки в сравнении с нативными: меньше возможностей по UX, юзабилити, они медленнее работают и в целом проигрывают нативным приложениям по качеству, но существенно выигрывают в стоимости разработки.
Сколько стоит?
Остановимся подробнее на вопросе цены разработки. В качестве примера возьмем популярный маркетплейс. Если у него из-за подтормаживания кросс-платформенного приложения продажи упадут хотя бы на 0,5%, это будет критично. А потому для маркетплейса нет альтернативы: только разработка нативных приложений. Если же мы рассмотрим в качестве примера небольшую сеть магазинов, которым в какой-то период некритично потерять в моменте небольшой процент заказов, то им можно сэкономить на нативных и выбрать кроссплатформенное.
Подведем итог: выбор технологий и требования зависят от бизнеса. Крупные компании будут требовать максимальную скорость, компании поменьше выберут эконом-вариант с пробелами в скорости.
Помимо стоимости самой разработки приложения нужно еще закладывать в бюджет интеграцию с внутренними системами компании. Приложение не может знать всю информацию, оно должно ее откуда-то получать. Конечно, существуют приложения, которым не нужна серверная часть, например приложение для обработки фотографий: теоретически ему не нужны бэка и интеграции. Но если мы говорим про приложения интернет-магазинов или сервисные, для них обязательно должен быть какой-то бэк, данные в который поступают в онлайн-режиме. В случае с интернет-магазином это будут данные по:
-
оперативным остаткам;
-
наличию товаров;
-
цене;
-
доставке и т. д.
И для всех этих данных нужна интеграция с одной или несколькими системами. Например, у интернет-магазина может быть интеграция со складской программой, с CRM-системой и с бонусной программой. Это пример трех интеграций, согласованных между собой. И плюс сам бэк. Приложение, как правило, не общается с системами напрямую и не содержит всю бизнес-логику. В нашей практике у всех приложений есть сервер, который передает необходимые данные в приложение.
Рекомендации заказчику приложения
Как и вс любом крупном проекте, заказчику хорошо бы иметь квалифицированных сотрудников со своей стороны — продуктового и/или проектного менеджера, который будет отвечать за развитие продукта, погрузится в нюансы разработки, выставит правильные приоритеты по реализации функционала. Кроме того, этот человек будет нужен для взаимодействия с командами:
-
разработки приложения;
-
поддержки приложения;
-
разработки и поддержки учетных систем, которые потребуется интегрировать.
По нашему опыту, сложнее всего работать с заказчиками, не имеющих в своей компании сотрудников, которые могут заниматься проектами, доказывать необходимость и важность шагов, действий и, соответственно, контролировать эти процессы. Часто многое ломается в тот момент, когда надо интегрировать приложение с внутренними системами. Как их сделать, если, например, нужна интеграция с 1С, а необходимые специалисты заняты на год вперед? Наш ответ: никак, работа встанет.
Как понять ценность мобильного приложения
Главная ценность мобильного приложения, как мы уже говорили выше, «попасть в телефон клиента». Однако у этой медали есть обратная сторона: нужно понимать, какую ценность получит клиент после установки приложения. Одно дело, когда это площадка крупного маркетплейса, на которой человек регулярно делает заказы. Ему удобно хранить там штрихкоды для получения заказов, отслеживать изменения цен, сравнивать аналогичные товары и т. д. Ценность здесь в принципе очевидна. Более мелким структурам сложнее посчитать и доказать ценность для клиента. Например, у нас есть клиент — компания, оказывающая автоуслуги. У нее несколько миллионов клиентов, поэтому очевидно, что компания хочет регулярно напоминать о себе и получать информацию про своих клиентов. Но есть нюанс: клиент пользуется услугами компании два раза в год. Как в этом случае мотивировать клиента поставить приложение?
В итоге мы сделали для компании MVP-приложение, которое выросло из разработки другого функционала: изначально мы создавали микросервис записи на услуги в виде виджета на сайт, в процессе решили вместе с заказчиком сделать приложение. Мы собрали его за два дня: в нем можно выбрать приемный день, необходимый филиал, время и записаться. Поскольку это MVP, то особых требований к UI/UX и дизайну не было, но появилась возможность протестировать, нужно ли такого рода приложение клиентам компании.
Однако это не единственный вариант, можно прозондировать почву с помощью Telegram-бота: он хорошо выполняет несложные операции — например, узнает статус доставки заказа, получает штрихкод на заказ и другие базовые функции. Конечно, в бота не загрузить каталог товаров или сложные процессы. Но главное преимущество бота в том, что мессенджер, скорее всего, уже есть в телефоне пользователя, поэтому бизнесу проще мотивировать его на подключение бота. С его помощью можно пушить пользователя и давать ему ту информацию, которую он сам хочет получить.
Да, это хуже MVP-приложения, но если компания задает вопрос, нужно ли ей приложение вообще, то Telegram-бот — оптимальный выбор. Главный плюс: он обойдется в разы дешевле приложения, клиенту будет гораздо проще подключиться, зная, что не нужно ничего устанавливать.
Опубликовано 28.08.2023
