Отправить запрос

Почему digital-проекты срывают сроки в 2026 году: 4 группы ошибок и как их избежать

Коротко
  • Сроки digital-проекта срывают четыре группы ошибок: стратегические (нет измеримой цели), планирования (слабые требования, план без контрольных точек), исполнения (нет ролей, тестирование в конце) и технические (архитектура и нагрузка без запаса).
  • По опросу BCG 2024 года больше двух третей крупных технологических программ не укладываются в срок, бюджет или объём; по PMI почти половина неуспешных проектов не достигла целей из-за работы с требованиями.
  • Многие причины срыва видны до первой строки кода: в формулировке цели, в техническом задании и в плане, где нет промежуточного результата.
  • В DNA Team предложение по проекту готовят за 2 дня, демо показывают через 4–8 недель после старта, первый релиз выходит от 2 месяцев: если к демо команда не успевает, отставание видно сразу.
  • Буксующий проект спасает новый план вокруг ближайшего результата: только функции, нужные к дате, и человек у заказчика, который отвечает в тот же день. Когда КБ Стрелка не успевала своими силами, DNA Team сделала портал «Индекс городов» с нуля и запустила его в срок за 2,5 недели.
IT Автор: Дмитрий Забавин
23.08.2026 Обновлено: Время чтения: 8 мин
598

Четыре группы ошибок, из-за которых сайт, сервис или приложение запускают позже плана, признаки отставания, как спасти буксующий проект и чек-лист до договора.

Дмитрий Забавин, сооснователь и CFO DNA Team. Обновлено 9 октября 2026 года.

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

Как часто IT-проекты не укладываются в сроки?

Часто, и с годами лучше не становится. В опросе BCG «Build for the Future» 2024 года участвовали больше 1 000 руководителей компаний. По их оценке, больше двух третей крупных технологических программ не уложатся в срок, бюджет или запланированный объём. Крупной BCG считает программу, которая забирает больше 3% годового ИТ-бюджета. Авторы отмечают, что с исследования 2015 года ситуация не улучшилась.

Обычные проекты разработки тоже опаздывают. В другом опросе BCG 2024 года о разработке ПО почти половина руководителей ответила, что больше 30% их проектов разработки выходят за сроки или бюджет. Главные причины по ответам: бизнес и ИТ по-разному понимают задачу, сроки нереалистичны с самого начала, денег и разработчиков выделено меньше, чем нужно.

Какие четыре группы ошибок срывают сроки?

Ошибки делятся на стратегические, ошибки планирования, исполнения и технические. Проявляются они в разное время, поэтому и ловить их нужно на разных этапах.

ГруппаКак выглядитКогда становится виднаЧто помогает
Стратегическиецель «удобный сайт», нет показателя успеха, не ясно, кому продукт нуженна приёмке: продукт сделан, но не тотцель с цифрой и сроком, проверка спроса через MVP
Планированиянедооценены интеграции, ТЗ без сценариев, план без промежуточного результатав середине проекта, когда сроки уже съеденытребования со сценариями, демо в плане, запас на риски
Исполненияникто не отвечает за согласования, вопросы висят неделями, тестирование в концеперед запускомроли до старта, тестирование на каждом этапе
Техническиеархитектура без расчёта на рост, нагрузку не проверяли, безопасность отложилиперед релизом или после запускатребования к нагрузке и данным в ТЗ, нагрузочный тест до релиза

Стратегические ошибки обходятся дороже других: их находят на приёмке, когда переделывать приходится уже готовое. Поэтому в DNA Team цель, требования и контрольные точки разбирают до договора: на первом созвоне и в предложении по проекту.

Почему размытая цель обходится дороже всего?

Размытую цель каждый участник понимает по-своему, и команда месяцами делает продукт, который заказчик потом не принимает. Никто в этой цепочке не ошибся технически. Просто «удобный личный кабинет» у директора по продажам и у разработчика означает разные вещи.

Иллюстрация: ряд падающих костяшек домино, первая красная: одна ошибка в цели на старте тянет за собой сдвиг всех следующих этапов

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

Если цель есть, а уверенности в спросе нет, полный продукт строить рано. HitHub, соцсеть для индустрии ММА, пришёл в DNA Team с общей бизнес-идеей: без видения интерфейса, без дизайна и списка функций, с небольшим бюджетом. Команда начала с бизнес-аналитики и выбора ключевой аудитории и оставила в первой версии только нужное. Готовое приложение вышло за 3,5 месяца, дальнейший план развития собирают по отзывам пользователей. Подробнее о таком подходе в статье что такое MVP и как он помогает проверить продукт.

