Сроки разработки мобильного приложения: способы проверки обещаний подрядчика

На выходе — перенос релиза, рост бюджета, конфликт по scope.

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

Нормативы разработки: что считать базовой линией

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

MVP обычно занимает 3–4 месяца. Полноценный продукт со сложной функциональностью — 8–12 месяцев. Это не включает произвольный набор функций. Это средний коридор для проекта, где есть аналитика, дизайн, backend, мобильная разработка, тестирование, релизная подготовка.

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

• аналитика и проектирование;
• прототипирование пользовательских сценариев;
• интеграции с внешними API;
• нагрузочные ограничения backend;
• тестирование на устройствах;
• исправление дефектов после первой сборки;
• публикация в App Store и Google Play;
• резерв на изменения требований.

Срок разработки IT-проекта проверяется не вопросом «успеете ли». Проверяется разложением на work packages.

Базовая структура мобильного проекта:

Эти цифры нужны не для спора с подрядчиком. Они нужны для выявления расхождений. Если оценка отличается от базовой линии в два раза, подрядчик должен объяснить архитектурную причину. Не общую. Конкретную.

Допустимые причины сокращения срока:

• используется готовый backend или BaaS;
• нет личного кабинета и ролей;
• нет платежей;
• нет офлайн-режима;
• нет сложных push-сценариев;
• одна платформа;
• дизайн основан на готовом UI-kit;
• интеграции уже документированы и доступны в sandbox;
• команда выделена full-time, без параллельных проектов.

Недопустимые причины:

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

Сжатый срок без сжатого scope — это не план. Это долг, перенесенный в середину проекта.

Аналитика и проектирование: почему 20–25 рабочих дней не являются бюрократией

Этап аналитики часто режут первым. Ошибка системная. Именно здесь формируется стоимость изменения.

20–25 рабочих дней на сбор информации, аналитику, ТЗ и навигационную карту экранов — нормальный диапазон для проекта, где заказчик ожидает управляемый результат. За это время подрядчик должен перевести бизнес-описание в инженерные сущности.

На выходе должны быть не «общие требования». Должны быть артефакты:

1. Карта ролей. Пользователь, администратор, оператор, курьер, менеджер, модератор. Если роли не описаны, не оценены права доступа и edge cases.

2. User flows. Основные маршруты. Регистрация, авторизация, восстановление доступа, создание заявки, оплата, отмена, повторное действие.

3. Карта экранов. Список экранов и переходов. Без нее оценка дизайна и frontend-разработки является оценкой воздуха.

4. Список интеграций. CRM, ERP, платежный шлюз, SMS, email, карты, аналитика, push-сервисы, внутренние API.

5. Модель данных верхнего уровня. Сущности, связи, статусы, жизненные циклы.

6. Нефункциональные требования. SLA, целевые платформы, минимальные версии iOS и Android, требования к безопасности, логированию, аналитике.

7. Границы MVP. Что входит в первый релиз. Что уходит в backlog. Что запрещено добавлять без пересчета.

Если подрядчик оценивает разработку до этих артефактов, он делает вероятностную ставку. Иногда ставка выигрывает. Чаще нет.

Критичный признак заниженных сроков разработки ПО — отсутствие вопросов по ограничениям. Архитектурный комитет в такой ситуации смотрит не на итоговую дату. Он смотрит на качество вопросов подрядчика.

Нормальный подрядчик уточняет:

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

Слабый подрядчик сразу дает срок. Обычно короткий.

Дизайн-макеты и адаптация: расчет времени на визуальную часть

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

Для одной мобильной платформы дизайн занимает 3–7 недель. Средний ориентир — около 4 недель. Разброс зависит от количества экранов, состояния компонентов и зрелости требований.

Ошибочная оценка выглядит так: «20 экранов умножить на 1 день». Этот расчет не работает. Экран не равен задаче. У экрана есть состояния.

Пример для экрана списка заказов:

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

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

Адаптация дизайна под вторую платформу обычно требует на 40–60% меньше времени, чем первая платформа. Не ноль. iOS и Android имеют разные паттерны навигации, системные элементы, разрешения, поведение back, push permission flow, обработку биометрии, правила публикации.

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

Минимальный состав дизайн-пакета для адекватной разработки:

• UI-kit или дизайн-система с компонентами;
• сетки и отступы;
• состояния кнопок и форм;
• ошибки валидации;
• empty states;
• loading states;
• модальные окна;
• push permission и системные разрешения;
• темная тема, если она входит в scope;
• адаптация под основные размеры экранов;
• спецификация анимаций, если они есть;
• экспорт ассетов;
• правила локализации, если приложение мультиязычное.

Расчет времени на разработку приложения ухудшается, когда дизайн оторван от backend. Типовая ситуация: макет содержит данные, которых нет в API. После старта разработки выясняется, что нужно менять модель данных, endpoints, админку. Срок frontend не сокращается. Срок backend растет.

Практичный способ проверки: взять 3–5 ключевых экранов и пройти их до API-контрактов. Если по каждому экрану можно назвать endpoint, поля, статусы ошибок и события аналитики, проект готов к оценке. Если нельзя — срок является предварительным.

