Поэтому мне комфортнее учитывать ресурсы в формате типа “Специалист по ИБ – 0,1 FTE на этапах планирования и опытной эксплуатации, по 0,2 FTE – на этапах разработки и тестирования, на остальных этапах не нужен”, а не позадачно. Правда, для этого нужен а) определенный кредит доверия б) готовность при необходимости обосновать свою оценку. В самом простом случае ресурсный план выглядит так – “на проекте длительностью полгода нужны 2 разработчика-мидла на джаве на полный день, один ручной тестировщик на полставки и адекватный руководитель проекта”. Или даже “на этом проекте пару месяцев поработает Петя, а потом еще кого-нибудь возьмем, да и тестировать пока сами будем”. Если в вашей компании все вас при этом понимают, риски осознают и проблемы с получением этих ресурсов нет – ну и отлично, значит, эта та степень детализации, которая вам нужна.
Часто трудоемкость считают и согласуют только на этап реализации, а дальше подготовка проекта затягивается, а ресурсы привлекаются на бесконечные обсуждения (или в конце – на бумажную работу по закрытию договоров или сбору извлеченных уроков). И вроде бы официально у РМа 3 проекта, а по факту – он половину времени тратит на другие 5, которые еще не стартовали или уже закончились. Это все была теория, а вот дальше – мои личные набитые шишки в части обеспечения проектов ресурсами. Согласовать выделение ресурсов в нужном вам объеме и в нужные периоды времени с ответственным за распределение ресурсов (в большинстве случаев это будут руководители соответствующих направлений). Составить список задач, ну или хотя бы WBS проекта.
Что такое ресурсный план
Как уже говорилось выше, в зависимости от потребности оценка может быть как позадачной, так и на уровне этапов проекта. Также в зависимости от специфики компании ресурсный план может предполагать привлечение фрилансеров или сторонних подрядчиков. Если поискать в интернете, то можно найти сотню разных вариантов того, как выглядит ресурсный план. Все примеры из Яндекса, так что за качество сорри. Но об этом, я надеюсь, никому лишний раз напоминать не надо. Не летать в облаках.
Как составить ресурсный план проекта
Когда я вижу в планах у своих РМов что-то оптимистичное типа вовлечения заказчика на 90% его рабочего времени на ближайшие полгода – остается только обнять и плакать. Даже если РМ каким-то образом протащил это через управляющий комитет – сложно поверить, что так и будет, а излишний оптимизм – зло. На выходе у вас и у основных стейкхолдеров должно появиться понимание того, кто будет работать в проекте, когда эти люди должны приступить к своим задачам, и когда они освободятся для других проектов. Степень формализации может быть от заметки в чате в телеграме (но лучше, чтобы это было хотя бы письмо по электронной почте) до полноценного документа на 50 страниц, утвержденного протоколом заседания управляющего комитета. Не забывать учитывать этапы инициации и закрытия проекта.
- Даже если РМ каким-то образом протащил это через управляющий комитет – сложно поверить, что так и будет, а излишний оптимизм – зло.
- Ресурсный план проекта или план ресурсного обеспечения проекта – это документ, в котором зафиксировано, какие ресурсы будут использоваться в проекте, и процессы получения и возврата этих ресурсов.
- Как уже говорилось выше, в зависимости от потребности оценка может быть как позадачной, так и на уровне этапов проекта.
- Если консенсуса достигнуть не удалось или если изначально предполагалось привлечение сторонних ресурсов – определить их источник (фриланс, подрядчики. овертаймы и проч.).
В случаях, когда ресурсы жестко ограничены и взять их негде, допустима ситуация, когда п.1 и п.2 меняются местами – задачи в проекте планируются от ресурсов, но это не самая хорошая практика. Составление ресурсного плана проекта – это обязательный этап при составлении базового плана проекта. В случае, если получить ресурсы в нужном объеме и в нужное время нельзя – долго и нудно балансировать задачи, сроки и ваши требования к ресурсам до достижения консенсуса. Если консенсуса достигнуть не удалось или если изначально предполагалось привлечение сторонних ресурсов – определить их источник (фриланс, подрядчики. овертаймы и проч.).
Мои принципы составления ресурсного плана
Ресурсный план проекта или план ресурсного обеспечения проекта – это документ, в котором зафиксировано, какие ресурсы будут использоваться в проекте, и процессы получения и возврата этих ресурсов. В жизни чаще всего встречается нечто среднее – руководитель проекта просто планирует ресурсы https://deveducation.com/blog/planirovanie-proekta-dlya-project-manager/ с привязкой к роли (разработчик, аналитик, тестировщик и т.д.) и получает их из пула ресурсов компании. И тут уже не до выбора “с опытом 3+ года именно в стройке”, кого дали – того дали. Наложить ресурсы на план-график, чтобы получить конкретную трудоемкость и сроки привлечения.
Такая степень детализации имеет смысл для крупных проектов типа внедрения SAP, под которые набираются или запрашиваются у партнеров целые команды. Не назначать ресурсы на конкретные задачи вместо этапа проекта. Очень редко получается сделать “как в книжках” – запланировать специалиста по информационной безопасности, например, на аудит архитектурного заключения, получить от него результаты аудита и больше никогда к этому не возвращаться. Даже в случае с самым махровым вотерфолом – с ним будут консультироваться в ходе подготовки заключения, встречаться для презентации результатов, обсуждать его замечания, присылать следующие итерации документа на правку и проч.
Ресурсный план проекта и как его разработать
Не пытаться высчитать трудоемость вплоть до дня. Учитывая, что проект – это очень динамичная вещь по своей сути, не стоит пытаться спланировать, кто, в какой день и на сколько часов будет привлечен. Все еще сто раз поменяется, и ничего, кроме головной боли, от постоянных перерасчетов ресурсов, вы не получите (я этим страдала в первый год в роли РМа, так что знаю на своем опыте). Сейчас лично мне комфортна оценка в целом на месяц, например, “0,3 FTE на март”. А как там эти часов размажутся по месяцу – не столь важно. Определить, какие ресурсы вам нужны для выполнения этих задач и в каком объеме, и требования к этим ресурсам (они могут быть как формальными, с указанием стажа и проч., так и неформальными типа “разработчик посильнее”).
