Разбираем, с каких вопросов начинается разработка мобильного приложения — от идеи до выбора формата и подрядчика, и какие решения на старте определяют судьбу проекта.
«Нам нужно мобильное приложение» — именно с такой фразы начинается большинство проектов. Но сама по себе она ничего не говорит разработчикам. Для одних компаний приложение — это удобный личный кабинет для клиентов, для других — полноценный интернет-магазин, маркетплейс, сервис доставки или корпоративная CRM для сотрудников. От того, какие задачи должно решать приложение, напрямую зависит выбор технологий, стоимость разработки, сроки запуска и возможность дальнейшего масштабирования. Именно поэтому профессиональная разработка начинается не с написания кода и даже не с дизайна экранов, а с анализа бизнес-процессов и постановки правильных вопросов.
С каких вопросов действительно начинается разработка мобильного приложения
Самая распространенная ошибка — сразу обсуждать дизайн, стоимость или технологии. На практике опытная команда сначала пытается понять одну простую вещь: какую проблему пользователя должно решить приложение? Если ответа на этот вопрос нет, существует высокая вероятность потратить месяцы разработки на функциональность, которой никто не будет пользоваться.
Например, если компания занимается доставкой еды, приложение должно максимально быстро привести пользователя к оформлению заказа. Если речь идет о внутреннем сервисе для сотрудников — важнее скорость доступа к рабочим инструментам и стабильность. Если создается интернет-магазин, то критически важны производительность каталога, удобный поиск, фильтрация, корзина и максимально простой процесс оформления заказа.
Поэтому еще до начала проектирования мы подробно обсуждаем не список экранов, а реальные бизнес-процессы компании. Очень часто уже на этом этапе становится понятно, какие функции действительно необходимы, а какие можно спокойно перенести на более поздний этап разработки. Такой подход позволяет не только сократить бюджет, но и значительно ускорить запуск продукта.
Перед стартом разработки мы обычно отвечаем на следующие вопросы:
- какую главную задачу должно решать приложение;
- кто является основной аудиторией — клиенты, сотрудники или партнеры;
- нужна ли регистрация и личный кабинет пользователя;
- будет ли приложение работать без подключения к интернету;
- необходимы ли Push-уведомления;
- будет ли использоваться камера, геолокация, Bluetooth, NFC или другие возможности смартфона;
- понадобятся ли онлайн-платежи;
- необходимо ли подключение к CRM, ERP, 1С или другим внутренним системам компании;
- планируется ли дальнейшее масштабирование проекта.
На первый взгляд эти вопросы кажутся очевидными, однако именно ответы на них определяют архитектуру приложения значительно сильнее, чем выбор конкретного языка программирования или фреймворка. Иногда после такого анализа становится понятно, что полноценное мобильное приложение вообще не требуется, а иногда наоборот — выясняется, что первоначальная идея гораздо масштабнее, чем казалось заказчику.
MVP или сразу полноценный продукт?
Практически каждый заказчик хочет получить приложение, которое умеет абсолютно все. Это вполне естественное желание: если вкладываться в разработку, то хочется сразу реализовать каждую идею. На практике именно такой подход чаще всего приводит к бесконечным срокам, росту бюджета и огромному количеству функций, которыми затем практически никто не пользуется.
Именно поэтому современная разработка строится вокруг понятия MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это первая версия приложения, которая уже полностью решает основную задачу пользователя, но при этом не перегружена второстепенными возможностями.
Важно понимать, что MVP — это не тестовая версия и не "сырой" прототип. Это полноценный рабочий продукт, который уже можно публиковать в App Store и Google Play, привлекать первых пользователей и получать реальные отзывы.
Такой подход позволяет принимать решения на основании настоящего поведения пользователей, а не предположений команды или заказчика.
- первая версия приложения выходит значительно быстрее;
- существенно снижается первоначальный бюджет разработки;
- появляется возможность проверить бизнес-идею без крупных инвестиций;
- новые функции добавляются только тогда, когда становится понятно, что они действительно нужны пользователям;
- архитектура сразу проектируется таким образом, чтобы приложение можно было постепенно расширять без полной переработки.
Мы регулярно сталкиваемся с ситуациями, когда после анализа первоначального технического задания удается сократить объем первой версии практически в два раза без какого-либо ущерба для бизнеса. Более того, после запуска приложения реальные пользователи зачастую начинают использовать продукт совсем не так, как это предполагалось на этапе проектирования. Именно поэтому гибкое развитие продукта почти всегда оказывается эффективнее попытки реализовать абсолютно все функции с первого дня.
Как проходит разработка после согласования идеи
После того как определены задачи приложения и состав первой версии, начинается полноценная работа над проектом. Многие считают, что разработка — это исключительно написание программного кода, однако в действительности это лишь один из этапов большого производственного процесса.
Сначала проектируются пользовательские сценарии, структура экранов и логика взаимодействия. Затем создается UX/UI-дизайн, после чего выбирается наиболее подходящая технология разработки. Для большинства коммерческих проектов сегодня оптимальным решением становится React Native и Expo, однако окончательный выбор всегда зависит от специфики конкретного бизнеса.
Далее начинается разработка серверной части, мобильного клиента, настройка интеграций с CRM, платежными системами, сервисами авторизации, Push-уведомлениями и другими внешними системами. После завершения программирования приложение проходит несколько этапов тестирования на реальных устройствах Android и iPhone, проверяется работа при слабом интернете, тестируются сценарии регистрации, оплаты, восстановления доступа и десятки других пользовательских сценариев.
Завершающим этапом становится публикация приложения в Google Play и App Store. Особенно внимательно к этому относится Apple — модерация App Store имеет множество требований к качеству интерфейса, производительности и использованию системных возможностей устройства. Именно поэтому публикация приложения — это отдельный этап проекта, требующий подготовки и опыта.
Если приложение разрабатывается для уже существующего интернет-магазина на 1С-Битрикс: Управление сайтом, появляется еще одна важная задача — интеграция мобильного приложения с сайтом. Именно через API приложение получает каталог товаров, остатки, фотографии, цены, корзину, оформление заказов, историю покупок, личный кабинет пользователя и другие данные.
Во многих студиях именно разработка API становится одним из самых продолжительных этапов проекта. Фактически для каждого нового интернет-магазина приходится заново проектировать десятки методов обмена данными, писать контроллеры, документировать интерфейсы и реализовывать типовую бизнес-логику.
В Codeking мы решили эту проблему иначе. За время работы с проектами на 1С-Битрикс мы разработали собственный модуль интеграции интернет-магазина с мобильными приложениями. В нем уже реализовано готовое API для большинства стандартных сущностей магазина: каталог товаров, категории, поиск, фильтрация, корзина, оформление заказа, авторизация пользователей, личный кабинет, избранное и многое другое.
Благодаря этому нам не приходится каждый раз заново писать одну и ту же инфраструктурную часть проекта. В большинстве случаев этап подключения мобильного приложения к существующему магазину на 1С-Битрикс занимает порядка 1–2 часов. После этого команда сразу приступает к разработке пользовательского функционала и интерфейсов. По нашему субъективному мнению, для проектов подобного уровня это действительно очень быстрый результат.
За годы использования модуль постоянно развивался вместе с нашими проектами. Сегодня он закрывает большую часть типовых задач интернет-магазинов буквально «из коробки», что позволяет существенно сократить сроки разработки и снизить стоимость интеграции для клиента.
Вся мобильная разработка в Codeking давно выстроена как полноценный pipeline. Мы используем стек React Native + Expo, который считаем оптимальной золотой серединой между скоростью разработки, стоимостью проекта и качеством конечного продукта. Большинство коммерческих приложений не требуют дорогостоящей полностью нативной разработки, но уже давно переросли возможности обычного WebView. Именно поэтому React Native позволяет получить практически нативный пользовательский опыт при значительно меньших сроках разработки.
Благодаря уже готовой инфраструктуре, собственным внутренним инструментам, автоматизированным процессам сборки и публикации, а также модулю интеграции с 1С-Битрикс мы можем запускать мобильные приложения заметно быстрее большинства студий, не жертвуя качеством архитектуры или пользовательского опыта. В результате клиент получает не просто команду разработчиков, а готовый производственный процесс, который уже неоднократно доказал свою эффективность на реальных коммерческих проектах.