Понедельник, 10 утра. Вы открываете проектный чат и читаете: «Ребята, нам нужно ещё 3 недели. Возникли непредвиденные технические сложности». Три недели назад было точно так же — только тогда просили две недели. А через месяц будет ровно то же сообщение. Подрядчик сорвал сроки — и вы понимаете, что разработка, обещанная за 3 месяца, растянется на полгода.
Знакомая ситуация? По данным The Standish Group (CHAOS Report 2025), 67% корпоративных IT-проектов выходят за первоначальные сроки. Причём средний перерасход по времени составляет 70% от первоначальной оценки. Если подрядчик сорвал сроки, для продукт-менеджера, который отчитывается перед CEO, это не просто задержка — это удар по репутации, карьере и доверию руководства к инновационным инициативам.
В этой статье разберём: что делать прямо сейчас, если подрядчик сорвал сроки или близок к этому, как предотвратить подобное в будущем и какие механизмы защиты существуют на уровне договора и процесса.
Первые 48 часов: что делать немедленно
Когда подрядчик сообщает о переносе сроков, худшая реакция — паника или обвинения. Лучшая — холодный анализ ситуации. Вот алгоритм действий на первые два дня.
Шаг 1: Зафиксируйте факты
Потребуйте от подрядчика письменный отчёт: что конкретно не готово, что является причиной задержки, какой новый реалистичный срок. Устные обещания — не данные. Вам нужен документ, на который можно ссылаться при дальнейших переговорах и при отчёте перед руководством.
Шаг 2: Оцените масштаб проблемы
Не все задержки одинаковы. Определите категорию вашей ситуации:
| Категория | Признаки | Что делать |
|---|---|---|
| Локальная задержка (1-2 недели) | Конкретная фича задерживается, остальное идёт по плану | Пересмотреть скоуп: убрать фичу из текущего релиза, выпустить без неё |
| Системная задержка (3-6 недель) | Несколько модулей отстают, команда перегружена | Аудит кода и процесса, усиление команды или смена подхода |
| Критическая задержка (2+ месяца) | Архитектурные проблемы, потеря ключевых разработчиков | Рассмотреть смену подрядчика, зафиксировать убытки |
Шаг 3: Уведомите стейкхолдеров
Не скрывайте проблему от руководства. Плохие новости не становятся лучше с течением времени — они становятся хуже. Представьте ситуацию в формате «проблема — причина — план действий — запрос». CEO ценит продукт-менеджеров, которые управляют рисками, а не прячут их.
Почему подрядчики срывают сроки: 5 реальных причин
Прежде чем решать проблему, важно понять корневую причину. Поэтому разберём пять типичных сценариев — от самых частых к менее очевидным.
Причина 1: Оптимистичная оценка (70% случаев)
Самая распространённая причина. На этапе продажи менеджер подрядчика обещает «2-3 месяца», потому что клиент хочет услышать именно это. Разработчики видят задачу иначе, но их голос тонет в оптимизме коммерческого отдела. Более того, в формате Time & Material (почасовая оплата) подрядчику невыгодно точно оценивать — чем дольше проект, тем больше выручка.
Причина 2: Размытое ТЗ
«Сделайте как в приложении X, только лучше» — это не техническое задание. Без формализованных требований, критериев приёмки и user stories каждый участник проекта понимает задачу по-своему. В результате через месяц оказывается, что подрядчик делал не то, что вы имели в виду.
Причина 3: Нехватка ресурсов
Подрядчик набрал больше проектов, чем может выполнить, и «размазывает» разработчиков между ними. Ваш проект получает не полную команду, а 30-50% внимания разработчиков, которые параллельно работают на другие проекты. Отсюда и задержки.
Причина 4: Технический долг с первых спринтов
Подрядчик начал с «быстрого» прототипа, чтобы показать прогресс, но заложил архитектурные решения, которые не масштабируются. Когда проект дорастает до реальной нагрузки, всё начинает ломаться. Рефакторинг на ходу — это месяцы задержки. Подробнее о рисках технического долга — в нашем разделе ошибки IT-проектов.
Причина 5: Отсутствие прозрачности
Если между вами и кодом стоит только менеджер подрядчика, который раз в неделю присылает оптимистичный отчёт — вы не контролируете процесс. Без доступа к репозиторию, дашборду задач и промежуточным демо вы узнаёте о проблемах, когда исправить их уже дорого.
Как спасти текущий проект
Итак, подрядчик сорвал сроки, причина понятна. Какие есть варианты действий?
Вариант A: Сократить scope (рекомендуемый)
Это самый эффективный способ вернуть проект в сроки. Пересмотрите список фичей и разделите их на три категории:
- Must have — без этого продукт не имеет смысла (обычно 30-40% от первоначального списка)
- Should have — важно, но можно добавить во второй релиз
- Nice to have — «хотелки», которые не влияют на core value
Оставьте только Must have. Как правило, это позволяет сократить оставшийся объём работ на 40-60% и вернуть проект в приемлемые сроки.
Практический совет: проведите сессию приоритизации с командой подрядчика и внутренними стейкхолдерами. Зафиксируйте пересмотренный список фичей в письменном виде и получите подписи обеих сторон. Это важно, потому что после сокращения скоупа часто возникают конфликты: заказчик утверждает, что убранные фичи были «обещаны», а подрядчик — что они никогда не входили в текущий релиз. Письменное соглашение о сокращённом scope исключает двусмысленность и становится юридическим основанием для приёмки MVP в новом объёме.
Вариант B: Усилить команду
Если проблема в ресурсах, потребуйте от подрядчика выделить дополнительных разработчиков. Однако помните закон Брукса: добавление людей к опаздывающему проекту часто делает его ещё более опаздывающим. Новые разработчики тратят время на погружение, а текущая команда — на объяснения.
Вариант C: Сменить подрядчика
Радикальный, но иногда необходимый шаг. Имеет смысл, если:
- Задержка превышает 100% от первоначального срока
- Код написан некачественно и потребует переписывания
- Подрядчик не предоставляет доступ к репозиторию
- Нет прогресса после двух итераций переговоров
При выборе нового подрядчика обратите внимание на фиксированные сроки и стоимость в договоре. Подход IT Integration — MVP за 22 рабочих дня с фиксированной стоимостью до 900 000 рублей — исключает главную причину срывов: отсутствие юридической ответственности за сроки.
Как предотвратить срыв сроков: 7 защитных механизмов
Лучший способ решить проблему — не допустить её. Вот семь механизмов, которые мы рекомендуем внедрять до старта проекта.
- Фиксированная цена и сроки в договоре. Не Time & Material, а Fixed Price с чётким описанием результата. Подрядчик несёт юридическую ответственность за сроки, а не только моральную
- Еженедельные демо. Не отчёты, а демонстрация работающего функционала. Если на демо нечего показать — проект в беде
- Доступ к репозиторию и таск-трекеру. Вы должны видеть коммиты, задачи и скорость их выполнения. Прозрачность — главный враг срывов
- Milestone-based delivery. Разбейте проект на 3-4 этапа. Каждый этап — приёмка. Если первый этап задерживается на 20%, проект остановится и не будет раздут на месяцы
- Формализованное ТЗ с критериями приёмки. Каждая фича — user story с Definition of Done. Нет серых зон — нет споров о «что имелось в виду»
- Штрафные санкции за просрочку. 0,5-1% от стоимости проекта за каждый рабочий день просрочки. Это дисциплинирует подрядчика и компенсирует ваши потери
- Exit strategy в договоре. Право расторгнуть договор и получить код в текущем состоянии, если задержка превышает согласованный порог (обычно 30-50% от срока)
При выборе подрядчика для следующего проекта обратите внимание на то, как компания относится к фиксации сроков. Подробнее — в нашем руководстве по выбору подрядчика для разработки.
Что говорить руководству, если сроки сорваны
Когда подрядчик сорвал сроки, отдельная задача продукт-менеджера — правильно донести ситуацию до CEO и совета директоров. Формула коммуникации:
- Факт: «Сроки сдвигаются на N недель по причине X»
- Анализ: «Мы проанализировали ситуацию и определили корневую причину»
- План: «Мы предпринимаем конкретные шаги: сократили scope / сменили подрядчика / усилили команду»
- Уроки: «Для будущих проектов мы внедрим защитные механизмы: фиксированные сроки, еженедельные демо, milestone-based delivery»
Ключевое: не оправдывайтесь, а демонстрируйте управление ситуацией. CEO увольняет не за проблемы, а за отсутствие плана их решения.
Из опыта IT Integration: продукт-менеджеры, которые открыто коммуницируют задержки с планом решения, сохраняют доверие руководства даже при серьёзных сбоях. А те, кто скрывает проблемы до последнего, теряют доверие навсегда — даже если в итоге проект завершается успешно.
FAQ о подрядчике, который сорвал сроки
Можно ли вернуть деньги, если подрядчик не уложился в сроки?
Зависит от договора. Если в контракте есть штрафные санкции за просрочку (пени за каждый день задержки) — да. Если договор на Time & Material без фиксированных сроков — практически нет, потому что подрядчик формально выполняет работу, просто медленнее ожидаемого. Именно поэтому при следующем проекте настаивайте на Fixed Price с юридической ответственностью за сроки.
Как понять на раннем этапе, что проект идёт к срыву?
Три красных флага: (1) на еженедельном демо нечего показать два раза подряд; (2) подрядчик перестаёт давать конкретные даты и переходит на «скоро будет»; (3) вы замечаете, что состав команды изменился без предупреждения. Любой из этих признаков — повод для серьёзного разговора с руководством подрядчика.
Стоит ли менять подрядчика в середине проекта?
Если задержка меньше 50% от срока и подрядчик демонстрирует прогресс — обычно выгоднее сократить scope и довести проект. Если задержка более 100% и прогресса нет — смена подрядчика экономит время и деньги. Критически важно: убедитесь, что код и доступ к репозиторию принадлежат вам (проверьте договор).
Как выбрать подрядчика, который точно не сорвёт сроки?
Гарантий нет, но три признака надёжности: фиксированная цена и сроки в договоре (а не оценка «примерно 2-3 месяца»), еженедельные демо работающего кода (а не отчёты в PDF), и реальные кейсы с подтверждёнными сроками от предыдущих клиентов. IT Integration фиксирует 22 рабочих дня в договоре с юридической ответственностью.
Итого: срыв сроков — управляемая ситуация
Когда подрядчик сорвал сроки, главное — не паниковать, а действовать по алгоритму: зафиксировать факты, оценить масштаб, уведомить стейкхолдеров, выбрать стратегию (сократить scope, усилить команду или сменить подрядчика). Для будущих проектов внедрите семь защитных механизмов — и вероятность повторения ситуации снизится на порядок.
Главный урок: фиксированные сроки в договоре — не маркетинговый трюк, а единственный надёжный механизм защиты бюджета и карьеры продукт-менеджера.
Столкнулись с проблемой сроков на текущем проекте или хотите защитить следующий? Запишитесь на бесплатный Zoom-колл — разберём вашу ситуацию и предложим план действий.