Предсказуемость сроков выполнения играет важную роль в разработке IT-проектов. И в связи с высокой сложностью процессов оценка задач является непростой проблемой, у которой нет явного алгоритма или простого плана. Усугубляется это тем, что в процессе общения об оценках бизнес, управление проектами и разработка могут говорить на разных языках, не понимать и не хотеть понимать проблемы и ценности друг друга. В результате получаются «отписки», на которые тратятся усилия, а необходимого эффекта они не приносят. 

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

Видеоверсия выступления доступна по ссылке.

Ну а теперь к делу.

Зачем давать оценки

В жизни каждого разработчика наступает тот неприятный момент, когда к нам приходят «они» и требуют: «когда будет готово?». «Они» — это менеджеры, продакты, тимлиды, начальники… Вопрос, а зачем это «им»? Что «они» будут с этим делать? Если мы это поймём, то сможем давать им ровно то, что им нужно, и экономить свое время.  Вариантов несколько, и вот основные из них.

• Менеджеру нужно оценить скоуп работ (поставка, релиз, спринт): календарный график и общий их объем. В этом случае важно попасть в суммарную оценку, попадание в каждую конкретную задачу неважно (где-то потратили больше, где-то меньше — в целом сошлось). В дальнейшем от этого планируется работа других подразделений, а также от этого зависят показатели, которыми управляет бизнес. А бизнесу нужна предсказуемость: для уменьшения рисков и повышения управляемости.
• Выстраивание приоритетов в уже существующем скоупе. В этом случае важны оценки каждой задачи, потому что от них может зависеть последовательность работ. Далее менеджер может выстроить последовательность по методике ценность/сложность. Например, в самом простом случае, можно оценить задачи по трёхбалльной шкале (высокая, средняя, низкая) по ценности для бизнеса и сложности для выполнения. И затем выстроить приоритеты так: сначала делаются очень ценные и очень быстрые, потом очень ценные и средне-быстрые и так далее. Малоценные и очень сложные задачи формируют вечный бэклог, откуда выбираются очень долго. Или никогда.
• Оценка проекта (или большого подпроекта целиком). Этот случай характеризуется многими неизвестностями, поэтому оценка нужна примерная. Не стоит пытаться раскладывать на мелкие подзадачи с деталями, потому что данных об этом все равно нет: никто на этом этапе не знает, что точно нужно сделать. Далее на основании этих оценок принимается решение, какие задачи оставить/убрать, какие отложить, какие действия предпринимать прямо сейчас (запуск сложных рискованных процессов), чтобы уложиться. Здесь же идёт планирование затрат (время, ресурсы, определение размеров команды), построение примерных диаграмм Ганта и прочая подобная деятельность.

Хорошо, зачем это «им» разобрали. А нужно ли это «нам»? Представьте себе, что ваш менеджер ушёл в отпуск. Навсегда. И вот вы сидите, спокойно работаете, день, два, неделю. Никто оценок не требует, жизнь удалась. Будете ли давать оценки самому себе?

Давать их или нет — дело личное, но вот аргументы за.

