Как заказать разработку мобильного приложения: от идеи до запуска

С чего начать разработку мобильного приложения

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

Формулировка «хотим мобильное приложение для клиентов» слишком общая. Она не помогает определить функциональность, бюджет и сроки.

Гораздо полезнее описать конкретную задачу:

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

После этого появляются понятные сценарии:

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

Так формируется основа будущего продукта.

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

Что нужно подготовить до обращения к разработчику

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

Как выбрать подрядчика

Стоимость разработки — важный критерий, но сравнивать подрядчиков только по цене рискованно. Из чего складывается бюджет IT-проекта, мы разбирали в статье «Сколько стоит разработка».

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

При выборе подрядчика стоит посмотреть:

• какие мобильные приложения команда уже запускала и есть ли реальные кейсы;
• какие технологии используются;
• как организовано тестирование;
• кто отвечает за проект;
• как оформляются результаты работы;
• как устроена поддержка после релиза;
• кто владеет исходным кодом и инфраструктурой;
• как команда работает с изменениями требований.

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

Discovery: зачем нужен этап аналитики

Discovery — это этап, на котором идея превращается в понятную концепцию продукта. На нём команда разбирает:

• целевую аудиторию;
• пользовательские сценарии;
• бизнес-логику;
• роли пользователей;
• интеграции;
• ограничения;
• технические риски;
• состав MVP.

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

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

Как формируется техническое задание

После аналитики можно сформировать требования к продукту. Для каждого сценария нужно понимать:

• кто выполняет действие;
• что пользователь видит;
• какие данные вводит;
• что происходит после действия;
• какие условия существуют;
• что происходит при ошибке.

Например, недостаточно написать: «Добавить оплату».

Нужно определить:

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

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

MVP или сразу полноценное приложение

Одна из главных задач на старте — определить минимальную версию продукта.

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

Например, для сервиса бронирования MVP может включать:

• регистрацию;
• каталог;
• выбор времени;
• бронирование;
• оплату;
• уведомления.

А программу лояльности, расширенную аналитику, рекомендации и дополнительные сценарии можно перенести на следующий этап.

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

Для части продуктов первым шагом может быть не полноценное приложение, а Telegram Mini App: быстрее проверить спрос и ключевой сценарий, а уже затем инвестировать в iOS и Android.

UX/UI-дизайн мобильного приложения

После определения логики создаётся пользовательский интерфейс. Сначала проектируются пользовательские сценарии и структура экранов, затем — визуальная часть.

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

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

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

Разработка приложения

После согласования логики и дизайна начинается непосредственно разработка. Для приложения под iOS и Android можно выбрать нативный или кроссплатформенный подход.

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

Для многих бизнес-приложений кроссплатформенная разработка позволяет эффективно развивать версии сразу для нескольких платформ.

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

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

Тестирование и подготовка к релизу

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

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

Отдельно проверяется производительность и стабильность приложения.

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

Публикация в магазинах приложений

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

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

В зависимости от продукта приложение может быть опубликовано сразу в нескольких магазинах.

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

В 2people IT мы публикуем разработанные приложения в App Store, Google Play, RuStore и AppGallery, если соответствующие площадки входят в требования проекта.

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

Что происходит после запуска

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

• где пользователи прекращают сценарий;
• какие функции используют чаще;
• какие ошибки возникают;
• какие устройства используются;
• какие функции требуют доработки.

На основе этих данных формируется следующий backlog.

Для бизнеса это означает переход от разовой разработки к развитию продукта. Также необходимо поддерживать приложение: исправлять ошибки, обновлять зависимости, адаптировать его к изменениям iOS и Android и развивать backend и интеграции.

Вывод

Заказать разработку мобильного приложения — это не значит просто передать подрядчику список функций.

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

Причём публикация — это не только App Store и Google Play. В зависимости от аудитории и задач продукта приложение может потребоваться разместить также в RuStore и AppGallery.

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

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

После этого можно определить MVP, выбрать технологию, оценить бюджет и построить понятный план разработки.

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