В прошлом посте мы разобрали ловушку оптимизма, в которую попадают при попытке оценки нового проекта. Главная причина — Planning Fallacy: когда наш мозг из раза в раз моделирует идеальный сценарий и игнорирует прошлые провалы.
В этом разберем, как оценивать так, чтобы потом попадать в свои оценки.
Переключиться на взгляд снаружи вместо изнутри
При оценке сроков нужно переключить свой взгляд с изнутри (Inside view) проекта/задачи на взгляд снаружи (Outside view):
Inside view — вы детально разбираете именно этот проект: какие шаги предпринять, что нужно сделать и т. п.
Outside view — смотрим, сколько времени занимали подобные проекты или задачи, с какими трудностями столкнулись.
Один из лучших методов борьбы с Planning Fallacy — метод Reference Class Forecasting — прогнозирование на основе референсных значений.
▸ Соберите статистику по подобным задачам и проектам.
▸ Вычислите среднее и медиану.
▸ Используйте эти цифры как базовую линию, а потом откорректируйте (только осторожно) с учетом уникальности оцениваемой задачи.
Оценка вслепую — ломаем якорь
Когда кто-то из команды или стейкхолдеров называет число, особенно кто-то авторитетный и имеющий вес, остальная команда начинает невольно подстраивать свои оценки под это число.
Чтобы избежать предвзятости, исключаем влияние цифр:
▸ Внедряем Planning Poker — каждый оценивает независимо, до обсуждения оценок.
▸ Вскрываем карты с оценками и обсуждаем результаты и скоуп работ.
▸ Если разброс большой — больше 30%, то необходимо обсудить и выяснить, что по-разному понимаем в этой задаче.
Таким образом из «политического торга» оценивание превращается в техническую дискуссию.
Декомпозиция и оценка по PERT
Чем больше неопределенности в задаче, тем труднее ее оценивать. Для более точной оценки дробите функциональность на небольшие понятные кусочки. И уже декомпозированные куски оценивайте.
Для более-менее точного предсказания оценки можно воспользоваться методом PERT. Он заключается в следующем:
▸ Вместо одной оценки запрашиваем три:
✦ O — Optimistic — когда все пойдет идеально;
✦ M — Most Likely — реалистичный случай;
✦ P — Pessimistic — когда все пойдет по наихудшему сценарию.
▸ Результирующая оценка будет равна: (O + 4M + P) / 6
Пример: O=2 дня, M=4 дня, P=10 дней Результирующая оценка: (2 + 16 + 10) / 6 = 4,7 дня
Добавляем буфер на то, что не можем предсказать
Даже с учетом всего выше перечисленного на срок выполнения проекта может повлиять множество неизвестных (пока) и случайных факторов: болезнь разработчика, случайные баги, пожар в датацентре, что-то забыли включить в скоуп.
Поэтому обязательно закладывайте буфер на непредвиденные обстоятельства:
▸ на уровне задач — 15–20%;
▸ на уровне спринта/итерации — 10–15%.
Важные правила:
▸ Буфером владеет менеджер или тимлид — это не свободное время, а страховка.
▸ Буфер прозрачен — стейкхолдеры знают, что он есть, но не распределяют его на «еще одну маленькую фичу».
▸ Буфер постоянно анализируется — смотрим, на что уходит буфер, если его постоянно не хватает, то вы слишком оптимистичны.
Вместо вывода
Победить ошибку планирования практически невозможно — это нормальная работа нашего мозга. Но можно построить процесс, который это компенсирует.
Реалистичная оценка — это не про то, чтобы «дать бизнесу то, что он хочет услышать». Это про управление ожиданиями, сохранение доверия и здоровье команды.
Лучше назвать честную оценку — «5 дней с учетом рисков» и сделать за 4, чем пообещать «3 дня» под давлением и сорвать дедлайн.
А какие техники оценки используете вы? Пробовали ли слепую оценку или PERT? Делитесь опытом в комментариях.
Reference class forecasting
Reference class forecasting - Wikipedia
#management #processes #agile #TeamLead #team