Почему сроки разработки срываются и как этого избежать

Срыв сроков — самая частая причина конфликтов между заказчиком и подрядчиком. При этом дело редко в лени или непрофессионализме: опоздания почти всегда системны и начинаются задолго до первой строчки кода — на этапе оценки, согласования и постановки задач. Разберём, откуда берутся сдвиги и что помогает проекту идти по плану.

Оценка — это прогноз, а не обещание

Первое, что стоит принять обеим сторонам: срок в договоре — не физическая константа, а прогноз в условиях неопределённости. Чем меньше изучен проект, тем шире реальный разброс. Оценка «два месяца» часто означает «скорее всего два, но возможно и четыре».

Почему оценки почти всегда оптимистичны

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

Оценку делает тот, кто хочет получить проект

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

Пять главных причин, по которым плывут сроки

1. Размытое ТЗ и «допилим по ходу»

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

2. Скрытая сложность

Интеграция с 1С, импорт каталога на 40 000 позиций, оплата в трёх валютах, нестандартный сценарий авторизации — всё это выглядит безобидно в списке задач, но съедает недели. Сложность обычно вскрывается не на оценке, а на середине проекта, когда менять архитектуру уже дорого.

3. Согласования и обратная связь

Разработка — это не только код, но и ожидание. Макеты на согласовании у заказчика, ответ юриста, комментарии отдела маркетинга, отпуск ключевого сотрудника — каждая задержка двигает весь конвейер. Если в проекте пять точек согласования и каждая занимает три дня, это уже две-три недели, которых нет в плане.

4. Ресурсы команды

Разработчики и дизайнеры почти всегда ведут несколько проектов. Человек, «выделенный на 100%», на деле бывает занят на трёх задачах. Плюс текучка, больничные, внезапный срочный баг у другого клиента. Оценки, сделанные без учёта реальной загрузки, — это фантазия.

5. Внешние зависимости

Доступы к хостингу, домену, API платёжной системы, аккаунту рекламного кабинета. Ждать их можно днями, а иногда и неделями. Мелочь, которая способна остановить работу целой команды.

Как заказчику снизить риск срыва

• Начинайте с аналитики. Этап исследования и прототипирования стоит денег, но именно он превращает туман в понятный объём работ.
• Фиксируйте не только сроки, но и объём. Что входит в релиз, что — в следующую версию. Список «потом» важнее списка «сейчас».
• Назначьте одного ответственного. Один человек с правом принимать решения вместо согласования всей командой.
• Отвечайте быстро. Договоритесь о регламенте: обратная связь в течение одного-двух рабочих дней.
• Просите промежуточные результаты. Демо каждые две недели показывают реальный прогресс лучше любого отчёта.

Как подрядчику не обманывать в сроках

• Считайте оценку в диапазоне: оптимистичный, реалистичный и пессимистичный сценарий.
• Добавляйте буфер на риски — обычно 20–30% от трудоёмкости.
• Декомпозируйте до задач на 1–2 дня: крупные «эпики» всегда скрывают неизвестность.
• Ведите прозрачный бэклог: заказчик должен видеть, что сделано, что в работе и что мешает.
• Сообщайте о сдвиге сразу, как только он стал очевиден. Неприятная новость за месяц — рабочая ситуация, за день до релиза — репутационная катастрофа.

Если сроки уже сдвинулись

Не ищите виноватого — сначала разберитесь в причине. Соберите факты: сколько задач закрыто, что блокирует остальные, насколько реалистичен новый срок. Затем пересмотрите объём: почти всегда можно выпустить урезанную, но работающую версию раньше, а остальное добавить позже. MVP, выкаченный в срок, полезнее идеального продукта, вышедшего через полгода после дедлайна.

И главное — фиксируйте договорённости письменно. Устные «давайте так» забываются ровно к моменту следующего сдвига.

Коротко

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