Всем привет! Меня зовут Пётр Третьяк. За 10 лет в управлении проектами я ни разу не видел, чтобы крупный релиз вышел ровно в ту дату, которую назвали на старте. Ни разу. При этом все на старте в эту дату верили: и заказчик, и команда, и я сам.

Это не особенность именно моих команд. Отчет BCG за 2024 год показывает, что две трети крупных IT-программ промахиваются или по срокам, или по бюджету, или по скоупу. В CHAOS-отчете Standish Group цифры такие: 31% проектов успешны, 50% «с проблемами», 19% откровенный провал. И это касается все it проектов целиком, по всему миру.

Так что давайте сейчас без самообмана. Сроки в IT почти всегда срываются. Причины системные независящие от того насколько шарит разраб. Хочу разложить все по полкам и рассказать, что с этим реально можно сделать на базе того опыта, который прошел я. 

«Когда будет готово?»: вопрос, на который невозможно честно ответить

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

В IT с ходу назвать срок почти никогда нельзя, если это конечно не тг бот на 400 строк, который на вайбкодить можно за пару часов. Это не как забор покрасить, где ты по опыту знаешь метр квадратный за 15 минут, плюс-минус погода. Тут разработка всегда упирается в задачу, задача упирается в то насколько продукт менеджер въехал в суть, что вендор на самом деле хочет, и новая ли задача для разраба. 

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

Почему сроки промахивают всегда. Вижу Четыре механики

Вот что происходит с любой оценкой, которую вы даете на старте.

Требования меняются. Не если, а когда. Пока программировали первую фичу, заказчик увидел черновой макет и понял, что хотел не так. Пока обсуждали с юристами, вышел новый закон, который меняет логику. Пока писали ТЗ, конкурент выкатил похожую фичу, и стейкхолдеры захотели помериться кое чем и выкатить еще лучше. Средний проект, который я вел, переживал 3–5 серьезных изменений скоупа за время разработки. Замечу - средний.

На старте известно не все. Легаси, чужие API, скрытые зависимости от других команд, странные edge-кейсы в данных. Все это всплывает на третью четвертую  неделю, в момент оценки мы об этом даже не подозреваем об этом масшабе трагедии.

Был у меня проект, где мы на старте оценили интеграцию со сторонней международной платежкой на в 80 часов. По факту вышло 340. я такой Пу пу пу…. как заку это нормально донести, а то мои слова для него как албанский. Вины нашей тут никакой не было, просто документация платежкой была немного кривой, апишку подредачили но обнову не выкатили, и половина методов работала не так, как написано. В итоге худо бедно вырулили.

Оценивают оптимистично. Это известное когнитивное искажение, называется ошибка планирования. Благо Канеман встрял до нас с этой дилеммой и мы можем на нее ссылаться, типо я не я и все дела. Даже опытные разрабы в среднем занижают оценку в 1,5–2 раза. Причем люди, которые раньше регулярно промахивались, в следующий раз оценивают так же оптимистично. Мозг помнит, к сожалению как надо было сделать, а не как получилось в реальности.

Работа не только про код. Когда девелопер говорит «сделаю за 3 дня», он имеет в виду чистое время за клавиатурой. В реальный срок добавляется еще куча всего: ревью кода, правки по ревью, тестирование, правки по тестированию, согласования с аналитиком, созвоны по уточнениям, ожидание доступов от DevOps, ожидание, пока заказчик посмотрит, ожидание, пока кто-нибудь развернет на стейдже. Именно поэтому сроки в IT срываются даже у опытных команд: мы оцениваем программирование, а платить приходится за весь жизненный цикл задачи.

У меня есть правило большого пальца: чистое время разработки занимает 30–40% от реального срока задачи. Остальное берут коммуникация, ожидания и переделки.

Короче, если кто-то говорит «сделаем за месяц» и никак не обосновывает: он не ошибается. Он гадает.

Главная ошибка: обещать одну точную дату

Будет готово 15 мая звучит красиво. Заказчик доволен, руководство успокоено, в плане стоит зеленая галочка. А потом 15 мая проходит, готово не становится, и начинается неприятный разговор.

Я много лет пытался делать наоборот. Рано или поздно понял:

одна дата создает ложную уверенность. Причем не только у заказчика, но и у меня самого.

Когда в таск-трекере стоит 15 мая, мозг отключает планирование рисков. Раз дата есть, значит, все под контролем.

Вместо одной цифры я теперь даю три:

• реалистичный срок, в который уложимся в 70% случаев;

• срок с учетом типовых рисков, в который уложимся в 90% случаев;

• срок если звезды сложатся или карта легла: бывает, но закладываться под такое явно нельзя.

Для задачи на примерно 3 недели это выглядит так. При текущем объеме 2–3 недели. С учетом рисков (новая интеграция, неизвестное качество данных) до 4 недель. Если фокус и без отвлечений, то 10 рабочих дней.

Заказчик получает общую картину. И когда через неделю что-то всплывает, это не срыв, это попадание в заранее обозначенную вилку. 

Как реально оценивать.

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

Декомпозируй до кусков по 1–2 дня. Задача сделать модуль аналитики должно скорее иметь интент намерения нежели задачи. Ее надо разложить: сбор требований, проектирование схемы данных, backend (с разбивкой по эндпоинтам), frontend (по экранам), интеграция, тестирование, правки, релиз. Чем мельче куски, тем точнее оценка в сумме. Крупный блок человек почти всегда недооценит. В куски по 1–2 дня попадает гораздо чаще.

Оценивай каждый кусок отдельно, не складывай в уме. Если оцениваешь весь модуль целиком, мозг берет среднее от примерно как тот похожий и добавляет интуитивный буфер. Это всегда мало. Сумма честных маленьких оценок обычно в 1,5 раза больше, чем одна большая оценка того же самого.

Риски вынеси отдельной строкой. Не прячь их внутри цифры, типа «ну я на всякий случай накинул». Пиши явно: базовая разработка 24 часа, риск новой библиотеки +8 часов, риск зависимости от команды X +16 часов. Когда риски видно списком, с ними можно работать: какой-то закрыть заранее, какой-то принять, какой-то вынести за скоуп.

Диапазоны, а не точки. 24–32 часа, а не 28. 3–4 недели, а не 3,5. Точная цифра создает иллюзию знания. Диапазон дает честную формулировку того, что ты реально понимаешь.

Пересматривай оценку по мере появления информации. Через неделю разработки ты знаешь о задаче в 10 раз больше, чем знал на старте. Значит, и оценка должна обновиться. В зрелых командах это называется rolling forecast: прогноз, который обновляется каждую неделю или спринт.

Как объяснять все это заказчику без суеты

У меня самая частая ошибка: прятать неопределенность, чтобы не пугать бизнес. Не работает. Плохо: Сделаем за 3 недели. Через 3 недели не готово, и ты крайний. Хорошо: При текущем объеме оценка 3 недели. Если добавим интеграцию с CRM, потребуется еще неделя. Если выяснится, что их API отдает данные не в том формате, еще плюс 3–5 дней, это риск. Цифры те же. Но теперь вы с заказчиком на одной стороне стола, а не по разные.

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

Что делать, когда понимаешь, что не успеваешь

А ты это поймешь. Не в день дедлайна, раньше. Обычно на 60–70% срока вдруг становится ясно, что оставшийся объем в оставшееся время не влезает.

Главное правило, которое я усвоил через боль: не молчать. Герои, которые до последнего пытались успеть своими силами проваливались с треском. Они молчат до пятницы, в пятницу вечером признаются, что не успели, и дальше все работают в выходные с матом и кофе. Я так делал. Результат: все равно не успели, а заодно команда выгорела.

Сейчас я действую так:

• как только видно, что риск реализуется, в течение 24 часов пишу заказчику и в команду;

• показываю причину: «всплыла вот такая зависимость, мы ее не учли»;

• предлагаю четыре варианта: сократить скоуп (вот что можно выкинуть), сдвинуть срок (вот на сколько), добавить ресурсы (вот что это даст, если даст), выпустить MVP и остальное доделать потом.

Это четыре рычага из проектного менеджмента. Их иногда называют «треугольник ограничений» плюс качество. На одном проекте я так договорился разбить релиз на две волны. Первая часть ушла в срок, вторая через 3 недели. Заказчик был доволен, потому что критичное получил вовремя. Если бы молчал и обещал «доделаем вот-вот», получил бы скандал и ноль фич в проде.

Что реально помогает попадать в сроки чаще

За годы набрал небольшой список того, что работает. Не методология, не фреймворк, просто вещи, которые повторяются у удачных команд.

История прошлых проектов. Если оцениваешь новый проект вообще без оглядки на то, как шли предыдущие, это скорее похоже на гадание. Заведите где угодно, хоть в таблице, журнал: что оценили, что получилось по факту, какой был коэффициент промаха. Через 10 проектов у вас будет собственный множитель для типовых задач. У нас в одной из команд он был стабильно 1,8. Это значит, что оценку разработчика мы смело умножали на 1,8 и чаще всего попадали.

Декомпозиция до мелких кусков. Повторюсь, потому что это реально номер один по эффекту. Задачи короче 2 дней оцениваются адекватно. Задачи на 2 недели почти всегда занижены.

Честные буферы на риски. Накинуть 20% на всякий случай идея не очень, лучше оценить все водные и накинуть 70% чтобы наверняка, сколько не оценивал, наценка в 70% по большей части это 90% вероятности совпадения сроков. Буфер на «неизвестность интеграции». Буфер на «заказчик еще не согласовал макеты». Буфер на «отпуска бэкендера» и еще парочку, с ними то на то и выходит.

Weekly review прогресса. Раз в неделю смотришь, что оценили, что сделали, какая дельта, как она влияет на срок. Это 30 минут в неделю. Экономит недели.

Прозрачные зависимости. Если твоя задача зависит от чужой команды, она не начнется, пока та не закончит. Это нужно рисовать явно. Самая дорогая просрочка в моей карьере была из-за того, что две команды 3 недели ждали друг от друга спецификацию. Каждая считала, что должна написать другая.

Фиксация изменений скоупа. Любое а давайте еще вот эту маленькую штучку фиксируется письменно, с оценкой. Не «ну мы же договаривались устно». Устно не договаривались. За 10 лет я видел ровно один проект, где устные договоренности не всплыли потом конфликтом. Ровно один, в остальном это все было обречено на провал.

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

И да, про ИИ. В 2026-м половина трекеров обзавелась таки AI-прогнозами сроков. Работают в целом нормально нежели хорошо, больше походят на джуна ассистента аналитика. Они видят повторяющиеся паттерны в ваших проектах, подсвечивают аномалии, предлагают вероятностные диапазоны вместо одной цифры. По данным McKinsey, ML-модели на исторических данных дают улучшение точности оценки на 20–30% по сравнению с чисто экспертным подходом. Это неплохо. Но только когда в умелых руках и ИИ пулемет, ну вы поняли. Без понимания сути получите просто эссе на тему с красивыми цифрами и радужными пони, которые поедут в первую же неделю. 

Итого

Сроки в IT срываются из-за того, что мы пытаемся оценить то, что по природе своей плохо оценивается.

• Хорошая оценка проекта не попытка угадать будущее, а больше относится к управлению неопределенностью.

• Одна точная дата создает ложную уверенность; диапазон с рисками дает честную картину.

• Декомпозиция до кусков по 1–2 дня дает кратно более точную оценку, чем крупные блоки.

• Риски надо выносить отдельной строкой, а не прятать внутри цифры.

• Молчать до дедлайна и геройствовать в выходные — классический путь к провалу проекта и команды.

• AI-инструменты помогают, но не заменяют человека, который понимает контекст.

• Честная коммуникация с заказчиком про риски не слабость, а главный рычаг.

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

А вы как оцениваете сроки? Есть свой коэффициент промаха по команде, или все еще надеетесь, что в этот раз обойдется?