Какие ошибки планирования сдвигают запуск?

Чаще всего сроки съедают недооценённый объём работ, техническое задание без пользовательских сценариев и план, в котором нет промежуточного результата.

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

Слабые требования бьют сильнее всего. В исследовании PMI Pulse of the Profession 2014 года (больше 2 000 специалистов по управлению проектами) 47% неуспешных проектов не достигли целей прежде всего из-за плохой работы с требованиями. Если в ТЗ нет сценариев и ограничений, как должна работать функция, выбирает разработчик, и часть таких функций потом переделывают. Как описать сценарии, роли и критерии приёмки, разобрано в статье как подготовить техническое задание на сайт или приложение.

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

В DNA Team контрольные точки закладываются в предложение: оно готово через 2 дня после разговора о задаче, демо появляется через 4–8 недель после старта, первый релиз выходит от 2 месяцев. Для сложного продукта с неясными требованиями работу делят на два этапа: сначала проектирование за 6–7 недель по фиксированной цене, потом разработка по его документации.

Что в работе команды тормозит проект сильнее кода?

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

Признаки этой проблемы на проекте:

  • вопросы команды висят без ответа дольше недели;
  • изменения в требования вносят в переписке, без оценки сроков и денег;
  • никто не может сказать, кто со стороны заказчика принимает работу;
  • тестирование стоит отдельным этапом в конце плана;
  • модули делали разные люди, и стыкуют их впервые перед релизом.

Последние два пункта переносят поиск ошибок на день запуска, когда исправлять дороже всего.

Ещё один источник срыва связан с выбором подрядчика: подрядчика берут по самой низкой цене и не проверяют, как он разобрался в задаче. Какие вопросы задать до договора, собрано в чек-листе выбора подрядчика.

В DNA Team заявку читает лично CEO, ответ приходит в течение 2 рабочих часов, а основатели остаются на связи весь проект. Так вопрос, который команда не может решить сама, не теряется между ролями.

Какие технические ошибки срывают сроки?

Сроки срывают архитектура без расчёта на рост, нагрузка, которую проверяют только перед релизом, и безопасность, отложенная «на потом». Если нагрузку и защиту данных проверяют в последний момент, найденные проблемы требуют переделок, и запуск сдвигается. Если не проверяют совсем, продукт работает на тестовых данных и падает на реальном трафике уже после релиза.

Защиту персональных данных тоже нельзя добавить в конце. Требования к хранению данных, ролям доступа и журналам меняют архитектуру, поэтому их записывают в ТЗ до начала разработки. У DNA Team сертификат ГОСТ Р ИСО/МЭК 27001:2021 и опыт проектов по 152-ФЗ, поэтому требования к данным обсуждают на этапе аналитики.

Отдельная ошибка: нет плана поддержки. После релиза выходят новые версии iOS, Android и браузеров, меняются внешние сервисы, и кто-то должен за этим следить. В DNA Team поддержку согласуют отдельной строкой ещё до запуска, в стоимость разработки она не входит.

Как понять, что проект уже отстаёт?

Проект отстаёт, если к ближайшей контрольной точке нет работающего результата, который можно открыть и проверить. Отчёт «сделано 80%» таким результатом не считается. В проектах DNA Team первая такая точка это демо через 4–8 недель после старта.

На что смотреть заказчику:

  1. Демо переносят второй раз подряд.
  2. Команда показывает макеты и документы, но не работающие экраны.
  3. Объём первой версии растёт, а дата релиза не сдвигается.
  4. Тестировщик ещё не видел ни одной сборки.
  5. Ответы на вопросы о сроках становятся общими: «скоро», «на этой неделе почти всё».

Один признак ещё не катастрофа. Два и больше означают, что план пора пересобирать сразу.

Можно ли спасти проект, который уже срывает сроки?

Да, если быстро пересобрать план вокруг ближайшего результата. Начинают с аудита: что из требований действительно нужно к дедлайну, кто утверждает результат, какие работы блокируют остальные. Потом фиксируют новый план с первой контрольной точкой через несколько недель.

