Блог

Дмитрий Денисов
Заместитель директора по информационным технологиям

Оценка задач: трудности, польза

Творческий труд не поддается планированию. Именно так мы любили объяснять заказчику невозможность назвать сроки завершения задачи. Или когда сроки все-таки были названы, но прошли уже дважды, а результата так и не было.

Мы научились опровергать это утверждение по крайней мере в двух случаях из трех :)

Во-первых, вопрос: зачем вообще оценивать трудозатраты по задачам разработки?

Заказчик любит знать, когда получит желаемое, ведь у него на эту дату завязаны маркетинговые акции, набор персонала и т. д. Либо срок может быть задан контрактом, заказчику нужно понимать, успеваем или не успеваем. И если не успеваем, то что нужно, чтобы все-таки успеть.
Еще оценки по задаче нужны для того, чтобы спланировать загрузку команды, когда она делает несколько (или много) задач сразу. При этом добиться того, чтобы разработчики были загружены достаточно равномерно, без простоев и больших переработок. Например, в команде справочных систем мы на каждый спринт планируем загрузку 1200–1500 человеко-часов.

Как добиться достоверных оценок?

Самое первое – это декомпозиция. Бывает, что оценка по задаче измеряется несколькими десятками часов. При этом задача не расписана на операции, каждая из которых имеет длительность хотя бы 6–8 часов. Значит, скорее всего, разработчик пока не очень понимает, как он будет решать эту задачу. Разбираться будет по ходу пьесы и, скорее всего, промахнется мимо своей оценки. Хотя, конечно же, в ситуации, когда оценку нужно дать очень быстро, плохая оценка лучше, чем ее отсутствие. И здесь нам поможет...

Второе — опыт оценки. Чтобы овладеть каким-либо навыком, нужно его тренировать. Чтобы повысить точность оценок, необходимо, во-первых, делать их систематически. А во-вторых (и это не менее важно), учитывать фактические затраты по задачам, сверять их с оценкой и анализировать большие расхождения. Как показывает жизнь, даже если разработчик никогда раньше не пытался оценивать свои задачи, за 2–3 месяца систематической практики точность оценок возрастает драматически.

Что такое достоверная оценка?

Если вы достигли точности оценки плюс-минус 15–20% – это уже очень хорошо. И следующие попытки повышения этой точности с большой вероятностью не принесут практической пользы.

В случае больших команд (и большого объема одновременных задач) приемлемой оказывается и более низкая точность. Одни разработчики склонны завышать оценки, другие – занижать. По одним задачам промахнулись в одну сторону, по другим – в обратную. По нашей практике, ошибки оценок чаще всего компенсируют друг друга, и в целом по спринту мы получаем те самые 10–20% отклонения от начальной оценки.

Что делать, если дельта все равно слишком велика?

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

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

Скорее всего, окажется, что разработчик просто не учитывал какие-то работы. Например, не закладывал время на правку багов. Или на взаимодействие с коллегами по команде. Все это достаточно легко отловить в результате анализа и выработать эмпирические правила. Например, если в задаче нужно взаимодействовать со смежником, на это закладываем +20% к оценке. Если задача требует разбирательства с новым API, то закладываем еще N часов. А если API при этом не задокументирован, то закладываем 2*N.

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

Представить себя посреди ночи на рабочем месте. До дедлайна 6 часов, а работы еще столько, будто не начинали :)