Как проверить, что обещанные сроки разработки приложения реальны — 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. Нет готового договора или договор содержит только общие формулировки. Профессиональный подрядчик всегда имеет шаблон договора с конкретными условиями по срокам, оплате и ответственности.