Экран без состояний не является экраном для оценки. Это иллюстрация.

Первая сборка через 2–4 недели: что она должна доказывать

Первая рабочая сборка обычно появляется через 2–4 недели после старта программирования. Это не релиз. Не beta. Не «почти готово». Это технический checkpoint.

Ее задача — подтвердить, что команда собрала контур разработки:

• репозиторий;
• CI/CD;
• окружения dev/stage;
• базовую архитектуру приложения;
• авторизацию или иной ключевой сценарий;
• подключение к backend или mock-server;
• логирование;
• crash reporting;
• установку на тестовые устройства;
• базовую навигацию.

Если через 4 недели нет installable build, нужно разбирать причину. Нормальные причины бывают. Например, доступ к API выдали позже. Или App Store Connect не настроен со стороны заказчика. Но причина должна быть документирована как блокер.

Плохие признаки:

• показывают только Figma вместо сборки;
• демонстрируют видео, а не установочный билд;
• нет changelog;
• нет списка реализованных задач;
• нет дефектов в трекере;
• сборка запускается только у разработчика;
• нет разделения dev/stage/prod;
• отсутствует владелец backend-интеграции.

Первая сборка нужна для контроля скорости. Не для приемки продукта. На этом этапе видно, насколько оценка совпадает с фактическим velocity.

Нужно сравнивать:

Сроки разработки IT-проекта проверяются через фактические инкременты. Не через статус-встречи. Статус «идем по плану» без сборки и трекера не имеет архитектурной ценности.

Метод PERT: защита от оптимистичной оценки

Подрядчики часто дают одну цифру: «10 недель». Такая оценка непригодна для управления риском. Нужен диапазон.

Метод PERT дает среднюю трудоемкость через три оценки:

E = (P + 4M + O) / 6

Где:

• P — пессимистическая оценка;
• M — наиболее вероятная оценка;
• O — оптимистическая оценка;
• E — расчетное ожидание.

Важно: порядок букв в формуле может выглядеть непривычно, но смысл простой. Оптимизм имеет меньший вес. Наиболее вероятная оценка имеет вес 4. Пессимизм учитывает риск.

Пример. Подрядчик оценивает разработку авторизации:

• O: 3 дня, если все API готовы;
• M: 5 дней, если будет стандартная интеграция;
• P: 10 дней, если появятся проблемы с SMS, refresh token и edge cases.

Расчет:

E = (10 + 4×5 + 3) / 6 = 5,5 дня.

Если в плане стоит 3 дня, подрядчик заложил оптимистичный сценарий. Не средний.

PERT полезен на уровне блоков:

Таблица не дает абсолютной истины. Она вскрывает модель мышления подрядчика. Если команда не может назвать O/M/P, значит она не видит риски. Если P отличается от M в 3–4 раза, блок требует декомпозиции или spike.

Для проверки сроков создания мобильного приложения нужно применять PERT не ко всему проекту одной строкой. Нужно считать по эпикам:

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

Затем добавляется резерв на интеграционные дефекты. Не «на всякий случай». По факту зависимостей.

Типовые факторы, которые увеличивают P:

• нет финального API;
• API делает другая команда;
• нет тестового стенда;
• платежный провайдер требует согласований;
• есть персональные данные;
• есть офлайн-режим;
• нужен realtime;
• есть мультиязычность;
• приложение должно работать на старых версиях ОС;
• требуется миграция данных;
• есть сложная роль администратора;
• нет product owner с правом быстро принимать решения.

Если подрядчик не включает эти факторы в P, он продает календарь, а не план.

Нативная и кроссплатформенная разработка: где срок действительно меняется

Кроссплатформенный стек может сократить время. Но не автоматически и не в два раза. Утверждение «Flutter/React Native дадут один код на две платформы, значит срок пополам» некорректно.

Сокращается часть работ:

• общий UI-слой;
• часть бизнес-логики;
• интеграция с API;
• единая команда;
• часть тестирования функциональных сценариев.

Не исчезают:

• платформенные разрешения;
• push-уведомления;
• платежи и in-app purchase;
• работа с камерой, файлами, геолокацией;
• публикация в stores;
• device-specific bugs;
• различия в навигации;
• performance tuning;
• регрессионное тестирование на iOS и Android.

Для простого MVP кроссплатформа часто рациональна. Для продукта с высокой нагрузкой на native API, сложной графикой, realtime, background mode или специфичными SDK нужно считать отдельно.

Архитектурный вопрос не «что быстрее». Вопрос: где больше риска для SLA, поддержки и найма команды.

Сравнение для оценки сроков:

Для проверки обещаний подрядчика нужно запросить раздельную оценку:

• общая часть;
• iOS-specific;
• Android-specific;
• backend;
• QA;
• release management;
• DevOps/CI/CD;
• поддержка после релиза.

Если подрядчик дает одну строку «мобильное приложение — 480 часов», оценка непроверяема. Она не проходит аудит.

Юридическая фиксация этапов: календарь должен быть управляемым

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

