Этапы разработки мобильного приложения

Если коротко: разработка приложения проходит семь этапов — аналитика, техническое задание с прототипом, UX/UI-дизайн, разработка, тестирование, публикация в сторах и поддержка. Каждый этап заканчивается конкретным результатом, который можно принять и пощупать: не «мы поработали неделю», а документ, кликабельный прототип, макеты, рабочая сборка, отчёт о тестировании, приложение в App Store и RuStore. Пропустить можно почти любой — вопрос лишь в том, на каком из следующих этапов это придётся оплатить переделкой. Ниже — что происходит на каждом, что вы получаете на выходе и где заказчики чаще всего теряют деньги.

Code Pilots с 2014 года проектирует и разрабатывает мобильные приложения, в том числе нагруженные продукты вроде VK Fest (50 000 установок за первые двое суток) и платформы GigAnt, и по умолчанию работает на Flutter. За это время через нас прошли десятки проектов от однодневного MVP до систем, которые живут и растут годами, — и мы хорошо видим, где процесс экономит деньги, а где его пытаются срезать и потом переплачивают. Материал написан для основателя или продакта, который заказывает приложение и хочет понимать, что реально происходит внутри проекта, а не только видеть счёт в конце.

Этапы — это не бюрократия подрядчика и не способ растянуть смету. Это контрольные точки, в которых заказчик видит результат и решает, идём дальше или правим сейчас, пока правка стоит дёшево. Ошибка, найденная на аналитике, стоит одного разговора. Та же ошибка, найденная после разработки, стоит переписанного кода и сдвинутого релиза. Вся логика этапности — двигать проверку как можно ближе к началу, потому что цена изменения растёт с каждым пройденным этапом.

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

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

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

Хороший аналитик здесь экономит больше денег, чем кто-либо дальше по цепочке. Он отсекает функции, которые звучат красиво, но никому не нужны, находит сценарии, о которых заказчик не подумал, и переводит бизнес-желания в технические требования. Для нагруженных продуктов уже здесь закладываются вопросы масштаба и интеграций — то, что потом определит архитектуру.

Что у вас на выходе: концепция продукта, карта функций (что и в каком приоритете), верхнеуровневая оценка сроков и состава команды. Этого достаточно, чтобы принять решение о запуске проекта осознанно, а не на энтузиазме.

Аналитика отвечает на вопрос «что делаем и зачем», ТЗ — на вопрос «как именно это должно работать». В техзадании фиксируются функции, роли пользователей, бизнес-логика и сценарии: что происходит при регистрации, что видит пользователь без интернета, как ведёт себя приложение при ошибке оплаты. Чем детальнее зафиксированы сценарии, тем меньше разночтений на разработке, где каждое «а мы думали, будет по-другому» стоит времени и денег.

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

Что у вас на выходе: техническое задание, по которому можно проверять готовый продукт, и кликабельный прототип ключевых экранов. С этого момента у проекта есть чёткий контур, а не «сделаем — увидим».

Дизайн мобильного приложения — это не «сделать красиво», а спроектировать поведение: как пользователь проходит сценарии, что видит в каждом состоянии экрана (загрузка, пустой список, ошибка, успех), как приложение выглядит на маленьком и большом экране. На выходе дизайнер отдаёт не просто набор картинок, а систему: макеты всех экранов и UI-kit — переиспользуемые компоненты (кнопки, поля, карточки), из которых собирается интерфейс. Дизайн-система ускоряет и разработку, и будущие доработки, потому что новые экраны собираются из готовых деталей, а не рисуются с нуля.

На iOS и Android есть свои нормы интерфейса, и хороший дизайн их учитывает, а не тащит один макет на обе платформы дословно. Детали UX/UI, исследований и дизайн-системы раскрыты в профильных статьях — на уровне этапов достаточно понимать, что качественный дизайн закрывает не только «как выглядит», но и «как себя ведёт в неочевидных ситуациях».

Что у вас на выходе: макеты всех экранов во всех ключевых состояниях и дизайн-система. Это то, что разработчик превращает в интерфейс, и то, по чему вы принимаете визуал до того, как за него заплатили разработкой.

Здесь проект обретает код. Перед тем как писать функции, команда закладывает архитектуру — то, как внутри разделены интерфейс, бизнес-логика и данные. Это невидимая пользователю часть, которая определяет, легко ли будет добавлять функции и менять команду через год; подходы и паттерны разобраны в отдельной статье про архитектуру. Выбор технологии тоже относится сюда: мы по умолчанию работаем на Flutter (одна кодовая база на iOS и Android), нативку Swift и Kotlin берём под особые задачи.

Разработка обычно делится на две части, которые идут во многом параллельно. Бэкенд — серверная логика, база данных, API, админка: то, что живёт на сервере и с чем приложение общается. Клиент — само мобильное приложение, которое ставят на телефон. Плюс интеграции: платежи, карты, пуш-уведомления, аналитика, сторонние сервисы. Работа идёт итерациями (спринтами): каждые одну-две недели появляется собранная версия, которую можно потрогать, а не ждать финала месяцами вслепую. Регулярные демо на этом этапе — не формальность, а способ заказчика держать руку на пульсе и ловить расхождения с ожиданием рано.

Что у вас на выходе: работающие сборки, которые растут от спринта к спринту, — от первого экрана до функционально полной версии, готовой к тестированию.

