Тотализатор для разработчика: попадаешь ли в свою оценку?

В этой статье я расскажу о том, почему даже опытные ребята промахиваются со своими оценками и почему это системный сбой мышления, а не случайность. Затронем проблему оценки задач, самообман при их оценке и разберемся, как избежать иллюзий и прокачать навык оценивания задач.

Основные проблемы оценки задач

Проблема оценки задач в мире IT не нова, с ней сталкиваются все в ходе работы. Первая ошибка заключается в том, что мы стараемся объять необъятное, а важно учитывать масштаб задачи. Зачастую рассматриваем только кусочек задачи и забываем, что формат и размер напрямую влияют на подход к ней. Нельзя оценивать одинаковыми мерками мелкую задачу по изменению формы и задачу по внедрению интеграции крупного модуля.

Вторая проблема – психосоматика и психология оценки задач. Человеческий фактор редко учитывается при оценивании, хотя мозг любит выдавать красивые, но нечестные цифры.

Третья проблема – мы забываем, что задача состоит не только из написания кода. В нее входят уточнения, код-ревью, деплой. Если не учитывать эти моменты, в итоге произойдет промах и срыв дедлайна.

Следующая серьезная проблема – отсутствие глубокого анализа. Когда задача описана верхнеуровнево, разработчику приходится самостоятельно продумывать детали и разбираться в них. В результате на задачу тратится в два-три раза больше времени, чем запланировано.

Важно фиксировать требования. Чем более четко они зафиксированы и прописаны, тем лучше результат на выходе.

Критически важный момент – рационально опираться на опыт прошлого. Если команда не ведет учет оценки и факта, ей сложно давать четкие прогнозы.

Вывод: навык оценивания требует честности, опыта и системности. Без этого сроки будут срываться, а работа превратится в угадайку.

Факторы, убивающие точность оценки

Точность оценки убивает не отсутствие таланта у разработчика, а конкретные вещи.

Первое – когнитивные искажения. Мы часто уверены, что в этот раз все будет быстрее и получится с первого раза.

Второе – планировочная ошибка. Это глобальная проблема, которую описывали Канеман и Тверски. Люди систематически недооценивают время, даже имея опыт провалов. Мозг по умолчанию настроен оптимистично.

Третье – отсутствие общей системы. Когда задачи разного масштаба оцениваются одной меркой, все провалы выглядят одинаково.

Самообман при оценке задач

Почему мы промахиваемся с оценками? Когда мы сосредоточены только на написании кода, мы забываем о важных моментах: утверждения, тестирование, ошибки на проде, которых не было на тестовой базе. Если это не учитывать, промах с оценкой гарантирован.

Мозг выстраивает идеальный сценарий: я сяду, напишу код, и все заработает с первого раза. В реальности возникает баг, меняются требования, что-то не взлетает. Мозг игнорирует этот опыт и каждый раз возвращается к идеальному миру.

Я хочу сказать, что важно выстроить процесс планирования задачи. Чем четче он выстроен, тем меньше расхождение между фактом и оценкой.

Психология занижения

Отдельно хочу затронуть тему психологии занижения. Человеческий фактор часто ломает расчеты.

Первое – страх завысить оценку. Разработчик боится назвать большую цифру. Он думает: «Если я скажу, что мне нужно три дня на решение проблемы, все подумают, что я слабый или некомпетентный». Он подсознательно срезает цифру, хотя понимает, что времени потребуется больше. Это желание показаться лучше, чем он есть на самом деле.

Второе – эффект приятного ответа. Когда разработчик общается с заказчиком, он понимает, что заказчик хочет быстро и недорого. Он называет приятную оценку, что выливается в срыв сроков, и от этого становится хуже всем.

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

Отдельно стоит затронуть оптимизм. Мозг оптимист по умолчанию. Если задача заняла три дня вместо обещанных двух, он не запоминает боль от провала. Он запоминает: «Было не так уж плохо, я почти справился вовремя». При новой оценке он снова думает, что в этот раз точно успеет.