Это нормальная модель для проекта с неопределенностью. Она снижает конфликт. Стороны не делают вид, что в первый день знают все детали последнего релиза.

Фиксировать нужно не только дату. Нужно фиксировать состав результата.

Для каждого этапа в ДС должны быть:

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

Пример плохой формулировки:

«Разработка мобильного приложения — 60 рабочих дней».

Пример рабочей формулировки:

«Этап 2. UX/UI-дизайн iOS-версии. Результат: интерактивный прототип, макеты 35 экранов, состояния ошибок и загрузки, UI-kit, спецификация компонентов. Срок: 25 рабочих дней с момента утверждения карты экранов. Замечания заказчика предоставляются в течение 3 рабочих дней. Изменение состава экранов более чем на 10% оформляется отдельной оценкой».

Разница существенная. Во втором варианте есть объект приемки. В первом — только повод для спора.

Срыв дедлайна часто возникает не из-за разработки. Он возникает из-за неуправляемого change request. Заказчик добавляет функции. Подрядчик соглашается устно. Календарь остается прежним. Через месяц обе стороны считают, что правы.

Правильная модель:

1. Новое требование попадает в backlog.

2. Подрядчик оценивает влияние на сроки и стоимость.

3. Product owner выбирает: добавить сейчас, заменить существующую функцию или перенести.

4. Изменение фиксируется в ДС или change request.

5. План пересчитывается.

Без этого «гибкость» превращается в неконтролируемое расширение scope.

Признаки заниженной оценки: что видно до подписания договора

Заниженные сроки разработки ПО имеют повторяющиеся признаки. Они видны до старта.

Список для аудита коммерческого предложения:

• Нет этапа аналитики. Значит, требования будут уточняться во время разработки. Сроки будут двигаться.
• Нет карты экранов. Значит, frontend и дизайн оценены без объема.
• Нет отдельной строки QA. Значит, тестирование спрятано в разработку или будет сокращено.
• Нет backend-оценки. Значит, мобильное приложение считают отдельно от системы, которая дает данные.
• Нет интеграционных рисков. Значит, сторонние API считаются стабильными по умолчанию.
• Нет резерва на исправления. Значит, план предполагает разработку без дефектов.
• Нет первой сборки как контрольной точки. Значит, прогресс будут показывать словами.
• Нет зависимости от заказчика. Значит, сроки обратной связи, доступы и согласования не управляются.
• Нет PERT или диапазонов. Значит, подрядчик продает оптимистичную дату.
• Нет правил change request. Значит, любое изменение будет конфликтом.

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

Нужно смотреть на хвосты. Сложные задачи должны иметь больший разброс между O, M и P. Интеграции должны иметь зависимость от доступов и sandbox. Релиз должен иметь отдельное время. Store review, исправления metadata, privacy labels, сертификаты, сборки — это не «последний день».

Оптимальный стек контроля: не инструмент, а контур управления

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

Минимальный стек управления:

• Jira, YouTrack или аналог для задач;
• Confluence, Notion или другой knowledge base для требований;
• Figma для дизайн-артефактов;
• GitLab/GitHub/Bitbucket для репозиториев;
• CI/CD для сборок;
• TestRail, Qase или структурированный QA-модуль для тест-кейсов;
• crash reporting;
• продуктовая аналитика событий;
• регулярный release notes по сборкам.

Но инструмент не решает проблему сам. Нужны правила.

Рабочий ритм:

1. Еженедельный контроль плана. Сравнение planned vs actual. Не презентация.

2. Демо по сборке. Только installable build или staging. Не скриншоты.

3. Burndown по scope. Видно, что закрыто, что добавлено, что заблокировано.

4. Реестр рисков. У каждого риска владелец и дата следующего действия.

5. Change control. Любое изменение имеет влияние на срок или scope.

6. Технический review. Архитектура, API, безопасность, performance, CI/CD.

7. QA-отчет. Дефекты по severity, reopened, regression status.

Без этих элементов дата релиза является административной. С ними дата становится управляемой.

Финальная оценка подрядчика должна отвечать на четыре вопроса:

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

Если ответа нет, срок не подтвержден.

Контрольная карта перед подписанием

Позиция архитектурного комитета простая. Короткий срок допустим. Непроверяемый срок — нет.

Перед подписанием договора нужно получить от подрядчика:

• декомпозицию по этапам и эпикам;
• отдельную оценку аналитики на 20–25 рабочих дней или обоснование меньшего срока;
• расчет дизайна по платформам с учетом адаптации;
• дату первой рабочей сборки в диапазоне 2–4 недель от старта программирования;
• PERT-оценку для ключевых блоков;
• список интеграционных рисков;
• отдельные оценки backend, mobile, QA, DevOps, release;
• правила change request;
• ДС с результатами и критериями приемки по каждому этапу;
• доступ к трекеру, сборкам и отчетности.

MVP за 3–4 месяца возможен. Сложный продукт за 8–12 месяцев реалистичен. Срок вдвое меньше возможен только при вдвое меньшем scope, готовой инфраструктуре или жестких ограничениях по функциональности. И это должно быть видно в документах.

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