Пример срочного запуска из практики DNA Team. Консалтинговая компания КБ Стрелка не успевала собственными силами сделать портал «Индекс городов» для ВЭБ.РФ: сервис сравнивает инфраструктуру 1 000+ городов России и мониторит федеральные программы. DNA Team взяла разработку с нуля и начала в тот же вечер, по гарантийному письму, не дожидаясь подписания договора. Портал запустили точно в срок, работа заняла 2,5 недели, требования по ходу менялись.

Такой запуск возможен при двух условиях: у заказчика есть человек, который отвечает и утверждает в тот же день, и обе стороны согласны отложить всё, что не нужно к дате.

Чек-лист: что сделать до старта проекта

  1. Записать цель с показателем и сроком, по которому через три месяца после запуска будет видно, достигнута ли она.
  2. Описать пользователей, их роли и главные сценарии.
  3. Разделить функции на первую версию и список «потом».
  4. Перечислить системы для обмена данными и проверить, есть ли у них документация и доступы.
  5. Записать требования к персональным данным и нагрузке.
  6. Поставить в план демо и промежуточные результаты с датами.
  7. Назначить со своей стороны человека, который утверждает требования и принимает работу.
  8. Договориться, как оценивают изменения объёма: по срокам и деньгам, до начала работ по ним.
  9. Заложить тестирование на каждом этапе и решить, кто поддерживает продукт после релиза.

С этим списком первый созвон в DNA Team занимает 30 минут, а предложение с этапами, сроками и бюджетом приходит через 2 дня. Веб-приложение, портал или личный кабинет DNA Team разрабатывает от 1 млн ₽, первый релиз выходит от 2 месяцев, бюджет фиксируют до начала работ.

Об авторе. Дмитрий Забавин, сооснователь и CFO DNA Team. Сооснователь стартапов CoActivity и LookLink, по образованию специалист по информационной безопасности (Санкт-Петербургский политехнический институт). DNA Team (dnateam.ru) основана в 2015 году, разрабатывает веб-сервисы, мобильные приложения и ИИ-решения и усиливает ИТ-команды компаний специалистами, за плечами команды 70+ проектов. Среди проектов: веб-портал для «Лаборатории Касперского», аналитический портал для вокзалов РЖД, спецпроекты для Aviasales, приложение с аудиогидом для Эрмитажа. 1-е место в Рейтинге Рунета 2026 среди компаний по аутстаффингу Санкт-Петербурга.

Услуга по теме: Разработка веб-приложений

Источники и методика

Доля проектов, которые не укладываются в сроки, и причины срывов по опросам BCG 2024 года: Most Large-Scale Tech Programs Fail: Here's How to Succeed (13 ноября 2024) и Software Projects Don't Have to Be Late, Costly, and Irrelevant (30 апреля 2024). Роль требований по отчёту PMI Pulse of the Profession: Requirements Management, август 2014. Источники открыты и сверены 8 октября 2026 года.

Сроки и цены DNA Team по странице разработки веб-приложений и справочнику фактов компании; кейсы по опубликованным страницам «Индекс городов» и HitHub. Группы ошибок и признаки отставания описаны по практике DNA Team.

Частые вопросы

Какая ошибка чаще всего срывает сроки digital-проекта?

По опросу BCG 2024 года главные причины опозданий в разработке ПО такие: бизнес и ИТ по-разному понимают задачу, сроки нереалистичны с самого начала, денег и разработчиков выделено меньше нужного. Все три закладываются до старта, поэтому в DNA Team цель, требования и план разбирают до договора.

Можно ли спасти проект, который уже не успевает к дедлайну?

Да. Сначала аудит требований, плана и ролей, затем новый план с ближайшей контрольной точкой и только теми функциями, которые нужны к дате. Когда КБ Стрелка не успевала своими силами, DNA Team сделала портал «Индекс городов» с нуля и запустила его в срок за 2,5 недели.

Как заказчику контролировать сроки, не разбираясь в разработке?

Смотреть на работающий результат в контрольных точках, а не на проценты готовности. В плане DNA Team демо стоит через 4–8 недель после старта: его можно открыть и проверить самому. Если демо переносят второй раз, план пересобирают сразу.

Сколько времени занимает запуск веб-приложения?

В DNA Team первый релиз веб-приложения, портала или личного кабинета выходит от 2 месяцев после старта, демо появляется через 4–8 недель. Точный срок зависит от объёма первой версии и интеграций; предложение с этапами и бюджетом готовят за 2 дня.

Связанные статьи

Поделиться

Отправить запрос

Не указывайте в комментарии паспортные данные и иные сведения, не относящиеся к запросу.