Почему оценки сроков в разработке всегда врут — и что мы делаем вместо них

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

Почему оценки врут — это не лень и не глупость

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

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

Что мы перестали делать

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

Что мы стали делать вместо

1. Делим до тех пор, пока не станет понятно. Если задачу нельзя оценить, её просто плохо понимают. Мы режем её на куски, пока каждый кусок не станет настолько мелким и ясным, что оценка перестаёт быть гаданием. Само это дробление часто и есть самая полезная часть планирования.

2. Говорим диапазонами и уверенностью, а не точкой. Не «три дня», а «от двух до пяти, и вот что может утянуть к пяти». Это честнее и сразу показывает, где риск. Точная цифра скрывает неопределённость, диапазон её обнажает.

3. Выделяем неизвестное в отдельную разведку. Если в задаче много тумана, мы сначала ставим маленькую исследовательскую задачу — разобраться и снять неопределённость, — и только потом оцениваем остальное. Оценивать в тумане бессмысленно, сначала надо его рассеять.

4. Считаем по факту, а не по обещаниям. Мы стали смотреть, сколько реально проходит задач за период, а не сколько мы наобещали. Реальная скорость команды предсказывает будущее куда лучше, чем оптимистичные оценки на берегу.

Что изменилось

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

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

Если вы до сих пор требуете (или даёте) точные оценки в часах на сложные задачи — спросите себя, сколько из них реально сбылось. Подозреваю, диапазон и честность сэкономят вам куда больше нервов, чем красивое число в таблице.

А как у вас в команде живут с оценками? Верите в сроки или давно махнули рукой?