Почему разработка затягивается — вопрос, который задаёт себе каждый второй CEO после третьего «ещё две недели» от подрядчика. Проект должен был занять три месяца. Прошло семь. Бюджет вырос на 60%. Продукт так и не в продакшене. А конкурент тем временем уже запустился и забирает вашу аудиторию.
Знакомая ситуация? По данным Standish Group (CHAOS Report), 66% IT-проектов выходят за рамки сроков или бюджета. Для заказной разработки в России картина ещё жёстче: около 70-75% проектов без фиксированных дедлайнов опаздывают минимум на 30%.
Однако дело почти никогда не в «ленивых программистах». Разработка затягивается по системным причинам, которые повторяются от проекта к проекту. За более чем 50 проектов мы выявили 7 таких паттернов — и каждый из них можно предотвратить. Разбираемся, в чём корень проблемы и что с этим делать.
7 системных причин, почему разработка затягивается
Прежде чем искать виноватых, стоит разобраться в механике задержек. Каждая из семи причин ниже — не случайность, а предсказуемый паттерн. Более того, большинство из них можно обнаружить и устранить ещё до написания первой строки кода.
| # | Причина | Симптомы | Решение |
|---|---|---|---|
| 1 | Scope creep (расползание требований) | «Добавьте ещё одну мелочь», scope вырос на 40% | Фиксированный scope + change request = допсоглашение |
| 2 | Ошибки оценки сроков | Оценка «2 месяца» → реальность 4-5 месяцев | Декомпозиция на задачи ≤8 часов, буфер 20-30% |
| 3 | Нечёткое ТЗ | Разные ожидания заказчика и команды | Acceptance criteria до старта, user stories |
| 4 | Параллельные проекты | Разработчики переключаются, теряют контекст | Выделенная команда, не менее 80% фокуса |
| 5 | Отсутствие промежуточных чекпоинтов | Первый результат через 2 месяца — уже поздно | Еженедельные демо рабочего кода |
| 6 | Технический долг и «костыли» | Простые фичи занимают в 3 раза дольше | Code review, рефакторинг 20% спринта |
| 7 | Коммуникационные потери | Согласования занимают больше времени, чем код | Один канал, один product owner, SLA на ответ |
Давайте разберём две самых разрушительных причины подробнее. Потому что именно они виноваты в 60-70% всех задержек.
Анатомия scope creep: как 20 «мелких» правок убивают дедлайн
Scope creep — главная причина того, почему разработка затягивается. По разным оценкам, неконтролируемое расширение требований виновато в 35-40% всех задержек. Механизм прост и коварен одновременно.
Как это выглядит на практике
Неделя 2: «Добавьте экспорт в Excel — это же просто». Неделя 3: «А можно сделать уведомления на почту?». Неделя 5: «Нужна ещё интеграция с CRM, иначе неудобно». Каждый запрос по отдельности кажется мелким — на пару дней работы. Тем не менее за два месяца набирается 15-20 таких «мелочей».
Проблема в том, что каждое изменение тянет за собой каскад:
- Доработка базы данных (новые таблицы, связи, миграции)
- Изменение API (новые эндпоинты, валидация, документация)
- Обновление фронтенда (формы, экраны, состояния)
- Написание тестов (unit, интеграционные, e2e)
- Регрессия — проверка, что старый функционал не сломался
В результате «два дня» превращаются в неделю. А 20 таких запросов — в 3-4 дополнительных месяца. Именно поэтому проекты с размытым scope опаздывают не на 10-20%, а вдвое.
Как предотвратить
Самый эффективный инструмент — фиксированный scope в договоре и формальный процесс change request. Любое изменение требований = дополнительное соглашение с пересчётом сроков и бюджета. Звучит бюрократично? Возможно. Однако этот механизм экономит месяцы и миллионы. Подробнее о типичных проблемах заказной разработки — в нашем разделе о проблемах разработки.
Из нашего опыта: в Prime IT scope фиксируется до старта и закрепляется в договоре. Если заказчик хочет изменить требования — мы не говорим «нет», мы говорим «да, вот новый срок и бюджет». За два года это сократило задержки из-за scope creep практически до нуля.
Почему оценки сроков всегда неточны: 4 типа когнитивных искажений
Вторая по частоте причина того, почему разработка затягивается, — систематические ошибки в оценке сроков. При этом виноваты не программисты, а человеческая психология. Вот четыре когнитивных искажения, которые искажают каждую оценку.
| Искажение | Суть | Как влияет на сроки | Противоядие |
|---|---|---|---|
| Planning fallacy | Люди оценивают идеальный сценарий, игнорируя прошлый опыт | Занижение сроков на 30-50% | Считать по историческим данным, а не по «ощущению» |
| Anchoring bias | Первая названная цифра становится «якорем» для всех дальнейших оценок | Если PM сказал «месяц», команда подгоняет оценки под этот срок | Оценивать снизу вверх: каждая задача отдельно, потом суммировать |
| Закон Паркинсона | Работа занимает всё отведённое время | Если дали буфер — он будет использован | Короткие спринты (1-2 недели) с жёсткими дедлайнами |
| Оптимизм выживших | Помним проекты, которые успели, забываем опоздавшие | «Обычно мы укладываемся» — нет, не укладываемся | Вести лог реальных сроков vs оценок |
Что с этим делать на практике
Лучший способ бороться с когнитивными искажениями — декомпозиция. Разбейте проект на задачи по 4-8 часов и оцените каждую отдельно. Затем суммируйте и добавьте буфер 20-30% на интеграцию, тестирование и непредвиденные проблемы. Таким образом, оценка получается в 2-3 раза точнее, чем «на глаз».
Кроме того, сеньор-разработчики оценивают сроки значительно точнее джуниоров. По нашей статистике, сеньоры ошибаются на 15-20%, а джуниоры — на 50-80%. Поэтому команда уровня Prime IT — не прихоть, а страховка от вечных «ещё две недели».
Дашборд ранних индикаторов: 5 сигналов, что проект начинает опаздывать
Задержки не возникают внезапно. Они накапливаются незаметно — и опытный заказчик может обнаружить их на ранней стадии. Вот пять сигналов, на которые стоит обращать внимание с первой недели проекта.
| # | Сигнал | Уровень тревоги | Что делать |
|---|---|---|---|
| 1 | На второй неделе нечего показать на демо | Высокий | Потребовать детальный план на ближайшие 5 дней |
| 2 | Подрядчик отвечает позже обычного (>24ч) | Средний | Уточнить загрузку команды, напомнить SLA |
| 3 | Появились задачи, которых не было в ТЗ | Высокий | Классифицировать: scope creep или пропущенная зависимость |
| 4 | Разработчики переключились на другой проект | Критический | Пересогласовать приоритет, зафиксировать в письме |
| 5 | Вместо рабочего кода показывают презентации | Критический | Потребовать демо на реальном сервере, провести аудит кода |
Если обнаружили два или более сигнала одновременно — это не «рабочий момент», а системная проблема. Самое время провести экстренный аудит прогресса и пересмотреть план. Подробнее о том, что делать, если сроки уже сорваны, — в нашей статье «Подрядчик сорвал сроки».
Правило двух недель: если за первые две недели проекта не было ни одного демо рабочего кода — вероятность задержки возрастает до 80%. Еженедельные демо — это не формальность, а единственный надёжный способ контролировать прогресс.
Чек-лист профилактики: 8 пунктов до старта проекта
Большинство причин задержки можно устранить ещё до написания первой строки кода. Вот восемь пунктов, которые мы проверяем перед каждым проектом в Prime IT. Используйте этот чек-лист при работе с любым подрядчиком.
- Scope зафиксирован в договоре — полный список функций с acceptance criteria, любые изменения = change request с допсоглашением
- Срок закреплён с пеней за просрочку — не «ориентировочно 3 месяца», а конкретная дата с финансовой ответственностью (0.1-0.5% в день)
- Milestone-оплата — оплата по этапам (20/30/30/20), а не 100% вперёд; вы платите только за принятые результаты
- Еженедельные демо прописаны в договоре — каждую пятницу команда показывает работающий код на реальном сервере, не презентацию
- Доступ к репозиторию с первого дня — вы видите коммиты, pull request'ы и реальную активность команды
- Один product owner со стороны заказчика — не комитет из пяти человек, а один ответственный с полномочиями принимать решения
- Буфер 20-30% заложен в оценку — на тестирование, интеграцию, деплой и неизбежные доработки
- MVP-подход — минимальный набор функций для запуска, всё остальное — в backlog на следующую версию
По нашему опыту, проекты, в которых выполнены все восемь пунктов, завершаются вовремя в 90% случаев. Проекты, в которых выполнено менее четырёх, — опаздывают почти всегда.
Когда чек-лист не поможет
Справедливости ради, есть ситуации, где даже идеальная подготовка не спасает. Например, если в процессе выясняется, что бизнес-модель нужно кардинально менять (pivot), или если внешний API, от которого зависит проект, внезапно меняет условия. Тем не менее такие случаи составляют не более 5-10% от всех задержек. Остальные 90% — предотвратимые системные ошибки.
Итог: разработка затягивается по системным причинам — и их можно предотвратить
Давайте подведём итог. Почему разработка затягивается? В абсолютном большинстве случаев — не из-за «плохих программистов», а из-за семи системных ошибок: scope creep, неточные оценки, нечёткое ТЗ, параллельные проекты, отсутствие чекпоинтов, технический долг и коммуникационные потери.
Хорошая новость: каждую из этих причин можно устранить заранее. Фиксированный scope в договоре, еженедельные демо, milestone-оплата, сеньор-команда с выделенным фокусом — эти четыре элемента предотвращают 90% задержек.
В Prime IT мы строим процесс именно вокруг предсказуемости: 22 рабочих дня, фиксированная цена до 900 000 рублей, еженедельные демо рабочего кода и доступ к репозиторию с первого дня. За два года — 95% проектов сданы в срок.
Если ваш текущий проект затягивается или вы планируете новый и хотите избежать типичных ловушек — запишитесь на бесплатный Zoom-звонок. Разберём вашу ситуацию, покажем конкретных разработчиков и дадим честную оценку сроков.
Ключевые выводы
- 7 системных причин, почему разработка затягивается. Прежде чем искать виноватых, стоит разобраться в механике задержек.
- Анатомия scope creep: как 20 «мелких» правок убивают дедлайн. Scope creep— главная причина того,почему разработка затягивается.
- Почему оценки сроков всегда неточны: 4 типа когнитивных искажений. Вторая по частоте причина того,почему разработка затягивается, — систематические ошибки в оценке сроков.
- Дашборд ранних индикаторов: 5 сигналов, что проект начинает опаздывать. Задержки не возникают внезапно.
FAQ о затягивании сроков разработки
Какой процент IT-проектов выходит за рамки сроков?
По данным Standish Group (CHAOS Report), 66% IT-проектов выходят за рамки сроков или бюджета. Для проектов заказной разработки в России ситуация хуже: около 70-75% проектов без фиксированных дедлайнов в договоре опаздывают минимум на 30%. Главные причины — scope creep (40% случаев), ошибки оценки и отсутствие промежуточных контрольных точек.
Что такое scope creep и как с ним бороться?
Scope creep — это неконтролируемое расширение требований к проекту по ходу разработки. Каждое «добавьте ещё одну мелочь» по отдельности кажется безобидным, но в сумме увеличивает объём на 30-50%. Бороться просто: зафиксировать scope в договоре, любые изменения оформлять как change request с пересчётом сроков и бюджета, вести backlog на следующую версию.
Как понять заранее, что проект начинает опаздывать?
Пять ранних сигналов: (1) на второй неделе нечего показать на демо; (2) подрядчик отвечает позже обычного; (3) появились задачи, которых не было в ТЗ; (4) разработчики переключаются между вашим и другими проектами; (5) вместо рабочего кода показывают презентации. Обнаружили два из пяти — пора проводить экстренный аудит прогресса.
Фиксированная цена защищает от затягивания сроков?
Да, при правильной структуре договора. Фиксированная цена с пеней за просрочку мотивирует подрядчика сдать проект вовремя — его прибыль зависит от эффективности, а не от количества часов. В Prime IT фиксированная цена до 900 000 рублей и срок 22 рабочих дня закреплены в договоре. За 2 года — 95% проектов сданы в срок.
Можно ли ускорить проект, который уже затягивается?
Три проверенных способа: (1) сократить scope — вынести часть функций в следующую версию, оставив ядро продукта; (2) параллелизировать работу — фронтенд и бэкенд одновременно; (3) заменить длинные согласования на быстрые демо-сессии. Добавление людей на поздних стадиях чаще замедляет проект (закон Брукса), чем ускоряет.