Разработка приложения по этапам: как принимать результат и управлять изменениями

03.11.2026 Эксперт 15 мин чтения

---

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

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

Приёмка по этапам: что заказчик проверяет и подписывает

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

Со стороны заказчика в приёмке участвуют три роли: ответственный за бизнес-требования, ответственный за ИТ-часть (интеграции, доступы, данные) и будущий ежедневный пользователь. Замечания отсутствующей роли приходят после запуска и стоят дороже: они затрагивают выпущенный продукт.

Результат этапа и критерии приёмки: из чего они состоят

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

Критерий приёмки отвечает на один вопрос: при каком условии заказчик обязан принять работу. Проверяемый критерий даёт ответ «да» или «нет» и проходится заказчиком самостоятельно.

Свойства критерия приёмки и формулировки, которые их нарушают

Критерии формулируют до начала этапа: написанные после, они превращаются в пересказ того, что получилось.

Этап 1. Предпроектное исследование и требования

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

Что входит в этап

• Интервью с владельцами процессов и сбор ограничений.
• Цели продукта и показатели для их измерения — вместе с оценкой окупаемости до начала разработки.
• Перечень сценариев первой версии с границами объёма — пример состава даёт архитектура приложения розничной сети.
• Инвентаризация внешних систем: учётная система, оплата, доставка, аналитика, программа лояльности, — и проверка того, как сценарии ложатся на омниканальную архитектуру.
• Выбор технологии и целевых платформ: матрица выбора между Flutter и нативной разработкой.
• Матрица ответственности: кто согласует, даёт доступы, принимает этапы.

Результат этапа

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

Критерии приёмки

• Каждый сценарий первой версии описан с условиями старта, шагами и ожидаемым результатом.
• Для каждой внешней системы указан способ обмена данными и владелец доступа.
• Объём разделён: «входит в первую версию» и «вынесено в развитие».
• Цели выражены показателями, измеримыми после запуска.
• Документ подписан бизнес-заказчиком и ответственным за ИТ.

Этап 2. Прототип и дизайн

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

Что входит в этап

• Карта пользовательских путей по экранам.
• Кликабельный прототип сценариев каталога, карточки товара, корзины и оформления заказа — часть черновой работы закрывают инструменты быстрого прототипирования.
• Проверка узких мест оформления заказа по сценариям UX-аудита брошенной корзины.
• Финальные макеты на все экраны согласованного перечня.
• Дизайн-система: цвета, типографика, отступы, состояния.
• Передача дизайна в разработку с описанием поведения элементов и ошибок.

Результат этапа

Кликабельный прототип, комплект согласованных макетов и дизайн-система с описанием состояний компонентов. Дальше макеты работают как эталон на приёмке разработки.

Критерии приёмки

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

Этап 3. Разработка и интеграции

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

Что входит в этап

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

Результат этапа

Работающие сценарии на тестовой среде и описание интерфейса, по которому заказчик проверяет обмен данными с внешними системами.

Критерии приёмки

• Сценарии итерации проходятся на тестовой среде без обходных действий.
• Заказ из приложения приходит в учётную систему с тем же составом, суммой и доставкой.
• Цены и остатки совпадают с учётной системой после обновления.
• Оплата проходит в тестовом режиме, статус заказа меняется сам.
• Доступы к средам, репозиторию и панелям оформлены на юридическое лицо заказчика.

Этап 4. Тестовый выпуск на ограниченной группе

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

Что входит в этап

• План тестирования: сценарии, набор устройств, версии iOS и Android.
• Проверка на устройствах с разными экранами и версиями систем — по принципам эффективного тестирования.
• Поведение под нагрузкой перед высоким спросом: что проверять в нагрузочном тестировании.
• Повторные проверки после исправлений — часть закрывает автоматизация проверок.
• Распространение закрытых версий: TestFlight для iOS, закрытое тестирование в Google Play для Android.
• Сбор обратной связи и регистрация дефектов по уровням важности.

