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