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

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

О чём нужно помнить, когда делаешь WBS?

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

Общие вопросы

Все ли бизнес-требования согласованы? Если не все, то как производилась оценка тех частей проекта, которые зависят от несогласованных требований?
На каком уровне производилась оценка того или иного модуля? Одно дело, когда в компании уже делали подобные вещи много раз. В таких модулях, обычно, оценка уже максимально детализированная (LLD — low level design). Другое дело, когда оценивался объём работ, который ранее в таком виде не делали. Тогда оценка, скорее всего, высокоуровневая (HLD — high level design), что подразумевает наличие предположений, рисков и неявную работу по детализации, как требований, так и оценок.
Имел ли в виду автор оценки модуля конкретных людей, которые будут делать реализацию этого модуля? Если оценка ведётся в часах и, скажем, архитектор, оценивая работу по модулю, предполагает, что имплементацией будет заниматься конкретный разработчик/команда, хорошо знакомый с такой работой, вы должны понимать, что тут заложен серьёзный риск. Если по каким-то причинам разработчик сменится, то у нового разработчика на ту же работу уйдёт гораздо больше времени.
Заложено ли LOE (level of effort) на разворачивания проектной инфраструктуры (баг-трекер, системный софт, dev- и test среды и т.п.)?
Заложено ли LOE на управление версиями сторонних библиотек и используемого стороннего софта?
Заложено ли LOE на обучение пользователей?
Заложено ли LOE на подготовку и изменение документации? На подготовку Release Notes?
Заложено ли LOE на обучение команды техподдержки?
Заложено ли LOE на тестирование и обеспечение безопасности системы (обфускация, тестирование на соответствие требуемым стандартам безопасности, приведение системы в соответствие с требуемыми стандартами безопасности)?
Заложено ли LOE на сертификацию системы?
Заложено ли LOE на проведение Lessons Learnt (работы над ошибками по итогам проекта)?
Какова вероятность получить на проект команду или хотя бы лидов и сеньёров, которые уже знакомы с системой и которым не нужно тратить много времени на погружение?

Отдельный список по QA-части

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

Есть ли согласованный с заказчиком HWE (Hardware Estimation — оценка и набор требований к продуктивному и тестовым окружениям внутри контура заказчика)? Если есть, то внимательно с ними ознакомиться, проанализировать, насколько HWE соответствует NFR. Если нет, то задаться вопросом, а как вы будете без этого работать?
Есть ли согласованные с заказчиком NFRs (non-functional requirements — нефункциональные требования)? Если есть, то внимательно ознакомиться с этими документами. При необходимости — уточнить. Если согласованных NFR нет, то в ваших интересах в максимально сжатые сроки этот документ разработать и согласовать с заказчиком. Отсутствие NFR или NFR с большими пробелами — это огромные риски для проекта.
Есть ли согласованный процесс разворачивания системы на окружениях заказчика?
Заложено ли LOE на разворачивание системы на dev-, test- и prod-окружениях?
Есть ли оценка SVT (stress volume testing)? Если есть, то что туда входит? Какие именно NFR будут использоваться при тестировании? На чьём окружении будет производится нагрузочное тестирование? Все ли этапы SVT заложены в оценку? В каком формате должны быть оформлены результаты SVT? Как заказчик будет принимать результаты SVT?
Есть ли оценка интеграционного тестирования? С какими системами заказчика будет производится интеграционное тестирование? На каком окружении будет производиться интеграционное тестирование? Как будут тестироваться системы, к которым не будет доступа из тестового окружения? Если на стабах, то есть ли соответствующая оценка?
Как посчитано LOE на UAT (user acceptance test — этап финального тестирования системы пользователями заказчика при активном сопровождении со стороны команды разработки)? Чьё присутствие запланировано в офисе заказчика во время UAT?
Какова вероятность получить на проект QA, которые уже знакомы с системой и которым не нужно тратить много времени на погружение?

Глядя на этот список, у многих может возникнуть вопрос — а зачем на этом этапе работать с HWE, NFR и SVT? Можно, конечно, с этими артефактами и не работать. Но в моей практике были случаи, когда все проектные оценки сделали, распланировали все ресурсы. И вроде даже HWE и NFR были и high-level SVT-план был. Только они не были согласованы между собой. Как можно догадаться, за это пришлось заплатить не одним десятком неоплаченных человеко-часов и кучей нервов.

Какие накладные расходы нужно закладывать в ресурсный план?

Под накладными расходами я понимаю активности, которые вроде бы и не очевидны, но которые способны сильно испортить вам жизнь на проекте. Если, конечно, вы к ним не подготовитесь.

Шаринг бойцов с другими проектами

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

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

Шаринг и работа с техподдержкой

Если ваш проект — долгоиграющая история и предыдущие версии уже находятся на проде, то есть большой пласт вопросов, в которых нужно ориентироваться для качественного ресурсного планирования.