• Оценка показывает способ выполнения задачи. Человеческий мозг — штука затратная, и думать человек не любит — это сложно. Поэтому естественное стремление думать как можно меньше. А как это сделать? Можно разделить деятельность на более узкую. Делим планирование и исполнение: сначала думаем о способе (при оценке), потом переключаемся на исполнение и думаем об исполнении (в процессе работы). 
• Создаем себе рамки, «скелет» плана. Если заметили, что вываливаемся из плана — это повод прекратить исполнение и сесть подумать. Таким образом мы можем себя контролировать, соответствует ли наше ожидание (оценка) реальности (попаданию в оценки) или реальность другая, и первоначальный план не подходит. Помогает принимать решения, если в процессе что-то пошло не так. 
• Если у нас нет оценок — мы не можем планировать свою работу. Без оценок единственное на что мы можем ответить — в каком порядке будем делать задачи. Непонятно, когда можно расслабиться, а когда наоборот этого делать нельзя. Проиллюстрируем примером. У вас есть несколько источников задач, все разной степени срочности и сложности. Приходит к вам очередной коллега и просит сделать небольшую вещь через 2 недели. Ну 2 недели срок приемлемый, вещь небольшая -  вроде норм, согласен. Оценок не даем. И со временем обнаруживаем, что целыми днями заняты, выбиваемся из сил — и все равно ничего не успеваем. Задачи вытесняют друг друга, перестают доходить до конца, новые все пребывают — и вы попадаете в замкнутый круг. Начинаются отрицательные эмоции (обвинение других/себя), это мешает работать и очень ест силы. И уже коллега, который пришел с очередной небольшой задачкой, получает ответ: «Я занят, у меня куча дел!!». Удовлетворение от работы на нуле, сил нет, результата нет. Почему так произошло? Потому что не планировали свою загрузку. Не смогли сказать очередной задаче «нет», потому что сами не знали, что не сможем ее выполнить. Не смогли понять, что сейчас есть возможность снизить темп и отдохнуть, потому что задачи идут одна за одной — и без каких-либо границ.
• Психологический эффект. Если задача сложная, меняется в процессе разработки или меняются наши знания о ней. Если мы не давали исходную оценку, задача в процессе обросла новыми подробностями, и в результате мы не попали — мы не помним, почему. Через несколько таких итераций в голову стучится эффект самозванца. А если бы дали изначальную оценку, то причина зафиксирована: считали, что надо 5 попугаев, а оказалось 10. Почему так оказалось — вопрос второй, его-то как раз хорошо помнят. А причину — не всегда («Разработчики вечно ничего не успевают»/«Эти продакты вечно ничего не могут продумать, а потом всплывает»).

Итак, определились: оценки нужны и «нам», и «им». Есть смысл продолжать читать статью дальше.

Цель оценки

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

Итак, оценка — это не попытка угадать, сколько займет задача. Оценка — это договоренность между заказчиком и исполнителем о рамках и (возможно) способе выполнения задачи.

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

Процесс оценки

Основа процесса оценки — увидеть стоимость бизнес-задачи, а также основные риски задачи и объем рутины. И затем оценить их, заключив в рамки: точно неизвестно, какое оно, но оно точно больше X и меньше Y. И конечно, оцениваем с той точностью, с которой нужно (потому что точная оценка дорогая, а мозг ленивый). 

Состав задачи:

