Как проверить, что обещанные сроки разработки приложения реальны — 5 вопросов к подрядчику

Почему подрядчики занижают сроки в коммерческом предложении

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

1. Конкуренция за проект. В сфере разработки мобильных приложений и цифровых сервисов подрядчики часто соревнуются за одного заказчика. Чтобы выиграть тендер, команда сознательно сжимает сроки — например, обещает MVP за 6 недель вместо реалистичных 10–12. По данным опроса, проведённого Project Management Institute в 2023 году, 35 % руководителей проектов признают, что на этапе продажи сроки занижаются намеренно.

2. Недооценка сложности интеграций. Подключение к CRM, платёжным шлюзам, государственным системам (например, ЕГИСЗ или ЕСИА) требует времени на согласование, тестирование и получение доступов. Это легко забыть в коммерческом предложении. Каждая внешняя интеграция добавляет от 5 до 15 рабочих дней к графику, а если подрядчик не работал с конкретным API ранее — срок может удвоиться.

3. Отсутствие детального технического задания на этапе оценки. Без ТЗ подрядчик оценивает проект «на глаз», опираясь на аналоги. По нашему опыту, погрешность такой оценки достигает 40–60 % в сторону занижения. Когда же ТЗ проработано детально, точность оценки вырастает до 85–90 %.

> По данным исследования Standish Group (CHAOS Report 2020), около 66 % крупных IT-проектов завершаются с превышением сроков или бюджета, а 33 % проектов вовсе не доходят до релиза.

5 вопросов к подрядчику перед подписанием договора

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

Вопрос 1. Какая команда будет работать над проектом и сколько часов в неделю она выделяет?

Попросите назвать конкретных людей: проджект-менеджера, разработчиков (сколько фронтенд, сколько бэкенд), дизайнера, QA-инженера. Уточните, заняты ли эти специалисты на других проектах. Если подрядчик обещает команду из 5 человек, но при этом у каждого из них ещё три активных проекта — сроки под угрозой.

Что проверить:

1. Попросите показать штатное расписание или хотя бы список ролей с указанием загрузки.

2. Уточните, есть ли резервные специалисты на случай болезни или ухода ключевого разработчика.

3. Сравните: команда из 3 человек, работающих на проект 40 часов в неделю, часто эффективнее команды из 7 человек с загрузкой по 15 часов.

Вопрос 2. Какая методология планирования используется и как фиксируются промежуточные этапы?

Спросите, работают ли они по Agile/Scrum, Waterfall или гибридной модели. Важно понять:

• Длительность одного спринта (обычно 1–2 недели).

• Какой артефакт вы получаете по итогам каждого спринта (демо, отчёт, доступ к репозиторию).

• Что происходит, если спринт не закрывается в срок.

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

Что проверить:

1. Попросите показать пример бэклога или доски из предыдущего проекта (с удалёнными конфиденциальными данными).

2. Уточните, ведётся ли лог спринтов и доступен ли он заказчику.

3. Спросите, какой процент спринтов в предыдущих проектах закрывался в срок (норма — 75–85 %).

Вопрос 3. Какие сторонние сервисы и API задействованы и какие риски по срокам они несут?

Любое приложение сегодня опирается на внешние интеграции: платёжные системы (ЮKassa, СБП), аналитика (AppMetrica, Firebase), облачные хранилища (AWS, Яндекс.Облако), push-уведомления, CRM. Каждая интеграция — это:

• Время на получение доступов и тестовых окружений (от 2 до 10 рабочих дней).

• Время на согласование с техподдержкой стороннего сервиса.

• Риск изменений в API, которые потребуют доработки.

Спросите подрядчика: «Какие интеграции уже реализованы вами в предыдущих проектах, а какие будут впервые?» Новые интеграции — зона повышенного риска.

Что проверить:

1. Попросите список всех внешних зависимостей с указанием статуса (уже реализовано / будет впервые).

2. Уточните, есть ли у подрядчика тестовые ключи API или sandbox-окружения для каждого сервиса.

3. Спросите, как подрядчик компенсирует задержки, если сторонний сервис не предоставит доступ в обещанный срок.

Вопрос 4. Покажите портфолио с похожими проектами и назовите реальные сроки их реализации.

Не верьте красивым кейсам без цифр. Попросите показать проект, максимально похожий по функционалу на ваш, и назвать:

• Фактический срок разработки от ТЗ до релиза.

• Были ли задержки и по какой причине.

• Сколько итераций потребовалось на тестирование.

Что проверить:

1. Попросите ссылку на приложение в App Store или Google Play — проверьте дату публикации и историю обновлений.

2. Сравните обещанный вам срок с фактическим сроком аналогичного проекта из портфолио.

3. Уточните, были ли в проекте незапланированные доработки и как они повлияли на график.

