Почему разработка затягивается — вопрос, который задаёт себе каждый второй 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-звонок. Разберём вашу ситуацию, покажем конкретных разработчиков и дадим честную оценку сроков.
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) заменить длинные согласования на быстрые демо-сессии. Добавление людей на поздних стадиях чаще замедляет проект (закон Брукса), чем ускоряет.