Сколько раз у меня было так: сажусь оценивать задачу, уверенно пишу «два дня», а через две недели всё ещё копаюсь в том же месте и объясняю заказчику, почему так вышло. Оценки в IT — пожалуй, самое болезненное место. Мы либо обещаем слишком много, либо боимся назвать реальные сроки и занижаем их, чтобы выглядеть быстрее. В итоге страдают все: клиент, команда и моя собственная нервная система.
Лет пять назад я наткнулся на метод трёх точек, который пришёл из управления проектами, и это стало переломным моментом. Суть проста: на каждую задачу вы даёте не одну цифру, а три. Оптимистичная оценка — если всё пойдёт идеально, ничего не сломается и все ответят в чате мгновенно. Реалистичная — самый вероятный сценарий, как оно обычно и бывает. Пессимистичная — если всплывут неожиданные зависимости, тесты упадут, доступы придут не сразу, а на ревью уйдёт два дня.
Дальше самое интересное — ожидаемое значение. Складываем оптимистичную оценку, четыре реалистичных и пессимистичную, а потом делим на шесть. Получается взвешенная цифра, где средний сценарий имеет наибольший вес, но крайние коридоры не выбрасываются. Звучит как математика ради математики, но на практике работает удивительно хорошо.
Помню задачу по интеграции с платёжным провайдером. Я бодро сказал «три дня», потому что API казалось простым. Реальность: пять дней на согласование, два на тестовые карты, неделя на разбор неочевидных ошибок. По методу трёх точек я бы дал так: оптимистично — 3 дня, реалистично — 6, пессимистично — 14. Ожидаемая оценка выходит около 7 дней, и я бы добавил буфер сверху. Заказчик в этом случае слышит не сказку про «три дня», а честный рабочий диапазон.
Почему это работает? Во-первых, снижается эмоциональное давление: ты не обязан выдавать одну «правильную» цифру, которую потом стыдно защищать. Во-вторых, появляется язык для торга — можно показать, что именно раздувает пессимистичный сценарий, и обсудить риски. В-третьих, сразу видно, какие задачи самые неопределённые: если разрыв между оптимистичной и пессимистичной оценкой огромный, это сигнал разбить работу на части или сначала провести короткое исследование.
Как внедрять это без бюрократии? Я советую начать с личных задач и вести простой журнал: оценка и фактическое время. Через месяц вы увидите, что системно недооцениваете, например, интеграции или код-ревью. Мелкие задачи можно объединять в один блок, иначе обсуждение каждой мелочи съест больше времени, чем сама работа. И обязательно давайте оценки независимо, до того как услышите цифру коллеги — иначе сработает эффект якоря, и все дружно назовут одно и то же число.
Главная ловушка — превратить метод в самообман. Если вы всегда называете пессимистичную оценку как основную «на всякий случай», вы просто переносите старую проблему в новую форму. Три точки не отменяют ретроспективы: сравнивайте прогноз с фактом, подкручивайте свой личный коэффициент и не бойтесь признавать, что в прошлый раз ошиблись. Честная история оценок ценнее любой красивой формулы.
Для меня метод трёх точек стал не столько про математику, сколько про разговор. Вместо спора «два дня или пять» мы обсуждаем, какие риски заложены и что можно сделать, чтобы уложиться в оптимистичный сценарий. Дедлайны всё ещё иногда трещат, но теперь это исключение, а не норма, и это сильно бережёт нервы.
А вы пробовали оценивать задачи через три точки или предпочитаете одну цифру и честный буфер? Расскажите, какие приёмы помогают лично вам не срывать сроки — будет очень интересно сравнить опыт!
Лет пять назад я наткнулся на метод трёх точек, который пришёл из управления проектами, и это стало переломным моментом. Суть проста: на каждую задачу вы даёте не одну цифру, а три. Оптимистичная оценка — если всё пойдёт идеально, ничего не сломается и все ответят в чате мгновенно. Реалистичная — самый вероятный сценарий, как оно обычно и бывает. Пессимистичная — если всплывут неожиданные зависимости, тесты упадут, доступы придут не сразу, а на ревью уйдёт два дня.
Дальше самое интересное — ожидаемое значение. Складываем оптимистичную оценку, четыре реалистичных и пессимистичную, а потом делим на шесть. Получается взвешенная цифра, где средний сценарий имеет наибольший вес, но крайние коридоры не выбрасываются. Звучит как математика ради математики, но на практике работает удивительно хорошо.
Помню задачу по интеграции с платёжным провайдером. Я бодро сказал «три дня», потому что API казалось простым. Реальность: пять дней на согласование, два на тестовые карты, неделя на разбор неочевидных ошибок. По методу трёх точек я бы дал так: оптимистично — 3 дня, реалистично — 6, пессимистично — 14. Ожидаемая оценка выходит около 7 дней, и я бы добавил буфер сверху. Заказчик в этом случае слышит не сказку про «три дня», а честный рабочий диапазон.
Почему это работает? Во-первых, снижается эмоциональное давление: ты не обязан выдавать одну «правильную» цифру, которую потом стыдно защищать. Во-вторых, появляется язык для торга — можно показать, что именно раздувает пессимистичный сценарий, и обсудить риски. В-третьих, сразу видно, какие задачи самые неопределённые: если разрыв между оптимистичной и пессимистичной оценкой огромный, это сигнал разбить работу на части или сначала провести короткое исследование.
Как внедрять это без бюрократии? Я советую начать с личных задач и вести простой журнал: оценка и фактическое время. Через месяц вы увидите, что системно недооцениваете, например, интеграции или код-ревью. Мелкие задачи можно объединять в один блок, иначе обсуждение каждой мелочи съест больше времени, чем сама работа. И обязательно давайте оценки независимо, до того как услышите цифру коллеги — иначе сработает эффект якоря, и все дружно назовут одно и то же число.
Главная ловушка — превратить метод в самообман. Если вы всегда называете пессимистичную оценку как основную «на всякий случай», вы просто переносите старую проблему в новую форму. Три точки не отменяют ретроспективы: сравнивайте прогноз с фактом, подкручивайте свой личный коэффициент и не бойтесь признавать, что в прошлый раз ошиблись. Честная история оценок ценнее любой красивой формулы.
Для меня метод трёх точек стал не столько про математику, сколько про разговор. Вместо спора «два дня или пять» мы обсуждаем, какие риски заложены и что можно сделать, чтобы уложиться в оптимистичный сценарий. Дедлайны всё ещё иногда трещат, но теперь это исключение, а не норма, и это сильно бережёт нервы.
А вы пробовали оценивать задачи через три точки или предпочитаете одну цифру и честный буфер? Расскажите, какие приёмы помогают лично вам не срывать сроки — будет очень интересно сравнить опыт!