⏱ Почему сроки в IT почти всегда срываются и почему это всех устраивает

В управлении IT-проектами жесткие сроки на старте - это всегда лотерея. Даже опытные команды промахиваются в 70% случаев, потому что оценивают чистый код, забывая про согласования, правки, ожидания и неизвестные риски вроде кривых API легаси.

Главная ошибка - обещать одну точную дату. Это создает ложную уверенность у всех, включая менеджера. Вместо одной цифры давайте три: реалистичный срок (70% случаев), с рисками (90%) и оптимистичный сценарий. Так заказчик видит картину целиком, а срыв дедлайна превращается в попадание в вилку.

Что реально работает. Разбивайте задачу на куски по 1-2 дня - сумма мелких оценок в 1,5 раза точнее одной крупной. Оценивайте риски отдельной строкой, а не "накидкой на глаз".

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

Если понимаете, что не успеваете, не молчите до дедлайна. В 24 часа сообщите причину и предложите четыре варианта на выбор: сократить скоуп, сдвинуть срок, добавить ресурсы или выпустить MVP волнами. Честная коммуникация про риски - не слабость, а ваш главный рычаг управления.

Заведите простой журнал: что оценили, что получилось, коэффициент промаха. Через несколько проектов появится свой множитель (например, 1,8). AI-прогнозы в трекерах дают плюс 20-30% точности на исторических данных, но не заменяют понимания контекста.

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

LinkedIn: Пётр Третьяк, Senior Project Manager - NDA

📖 Читать статью (~8 минут)