Мобильное тестирование сложнее вебового по одной причине — устройств слишком много. Одно и то же приложение должно одинаково работать на свежем iPhone и на трёхлетнем Android с урезанной памятью, на маленьком экране и на планшете, на быстром Wi-Fi и в метро без связи, на актуальной версии ОС и на той, что вышла пару лет назад. Проверить это на эмуляторе недостаточно — нужны реальные устройства, потому что именно на них вылезают подтормаживания, съехавшая вёрстка и разряжающие батарею фоновые процессы.

QA проверяет функциональность (всё ли работает по сценариям из ТЗ), совместимость (разные устройства и версии ОС), поведение на плохой сети и при прерываниях (звонок во время оплаты), а перед релизом прогоняет регресс — убеждается, что новые правки не сломали то, что уже работало. Найденные дефекты фиксируются, чинятся, перепроверяются. Этап, который заказчики любят урезать «ради сроков», — и именно он потом всплывает однозвёздочными отзывами в сторе.

Что у вас на выходе: отчёт о найденных и исправленных дефектах и стабильная сборка, которую не стыдно показывать пользователям.

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

Три площадки, три разных истории:

Релиз — это не финиш, а точка, с которой начинается жизнь продукта. Выходят новые версии iOS и Android, и приложение нужно под них адаптировать, иначе оно однажды перестанет запускаться. Появляются отзывы и метрики, по которым видно, где пользователи спотыкаются. Растёт нагрузка, всплывают баги, которые не поймали на тесте, копятся идеи новых функций. Поддержка — это и техническое сопровождение (чтобы работало), и развитие (чтобы продукт двигался за пользователем и бизнесом).

Для продукта, который задуман надолго, поддержка — не строчка в конце сметы, а основной этап по времени и вложениям: разработка длится месяцы, а жизнь приложения — годы. Именно поэтому так важно, как пройдены предыдущие этапы: на хорошей архитектуре и с нормальным ТЗ развитие идёт предсказуемо, на «god object без документации» каждое обновление превращается в риск.

Что у вас на выходе: работающее приложение, которое обновляется, не отстаёт от платформ и растёт по метрикам, а не застывает в версии 1.0.

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

Строгий «водопад», где каждый этап полностью завершается до следующего, в мобильной разработке скорее миф — гибкий итеративный подход почти всегда выигрывает. Как именно устроены модели жизненного цикла (waterfall, agile, спираль) и когда какая уместна — это тема жизненного цикла разработки ПО, ей посвящён отдельный материал. Для понимания этапов достаточно запомнить: границы между ними подвижны, и это правильно.

Одна и та же вывеска «разработка приложения» скрывает и трёхнедельный MVP, и годовой highload-проект, поэтому назвать универсальные сроки нельзя — они зависят от нескольких факторов. Точную оценку под конкретную задачу мы считаем по вашим требованиям за пару дней; вопрос «сколько это стоит и почему» вынесен в отдельную статью. Что реально двигает длительность каждого этапа:

• Сложность бизнес-логики. Каталог с корзиной и маркетплейс с расчётами между сторонами — разные вселенные по объёму разработки и тестирования.
• Количество интеграций. Каждый внешний сервис — платежи, карты, госсистемы, CRM — это отдельная работа и отдельная точка отказа, которую надо проверить.
• Число платформ. iOS плюс Android плюс веб-версия — больше поверхности для дизайна, разработки и тестов (кроссплатформа на Flutter здесь экономит, но не отменяет проверку на всех устройствах).
• Готовность на стороне заказчика. Нет контента, нет решений по спорным сценариям, долго согласуются макеты, поздно оформляются доступы к сторам — сроки плывут не по вине команды.

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

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

Каждый этап должен заканчиваться приёмкой: вы получаете конкретный результат из таблиц выше, сверяете его с тем, что планировали, и только тогда команда идёт дальше. Это дисциплина, которая защищает обе стороны — заказчик не платит за воздух, подрядчик не переделывает всё в конце из-за накопленных недоговорённостей. Расплывчатое «ну вроде норм, продолжайте» без фиксации результата — прямая дорога к спору на финале.

Отдельный вопрос, о котором вспоминают слишком поздно: кому принадлежит то, что сделано. Здоровая практика — репозиторий с кодом и аккаунты разработчика (Apple, Google, RuStore) оформлены на заказчика или переданы ему, а не заперты у подрядчика. Тогда смена команды — это неприятность, а не потеря продукта. Мы работаем именно так: код и доступы ваши, без привязки к нам как к единственному, кто может тронуть проект. Как принимать финальный результат и что забрать при передаче — подробнее в гайде по созданию приложения.

Порядок разумного старта такой: сформулировать задачу и не пропускать аналитику, даже если руки чешутся сразу «делать»; зафиксировать функционал в ТЗ и пройти его прототипом до строчки кода; принимать каждый этап по конкретному результату, а не на словах; заранее оформить аккаунты в сторах на себя; закладывать поддержку в план с самого начала, а не после релиза. И держать в голове главное — цена изменения растёт с каждым этапом, поэтому проверять и спорить выгоднее в начале.

Самое дорогое в приложении — не написать первую версию, а довести её до пользователя и развивать годами; и именно выстроенный процесс определяет, пройдёт это гладко или превратится в бесконечную переделку. Code Pilots ведёт проект по всем этапам силами senior-команды — аналитики, дизайнеры, разработчики на Flutter и нативке, QA и DevOps внутри, — с приёмкой на каждом шаге и кодом, который остаётся вашим. Расскажите о задаче — соберём план этапов и оценку под ваш продукт за пару дней.