Вопрос 5. Как зафиксированы штрафные санкции за срыв сроков и что является форс-мажором?

Это ключевой вопрос для защиты ваших интересов. В договоре должны быть прописаны:

1. Конкретные даты или привязка к событиям (например, «MVP — не позднее 15 августа 2025 года»).

2. Размер пеней за каждый день просрочки (типичная практика — 0,1–0,5 % от стоимости проекта в день).

3. Порог, при котором вы имеете право расторгнуть договор (например, просрочка более 30 календарных дней).

4. Перечень обстоятельств, которые считаются форс-мажором (ст. 401 ГК РФ).

Что проверить:

1. Попросите проект договора до подписания и покажите его юристу.

2. Убедитесь, что штрафы привязаны к конкретным датам, а не к размытым формулировкам вроде «в разумные сроки».

3. Проверьте, есть ли в договоре механизм эскалации — порядок эскалации при задержке более 5–7 дней.

Таблица проверки: реалистичны ли обещанные сроки

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

Риски срыва сроков и как их зафиксировать в договоре

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

1. Фиксация промежуточных вех с привязкой к датам. Разбейте проект на этапы: ТЗ и прототип (неделя 1–2), дизайн-макеты (неделя 3–4), MVP (неделя 5–10), бета-тестирование (неделя 11–12), релиз (неделя 13). Каждая веха — конкретная дата и конкретный артефакт.

2. Механизм удержания части оплаты. Не платите 100 % предоплаты. Оптимальная схема: 30 % — при подписании договора, 30 % — по завершении дизайна, 30 % — по завершении разработки, 10 % — после успешного прохождения приёмочного тестирования. Это мотивирует подрядчика соблюдать график.

3. Штрафные санкции за просрочку. Типичная практика — 0,1–0,5 % от стоимости проекта за каждый день просрочки. При стоимости проекта 3 000 000 ₽ и просрочке в 20 дней штраф составит 60 000–300 000 ₽. Убедитесь, что договор содержит верхний предел штрафа (обычно 10–15 % от стоимости) и порог для расторжения.

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

5. Фиксация форс-мажора. Статья 401 ГК РФ определяет форс-мажор как «чрезвычайные и непредотвратимые обстоятельства». В договоре перечислите конкретный список: стихийные бедствия, военные действия, решения государственных органов, блокировка интернет-трафика. Не допускайте формулировок вроде «иные обстоятельства» — это лазейка для подрядчика.

Когда не подходит: признаки, что подрядчик не справится

Есть ситуации, когда даже правильные вопросы не спасут — подрядчик объективно не способен уложиться в обещанные сроки. Вот красные флаги, на которые стоит обратить внимание.

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

2. Нет опыта с вашей технологической стекой. Если ваше приложение требует нативной разработки на Swift/Kotlin, а подрядчик специализируется на кросс-платформенных решениях на React Native — сроки будут сорваны на этапе адаптации.

3. Подрядчик не может показать ни одного работающего приложения. Кейсы в формате «мы делали похожий проект» без ссылок на App Store или Google Play — это не портфолио, а маркетинговые материалы.

4. Цена значительно ниже рынка. Если подрядчик предлагает разработку MVP за 500 000 ₽, когда рыночная стоимость аналогичного проекта — 1 500 000–2 000 000 ₽, это либо занижение для получения проекта, либо работа на низком качестве.

5. Нет готового договора или договор содержит только общие формулировки. Профессиональный подрядчик всегда имеет шаблон договора с конкретными условиями по срокам, оплате и ответственности.

Какой минимальный срок разработки мобильного приложения?

Для MVP с базовым функционалом (авторизация, личный кабинет, 3–4 экрана, интеграция с одним API) реалистичный срок — 8–12 недель при команде из 3–4 специалистов. Сложные приложения с кастомным дизайном, несколькими интеграциями и серверной частью требуют от 4 до 6 месяцев. Любой подрядчик, обещающий MVP за 3–4 недели, либо недооценивает объём, либо сознательно занижает сроки.

Что делать, если подрядчик уже сорвал первые промежуточные сроки?

Немедленно фиксируйте задержку письменно (электронное письмо или акт). Потребуйте обновлённый график с причинами задержки и планом компенсации. Если задержка превышает 10 рабочих дней и подрядчик не предлагает конкретного плана — это повод для эскалации или начала процедуры расторжения по п. 3 ст. 450 ГК РФ.

Можно ли изменить сроки после подписания договора?

Да, через дополнительное соглашение (допсоглашение) к основному договору. Любые изменения сроков должны быть оформлены письменно и подписаны обеими сторонами. Устные договорённости не имеют юридической силы и не защищают заказчика при споре.

Для продолжения темы — Поддержка после запуска в 2026 году.

Практический контекст — оформить пробный период корпоративной версии CRM.

Близкий по теме материал — Перенос данных: чек-лист, риски и следующий.