• Реальная бизнес-ценность (зачем задача нужна бизнесу). Минимально допустимый функционал, без которого задача имеет нулевую ценность для бизнеса. Нечто похожее на smoke-test в тестировании. Если мы этого не будем учитывать, можем наткнуться на ситуацию, когда выкатываем задачу, а нам бизнес говорит «она не работает». Как не работает, я же проверял все! Идем дрожащими руками на прод — и все на месте. Показываем бизнесу, а он говорит: «Здесь не хватает такой-то штуки, а без нее мне это не нужно».
• Необходимые дополнительные задачи, которые напрямую в бизнес-ценность не входят, но без них задача не будет работать. «Нагрузка» к бизнес-ценности. Требования юридические, требования интеграций, требования технологические (исполнение архитектуры, покрытие тестами, требования безопасности, требования отказоустойчивости, требования по скорости), согласованность с остальным продуктом — если без них задача не будет принята или не заведется. 
• Риски. Мы чего-то не знаем, не умеем, что-то зависит не от нас. В них оценка может быть в очень широких пределах или мы не знаем, какая она (и сможем уточнить только в процессе). В этом случае разумно попытаться максимально снизить риск на этапе планирования: аналитика разного рода, копание в коде, консультации у экспертов, согласование вопросов с внешними системами (говорим, что нам критично это знать или вот так сделать. Есть и еще один типовой подход — просто переложить ответственность на кого-то другого. Типовые риски: интеграция с внешними системами (особенно неизвестными или под большой нагрузкой, а также если понятно, что система не будет меняться под нас: править баги или консультировать по тому, как работает система, а также, если они только разрабатываются, и есть только документация), зависимость от других подразделений, не заинтересованных напрямую в задаче, новые технологии, новая система (первый день на работе) или часть системы, известная техническая сложность в системе, zero-tolerance к качеству или очень жесткие и неизменяемые требования к задаче, взаимодействие со сложными коллегами, размытые, непонятные или противоречивые бизнес-требования, которые нельзя уточнить. Чтобы упорядочить риски, их оценку можно производить по вероятности (высокий/средний/низкий), по степени влияния (высокая/средняя/низкая). 
• Все остальное.

Порядок выполнения оценки эпика

Схема рождается из того, что любую задачу можно сделать за любое количество времени. Утверждение утрировано, конечно, но в целом отражает суть. Например, ко мне приходит заказчик и говорит: «Я хочу facebook. Когда будет готово?» Минимальное время решения такой задачи, которое мне удалось придумать, — 15 минут. Захожу на facebook, делаю скриншот, верстаю страницу с картинкой скриншота, кладу на свой сервер. Условиям задачи удовлетворяет. Можно даже улучшить реализацию: возьмём не картинку, а сделаем iframe с facebook (правда, как я и предполагал, в facebook уже позаботились об этом). Так как временнАя оценка определяет способ выполнения задачи, можно сократить время на выполнение любой задачи в 2-3 раза (бывает, что и в 5 раз). Забавно, что этот эмпирический закон постоянно получается проверять на практике.

1. Декомпозируем задачу на подзадачи. Получается примерно такая картина (у нас её называют «ёлка»): по горизонтали оценки задач по времени, по вертикали — приоритет.
   
2. Сортируем подзадачи по приоритетам (сначала бизнес-ценность + «нагрузка», потом рискованные, потом в порядке важности остальные).
   
   
3. Если оценку надо сокращать, обрезаем задачу снизу. Почему можем сокращать: какой-то из рисков сработал и распух или бизнес-ценность оказалась не совсем такой, как предполагали — это важные вещи, и без них задачу не сдать. Надо исправлять. Тогда мы сможем попасть в оценку, сделав основные части задачи (в зависимости от непопадания будет сделана бОльшая или меньшая часть задачи).
   
   

Процесс оценки конкретной задачи

Хорошо, эпик декомпозировали. А как оценивать размер конкретной задачи?

• Если мы уже делали ровно такую задачу. У нас где-то есть статистика, сколько времени ушло на аналогичную задачу.  Если делали не мы, а коллега — то можем взять его результат и домножить на коэффициент разницы между им тогда и нами сейчас (уровень разработчика, знание системы, знание рисков). Лезем в статистику, домножаем — получаем. 
• Если мы делали примерно такую задачу. Аналогично предыдущему способу, только нужно накинуть примерную разницу между задачами. Например, эта задача совпадает на 60%. Значит, 60% задачи уже мы оценили, оцениваем остаток. Или примерно понимаем, что прошлая задача в полтора раза легче — значит, и оценка будет в 1.5-2 раза больше.
• Если не делали таких задач. Тогда применяем R&D. Если задача мелкая — можно делать исследование сразу, перед оценкой. Если большая — лучше запросить время и делать отдельно. Берем определенное время на аналитику (1, 2, 4 часа), цель которого — дать оценку исходной задаче. Исследуем информацию, разговариваем с экспертами, собираем прототипы на коленке. Если совсем непонятно, сколько времени нужно взять на R&D, то можно взять 1-2 часа на то, чтобы составить план на R&D и его оценить. Тогда цель этого этапа будет — дать оценку R&D. Если надо встретиться и обговорить что-то — время встречи, например, час. Если написать прототип — то N строчек — примерно столько-то (в зависимости от сложности). Если прикинули, взяли и не хватило времени — хотя бы можно сравнить, что мы успели и что хотели. И, разделив одно на другое, получить коэффициент — на него умножить исходное время.

Полезные техники при оценке:

• Обычно разработчики склонны переоценивать проблемы, с которыми они уже сталкивались (и которые есть в задаче) и недооценивать те, которые они видят, но не сталкивались. Это психологическая особенность человека, и о её наличии просто нужно знать, чтобы корректировать себя.
• Planning poker. Оцениваем вместе, используем опыт коллег. Цели две: во-первых, фиксируем внутри команды один способ выполнения задачи и, соответственно, одну оценку, а во-вторых, смотрим на задачу вместе, подстраховывая друг друга,
• Риски можно классифицировать по таблице (вероятность/степень воздействия), оценить коэффициентами и получить в числах. А затем домножить оценки на эти коэффициенты. Например, этот риск средней степени вероятности и разрушительного воздействия. Поэтому берем докидываем в задачу, например, еще 70% на него.
• Оценка ожидаемого времени задачи из PERT. Удобно использовать, если границы вилки (минимум-максимум) по задаче различаются в 5 и более раз. В этом случае простое среднее может быть далеко от реальности.
  

  Задача	Оценка min	Оценка real	Оценка max	Оценка итог
  <Формулировка>	2	8	20	9

  
  Здесь минимум — минимальное возможная длительность выполнения задачи в предположении, что всё происходит наилучшим или наиболее удачным образом, максимум — максимально возможная длительность выполнения задачи в предположении, что всё происходит наихудшим или наименее удачным образом (исключая крупные катастрофы), реализм — длительность выполнения задачи в предположении, что всё происходит так, как бывает чаще всего (как обычно).
  Тогда итог считается как:
  

Коэффициенты 4 и 6 взяты, как я понимаю, из предположения, что в общем случае вероятность риска распределена нормально, и хвосты (min/max) равновероятны.

Процесс попадания в оценки

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

Полезные техники при попадании:

• Декомпозиция на подзадачи не более 6ч. Смысл этого действия: каждый день должна закрываться одна задача. Если не закрылась — это сигнализирует о том, что что-то не так, и разработчик застрял. Надо обратить внимание или менеджеру/лиду, или самому разработчику. Также подобная декомпозиция сужает область деятельности (в рамках такой задачи сложнее «расползтись» или заняться чем-то другим). Например, делали задачу, увидели старый костыль или что-то в результате реализации стало слишком неоптимальным или запутанным. Поставили отдельную задачу и забыли — сейчас цель заниматься основной задачей. Также есть и психологический эффект в виде положительного подкрепления. Зачем сегодня на работу ходил? Сделал задачу N.
• Выстраиваем «ёлку».
• Прикидываем, сколько времени на минимум (бизнес-ценность + риски) — минимальное время, которое нам надо на задачу. В моём опыте это обычно составляет около 30%.
• Делаем.
• В процессе отслеживаем план, зачеркиваем (либо другим способом помечаем) выполненные задачи. Как только с начала задачи прошло минимальное время (которое определили два пункта назад) — проверяем, отклонились ли от плана. Если да — повод подумать, ну или сразу бить в набат. Если оценка превышена — скорее всего, она будет превышена и в оставшихся задачах. И пока еще есть время перепланировать работу.
• Приступаем к остальным задачам (не из минимума). И на середине работы общее время внезапно заканчивается. Конечно, у нас есть возможности превысить оценку, попросить еще времени, попросить добавить разработчиков и прочее. Это рабочие способы, но сейчас вопрос в том, какие у нас есть возможности уложиться в исходную. Бессмысленно пытаться «программировать быстрее» — это даст ускорение всего на 20-30%, максимум на 50. Недостающее время отпиливаем от нижней части. Автоматически получаем (и можем эскалировать наверх) прогноз, что, скорее всего, эти задачи не будут сделаны без превышения исходной оценки.

Бонус

И на закуску, есть связанный с оценками задач эффект выпрямления сроков. Подробнее он описан, например, здесь, а потому не буду повторяться. В применении к оценкам он имеет следствие, что нужно оценивать задачи и следить за попаданием, если нам важно завершить к какому-то времени. Даже если задача мелкая, а времени до ее сдачи много (как у ранее упомянутого разработчика, заваленного работой, который не любил давать оценок). А если мы не представляем точно, какой есть запас (и руководствуемся, что он большой, и «государство не обеднеет») — получается неконтролируемое превышение сроков. И уже неважно, какой буфер заложили: 2x, 5x, 100x — если им не управлять, он все равно весь будет съеден.

Заключение

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