Как проверить реальные сроки разработки мобильного приложения до подписания договора
Проверить реальные сроки разработки мобильного приложения до подписания договора можно и нужно — иначе вы рискуете потерять аванс и несколько месяцев ожидания. Команда ormobil.com рекомендует подходить к оценке
Как подрядчик определяет сроки: документы и критерии
Прежде чем оценивать, адекватны ли обещанные сроки, нужно понять, откуда они берутся. Любой профессиональный подрядчик опирается на набор документов и внутренних метрик.
1. Анализ технического задания. На основе ТЗ команда разбивает проект на функциональные блоки: авторизация, личный кабинет, интеграция с платёжной системой, push-уведомления и так далее. Каждый блок оценивается в часах или story points. По нашему опыту, типичное мобильное приложение средней сложности — MVP с 5–7 экранами — требует от 300 до 600 часов разработки. Если подрядчик называет меньше, это повод насторожиться.
2. Определение состава команды и спринтов. Срок напрямую зависит от размера команды. Один разработчик с дизайнером и тестировщиком закроют MVP за 4–6 месяцев. Команда из 5–7 человек с DevOps и аналитиком способна уложиться в 2–3 месяца. Подрядчик должен назвать состав команды и количество спринтов — обычно спринт длится 2 недели.
3. Учёт интеграций и внешних зависимостей. Если приложение интегрируется с CRM, ERP, платёжным шлюзом или государственными системами — например, Госуслугами — каждая интеграция добавляет от 2 до 6 недель. Подробнее о том, как декомпозировать ТЗ на интеграционные блоки, мы рассказали в материале Как оценить техническое задание на интеграции.
4. Резерв на тестирование и исправления. Профессиональные команды закладывают минимум 15–20% времени на QA и багфиксы. Если в графике нет отдельного этапа тестирования — это тревожный сигнал.
> По данным Standish Group (CHAOS Report, 2023), около 66% IT-проектов завершаются с превышением сроков или бюджета. Основная причина — некорректная оценка на этапе планирования.
Критерии проверки
Чтобы объективно оценить, насколько реалистичны обещанные сроки, мы разработали систему из пяти проверяемых критериев. Каждый из них можно верифицировать ещё до подписания договора.
1. Детализация оценки по задачам. Запросите у подрядчика разбивку сроков не «в целом по проекту», а по каждому функциональному блоку. Если вам говорят «приложение будет готово через 3 месяца», но не могут показать, сколько дней уйдёт на каждый экран, — оценка носит приблизительный характер.
2. Соответствие нагрузки и размера команды. Проверьте, совпадает ли заявленный срок с реальными мощностями. Формула простая: общее количество часов, делённое на произведение числа разработчиков и часов в спринте, равно количеству спринтов. Если подрядчик обещает 3 месяца, но в команде всего два фронтенд-разработчика — скорее всего, срок занижен.
3. Наличие этапов в графике. Реалистичный график всегда включает: проектирование UI/UX, разработку фронтенда и бэкенда, интеграции, тестирование, публикацию в App Store и Google Play. Отсутствие хотя бы одного этапа — признак того, что подрядчик намеренно упрощает картину.
4. Проверка SLA и гарантий. Изучите раздел договора, посвящённый. SLA должен фиксировать не только сроки разработки, но и штрафы за просрочку, порядок приёмки, условия внесения правок.
5. Сравнение предложений от разных подрядчиков. Запросите оценки минимум у 2–3 компаний. Если одна компания называет срок в 2 месяца, а две другие — в 4–5, первая, скорее всего, занижает для привлечения. Поможет наш гайд Сравнение предложений на разработку по ТЗ.
| Критерий | Реалистичный вариант | Завышенный / заниженный вариант | Как проверить |
|---|---|---|---|
| Детализация по задачам | Разбивка по каждому экрану и функции | Одна строка «MVP — 3 месяца» | Запросить таблицу с оценками в часах |
| Состав команды | Названы роли и количество человек | «Наша команда справится» без деталей | Попросить список участников проекта |
| Этапы графика | 5–7 этапов с датами | Только «разработка» и «сдача» | Сверить с типичным циклом разработки |
| Резерв на QA | 15–20% от общего времени | Тестирование «включено» без сроков | Спросить отдельный этап тестирования |
| SLA в договоре | Штрафы, приёмка, правки | «Сроки ориентировочные» | Изучить раздел договора |
Риски завышенных сроков и последствия для бизнеса
Заниженные сроки — это не просто неудобство. Для бизнеса они влекут конкретные финансовые и репутационные потери.
1. Потеря рыночного окна. Если вы планировали запуск к сезону или дате мероприятия, сдвиг на 2–3 месяца может означать, что конкуренты выйдут раньше. По оценкам аналитиков, задержка запуска мобильного приложения на 6 месяцев может обернуться потерей до 20–40% первичной аудитории.
2. Удорожание проекта. Каждый дополнительный месяц разработки — это зарплаты команды (от 500 000 до 1 500 000 ₽ в месяц для средней команды из 4–5 человек), серверные расходы и стоимость привлечения пользователей, которые уже не могут быть окуплены в запланированные сроки.
3. Деградация качества. Когда подрядчик пытается «успеть» в нереальные сроки, он экономит на тестировании, код-ревью и документации. Результат — приложение с багами, которое пользователи удаляют в первые дни. По данным Google, 25,9% приложений удаляются после одного использования.
4. Юридические последствия. Если в договоре не прописаны штрафы за просрочку, вы не сможете компенсировать убытки. Согласно статье 723 Гражданского кодекса РФ, заказчик вправе требовать переработки, но только если работа выполнена с отступлениями от условий договора. А если сроки нигде не зафиксированы точно — доказать просрочку будет сложно.
5. Повреждение репутации. Если приложение разрабатывается для клиентов или партнёров, срыв сроков подрывает доверие. В B2B-сегменте это особенно критично: один сорванный дедлайн может стоить контракта на миллионы рублей.
Какой реальный срок разработки мобильного приложения?
Для MVP средней сложности — 5–7 экранов, базовые интеграции — реалистичный срок составляет от 3 до 6 месяцев при команде из 3–4 человек. Сложные проекты с множеством интеграций, кастомной графикой и высокой нагрузкой могут занимать от 6 до 12 месяцев. Срок напрямую зависит от количества функций, состава команды и сложности интеграций.
Можно ли сократить сроки разработки?
Да, но только за счёт сокращения функциональности — подход MVP — или увеличения команды. Ускорение за счёт экономии на тестировании или документации — это прямой путь к багам и переделкам, которые в итоге увеличат сроки и бюджет.
Что делать, если подрядчик сорвал сроки?
Зафиксируйте нарушение письменно: акт, переписка, email. Проверьте договор на наличие штрафных санкций. Если штрафы не прописаны — направьте претензию с требованием компенсации. В случае отказа можно обратиться в суд на основании статей 723 и 739 ГК РФ.