Подрядчик сорвал сроки — и вы не первый, кто это слышит. Дедлайн был три месяца назад. Разработчик в пятый раз обещает «ещё две недели». Бюджет вырос вдвое. Продукт готов на 60%. При этом параллельно конкурент уже запустил аналогичное решение и забирает вашу аудиторию.
Знакомая ситуация? По данным Standish Group, 60-70% IT-проектов выходят за рамки сроков или бюджета. Для заказной разработки в России картина ещё жёстче: по нашим наблюдениям, около 75% проектов без фиксированных дат в договоре задерживаются минимум на 30%.
В этой статье — конкретный план действий: что делать прямо сейчас, какие пункты включить в договор заранее и как выстроить процесс так, чтобы подрядчик не сорвал сроки в следующий раз.
Почему 75% IT-проектов опаздывают: 5 системных причин
Прежде чем разбирать план действий, важно понять корневые причины. Потому что срыв сроков разработки — это почти никогда не «лень программистов». За каждой задержкой стоит системная проблема, которую можно было предотвратить.
При выборе подрядчик сорвал сроки это определяет итоговый результат.
1. Нечёткое техническое задание
Требование «сделать удобный дашборд» — это не ТЗ. Это пожелание. Без конкретных acceptance criteria каждый разработчик интерпретирует задачу по-своему. В результате каждое несовпадение ожиданий превращается в переделку, а каждая переделка — в потерянные дни.
По данным IBM Systems Sciences Institute, исправление ошибки в требованиях на этапе разработки стоит в 6 раз дороже, чем на этапе проектирования. Следовательно, нечёткое ТЗ — это не просто неудобство, а финансовая бомба замедленного действия.
2. Scope creep — тихий убийца дедлайнов
Scope creep (расползание требований) является причиной примерно 40% всех срывов сроков. Механизм прост: заказчик по ходу проекта просит «добавить маленькую функцию». Каждый запрос по отдельности кажется мелким — пара дней работы. Тем не менее за два месяца набирается 15-20 таких запросов, и каждый тянет за собой изменения в базе данных, API, фронтенде и тестах.
3. «Оптимистичные» оценки подрядчика
Многие студии занижают сроки, чтобы получить проект. Оценка «два месяца» на практике превращается в четыре. Причина проста: подрядчик оценивает время на написание кода, однако забывает про согласования, тестирование, интеграции, деплой и неизбежные доработки. Более того, «оптимистичные» оценки часто исключают время на code review и рефакторинг.
4. Параллельные проекты в студии
Ваш проект — один из десяти в очереди. Разработчики переключаются между задачами, теряя контекст и продуктивность. Исследования показывают, что каждое переключение снижает эффективность на 20-25%. Иными словами, если ваш разработчик ведёт три проекта одновременно, вы получаете не 33% его времени, а ближе к 25%.
5. Отсутствие промежуточных чекпоинтов
Если первый раз вы видите результат через два месяца после старта — вы уже опоздали. Без еженедельных milestone'ов отклонение от плана обнаруживается, когда исправлять уже поздно. Именно поэтому контроль процесса разработки начинается с первой недели.
| Причина срыва | Доля случаев | Как предотвратить |
|---|---|---|
| Нечёткое ТЗ | ~25% | Acceptance criteria до старта |
| Scope creep | ~40% | Фиксированный scope + change request |
| Занижение оценки | ~15% | Фиксированная цена в договоре |
| Параллельные проекты | ~10% | Выделенная команда |
| Нет чекпоинтов | ~10% | Еженедельные демо |
Подрядчик сорвал сроки: 4 шага прямо сейчас
Допустим, ситуация уже произошла: подрядчик сорвал сроки, проект опаздывает, а вы не знаете, что делать. Вот конкретный алгоритм действий — от мягких мер к жёстким.
Шаг 1. Зафиксируйте факт задержки письменно
Напишите подрядчику официальное письмо (email с уведомлением или через канал, указанный в договоре). В письме укажите:
- Изначальный срок сдачи по договору
- Фактическое количество дней просрочки
- Требование предоставить обновлённый график с конкретными датами
- Ссылку на пункт договора о штрафных санкциях (если есть)
Это не агрессия — это фиксация фактов. Без письменной фиксации у вас нет юридической базы для претензий. Кроме того, сам факт официального обращения часто ускоряет работу подрядчика.
Шаг 2. Проведите экстренный аудит прогресса
Потребуйте демонстрацию текущего состояния продукта. Не отчёт, не презентацию — работающий код на реальном сервере. Оцените:
- Какой процент функционала реально готов (не «в процессе», а работает)?
- Есть ли у вас доступ к репозиторию кода?
- Какие задачи блокируют завершение?
- Сколько человек фактически работает над вашим проектом?
Если подрядчик отказывается показывать код или демо — это красный флаг, который говорит о серьёзных проблемах.
Шаг 3. Пересогласуйте scope и дедлайн
После аудита у вас два варианта:
- Сократить scope — вынести часть функций в следующую версию, сфокусироваться на core-функциональности. Помните правило Парето: 80% ценности продукта содержится в 20% функций.
- Продлить срок — но только с новыми условиями: еженедельные демо, milestone-оплата, пеня за повторный срыв.
В обоих случаях зафиксируйте новые договорённости в дополнительном соглашении. Устные обещания ничего не стоят.
Шаг 4. Подготовьте план B
Параллельно начните искать альтернативу. Не потому, что вы обязательно уйдёте, а потому что наличие плана B меняет переговорную позицию. Убедитесь, что у вас есть:
- Доступ к репозиторию с полным кодом
- Документация по API и архитектуре
- Доступы к серверам, домену, базе данных
- Все дизайн-макеты в исходных файлах
Если чего-то из этого нет — требуйте немедленно. По ГК РФ исходный код принадлежит заказчику, если иное не указано в договоре.
Из нашего опыта: в 70% случаев достаточно шагов 1-3, чтобы подрядчик мобилизовался. Письменная фиксация + аудит + пересогласование scope решают большинство ситуаций без разрыва отношений.
Как защитить проект договором: штрафы, эскроу, milestone
Лучший способ бороться со срывом сроков — не допустить его. А для этого договор на разработку должен содержать три обязательных механизма.
Механизм 1. Пеня за просрочку
Стандартная ставка: 0.1-0.5% от стоимости проекта за каждый рабочий день просрочки. Для проекта стоимостью 900 000 рублей это 900-4500 рублей в день. Сумма кажется небольшой, однако за месяц просрочки она вырастает до 20 000 — 100 000 рублей. Поэтому пеня дисциплинирует.
Также включите потолок пени (например, 10-20% от стоимости договора) и право на расторжение при достижении потолка с возвратом предоплаты за невыполненные этапы.
Механизм 2. Milestone-оплата
Не платите 100% вперёд. Разбейте оплату по этапам:
| Milestone | Доля оплаты | Критерий приёмки |
|---|---|---|
| Подписание договора | 20% | Согласованное ТЗ с acceptance criteria |
| Демо середины проекта | 30% | Работающий прототип core-функций |
| Приёмочное тестирование | 30% | 100% acceptance criteria выполнены |
| Запуск в продакшен | 20% | Проект развёрнут на боевом сервере |
Таким образом, milestone-оплата снижает финансовые риски заказчика на 80%. Вы платите только за принятые результаты. Если подрядчик пропал после второго этапа — вы потеряли 50%, а не 100%.
Механизм 3. Эскроу или аккредитив
Для проектов дороже 1 500 000 рублей имеет смысл использовать эскроу-счёт. Деньги лежат на счёте третьей стороны (банка) и перечисляются подрядчику только после подтверждения заказчиком приёмки этапа. В результате ни одна сторона не рискует: подрядчик видит, что деньги есть, заказчик знает, что не заплатит за воздух.
Что ещё включить в договор
- Передача исходного кода — весь код принадлежит заказчику с момента создания
- Доступ к репозиторию — с первого коммита, а не после завершения
- SLA на коммуникацию — ответ в течение 4 рабочих часов, доступность через Slack/Telegram
- Процедура change request — любые изменения scope = допсоглашение с новыми сроками
- Гарантийный период — минимум 2-4 недели после запуска
Менять подрядчика или дожимать текущего: фреймворк решения
| Сигнал | Оставайтесь и дожимайте | Меняйте подрядчика |
|---|---|---|
| Задержка от первоначального срока | До 30% | 50% и больше |
| Связь с командой | Регулярные созвоны, прогресс-репорты | Не выходят на связь больше 3 рабочих дней |
| Качество кода (по independent review) | Удовлетворительное | Критические проблемы выявлены |
| Доступ к репозиторию и коду | Есть, можно проверить любой коммит | Нет доступа или ограниченный |
| Причина задержки | Понятна и устранима (scope creep) | Не объяснена или объяснения меняются |
| Burn rate vs стоимость перезапуска | Дешевле дожать текущего | Дешевле перезапустить с новой командой |
Самый сложный вопрос при срыве сроков: уходить или оставаться? Смена подрядчика — болезненная операция, однако иногда она необходима. Вот конкретный фреймворк для принятия решения.
Оставайтесь, если:
- Задержка не превышает 30% от первоначального срока
- Подрядчик выходит на связь и показывает реальный прогресс
- Качество кода удовлетворительное (проверено независимым code review)
- Причина задержки понятна и устранима (scope creep, изменение требований)
- У вас есть рычаги давления (milestone-оплата, штрафы в договоре)
Уходите, если:
- Подрядчик не выходит на связь более 3 рабочих дней
- Задержка превышает 50% от первоначального срока
- Нет доступа к репозиторию или коду
- Независимый code review выявил критические проблемы
- Burn rate (ежемесячные затраты) выше, чем стоимость перезапуска с новой командой
Важный нюанс: смена подрядчика в середине проекта добавляет 2-4 недели на погружение новой команды в код и контекст. Прежде всего убедитесь, что у вас есть полный доступ к коду, документация и ТЗ. Без этого новая команда начнёт практически с нуля.
Подробнее о том, как выбрать надёжную команду разработки, если вы решили сменить подрядчика.
5 правил, которые предотвращают срыв сроков
Если вы прошли через срыв сроков один раз — вот как сделать так, чтобы это не повторилось. Пять правил, каждое из которых основано на нашем опыте работы с десятками проектов.
Правило 1. Фиксируйте сроки в договоре — с пеней
Не «ориентировочные сроки», а конкретная дата с финансовой ответственностью. Наш опыт показывает: проекты с фиксированными сроками в договоре завершаются вовремя в 3 раза чаще, чем без них. Потому что подрядчик знает — просрочка стоит денег.
Правило 2. Требуйте еженедельные демо
Каждую пятницу команда показывает работающий функционал на реальном сервере. Не презентацию, не отчёт — рабочий код. Таким образом, вы обнаруживаете отклонения на ранней стадии. Если после двух недель нечего показать — это сигнал о проблеме, а не о «подготовительной работе».
Правило 3. Выбирайте фиксированную цену, а не time & materials
При модели T&M (оплата за часы) подрядчику финансово выгодно растягивать проект. Чем дольше работает — тем больше зарабатывает. При фиксированной цене мотивация обратная: подрядчик заинтересован сдать быстрее, ведь его прибыль зависит от эффективности, а не от количества часов.
Правило 4. Проверяйте подрядчика до подписания
Перед стартом проведите due diligence: работающие ссылки в портфолио, контакты предыдущих клиентов, LinkedIn-профили конкретных разработчиков. Уделите этому 48 часов — это сэкономит месяцы потерянного времени. Подробнее — в статье о типичных проблемах заказной разработки.
Правило 5. Начинайте с MVP, а не с полного продукта
Чем больше scope — тем выше вероятность срыва. MVP с фиксированным набором функций за 22 рабочих дня — это управляемый проект с предсказуемым результатом. Масштабировать можно после того, как core-функциональность работает и бизнес-гипотеза подтверждена.
| Правило | Что даёт | Без него |
|---|---|---|
| Фиксированные сроки с пеней | Юридический рычаг + мотивация | «Ну примерно через 3 месяца» |
| Еженедельные демо | Раннее обнаружение проблем | Сюрприз через 2 месяца |
| Фиксированная цена | Предсказуемый бюджет | +30-50% перерасхода |
| Due diligence подрядчика | Надёжная команда | Лотерея |
| MVP-подход | Управляемый scope | Scope creep + срыв сроков |
Как Prime IT гарантирует соблюдение сроков
Мы не случайно разбираем эту тему так детально. За последние два года мы видели десятки проектов, которые приходили к нам «на спасение» после того, как предыдущий подрядчик сорвал сроки. Поэтому наша модель работы построена именно вокруг предсказуемости:
- 22 рабочих дня — фиксированный срок, закреплённый в договоре с пеней за просрочку
- До 900 000 рублей — фиксированная цена, без доплат и «сюрпризов»
- Еженедельные демо — каждую пятницу вы видите работающий код на реальном сервере
- Сеньор-команда — опытные разработчики точнее оценивают задачи и реже ошибаются в сроках
- Код с первого дня — полный доступ к Git-репозиторию, код принадлежит вам
За последние 2 года мы сдали 95% проектов в срок. Оставшиеся 5% — случаи, когда заказчик сам менял требования после старта. Даже в этих случаях задержка не превышала одной недели.
Итог: три вещи, которые нужно сделать сегодня
Если подрядчик сорвал сроки — не паникуйте, но и не ждите. Действуйте по плану:
- Зафиксируйте факт задержки письменно — это ваша юридическая база
- Проведите аудит прогресса — потребуйте демо работающего кода
- Пересогласуйте scope и дедлайн — или начните искать альтернативу
А для следующего проекта включите в договор три защитных механизма: фиксированный срок с пеней, milestone-оплату и обязательные еженедельные демо. Эти три пункта предотвращают 90% ситуаций со срывом сроков.
Если вам нужна разработка с гарантией сроков и прозрачным процессом — запишитесь на бесплатный Zoom-звонок. Расскажем, как устроен наш процесс, покажем конкретных разработчиков и дадим фиксированную оценку вашего проекта.
FAQ о срыве сроков подрядчиком
Какой процент IT-проектов сдаётся с опозданием?
По разным исследованиям (Standish Group, McKinsey), 60-70% IT-проектов выходят за рамки сроков или бюджета. Для заказной разработки в России ситуация ещё хуже: по нашим наблюдениям, около 75% проектов без фиксированных сроков в договоре задерживаются минимум на 30%. Основные причины: нечёткое ТЗ, scope creep и отсутствие промежуточных чекпоинтов.
Какие штрафные санкции включить в договор на разработку?
Три обязательных пункта: (1) Пеня за просрочку — 0.1-0.5% от стоимости за каждый рабочий день; (2) Право на расторжение при задержке более 20-30 рабочих дней с возвратом предоплаты; (3) Эскроу или поэтапная оплата по milestone'ам — вы платите только за принятые этапы. Также включите обязательство передачи исходного кода и документации при любом варианте завершения.
Стоит ли менять подрядчика в середине проекта?
Смена подрядчика — крайняя мера. Новой команде потребуется 2-4 недели на погружение в код и контекст, что фактически добавляет задержку. Меняйте, если: (1) подрядчик не выходит на связь; (2) качество кода критически низкое; (3) задержка превышает 50% от первоначального срока. В остальных случаях эффективнее усилить контроль и пересогласовать scope.
Как Prime IT гарантирует соблюдение сроков?
Тремя механизмами: (1) Фиксированный срок — 22 рабочих дня — закреплён в договоре с пеней за просрочку; (2) Еженедельные демо — вы видите прогресс каждую неделю и можете скорректировать курс; (3) Сеньор-команда — опытные разработчики точнее оценивают задачи и реже ошибаются в сроках. За последние 2 года мы сдали 95% проектов в срок.
Можно ли ускорить проект, если подрядчик опаздывает?
Три способа: (1) Сократить scope — вынести часть функций в следующую версию, оставив core-функциональность; (2) Добавить ресурсы — но помните закон Брукса: добавление людей на поздних стадиях замедляет проект; (3) Параллелизировать задачи — разделить фронтенд и бэкенд работы. Самый эффективный — первый: 80% ценности продукта обычно содержится в 20% функций.