Результат этапа

Установочный пакет, прошедший план тестирования, и журнал дефектов с уровнем важности и статусом у каждой записи.

Критерии приёмки

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

Этап 5. Промышленный запуск

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

Что входит в этап

• Подготовка карточек приложения и материалов для проверяющих.
• Публикация в App Store, Google Play, RuStore и других сторах под целевую аудиторию проекта.
• Прохождение модерации и ответы на замечания проверяющих. Требования публикует сам сторе: для iOS это правила проверки App Store, для Android — справка Google Play Console, для RuStore — документация для разработчиков. Редакцию сверяют на дату подачи: требования меняются без предупреждения.
• Включение мониторинга сбоев и отчётов о падениях.
• Передача доступов: аккаунты разработчика, аналитика, боевая среда.
• План поддержки: порядок обращений, время реакции, состав работ после запуска.

Результат этапа

Приложение, опубликованное в целевых сторах проекта, с переданными доступами, мониторингом и подписанным планом поддержки.

Критерии приёмки

• Приложение доступно для установки в каждом сторе перечня.
• Доля сессий без сбоев отслеживается, отчёт доступен заказчику.
• Доступы к аккаунтам разработчика и аналитике проверены входом.
• Сценарий оформления заказа пройден на боевых данных с реальной оплатой.
• План поддержки подписан, порядок обращений известен сотрудникам.

Демонстрации: как проверять результат по ходу работ

Демонстрация — встреча в конце итерации (спринта), на которой команда показывает работающий продукт на устройстве. От приёмки она отличается последствиями: приёмка закрывает отрезок работ юридически, демонстрация даёт промежуточную картину и возможность поменять приоритеты, пока объём не закрыт.

Содержание демонстрации

• Работающие сценарии на устройстве или в тестовой среде — показ идёт на самом продукте.
• Сопоставление с перечнем работ итерации: что сделано, что перенесено и почему.
• Открытые вопросы, которые блокируют работу.
• Состояние журнала дефектов: сколько записей открыто, какого уровня.

Состав протокола демонстрации

• Дата, участники, перечень показанных сценариев.
• Замечания заказчика с отметкой типа: дефект, уточнение или изменение.
• Решения по приоритетам на следующую итерацию.
• Действия с ответственными на стороне заказчика и команды.

Из протокола потом вырастают запросы на изменение. Без него замечание «мы же договорились на демонстрации» не имеет формы.

Запрос на изменение: как провести правку без спора о бюджете

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

Дефект, уточнение и изменение: как различать

Три типа обращений заказчика и порядок работы с каждым

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

Порядок прохождения запроса на изменение

1. Регистрация. Заказчик описывает, что должно работать иначе и зачем — в терминах результата, а не решения.
2. Оценка влияния. Команда показывает, как изменение отражается на объёме работ, сроке, стоимости и принятых этапах.
3. Решение заказчика: внести сейчас, вынести в развитие после запуска, отказаться.
4. Фиксация. Изменение дописывается в техническое задание и в критерии приёмки затронутых этапов.
5. Пересчёт плана. Перечень работ итераций обновляется, демонстрации переносятся.

Один пункт стоит закрепить до старта: предельная доля изменений, которую проект принимает без пересмотра срока. Без неё правки накапливаются до момента, когда срок становится недостижимым.

Fixed Price и Time & Materials: как разделить работы

Модель расчётов определяет, кто несёт риск неточной оценки. При фиксированной стоимости (Fixed Price) риск у исполнителя, при оплате по отработанным часам (Time & Materials) — у заказчика. Поэтому модель выбирают не одну на весь проект, а по этапам.

Fixed Price: когда модель работает

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

Time & Materials: когда модель работает

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

Распределение работ по этапам

Какая модель расчётов чаще подходит каждому этапу проекта

Итог: приёмка и изменения на одной странице

Результат этапа и главный критерий его приёмки

Что проверить на своём проекте

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

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