Давно не было теоретических постов, давайте сегодня про ресурсное планирование поговорим, что ли.
Что такое ресурсный план
Ресурсный план проекта или план ресурсного обеспечения проекта – это документ, в котором зафиксировано, какие ресурсы будут использоваться в проекте, и процессы получения и возврата этих ресурсов.
Так как блог про управление проектами в ИТ, под ресурсами, конечно, в первую очередь подразумеваются люди, а во-вторую – оборудование и сопутствующие вещи, количество которых в компании ограничено.
В самом простом случае ресурсный план выглядит так – “на проекте длительностью полгода нужны 2 разработчика-мидла на джаве на полный день, один ручной тестировщик на полставки и адекватный руководитель проекта”. или даже “на этом проекте пару месяцев поработает Петя, а потом еще кого-нибудь возьмем, да и тестировать пока сами будем”. Если в вашей компании все вас при этом понимают, риски осознают и проблемы с получением этих ресурсов нет – ну и отлично, значит, эта та степень детализации, которая вам нужна.
В самом сложном случае ресурсный план представляет собой список всех задач проекта, для каждой из которых обозначены требования к ресурсам (например, на задачу составления ТЗ нужен аналитик с опытом 3+ года в аналогичной должности, знанием строительной отрасли, высшим техническим образованием и свободным английским, объем задачи – 180 часов). Такая степень детализации имеет смысл для крупных проектов типа внедрения SAP, под которые набираются или запрашиваются у партнеров целые команды.
В жизни чаще всего встречается нечто среднее – руководитель проекта просто планирует ресурсы с привязкой к роли (разработчик, аналитик, тестировщик и т.д.) и получает их из пула ресурсов компании. И тут уже не до выбора “с опытом 3+ года именно в стройке”, кого дали – того дали.
Также в зависимости от специфики компании ресурсный план может предполагать привлечение фрилансеров или сторонних подрядчиков.
Еще есть такое понятие, как календарно-ресурсный план или ресурсный план-график – как легко понять из названия, это ресурсный план, наложенный на план-график проекта. Т.е. мы уже не просто говорим, что на проекте у нас будет два разработчика, а что у нас будет два разработчика, занятых на проекте три месяца подряд с 15 августа по 15 ноября.
Важно различать ресурсный план проекта, который отвечает на вопрос “кто будет работать в конкретном проекте”, и ресурсный план отдела/компании/портфеля проектов, который отвечает на вопросы “чем будут заниматься наши сотрудники на в ближайшие полгода” и “есть ли у нас люди, чтобы начать вот эти два проекта”. В посте мы в первую очередь говорим о ресурсном плане конкретного проекта, про ресурсное планирование уровня отдела или портфеля – в следующий раз.
Как составить ресурсный план проекта
Составление ресурсного плана проекта – это обязательный этап при составлении базового плана проекта.
Шаги:
- Составить список задач, ну или хотя бы WBS проекта.
- Определить, какие ресурсы вам нужны для выполнения этих задач и в каком объеме, и требования к этим ресурсам (они могут быть как формальными, с указанием стажа и проч., так и неформальными типа “разработчик посильнее”). В случаях, когда ресурсы жестко ограничены и взять их негде, допустима ситуация, когда п.1 и п.2 меняются местами – задачи в проекте планируются от ресурсов, но это не самая хорошая практика.
- Наложить ресурсы на план-график, чтобы получить конкретную трудоемкость и сроки привлечения. Как уже говорилось выше, в зависимости от потребности оценка может быть как позадачной, так и на уровне этапов проекта.
- Согласовать выделение ресурсов в нужном вам объеме и в нужные периоды времени с ответственным за распределение ресурсов (в большинстве случаев это будут руководители соответствующих направлений).
- В случае, если получить ресурсы в нужном объеме и в нужное время нельзя – долго и нудно балансировать задачи, сроки и ваши требования к ресурсам до достижения консенсуса. Если консенсуса достигнуть не удалось или если изначально предполагалось привлечение сторонних ресурсов – определить их источник (фриланс, подрядчики. овертаймы и проч.).
На выходе у вас и у основных стейкхолдеров должно появиться понимание того, кто будет работать в проекте, когда эти люди должны приступить к своим задачам, и когда они освободятся для других проектов. Степень формализации может быть от заметки в чате в телеграме (но лучше, чтобы это было хотя бы письмо по электронной почте) до полноценного документа на 50 страниц, утвержденного протоколом заседания управляющего комитета.
Мои принципы составления ресурсного плана
Это все была теория, а вот дальше – мои личные набитые шишки в части обеспечения проектов ресурсами.
- Не пытаться высчитать трудоемость вплоть до дня. Учитывая, что проект – это очень динамичная вещь по своей сути, не стоит пытаться спланировать, кто, в какой день и на сколько часов будет привлечен. Все еще сто раз поменяется, и ничего, кроме головной боли, от постоянных перерасчетов ресурсов, вы не получите (я этим страдала в первый год в роли РМа, так что знаю на своем опыте). Сейчас лично мне комфортна оценка в целом на месяц, например, “0,3 FTE на март”. А как там эти 50-60 часов размажутся по месяцу – не столь важно. Если вдруг случается нечастая ситуация, когда на проекте мне на 1-2-3 дня нужен какой-то редкий специалист типа дизайнера – я просто заранее договариваюсь с его руководителем, что приду с этим запросом заранее, и что он найдет время в течение недели-двух, и это дает достаточную гибкость нам обоим.
- Не назначать ресурсы на конкретные задачи вместо этапа проекта. Очень редко получается сделать “как в книжках” – запланировать специалиста по информационной безопасности, например, на аудит архитектурного заключения, получить от него результаты аудита и больше никогда к этому не возвращаться. Даже в случае с самым махровым вотерфолом – с ним будут консультироваться в ходе подготовки заключения, встречаться для презентации результатов, обсуждать его замечания, присылать следующие итерации документа на правку и проч. Поэтому мне комфортнее учитывать ресурсы в формате типа “Специалист по ИБ – 0,1 FTE на этапах планирования и опытной эксплуатации, по 0,2 FTE – на этапах разработки и тестирования, на остальных этапах не нужен”, а не позадачно. Правда, для этого нужен а) определенный кредит доверия б) готовность при необходимости обосновать свою оценку.
- Не забывать учитывать этапы инициации и закрытия проекта. Часто трудоемкость считают и согласуют только на этап реализации, а дальше подготовка проекта затягивается, а ресурсы привлекаются на бесконечные обсуждения (или в конце – на бумажную работу по закрытию договоров или сбору извлеченных уроков). И вроде бы официально у РМа 3 проекта, а по факту – он половину времени тратит на другие 5, которые еще не стартовали или уже закончились.
- Не летать в облаках. Когда я вижу в планах у своих РМов что-то оптимистичное типа вовлечения заказчика на 90% его рабочего времени на ближайшие полгода – остается только обнять и плакать. Даже если РМ каким-то образом протащил это через управляющий комитет – сложно поверить, что так и будет, а излишний оптимизм – зло.
- Ну и, конечно, не планировать 100% загрузку на год вперед, так как люди имеют свойство болеть, уходить в отпуска, учиться и вообще заниматься не проектом единым, а еще и какими-то мелкими административными задачами типа постановки целей или обсуждением достигнутых результатов. Но об этом, я надеюсь, никому лишний раз напоминать не надо.
Пример ресурсного плана проекта
Если поискать в интернете, то можно найти сотню разных вариантов того, как выглядит ресурсный план. Все примеры из Яндекса, так что за качество сорри.
Например, так (с детализацией по задачам и, видимо, на full-time):
Или так (c наложением на календарь, но без учета процента привлечения):
Или даже так (очень крутой план, кстати, я его еще до написания поста в статье на хабре встречала):
Лично я сейчас делаю ресурсные планы только на уровне всего портфеля проектов, а не для отдельных проектов. Но когда делала – мои планы выглядели примерно так:
В зависимости от проекта мог быть указан как абстрактный ресурс, так и ФИО конкретного исполнителя.
Используете ресурсные планы в проектах? Поделитесь лайфхаками!
Добавить комментарий