Социальное давление. Многие сталкивались с этим на этапе младших специалистов. Представим, что junior-разработчик попадает в команду опытных ребят, которые тратят меньше времени на схожие задачи. На планерке обсуждаются сроки, и джун начинает инстинктивно срезать оценку, подстраиваясь под большинство. Это эффект группового мышления, когда человек подстраивается под общество или лидера.

Ошибки в оценках – это не только про математику и опыт, но и про психологию и психосоматику. Пока мы не признаем и не разберем в себе эти сложности, никакие практики и методики не помогут решить проблему.

Когнитивные искажения

Говоря о психологии, нельзя не затронуть тему когнитивных искажений. Вот некоторые из них:

• Планировочная ошибка, когда мы склонны недооценивать сроки и ресурсы, которые необходимо потратить на задачу.

• Иллюзия контроля. Мы уверены, что задача пойдет по намеченному плану.

• Эффект якоря, когда первая названная оценка сильно влияет на итоговую.

• Излишний оптимизм, когда мы считаем задачу более простой, чем она есть.

• Групповое мышление, когда человек подстраивается под мнение большинства или лидера.

Практические методы улучшения оценки

Как перестать врать самому себе и исправить ситуацию?

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

Второе – нужна практика, которая срезает оптимизм. Один из рабочих инструментов – метод трех точек (PERT). Даются три оценки: оптимистичная (O), пессимистичная (P) и реалистичная (M). Затем рассчитывается итоговая оценка по формуле (O+4M+P)/6. Это позволяет вместо «задача займет день» говорить: «С восьмидесятипроцентной вероятностью задача займет от полутора до двух дней». Разработчик меньше попадает в капкан иллюзий, а руководству и команде проще планировать загрузку.

Третье – исторические данные. Если не вести сравнение факта и оценки, команда играет в угадайку. Можно взять последние десять задач и сравнить оценку и факт. Если расхождение больше 1,25, есть системная проблема – оптимизм, а не случайность.

Как же попасть в ту самую оценку задачи?

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

За фундамент можно взять следующий подход: разный размер – разный подход.

Во-первых, это дает предсказуемость. Маленькая задача почти всегда точна в оценке, а крупная содержит десятки неизвестных. Если ставить их в один ряд, результат будет искажен.

Второе – уровень детализации. Для маленькой задачи достаточно наброска, а для средней и крупной нужно фиксировать требования, прорабатывать их, описывать архитектуру. Иначе оценка превращается в гадание.

Третье – контроль рисков. В больших задачах много точек, где можно выйти за сроки. Без классификации никто не закладывает резервы и буферы, потому что задачи оцениваются одинаково.

Четвертое – управление ожиданиями. Когда бизнес видит классификацию задач, он понимает, что разные масштабы требуют разного подхода к срокам и контролю. Это снижает конфликт, и никто не ждет, что крупная задача будет выполнена за несколько дней.

Поэтому я считаю, что классификация – не формальность, а первый шаг к попаданию в оценку. Нужно выстроить систему, которая позволяет хорошо планировать и давать точные оценки.

Прогноз сроков

При прогнозировании сроков главное правило – использовать статистику вместе с экспертными оценками. Опираться только на статистику неудобно: подход получается бездушным и негибким. Экспертные оценки позволяют учитывать нюансы проекта и выявлять технические риски, которые не отражены в цифрах.

Лучше использовать комбинацию статистики и экспертных оценок. Статистика позволяет анализировать задачи, сравнивать оценку и факт, понимать, где есть проблемы и какие задачи превышают первоначальные оценки. Экспертное мнение помогает разобраться, что с этим делать, и выявить новые факторы для проработки. В результате получается относительная оценка, которая снижает иллюзию точности и позволяет сравнивать задачи между собой.

Не нужно искать идеальную формулу оценки задачи. Нужно выстроить систему, которая адаптируется к изменениям, учитывает расхождения и корректирует подход к задачам.

Как прокачать навык оценивания задач?

