Всем привет!
Сегодня я хочу рассказать о нескольких практиках оценок задач, которые сложились в нашей команде за годы совместной работы. Я надеюсь, что статья будет полезна тем, кто только начинает свой путь в менеджменте, и особенно тем, кто работает по ватерфелу в "кровавом enterprise".
Эффективное планирование зависит от множества разных факторов: от качества оценки, проработки деталей решения, использованной методики планирования, правильной оценки рисков.
Для начала я расскажу о подготовительной части планирования – оценке задачи разработчиками. В нашей команде нам удалось, балансируя между бюрократией и жизненной необходимостью, разработать ряд практик, которые позволяют без лишних промедлений и размышлений превращать оценки в план работ.
Итак, начнем с правил оценки.
Оцениваем задачи по единым правилам
Правила оценки появились у нас после того, как выяснилось, что один из разработчиков в оценке под 1 человеко-днем работы подразумевает 8 часов непрерывной работы без перерывов на планерки, чай/кофе и даже санитарно-гигиенические нужды. Поэтому мы в команде составили очень простое соглашение:
- оценка проводится в человеко-днях (в документах пишем просто «дни»);
- задача на 1 человеко-день решается за 1 рабочий день. 0,5 человеко-дня – это начать утром и завершить к обеду. В этот человеко-день включена планерка, помощь коллегам, чай с печеньками и так далее;
- (для менеджера) в 1 человеко-дне около 6 часов эффективной разработки.
Не обязательно ваши правила должны быть такими же, главное, чтобы вы работали в одной системе координат.
Декомпозируем задачу
Зачастую разработчику гораздо проще сказать: «да там на пару недель работы». А менеджеру добавить в план задачу на 80 часов. Однако из-за такого подхода к планированию потом и возникают вопросы вида: «скажи, сколько процентов работы тебе осталось сделать» и другие способы понять, какой у разработчика прогресс по выполнению задаче.
Мы установили следующие ограничения: любая задача декомпозируется на подзадачи длительностью 0,5-3 дней. Каждая подзадача представляет собой законченную часть функционала.
Опять-таки в вашей команде ограничения могут быть другими. Здесь необходимо соблюдать баланс.
Но по нашему опыту подзадачи более 3 дней:
- вызывают эффект выпрямления сроков;
- демотивируют разработчика долгим отсутствием результата;
- осложняют контроль и снижают скорость реакции на проблемы.
Менее 0,5 дня тоже имеют недостатки:
- чем меньше задачи, тем больше зависимостей между ними;
- чем меньше задачи, тем больше времени и внимания требуется для их отслеживания.
При этом мы сразу нумеруем пункты декомпозиции (подзадачи) – так гораздо удобнее работать с ними в сетевой диаграмме (об этом ниже) и в плане.
Унифицируем подход к декомпозиции
Однажды мы столкнулись с такой ситуацией: оценка трудоемкости разработки другой команды оказалась на 25% меньше, чем наша. Эта ситуация очень заинтересовала руководство – расследование показало, что наши коллеги не включили в оценку проверку разработчиками результатов своей разработки (внутреннее дымовое тестирование).
Чтобы таких ситуаций не было, мы добавили в правила оценки еще пару пунктов:
- модульное тестирование включается в оценку разработки;
- дымовое тестирование мы оцениваем отдельно.
Этот пункт еще раз напоминает, что все члены команды и заинтересованные стороны должны работать в одной системе координат.
Оцениваем зависимости задач
Планирование без учета зависимостей похоже на игру в рулетку. Если все пойдет хорошо, то ваш план вполне может быть успешно реализован. Но если вы столкнетесь с жесткой взаимозависимостью нескольких элементов работ, то план «поедет».
Поэтому для качественного планирования, кроме декомпозиции необходима информация о связях подзадач между собой. Например, вы сначала разрабатываете бэкэнд, а потом фронтэнд. Или сначала делаете заглушки на стороне бэкенда, а потом пилите бэкэнд и фронтэнд параллельно. И в том, и в другом случае между работами есть зависимость. Она окажет влияние на старт работ фронтэнда.
Наиболее простой и понятный способ отображения зависимостей – сетевая диаграмма. Например, такая, где элементами являются подзадачи, а стрелки показывают зависимости между ними.
Учитываем ограничения
Часто в задаче заложены еще какие-то ограничения: например, необходимо применить технологию, которой владеют не все члены команды. В нашей команде все владеют стеком бэкенда, но лишь несколько разработчиков могут разрабатывать фронтэнд. Поэтому в каждом элементе декомпозиции мы указываем, к какой технологии относится тот или иной пункт. Эта информация о делении работ на фронтэнд и бэкенд используется при планировании при построении критической цепи.
Оцениваем риски
Есть анекдот про менеджеров, которые умножают оценки разработчиков на некоторое эмпирическое число. Максим Дорофеев объясняет, почему не надо так делать.
Вместо того, чтобы играть в угадайку, мы оцениваем риски следующим образом: на каждый пункт декомпозиции разработчик пишет, какие есть риски, каковая их вероятность и какое влияние они окажут на трудоемкость. Мы называем этот рисками разработки.
При планировании менеджер решает, как обработать риски. А кроме рисков разработки он оценивает и добавляет на этапе планирования менеджерские риски. Например, основываясь на статистике предыдущих проектов.
На практике
На практике в нашей команде при выполнении оценки разработчик заполняет вот такую простую таблицу:
| Номер подзадачи | Подзадача | Пункт ТЗ | Технология | Оценка, дней | Риски, дней |
|---|---|---|---|---|---|
| 1 | Разработать заглушки | бэкэнд | 1 | ||
| 2 | Реализовать фичу | 1 | бэкэнд | 3 | 1 (возможно придется перенастраивать макет) |
| 3 | Реализовать форму | 2 | фронтенд | 2 |
А также рисует сетевую диаграмму примерно такого вида:
Заключение
На этом оценка со стороны разработчика завершается. И к работе приступает менеджер, в задачу которого входит превратить два данных артефакта в готовый план работ по задаче. Как происходит такое превращение я расскажу в следующей части.
Спасибо за внимание!
