Всем привет!

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

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

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

Итак, начнем с правил оценки.

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

Правила оценки появились у нас после того, как выяснилось, что один из разработчиков в оценке под 1 человеко-днем работы подразумевает 8 часов непрерывной работы без перерывов на планерки, чай/кофе и даже санитарно-гигиенические нужды. Поэтому мы в команде составили очень простое соглашение:

• оценка проводится в человеко-днях (в документах пишем просто «дни»);
• задача на 1 человеко-день решается за 1 рабочий день. 0,5 человеко-дня – это начать утром и завершить к обеду. В этот человеко-день включена планерка, помощь коллегам, чай с печеньками и так далее;
• (для менеджера) в 1 человеко-дне около 6 часов эффективной разработки.

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

Декомпозируем задачу

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

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

Опять-таки в вашей команде ограничения могут быть другими. Здесь необходимо соблюдать баланс.

Но по нашему опыту подзадачи более 3 дней:

• вызывают эффект выпрямления сроков ^[1];
• демотивируют разработчика долгим отсутствием результата;
• осложняют контроль и снижают скорость реакции на проблемы.

Менее 0,5 дня тоже имеют недостатки:

• чем меньше задачи, тем больше зависимостей между ними;
• чем меньше задачи, тем больше времени и внимания требуется для их отслеживания.

При этом мы сразу нумеруем пункты декомпозиции (подзадачи) – так гораздо удобнее работать с ними в сетевой диаграмме (об этом ниже) и в плане.

Унифицируем подход к декомпозиции

Однажды мы столкнулись с такой ситуацией: оценка трудоемкости разработки другой команды оказалась на 25% меньше, чем наша. Эта ситуация очень заинтересовала руководство – расследование показало, что наши коллеги не включили в оценку проверку разработчиками результатов своей разработки (внутреннее дымовое тестирование).

Чтобы таких ситуаций не было, мы добавили в правила оценки еще пару пунктов:

• модульное тестирование включается в оценку разработки;
• дымовое тестирование мы оцениваем отдельно.

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

Оцениваем зависимости задач

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

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

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

Учитываем ограничения

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

Оцениваем риски

Есть анекдот про менеджеров, которые умножают оценки разработчиков на некоторое эмпирическое число. Максим Дорофеев объясняет ^[2], почему не надо так делать.

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

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

На практике

На практике в нашей команде при выполнении оценки разработчик заполняет вот такую простую таблицу:

Номер подзадачи	Подзадача	Пункт ТЗ	Технология	Оценка, дней	Риски, дней
1	Разработать заглушки		бэкэнд	1
2	Реализовать фичу	1	бэкэнд	3	1 (возможно придется перенастраивать макет)
3	Реализовать форму	2	фронтенд	2

А также рисует сетевую диаграмму примерно такого вида:

Заключение

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

Спасибо за внимание!

Автор: Kluge

Источник ^[3]