Попросите джуна и сеньора оценить одну и ту же задачу и получите разные цифры. Джун скажет «дня за два», сеньор «неделя, может полторы». Они ошибаются в разные стороны: джун систематически в минус, сеньор систематически в плюс. В этой статье разберу, откуда берётся это смещение и какие методы позволяют с ним работать.
Почему джуны всегда оптимисты
Оптимизм джуна растёт из незнания. Он оценивает «счастливый путь»: сел, написал код, оно заработало. В его картине задачи есть только та часть, которую он видит. Собственно только написание функции. А дальше начинается то, чего он пока не видел ни разу или видел редко.
Между «код написан» и «задача в проде» лежит длинный процесс, про который джун не подозревает или про который забывает: код-ревью, несколько исправлений кода, unit тесты, e2e тесты, краевые случаи, которые всплывают только когда руки доходят до реализации, интеграция с чужим сервисом, который ведёт себя не как в документации, ожидание ответа от смежной команды, поднявшийся на стейдже баг, сломавшийся стейдж. Эти этапы джун не закладывает в оценку просто потому, что неглубоко их понимает. А чего не знаешь, того и не закладываешь.
Это хорошо ложится на модель уровней знания, про которую я уже писал отдельно: джун находится в зоне «не знаю, что не знаю». Он не может заложить в оценку риск, о существовании которого даже не догадывается. Поэтому его оценка — это оценка лучшего из возможных сценариев. А лучший сценарий случается примерно никогда.
Почему сеньоры пессимисты
Сеньор ошибается в обратную сторону, и причина у него тоже одна — память. Он слишком много раз видел, как «задача на 15 минут» превращалась в две недели. В его оценку зашита сумма всех граблей, на которые он наступал. Там, где джун видит написание функции, сеньор видит ревью, тесты, прод-инцидент в три часа ночи и того самого смежника, который не отвечает по три дня. Он закладывает на «всё, что может пойти не так», потому что наблюдал, как оно постоянно идёт не так.
Само по себе это полезнее джунского оптимизма, потому что такая оценка ближе к реальности. Но и здесь есть перекос, хоть и не такой заметный. Страх недооценить однажды и потом за это ответить толкает сеньора закладывать буфер с запасом. А дальше включается закон Паркинсона: работа занимает всё время, отведённое на неё. Если на задачу заложена неделя, она и займёт неделю. Даже если по-настоящему там было бы три дня. Буфер не лежит нетронутым «на всякий случай», он тихо расходуется. Перестраховка — тоже ошибка оценки, просто в сторону перезакладывания времени, а не недозакладывания. И стоит она реальных денег и сроков, только эта переплата не видна явно. Потому что в сроки и дедлайны-то уложились.
Откуда берётся систематическая ошибка
Джунский оптимизм и сеньорский пессимизм — всё это частные случаи одного явления. В психологии его называют ошибкой планирования (planning fallacy): люди систематически недооценивают время на собственные задачи, даже когда прекрасно помнят, что прошлые такие же задачи заняли больше. Мы оцениваем по тому сценарию, который держим в голове. А в голове чаще всего один конкретный путь, чаще оптимистичный.
Ключевое слово здесь — систематическая. Ошибка устойчиво смещена в одну сторону, и сторона зависит от опыта оценивающего. Для руководителей это хорошая новость: случайный шум убрать нельзя, а устойчивое смещение — можно. Только не силой воли. Ошибки планирования так не побороть. Нужен процесс, который учитывает смещение за вас. Фундаментально таких процессов два.
Как оценивать сроки разработки правильно
Сразу оговорюсь: называть точную цифру вы не научитесь. Точная оценка недостижима в принципе, и любой, кто её обещает, либо не понимает задачи, либо лукавит. Реальная цель скромнее: чтобы оценка не врала систематически в одну сторону и чтобы по ней было видно, насколько вы в ней уверены.
Если бы я умел точно предсказывать будущее, то только и покупал бы лотерейные билеты, а не работал.
Мой ответ, когда просят дать оценку «поточнее»
Трёхточечная оценка (PERT)
Вместо одной цифры дайте три. Оптимистичную (O) — если всё пойдёт гладко. Реалистичную (M) — как, скорее всего, будет. Пессимистичную (P) — если всплывёт то, что обычно всплывает. А итоговую оценку считайте по формуле PERT:
Оценка = (O + 4·M + P) / 6
Реалистичный сценарий берётся с весом 4, а крайние с весом по 1 каждый. Получается взвешенное среднее, смещённое к «как обычно», но с поправкой на оба хвоста.
Простой пример. Задача, которую джун оценил бы в 2 дня, а сеньор — в 9. Раскладываем по трём точкам: оптимистично 2 дня, реалистично 4, пессимистично 9.
(2 + 4·4 + 9) / 6 = 27 / 6 = 4.5 дня
Четыре с половиной дня — цифра, выведенная из явно проговорённых сценариев, а не по ощущениям. Но главное в этой технике даже не итоговое число, а разрыв между O и P. Если оптимистичная оценка 2 дня, а пессимистичная 9, задача плохо понята: в ней слишком много неизвестного. Такую задачу рано оценивать. Её надо декомпозировать или сначала исследовать, а потом оценивать куски.
Reference class — смотри на похожие прошлые задачи
Трёхточечная оценка всё ещё опирается на цифры из головы, а голова смещена. Второй приём чинит как раз это: не оценивайте из головы вовсе. Поднимите данные о том, сколько на самом деле заняли похожие задачи в прошлом.
Этот подход называется reference-class forecasting: вместо того чтобы фантазировать «сколько займёт эта задача», вы смотрите на класс похожих задач и берёте их реальную статистику. Сколько по факту заняли последние пять интеграций с внешним API? Сколько реально длилась прошлая миграция схемы? Эти цифры уже включают в себя грабли. Как те, что джун не предвидел, так и те, под которые сеньор закладывал буфер. Они более объективны, потому что опираются не на прогноз, а на прошлые факты.
Здесь и проявляется главная ценность трекера задач. Если у вас есть история, то у вас есть противовес от джунского оптимизма и от сеньорского пессимизма одновременно. Реальности всё равно. Она не оптимист и не пессимист. Она просто была такой, какой была.
К этим двум техникам добавлю три привычки, которые делают оценки адекватнее и ближе к реальности:
- Декомпозируйте до задач в один-два дня. Чем мельче кусок, тем меньше места для систематической ошибки. Оценить пять задач по дню точнее, чем одну «на неделю». Но не переусердствуйте, иначе на декомпозицию можно потратить времени больше, чем на сами задачи.
- Давайте диапазон, а не точку: «от 3 до 6 дней» будет честнее, чем «4 дня». Точка создаёт иллюзию уверенности, которой у вас нет.
- Отделяйте оценку от обязательства. «Оценка» — это синоним «столько, по моим данным, займёт эта задача». А «обязательство» — синоним «обещаю сдать задачу к такому сроку». Если смешивать два термина, то оценка задач превратится в гонку или измерения «у кого короче».
Что с этим делать тимлиду
Как тимлиду вам важна не столько оценка отдельного сотрудника, сколько калибровка всей команды. Для вас важно фиксировать как оценку, так и факт, чтобы потом посмотреть на расхождение.
Если человек стабильно оценивает в два раза меньше реального, то ругать его бесполезно. Полезнее завести калибровочный коэффициент: умножать его оценки на два, а со временем помочь ему увидеть тот хвост работы, который он не закладывает. С сеньором-перестраховщиком то же самое, но в обратную сторону. Разбор расхождения между оценкой и фактом — это, по сути, тот же метод пяти «почему»: почему задача заняла втрое больше? Упёрлись в чужой сервис? Не учли тесты? Каждый такой разбор делает следующую оценку точнее.
Подчеркну также вот что. За честную оценку нельзя наказывать. Если человек получает по голове каждый раз, когда назвал большую цифру или промахнулся, то он перестаёт оценивать честно и начинает называть то, что от него хотят услышать. Так вы потеряете возможность оценивать задачи, а вместе с ней и возможность планировать работу. Оценки, подогнанные под ожидания руководителя, — это прямой путь к хроническим переработкам и выгоранию команды. Считайте, что рукотворный Highway to Hell. За плохие оценки вы заплатите не абстрактными цифрами в таблице, а людьми, которые сидят до ночи, потому что кто-то однажды сказал «ну, дня за два».
Для нового тимлида умение работать с оценками команды один из базовых навыков. Без него не получится защищать сроки перед бизнесом и не сжигать при этом людей. Я собрал такие навыки в Карте первых 90 дней тимлида. Там оценка стоит рядом с делегированием и обратной связью как часть работы, которую новый руководитель осваивает первой.
Итог
Джун будет оптимистом, потому что не видит хвоста работы. Сеньор будет пессимистом, потому что помнит все грабли. Оба смещения никуда не денутся, но их можно компенсировать: трёхточечная оценка делает разброс явным, а статистика похожих задач возвращает к фактам.
Начните с малого. Возьмите ближайшую задачу, которую собирались оценить одной цифрой, и назовите вместо неё три. А потом загляните в трекер. Сколько на самом деле заняла прошлая такая же задача?
Теги: