Короткий ответ: типичный проект проходит путь исследование → требования и ТЗ → прототип и дизайн → архитектура → разработка → тестирование → публикация → поддержка и развитие. Этапы частично пересекаются, а в гибких командах повторяются циклами по одной-две недели. Но пропустить какой-то из них целиком почти всегда дороже, чем пройти его быстро: сэкономленная на исследовании неделя легко превращается в месяц переделок после релиза.
| Этап | Главный результат | Доля времени* |
|---|---|---|
| 1. Исследование | Описание пользователей, сценариев и критериев успеха | 5–10% |
| 2. Требования и ТЗ | Список функций первой версии, ограничения, приоритеты | 5–10% |
| 3. Прототип и дизайн | Кликабельный прототип, UI-кит, макеты ключевых экранов | 10–20% |
| 4. Архитектура | Выбор технологий, схема данных, интеграции, план API | 5–10% |
| 5. Разработка | Работающие сборки клиента и серверной части | 40–55% |
| 6. Тестирование | Проверенная сборка-кандидат, список известных ограничений | 10–20% |
| 7. Публикация | Приложение в магазинах, настроенная аналитика | 2–5% |
| 8. Поддержка | План обновлений, мониторинг, бэклог следующих версий | постоянно |
* Доли условные и зависят от проекта: в приложении с простым интерфейсом и сложной логикой больше времени уходит на серверную часть, в продукте для широкой аудитории — на дизайн и тестирование. Тестирование в хорошем процессе идёт параллельно разработке, а не только в конце.
Этап 1. Исследование: зачем продукт нужен
Первый этап отвечает на вопросы, которые сформулированы и на главной странице Mobi2B: кто будет пользоваться приложением, какое действие оно упрощает и как вы поймёте, что продукт работает. Ответы кажутся очевидными, пока их не попробуешь записать одной фразой.
Что сделать
- Описать пользователей и ситуации. Не «все владельцы смартфонов», а «клиент салона, который хочет перенести запись, не звоня администратору». У одного приложения может быть несколько ролей — клиент, сотрудник, администратор, — и у каждой свои сценарии.
- Поговорить с 5–10 будущими пользователями. Спрашивайте о том, как они решают задачу сейчас, а не «нужно ли вам приложение». Люди охотно соглашаются с идеей, но точнее описывают свои реальные действия и раздражители.
- Посмотреть на альтернативы. Конкурентом мобильного приложения часто оказывается не другое приложение, а мессенджер, сайт, звонок или таблица. Если текущий способ «достаточно хорош», новое приложение должно быть заметно удобнее, иначе его не установят.
- Решить, нужно ли именно приложение. Для редких действий (раз в полгода) часто хватает адаптивного сайта. Приложение оправдано, когда человек возвращается регулярно, нужны push-уведомления, камера, геолокация, офлайн-режим или быстрый доступ с главного экрана.
- Сформулировать критерии успеха. Например: «30% клиентов записываются через приложение через три месяца после запуска» или «выездные сотрудники закрывают заявки без звонка диспетчеру».
Результат этапа
Одностраничный документ: проблема, целевые пользователи, основные сценарии, альтернативы, метрики успеха и ограничения (бюджет, сроки, обязательные интеграции). Этот документ станет введением к техническому заданию.
Этап 2. Требования и техническое задание
На втором этапе идеи превращаются в список функций, которые можно оценить и проверить. Главная задача — не описать «всё, что хотелось бы», а отделить первую версию от будущих. Для приоритизации удобен метод MoSCoW: must have (без этого продукт не решает задачу), should have (важно, но можно выпустить без него), could have (приятно) и won't have (сознательно отложено).
Хорошие требования описывают поведение, а не реализацию: «пользователь может отменить запись не позднее чем за 2 часа до визита, после отмены слот снова доступен» — проверяемо; «удобная система записи» — нет. Подробная структура документа и типичные пробелы разобраны в статье «Техническое задание на мобильное приложение».
Что обязательно зафиксировать
- роли пользователей и права доступа;
- пользовательские сценарии первой версии и их приоритет;
- платформы: iOS, Android, веб, планшеты, минимальные версии ОС;
- интеграции: CRM, 1С, платёжный сервис, карты, телефония, существующий сайт;
- какие персональные данные собираются и где они хранятся;
- нефункциональные требования: скорость, работа без сети, доступность, число пользователей;
- кто и как будет наполнять контент и администрировать систему.
На этом этапе уже можно получить первую честную оценку бюджета. Почему «вилка» у разных исполнителей отличается в разы и как её сузить — в материале «Сколько стоит разработка мобильного приложения».
Этап 3. Прототип и дизайн
Прототип — самый дешёвый способ ошибиться. Изменить схему экранов в Figma занимает часы, изменить готовый экран в коде — дни. Поэтому дизайн обычно идёт в два шага. Подробно об артефактах этапа и юзабилити-тесте — в статье «Прототип и дизайн мобильного приложения».
- Карта экранов и вайрфреймы. Чёрно-белые схемы без цветов и иллюстраций: какие экраны есть, что на них расположено, как пользователь переходит от одного к другому. На этом шаге проверяется логика, а не красота.
- Кликабельный прототип и тест с пользователями. Дайте 5–7 людям из целевой аудитории выполнить задачу («запишитесь на пятницу к любому мастеру») и молча наблюдайте. Места, где человек остановился или ошибся, — главные кандидаты на переделку.
- Визуальный дизайн и UI-кит. Цвета, шрифты, компоненты, состояния (загрузка, ошибка, пустой список), тёмная тема, если она нужна. UI-кит экономит время разработки: кнопки и поля собираются один раз и переиспользуются.
- Адаптация под платформы. Навигация, жесты и системные элементы на iOS и Android устроены по-разному. Руководства Apple Human Interface Guidelines и Material Design от Google стоит учитывать, даже если у приложения собственный фирменный стиль.
Не забудьте про «скучные» экраны: онбординг, запрос разрешений, пустые состояния, ошибки сети, восстановление доступа, удаление аккаунта, настройки уведомлений. Их часто нет в макетах, и тогда разработчики придумывают их сами — непоследовательно и в последний момент.
Этап 4. Архитектура и выбор технологий
Архитектура отвечает на вопрос, из каких частей состоит система и как они общаются. Почти любое приложение, где есть аккаунты или общие данные, — это не только клиент на телефоне, но и серверная часть (бэкенд), база данных и панель администратора.
Ключевые решения этого этапа:
- Способ разработки клиента: нативно (Swift для iOS, Kotlin для Android), кроссплатформенно (Flutter, React Native, Kotlin Multiplatform) или как PWA. Сравнение с плюсами и ограничениями — в статье «Нативная или кроссплатформенная разработка».
- Бэкенд: собственный сервер, готовая платформа (BaaS) или доработка существующей системы компании. Готовые платформы ускоряют старт, но важно заранее проверить, где физически хранятся данные и можно ли будет переехать.
- API и интеграции: формат обмена данными, авторизация, что происходит при недоступности внешней системы.
- Хранение данных и безопасность: что хранится на устройстве, что на сервере, как шифруются токены и пароли, где находится база с персональными данными пользователей из России (требования 152-ФЗ разобраны в статье «Персональные данные в мобильном приложении»).
- Инфраструктура: хостинг, резервное копирование, мониторинг ошибок, среда для тестирования.
Результат этапа — схема компонентов, описание API (хотя бы черновое), выбранный стек и список рисков. Если проект передаётся подрядчику, попросите включить эти документы в состав результата: без них поддерживать и развивать приложение силами другой команды будет заметно дороже.
Этап 5. Разработка
Самый длинный этап. В большинстве команд он организован итерациями (спринтами) по 1–2 недели: в начале итерации выбираются задачи, в конце показывается работающий результат. Для заказчика это главный инструмент контроля — вы видите прогресс в виде сборки, которую можно установить на свой телефон, а не в виде процентов в отчёте.
Как понять, что разработка идёт нормально
- каждую итерацию есть тестовая сборка (через TestFlight для iOS, закрытое тестирование в Google Play или прямую установку APK для Android);
- задачи и их статус видны в трекере, а не только в переписке;
- код хранится в репозитории, к которому у заказчика есть доступ;
- решённые вопросы фиксируются письменно — в задаче или в документе требований;
- изменения объёма обсуждаются явно: «добавляем фильтр — сдвигаем срок на неделю или убираем что-то другое».
Параллельно с клиентом разрабатывается серверная часть и панель администратора. Частая ошибка — оставлять админку «на потом»: без неё контент приходится добавлять вручную через базу данных, и запуск откладывается.
Этап 6. Тестирование
Мобильное приложение работает в условиях, которые невозможно полностью воспроизвести на компьютере разработчика: десятки моделей устройств, разные версии ОС, медленный или пропадающий интернет, входящие звонки, экономия заряда, крупный шрифт в настройках. Поэтому тестирование — отдельный этап с отдельным бюджетом. Виды проверок, выбор устройств и приёмка разобраны в статье «Тестирование мобильного приложения».
| Вид проверки | Что ищем |
|---|---|
| Функциональное тестирование | Соответствие требованиям: сценарии работают так, как описано в ТЗ |
| Тестирование на устройствах | Вёрстка на маленьких и больших экранах, старые версии ОС, разные производители Android |
| Сеть и прерывания | Поведение без интернета, при переключении сети, при звонке и сворачивании |
| Производительность | Время запуска, плавность прокрутки, расход батареи и трафика |
| Безопасность | Хранение токенов, передача данных только по HTTPS, права доступа на сервере |
| Доступность | Работа с экранным диктором, крупным шрифтом, достаточный контраст |
| Бета-тест | Реальные сценарии небольшой группы пользователей до публичного релиза |
Для публикации в Google Play у новых личных аккаунтов разработчика есть отдельное требование: перед выходом в продакшн приложение должно пройти закрытое тестирование минимум с 12 участниками в течение 14 дней подряд. Это стоит учесть в графике заранее.
Этап 7. Публикация в магазинах приложений
Публикация — короткий, но насыщенный формальностями этап. Пошаговый разбор для каждого магазина — в статье «Публикация приложения в RuStore, App Store и Google Play». Для российских проектов основными каналами в 2026 году обычно становятся RuStore, App Store и Google Play; для части аудитории — также AppGallery и магазины производителей смартфонов.
Что нужно подготовить заранее:
- аккаунты разработчика в каждом магазине (оформление аккаунта организации может занять от нескольких дней до нескольких недель);
- название, описание, ключевые слова, скриншоты и иконку;
- политику конфиденциальности по постоянному адресу и описание собираемых данных;
- тестовый аккаунт для модераторов, если в приложении есть авторизация;
- актуальные технические требования: например, Google Play с 31 августа 2026 года принимает новые приложения и обновления только с целевым API level 36 (Android 16), а App Store с 28 апреля 2026 года — сборки, сделанные в Xcode 26 с SDK iOS 26.
Модерация может вернуть приложение на доработку, поэтому дату публичного запуска лучше назначать с запасом в 1–2 недели после отправки на проверку.
Этап 8. Поддержка и развитие
После релиза работа не заканчивается, а меняет характер. Подробно о том, что входит в сопровождение, — в статье «Поддержка мобильного приложения после релиза», а о том, какие показатели отслеживать, — в статье «Метрики мобильного приложения». Каждый год Apple и Google выпускают новые версии ОС и поднимают требования магазинов; библиотеки устаревают; пользователи находят ошибки, которые не поймал ни один тест. Приложение, которое не обновлялось год-два, рискует перестать корректно работать на новых устройствах или потерять возможность выпускать обновления.
Минимальный набор поддержки: мониторинг сбоев (crash reporting), продуктовая аналитика, регулярные обновления зависимостей, проверка на бета-версиях новых ОС, резервное копирование серверных данных и канал обратной связи от пользователей. Всё остальное — развитие: новые функции по результатам аналитики и отзывов.
Сколько времени занимают этапы
Сроки зависят от объёма и от того, насколько быстро заказчик принимает решения. Ориентиры ниже — не обещание, а способ проверить реалистичность плана: если вам предлагают сделать приложение с личным кабинетом, оплатой и интеграцией с 1С за три недели, стоит уточнить, что именно будет сделано.
| Тип проекта | Пример | Ориентир по срокам |
|---|---|---|
| Прототип для проверки идеи | Кликабельный макет без кода или простое приложение на готовых сервисах | 2–6 недель |
| MVP с одним основным сценарием | Запись к специалисту, каталог с заявкой, простой трекер | 2–4 месяца |
| Приложение среднего масштаба | Личный кабинет, оплата, уведомления, интеграция с CRM | 4–8 месяцев |
| Сложная система | Маркетплейс, финтех, приложение для курьеров с диспетчерской | от 8 месяцев, дальше непрерывно |
Сократить срок без потери качества помогает не ускорение разработчиков, а уменьшение объёма первой версии. Как выбрать этот объём, объясняет статья «MVP мобильного приложения».
Типичные ошибки на пути от идеи к релизу
- Начинать с выбора подрядчика, а не с задачи. Без описания сценариев разные исполнители оценивают разные продукты, и сравнивать их предложения бессмысленно.
- Раздувать первую версию. Каждая «маленькая» функция добавляет экраны, тесты и поддержку. Функции, которыми пользуется 5% аудитории, лучше добавить после запуска, если в них появится реальная потребность.
- Экономить на тестировании. Ошибки в приложении, установленном у пользователей, исправлять дольше, чем на сайте: обновление проходит модерацию, а часть людей не обновляется неделями.
- Не иметь доступа к своим активам. Исходный код, аккаунты разработчика в магазинах, серверы и домены должны быть оформлены на заказчика или быть ему доступны.
- Не планировать поддержку. Бюджет на год после релиза нужно закладывать сразу, иначе приложение быстро устареет.
- Не измерять результат. Без аналитики невозможно понять, достигнуты ли критерии успеха из первого этапа.
Чек-лист готовности к разработке
- Сценарии и пользователи описаны письменно
- Первая версия ограничена списком must have
- Прототип проверен хотя бы на пяти пользователях
- Выбраны платформы и способ разработки
- Понятно, какие данные собираются и где хранятся
- Есть бюджет на тестирование и год поддержки
- Аккаунты, код и серверы принадлежат заказчику
Частые вопросы
Можно ли пропустить этап дизайна и сразу писать код?
Для внутреннего инструмента на несколько человек иногда можно ограничиться вайрфреймами и готовыми системными компонентами. Для продукта, который должен конкурировать за внимание клиентов, отказ от прототипа обычно приводит к переделкам уже в коде, а это дороже.
Кто должен писать техническое задание — заказчик или разработчик?
Цели, сценарии и ограничения может описать только заказчик. Техническую часть — архитектуру, API, нефункциональные требования — удобнее готовить вместе с исполнителем. Часто это оформляют как отдельный оплачиваемый этап аналитики перед разработкой.
Сколько итераций разработки нужно до релиза?
Для MVP обычно 4–10 двухнедельных итераций, но важнее не число, а то, что после каждой есть работающая сборка. Если несколько итераций подряд показать нечего, это повод разобраться в причинах.
Нужно ли сразу выпускать приложение и для iOS, и для Android?
Зависит от аудитории. В России у Android большая доля устройств, но в отдельных сегментах клиентов доля iPhone высокая. Кроссплатформенные технологии позволяют выпустить обе версии с меньшими затратами, чем две отдельные нативные разработки.
Когда начинать думать о продвижении?
До релиза. Страница в магазине, скриншоты, описание и канал, через который первые пользователи узнают о приложении, готовятся параллельно с тестированием. Приложение без плана привлечения пользователей после публикации почти никто не находит.
Что делать, если требования меняются во время разработки?
Это нормально. Важно, чтобы изменение объёма сопровождалось явным решением о сроке и бюджете: что-то добавляется — что-то сдвигается или убирается. Итерационная разработка как раз рассчитана на такие изменения.
Итог
Этапы разработки нужны не ради бюрократии, а чтобы каждое дорогое решение принималось на основе более дешёвой проверки: интервью перед ТЗ, прототип перед кодом, бета-тест перед публичным релизом, аналитика перед новыми функциями. Если каждый этап заканчивается понятным результатом — документом, прототипом, сборкой, — проект остаётся управляемым, даже когда требования меняются.