Что делать, если вы регулярно не попадаете в свою оценку?

Если вы заметили, что стабильно не укладываетесь в сроки, значит, это не проблема конкретной задачи, а системный паттерн. Важно не превращать это в самобичевание, а научиться видеть закономерности.

Первое, что нужно сделать – перестать жить в иллюзии, что в следующий раз получится угадать. Это не лотерея. Навык оценивания – это мышца, которая прокачивается через регулярную практику и обратную связь.

Что работает на практике:

• Фиксация фактов. Можно завести журнал или таблицу и выписывать туда задачи, оценки и фактическое время. В конце месяца указывать причину расхождения оценки и факта. Это позволит увидеть, что именно хромает: например, недостаток времени на тестирование или системная проблема оптимизма.

• Анализ паттернов. Если регулярно проваливаются похожие задачи, значит, в этой зоне есть слепое пятно, которое нужно проработать.

• Использование коэффициентов коррекции. Если обнаружено расхождение в полтора раза между оценкой и фактом, то первоначальную оценку стоит умножать на этот коэффициент. Лучше неприятно удивить в начале, чем сорвать дедлайн и тушить пожары.

• Важно учиться у команды, перенимать опыт и сравнивать свои оценки с оценками коллег. Если разница значительная, это сигнал: либо у вас больше оптимизма, либо у них больше опыта и наоборот.

• Можно делать маленькие ставки – разбивать задачу на небольшие части и оценивать каждую отдельно. Проще скорректировать часть в процессе, чем сорвать всю задачу.

• Главное – нужно перестать бояться называть большие оценки. Разработчику бывает стыдно сказать, что задача займет пять дней, потому что кажется мелочью. Но когда эти мелочи вскрываются, это перерастает в переработки и пожары. Если честно говорить, что задача займет пять дней из-за необходимости проработки деталей, учета подводных камней и обязательного тестирования перед постановкой на прод, то у вас появится репутация человека, на чьи оценки можно опереться.

Мини-чек-лист для анализа задачи

Что делать, когда задача поступает на вход?

1. Потратить время на анализ. Минимум 5–10% от общего времени, заложенного на задачу, должно быть выделено на анализ.

2. Максимально вникнуть в суть и контекст.

3. Если вы не сталкивались с подобным, нужно обратиться к чужому опыту или базе знаний.

4. Учитывать время не только на разработку. Если требуется серьезное тестирование, его нужно закладывать сразу.

5. Декомпозировать сложную задачу на более мелкие. Это помогает контролировать выполнение и не выйти за сроки.

Методы оценивания задач в IT

Первый – метод «Делфи». Это классический метод оценки. Собирается группа экспертов, которые дают индивидуальные оценки задачи. Затем эксперты обсуждают задачу коллективно и снова дают индивидуальные оценки. Процесс повторяется до достижения общего результата.

Метод хорошо подходит для команд, работающих по Agile, и позволяет максимально задействовать экспертный опыт для выявления технических рисков. Недостаток – значительные затраты времени на подготовку, анализ и обсуждение.

Второй метод – «Светофор». Получив задачу, нужно определить, на каком сигнале вы находитесь.

• Красный – вы никогда не сталкивались с подобной задачей, не понимаете финальный результат и шаги решения.

• Желтый – делали что-то похожее, но не до конца понимаете итог, либо можете найти аналогичное решение, которое станет основой.

• Зеленый – уже сталкивались с подобной задачей и понимаете, как ее решать.

Для каждого цвета применяется свой коэффициент. Первоначальная оценка умножается на коэффициент в зависимости от уровня неопределенности.

Ключевые выводы

При работе с задачами важно помнить:

• Фиксировать факты, чтобы анализировать себя.

• Анализировать паттерны, чтобы выявлять проблемные типы задач и зоны для развития.

• Использовать коэффициенты коррекции для повышения точности оценок.

• Учиться у команды и не бояться озвучивать большие цифры. Для этого можно применять метод трех точек, метод «Делфи» и метод «светофора».

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.