Есть ли у вашей техподдержки свои разработчики? Если есть, то как они получают знания о новых фичах, которые вы выкатываете на прод? Как это отражено в WBS? Если нет, то какие члены вашей команды (SA, BA, Dev, QA) и как часто будут отвлекаться на решение вопросов техподдержки? Даже если в составе техподдержки есть свои разработчики, периодическое отвлечение членов команды разработки на техподдержку неизбежно.
Заложено ли LOE на knowledge transfer сотрудникам техподдержки?
Заложено ли LOE на гарантийное сопровождение системы? Кто и как будет осуществлять гарантийное сопровождение?

Совещания и коллы

Другим видом накладных расходов является участие членов команды в совещаниях. В совещаниях. Типичная картина — на сеньёрного разработчика запланировано по 40 часов разработки в неделю, а по факту он регулярно тратит по несколько часов в день на коллы и очные совещания с командой и заказчиком. И вместо 40 часов у него на работу остаётся 30. В результате разработчик или не успевает или овертаймит или выдаёт код не самого лучшего качества.

Ещё более острая проблема, обычно, складывется у бизнес-аналитиков. С одной стороны, они, по роду своей деятельности, должны тесно работать с заказчиком. С другой стороны, бесконечные совещания у заказчика зачастую пожирают более половины общего времени BA и он не успевает детализировать требования к следующим спринтам, начинает овертаймить и/или выдавать требования не лучшего качества.

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

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

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

Сразу решить, как управлять изменениями

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

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

Если у вас большой проект, вы сразу согласовали с заказчиком объём возможных изменений и у вас есть CR Bucket (объём LOE, оплаченное заказчиком, которое будет потрачено на изменения) — отлично. Тогда у вас есть почти точная цифра часов, которые вы должны заранее зарезервировать под пока неизвестные задачи. В зависимости от размера этого LOE и предполагаемого потока изменений, полезно заранее решить. В любом случае, нужно ответить себе на следующие вопросы:

Известен ли объём предполагаемых изменений? Если нет согласованного CR Bucket, то нужно попробовать сделать свою оценку на базе проектных рисков и вашего видения ситуации.
Сможете вы лично управлять изменениями или у вас это будет делать специально обученный человек (Change Manager)?
Выделяете ли вы отдельную команду для работы с изменениями или эта нагрузка будет распределяться по всем членам команды. Хорошей практикой является выделение хотя бы отдельного бизнес-аналитика на работу с изменениями.
Будете вы делать отдельный ресурсный план на работу с изменениями или всё будет в едином ресурсном плане?

Подумать про методику учёта и сбор фактического времени

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

Факт не равен факту

Что такое факт в терминах ресурсного планирования? Это часы, которые члены команды действительно потратили за прошедший период на:

работу на вашем проекте
выполнение конкретных, ранее запланированных задач на проекте

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

Приступая к этому вопросу нужно осознавать разницу между часами для ресурсного планирования и LOE, выделенным на выполнение задачи. Например, разработчик в течение дня закрыл два бага, на каждый из которых он потратил 3 часа. В сумме он отработал по задачам 6 часов. В Jira списано 6 часов. Но заработную плату он получит за 8 часов и на проекте он отработал 8 часов за этот день. И это нормально — часы нахождения на проекте никогда не будут равны эффорту, потраченному на решение проектных задач.

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

Как собирать факт в ресурсный план?

Вариант номер 1. Целиком полагаемся на таск-трекер (например, Jira)

Преимущества:

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

Недостатки:

большой риск получения либо завышенных часов (большинство традиционно подгонит потраченное на задачи время под 8 часов в день — никто не любит списывать время на задачи типа “doing nothing”), либо излишне детализированную классификацию задач, с которой потом сложно будет работать.

Вариант номер 2. Используем систему таймшитов

Преимущества:

однозначное разделение потраченных на проект часов (в таймшитах) и проектного LOE (в таск-трекере)
все преимущества варианта 1

Недостатки:

какая-то часть людей всегда будет недовольна двойным вводом часов — им всегда будет казаться, что вся необходимая информация уже есть в таск-трекере и они делают ненужную работу;
необходимость как-то согласовывать классификацию задач в таск-трекере и системе таймшитов

Вариант номер 3. Две крайности

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

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

У полностью автоматизированных систем ресурсного планирования и управления проектами преимущества и недостатки прямо противоположны ручному варианту — работая в таких системах руководитель проекта может легко потерять “связь с землёй”, полагаясь на цифры из своей системы. С другой стороны, такой процесс гораздо менее трудоёмкий и применим на проектах разного размера.

Как учитывать овертаймы?

Если у вас в компании практикуется оплата овертаймов по повышенной ставке, то нужно заранее определиться по двум важным моментам:

будете ли вы оплачивать овертаймы в будни?
допустимо ли в будни списывать больше 8 часов?

Правильных ответов тут нет, каждый подход имеет свои плюсы и минусы. Как показывает моя практика, наименее проблемный набор тут такой:

в будни овертаймы оплачиваются только для работ по техподдержке и реанимации прода;
больше 8 часов в будни списывать нельзя.

В любом случае, у вас должен быть готов ответ на эти вопросы.

В следующей части мы наконец-то начнём создавать ресурсный план.