Краткий обзор этапов
Приложение делается цепочкой стадий, и каждая опирается на результат предыдущей. Ошибка на ранней стадии обходится дороже всего: переделать готовый экран или код сложнее, чем поправить строку в документе. Типичные этапы разработки мобильного приложения мы ведём в рамках услуги по созданию приложений, а общая карта выглядит так.
| Стадия | Что получается на выходе |
|---|---|
| Аналитика и концепция | Портрет аудитории, цели продукта, состав функций |
| Проектирование и ТЗ | Техническое задание, команда, договор |
| UX/UI дизайн | Схема переходов и макеты экранов |
| Разработка | Рабочая сборка на выбранной технологии |
| Тестирование, релиз и публикация | Проверенная версия в магазинах приложений |
| Поддержка и развитие | Исправления, обновления, новые функции |
Развилка появляется уже в начале: писать отдельно под каждую систему или одним кодом сразу для обеих. Выбор подробно описан на странице про кроссплатформенную разработку. Там же указан ориентир стоимости: 1 100 000 ₽ за проект целиком.
Аналитика и концепция
Аналитика отвечает на вопрос, зачем приложение нужно именно вашему бизнесу и кто будет им пользоваться. Без этого ответа дальше строят не продукт, а набор экранов. Результат стадии — короткий документ, который понятен и владельцу, и разработчику.
Что выясняют на старте
- Какую задачу решает приложение: продажи, удержание клиентов, внутренние процессы, запись и оплата.
- Кто пользователь, где и в какой ситуации он достаёт телефон.
- Чем решение лучше сайта и чем отличается от приложений конкурентов.
- Какие функции нужны в первой версии, а какие можно отложить.
- Как будет измеряться успех: заказы, повторные визиты, нагрузка на менеджеров.
Тип задачи сильно меняет концепцию. Приложение для бизнеса строится вокруг процессов компании и сотрудников. Витрине нужны каталог, корзина и оплата, и эти особенности разобраны отдельно для приложения магазина.
Как отбирают функции
Самая частая ошибка начала — желание вместить всё сразу. Первая версия должна решать одну главную задачу пользователя и проверять спрос, а остальное ждёт своей очереди. Функции делят на обязательные, желательные и отложенные, а к каждой привязывают ожидаемую пользу для бизнеса.
Параллельно собирают то, что понадобится дизайнеру: названия, фирменные цвета, логотип. Если логотипа ещё нет, его стоимость и состав работ мы разбирали в статье сколько стоит разработка логотипа. Как мы проходим такие стадии на практике, видно в наших кейсах.
Проектирование и ТЗ: планирование, команда и договор
Первые этапы разработки мобильного приложения почти не видны снаружи, но именно они определяют, уложится ли проект в бюджет. Сначала после аналитики фиксируется цель: что приложение должно делать для бизнеса и какое действие пользователь совершает чаще всего. Под эту цель собирается план работ.
Результат планирования — ТЗ. Хорошее ТЗ описывает сценарии пользователя, экраны, роли, интеграции с учётными системами и платёжными сервисами, а также то, что в первую версию не входит. Если вы заказываете разработку приложения под ключ, это задание станет основой и для сметы, и для приёмки.
Задачи у проектов разные. Для сервиса компании важны личный кабинет и заявки, подробнее об этом на странице про приложение для бизнеса. Магазину нужны каталог, корзина и оплата, их разбирает страница про приложение для интернет-магазина.
Команда
Минимальный состав зависит от сложности, но роли обычно такие:
- менеджер проекта, который держит сроки и общается с вами;
- аналитик, отвечающий за ТЗ;
- дизайнер интерфейсов;
- разработчики серверной и клиентской частей;
- тестировщик.
Спросите, кто из них будет на связи после релиза: от этого зависит поддержка. Уже на этой стадии возникает развилка между нативной и кроссплатформенной разработкой, её сравнение вынесено на страницу про кроссплатформенную разработку. Ориентир по цене там тоже есть: пакет «Под ключ» стоит от 1 100 000 ₽ и включает каталог, корзину и оплату в приложении, обмен с 1С и CRM, продвижение в сторах.
Договор
В договоре фиксируются не только сумма и сроки. Проверьте, что в нём описаны порядок приёмки, права на исходный код и дизайн-макеты, а также передача доступов к аккаунтам магазинов. Без этого после завершения работ вы можете оказаться владельцем приложения, которым не можете управлять.
| Пункт договора | Что уточнить |
|---|---|
| Оплата | Идёт ли она по этапам и что считается принятым этапом |
| Правки | Сколько кругов правок входит в стоимость |
| Права | Кому принадлежит код и макеты после оплаты |
| Поддержка | Входят ли исправления ошибок после релиза |
Как подрядчик ведёт такие проекты, видно по нашим кейсам: там описано, что было исходной задачей и что получилось.
UX/UI дизайн
Дизайн делится на две части, и путать их дорого. UX отвечает за то, как человек проходит путь к цели, а UI — за то, как выглядит каждый экран. Сначала строится схема переходов и прототип без цвета и шрифтов, затем поверх него рисуются макеты.
Прототип проверяют до разработки: дают его потенциальным пользователям и смотрят, где они останавливаются. Исправить схему на бумаге дешевле, чем переписывать готовый экран. Хороший сигнал, когда главное действие, будь то заказ или запись, доступно за минимум касаний.
UI-макеты включают набор компонентов: кнопки, поля, состояния ошибок и пустых списков. Отдельно готовятся версии под iOS и Android, потому что у платформ разные привычки навигации. Для разработчиков передаётся набор файлов с размерами, цветами и иконками, чтобы публикация в магазинах не задерживалась из-за правок вёрстки.
При оценке работы дизайнера смотрите на состав, а не на красивую картинку. Принцип тот же, что описан в разборе стоимости разработки логотипа: цена зависит от объёма и числа вариантов. Уточните, что входит:
- прототип основных сценариев;
- макеты всех экранов и состояний;
- адаптация под разные размеры устройств;
- иконка и материалы для карточки в магазине.
Только после утверждения макетов начинается программирование. Тестирование, релиз и дальнейшая поддержка опираются на эти же материалы, поэтому изменения после утверждения дизайна обходятся заметно дороже, чем правки на стадии прототипа.
Разработка и выбор технологии
Когда аналитика, ТЗ, UX и UI-дизайн утверждены, начинается программирование. Первое решение здесь — технология: от неё зависят бюджет, скорость запуска и поведение приложения на телефоне. Подробнее о том, как мы ведём такие проекты, рассказано в разделе «Разработка мобильных приложений».
Основные этапы разработки мобильного приложения на Java в работе программистов выглядят так:
- серверная часть и API, через которые приложение получает данные;
- клиентская часть по утверждённым макетам;
- интеграции: оплата, push-уведомления, карты, учётные системы;
- сборка тестовых версий для тестирования и подготовка к релизу.
| Путь | Когда подходит |
|---|---|
| Нативный: Java или Kotlin для Android, Swift для iOS | Нужны тяжёлая графика, работа с датчиками, предельная скорость отклика |
| Кроссплатформенный: один код для обеих систем | Важно быстро выйти на Android и iOS одновременно и не удваивать бюджет |
Нативный путь дороже и дольше, но даёт максимум возможностей системы. Кроссплатформа экономит на второй версии, хотя в редких случаях упирается в ограничения. Развилку мы разобрали на странице кроссплатформенной разработки: там указан ориентир 1 100 000 ₽ за такой проект.
Тип задачи тоже влияет на выбор. Приложению для бизнеса обычно важна связка с внутренними системами, а приложению магазина — быстрый каталог и оплата. Мелочи вроде значка на экране телефона закладывайте заранее: цены на похожую работу разбирает статья о стоимости логотипа. Как мы решали такие задачи на практике, видно в наших кейсах. После разработки идут публикация, релиз и поддержка.
Тестирование, релиз и публикация в магазинах
Когда разработка мобильного приложения дошла до рабочей сборки, начинается проверка. Тестирование показывает, где приложение расходится с ТЗ и с ожиданиями пользователя. Это касается и приложения для бизнеса, например личного кабинета или заказа услуг, и приложения магазина, где важны каталог и оплата.
Проверяют не только то, что кнопки нажимаются. Тестировщик идёт по сценариям из аналитики и сверяет экраны с макетами: UX должен быть понятен без подсказок, а UI совпадать с утверждённым дизайном.
- функциональность: каждый сценарий из ТЗ проходит от входа до результата;
- устройства: разные версии iOS и Android, маленькие и большие экраны;
- сеть: слабый интернет, обрыв связи, возврат из фонового режима;
- нагрузка и безопасность: вход, оплата, хранение личных данных;
- приёмка заказчиком: он сам проходит основные сценарии на своём телефоне.
Релиз готовят отдельно от тестирования. Сначала закрытая выдача сборки небольшой группе: так находят ошибки, которые не видны на тестовых устройствах. Затем собирают финальную версию, подписывают её и готовят публикацию. Для карточки в магазине нужны название, описание, скриншоты и иконка. Если фирменного знака ещё нет, посмотрите, сколько стоит разработка логотипа: иконку лучше сделать до отправки на проверку.
Поддержка, развитие и ориентиры по срокам
Публикация не завершает проект. После выхода начинаются реальные сценарии, и часть проблем всплывает только теперь. Поддержка нужна, чтобы приложение не устарело вместе с очередным обновлением iOS или Android. Магазины меняют требования, и без доработок приложение рискует пропасть из выдачи.
| Направление | Что входит |
|---|---|
| Исправления | ошибки из отзывов и отчётов о сбоях |
| Совместимость | новые версии систем, устройства, требования магазинов |
| Аналитика | воронки, отказы, экраны, на которых уходят пользователи |
| Развитие | новые функции по итогам данных, а не по догадке |
Сроки зависят от числа экранов, интеграций с учётными системами, платёжных сервисов и выбранной технологии. Чем точнее ТЗ и чем раньше утверждён дизайн, тем меньше правок на поздних этапах. Это же влияет на цену: на странице о кроссплатформенной разработке указан ориентир 1 100 000 ₽ за проект. Точную смету считают после аналитики и ТЗ. Как мы доводим проекты до запуска и сопровождаем их, видно на примерах наших работ.
Вопрос — ответ
Какие этапы разработки мобильного приложения и в каком порядке их делать?
Сначала аналитика и концепция, затем ТЗ, UX и UI дизайн, разработка, тестирование, релиз с публикацией и поддержка. Менять порядок рискованно: без аналитики дизайн рисуют вслепую, а без ТЗ разработка уходит в споры о том, что считалось готовым.
Что должно быть в ТЗ и на какой стадии его оформлять?
ТЗ оформляют после аналитики и до начала дизайна. В нём описывают цели, роли пользователей, сценарии, список экранов, интеграции, требования к безопасности и критерии приёмки. Каждый пункт должен допускать проверку: «работает быстро» не годится, нужен измеримый признак.
Как выбрать технологию: нативно, кроссплатформенно или на Java?
Нативная разработка даёт максимум возможностей устройства, но требует отдельных версий под iOS и Android. Кроссплатформенный подход экономит бюджет на простых и средних задачах, подробнее о нём на странице услуги. Java остаётся одним из языков для Android, но выбирают его под задачу, а не по привычке.
Что нужно для публикации в App Store и Google Play?
Нужны аккаунты разработчика в обоих магазинах, подписанная сборка, иконка, скриншоты, описание и политика конфиденциальности. Магазины проверяют приложение на соответствие правилам и могут вернуть его на доработку. Поэтому закладывайте время на проверку и возможные правки до даты запуска.
Как организовать тестирование и кто за него отвечает?
Основную проверку ведёт тестировщик подрядчика по сценариям из ТЗ. Заказчик отвечает за приёмку: проходит ключевые сценарии на своих устройствах и подтверждает результат. Ошибки заводят в единый список с приоритетами, чтобы критичные исправления не терялись среди мелких правок.