Оценка сроков в разработке: почему конкретные цифры почти всегда врут

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

Откуда берётся систематическое занижение сроков

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

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

Почему одно число хуже, чем диапазон

Отдельная проблема — не сама оценка, а формат, в котором она произносится вслух. Число «три дня» в голове у того, кто его слышит, мгновенно превращается в обещание, а не в прогноз. Дальше срабатывает обычная психология: как только у задачи появляется дедлайн, ни у кого больше нет стимула сообщать о рисках заранее — все ждут до последнего момента в надежде, что успеют, и сообщают о срыве только когда откладывать уже некуда.

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

Что реально помогает оценивать точнее

Полностью убрать неопределённость из оценки нельзя — задача, которую можно оценить со стопроцентной точностью, обычно уже почти сделана. Но есть практики, которые заметно снижают систематическую ошибку:

• Декомпозиция перед оценкой, а не после. Задача «сделать импорт CSV» оценивается интуитивно и почти всегда неточно. Задача, разбитая на «парсинг файла», «валидация строк», «запись в базу пачками», «обработка дублей», «отображение прогресса в интерфейсе», оценивается по частям гораздо точнее — потому что для каждой части видно, что именно неизвестно.
• Явное разделение «знаю» и «не знаю». Если задача требует интеграции с незнакомым API или библиотекой, честнее сразу выделить отдельный шаг «разведка» с собственной, отдельной оценкой, а не размазывать неопределённость по общей цифре.
• Учёт истории, а не ощущений. Если последние несколько похожих задач в среднем занимали заметно больше исходной оценки, это не случайность и не невезение — это сигнал, что метод оценки для этого типа задач нужно скорректировать, а не что команда стала работать медленнее.
• Отдельный учёт «работы вокруг работы». Ревью, ожидание ответа от смежной команды, деплой и настройка окружения часто вообще не попадают в оценку, хотя реально занимают время между стартом и завершением задачи.

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

Как говорить о сроках, чтобы это работало на команду

Разработчику стоит не бояться называть диапазон и явно проговаривать главное допущение: «если ничего не всплывёт — два дня, если зацепим авторизацию — плюс два». Это не признак неуверенности, а ровно та информация, которая нужна менеджеру или тимлиду, чтобы планировать реалистично, а не оптимистично. Точно так же полезно как можно раньше сообщать не о срыве срока, а об изменении вероятности срыва — например, в середине задачи сказать «пока укладываемся, но нашли зависимость, которую не учли», а не молчать до последнего дня.

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