Про оценку трудоёмкости и что с ней можно сделать

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

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

И в конце сделаем выводы.

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

В контексте этой статьи термины «задача» и «проект» стоит понимать одинаково. А «инженер» — это исполнитель задачи (разработчик, дизайнер, инженер инфраструктуры).

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

При этом люди оценивают трудоёмкость чаще всего позитивно и недооценивают риски. Поэтому более приближены к реальности несимметричные диапазоны:

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

Оценка — это вероятная характеристика. Она подчиняется нормальному закону распределения. Например, из википедии:

Вероятность попадания в диапазон среднего отклонения (+/- σ‎) составляет 68%. Вероятность 95% уже относится к диапазону +/- 2σ. Чем шире диапазон, тем выше вероятность в него уложиться, и наоборот. Вопрос только в величине отклонения, который зависит от разброса пессимистичной и оптимистичной оценок. Другими словами отклонение отражает риски и неопределённость задачи.

Диапазон оценки можно рассчитать, используя метод оценки по трём точкам и бета-распределение (формулы, если интересно). Например, имеем следующую оценку задачи от эксперта:

Тогда с вероятностью 0.9 (90%) удастся уложиться в диапазон 93-112 часов. Это достаточно вероятно, но не на 100%.

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

Иногда на вдумчивую экспертную оценку нет времени или давать её пока не нужно. Например, при проверке гипотез и оценке бюджета на разработку продукта в порядках: миллионы или десятки. В таком случае можно давать быстрые оценки по аналогии. Они основаны на опыте конкретных людей, которые делали подобные проекты и могут переложить этот опыт на текущую задачу. Такая оценка всегда грубая. Быструю оценку по аналогии может дать даже опытный руководитель проекта, и она также будет достоверной в границах грубой оценки.

«Плюс-минус» в оценке откладывается от наиболее реалистичной оценки. Диапазон зависит от начальной неопределённости требований и способа решения задачи. Думая о ширине диапазона, нужно поработать с рисками: выявить основные и решить, что с ними делать.

Оценка — это предположение. Даже самые точные оценки — это вероятностная характеристика задачи. Если нужно зафиксировать затраты до начала работы по модели fixed price, мы можем заложить в бюджет резервы на риски и зафиксировать именно стоимость работ, а не сделать оценку трудоёмкости с точностью 100%.

Комбинировать эти варианты не стоит. Странно будет выглядеть оценка в виде 80-100 часов с точностью -10+25%. На самом деле это либо 70-125 часов, либо 98 часов при условии, что оценка средней точности (+/-30%).

Мы используем следующий подход. Для расчёта быстрых и грубых оценок эффективнее использовать несимметричный метод и преподносить оценку диапазоном, например 70-125 часов. Если есть возможность дать осмысленную экспертную оценку, то добавлять можно уже привычный диапазон, например +/-20%. Заказчики — не методологи, им непривычно смотреть на -10+30%.

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

Способов несколько:

Точная оценка — это долго и ресурсозатратно. Она требует времени на уточнение и анализ требований командой разработки. Поэтому нужно понимать, кому и с какой целью нужна точная оценка.

При этом оценка сама по себе слабо влияет на реальную трудоемкость. Решение задачи всё равно потребует столько времени, сколько нужно при фиксированном уровне качества.

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

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

Выше в блоке про матчасть я уже упомянул оценку по трём точка (или PERT). Но в любом случае разные люди могут давать разные оценки, и это нормально. Это зависит от их опыта и ключевых навыков.

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

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

А также детальнее поработать с рисками.

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

Уточнение требований — самый трудоёмкий способ повышения точности оценки. Нужно понимать, зачем это нужно делать.

Далее разберём типовые ситуации, с которыми мы сталкиваемся при обсуждении оценок.

И чаще всего это просьба идёт за руку с невозможностью по той или иной причине уточнять требования. Ведь для этого нужно запускать отдельный этап аналитики и проектирования, выделять ресурсы, то есть уже начинать работать. Главные вопросы, на которые нужно сначала ответить, — кому и зачем нужна точная оценка?

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

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

Другими словами нужно не уточнять и фиксировать все требования в деталях, а наоборот дать инженерам больше свободы. Можно позволить им сконцентрироваться на получении результата, удовлетворяющего цели, а не требовать детальной реализации по ТЗ и макету. Во главе угла будет продукт для пользователя, а не «более весёлый и праздничный дизайн» и «игра шрифтами».

Это уже не уточнение оценки, а управление проектом в условиях понятных ограничений и приоритетов. Но ведь и оценка — это не самоцель, а инструмент проектного управления.

Это иллюзия. Оценка сама по себе слабо влияет на реальную трудоёмкость.

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

Можно, конечно, «рисовать» красивые цифры для заказчика и дальше работать с его ожиданиями, что в эту оценку мы можем не уложиться. Но реальная точность оценки тут вообще ни причём.

Могут быть разные мотивации у этой просьбы, но все они сводятся либо к стоимости решения задачи, либо к сроку. Оценка трудоёмкости в часах сама по себе мало кого беспокоит.

Ниже несколько типовых ситуаций.

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

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

Кстати, про наше отношение к качеству здесь писал технический директор SmartHead Рамиль Аминов. Рекомендую.

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

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

Если в задаче не было ограничений по способу решения и применяемым технологиям, можно поискать менее трудоёмкий вариант. Банальный пример: использовать частично готовые решения вместо разработки своих с нуля. Можно оставить в задаче только основные бизнес-требования, а деталями решения управлять по ходу реализации проекта. Нужно говорить о приоритетах и том, чем исполнитель задачи может управлять, чтобы снизить трудоёмкость достижения цели.

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

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

Для снижения стоимости (потому что именно стоимость хочет снизить заказчик, а не трудоёмкость) подрядчик должен чем-то управлять: деталями требований или способом решения задачи, составом команды, сроком. Нужно договариваться, что из проектного треугольника для заказчика в приоритете. Одно ограничение обычно фиксируют, второе оптимизируют, а третье получается само собой.

В общем, если дорого, можно решить задачу (здесь правильнее сказать «достигнуть цель») или другим способом, или просто дольше. Но в итоге это снова управление проектом в условиях известных ограничений и приоритетов, а не корректировка оценки трудоёмкости.

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

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

Чаще всего они банально заняты. Также привлечение опытного инженера стоит дороже.

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

И в конечном счёте мы снова говорим именно о сроке или стоимости, а не о снижении трудоёмкости в часах и исполнителе задачи.

Оценка трудоёмкости — это вероятностная величина. Относиться к ней нужно как к инструменту проектного управления, в частности, для планирования сроков и стоимости.

Оценка должна отражать текущую задачу и её ограничения. Если не меняются ограничения задачи, её постановка и исполнитель, оценка трудоёмкости также не изменится. Если меняется одно ограничение, это влечёт изменение других.

Сколько задачу не оценивай, это не приближает к получению результата и не меняет фактическую трудоёмкость оцениваемой задачи.

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

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

Спасибо, что дочитали до конца. Буду рад обратной связи в комментариях и вашим мнением, как вы работаете с оценками трудоёмкости и выходите из озвученных здесь ситуаций.