Давно не было теоретических постов, исправляюсь. Давайте сегодня про такой простой и, возможно, недооцененный инструмент руководителя проекта, как иерархическая структура ресурсов.
Сразу ремарка – иерархическая структура работ (она же – WBS, Work Breakdown Structure) и иерархическая структура ресурсов – это взаимосвязанные, но все-таки разные вещи. А то в интернетах периодически вижу, что их путают.
Что такое иерархическая структура ресурсов?
Вообще ресурсы в проекте бывают самые разные – люди, оборудование, материалы и т.д. Да даже переговорные комнаты могут быть ресурсом, если у вас проект масштабного очного обучения, а количество комнат ограничено.
Иерархическая структура ресурсов (на английском она называется Resource Breakdown Structure) – дерево всех ресурсов, доступных для использования в проекте, с указанием их типа.
Выглядит она примерно так (картинка из яндекса):
Самое ключевое здесь – “с указанием типа”. Ресурсы структурируются не от имен или названий, а от того, какую пользу они могут принести проекту.
Зачем нужна иерархическая структура ресурсов
Как вы помните, при составлении базового плана проекта у нас есть шаг, когда мы определяем, какие задачи нужно выполнить для получения конкретного результата из WBS и ресурсы какого типа нужны для выполнения этих задач (например, люди с определенными компетенциями, автомобили для поездок этих людей на объекты заказчика, сервера с определенными характеристиками и т.д.) .
На следующем шаге мы выбираем из доступных ресурсов те, которые подходят под наши задачи, и на основе этого формируем итоговую стоимость задачи, которая ляжет в бюджет проекта.
Но тут-то и кроется засада – легко определить ресурсы, если вы работаете в маленькой компании, и выбор у вас между программистом Лешей и программистом Петей, причем загрузку и того и другого вы прекрасно знаете. А если Леш и Петь у вас 50 или 100? А если на проект нужен не просто программист, а строго со знанием определенной технологии? Или строго Козерог (ну вдруг заказчик так захотел)? Тут уже так просто ответить на вопрос “а кто мне подойдет” нельзя, и вы садитесь, обозначаете ключевую компетенцию и подбираете под нее ресурсы, а потом уже согласуете их выделение на проект.
Вот тут-то вам и пригодится иерархическая структура ресурсов, которая позволяет взглянуть на ресурсы проекта в систематизированном виде.
Говоря про иерархическую структуру ресурсов, важно иметь ввиду, что ресурсы – это не только люди (хотя в большинстве случаев, конечно, они). Задача руководителя проекта – проанализировать в том числе все материальные ресурсы, которые ему понадобятся, и также отразить их в структуре.
Как и практически любая задача на этапе планирования, построение иерархической структуры работ позволяет лучше структурировать планируемые работы, определить “белые пятна” и пополнить реестр рисков.
Пара простых примеров из моей практики:
- Проект предполагает масштабное офлайн обучение 10 000 человек. По 20 человек в группе – это 500 групп, по 8 часов каждая. Мы можем попробовать уговорить тренера работать сверхурочно и проводить по 2 группы в день (хотя это вряд ли), но помещение для обучения, в котором установлены компьютеры, у нас только одно. Сколько времени нам понадобится, чтобы обучить 500 групп, 250 дней, почти год? И второй, третий и пятый тренера нас не спасут, так как нет ключевого ресурса – места для обучения. Хоп – и в проекте появляется новая задача по организации двух дополнительных классов, и огромный риск снят!
- Запланирован огромный даже по моим меркам проект – внедрение SAP S/4HANA (кто участвовал во внедрениях SAP – тот поймет). Садимся и думаем – сроки очень агрессивные, на этапе обследования у нас тут будет толкаться три-четыре десятка консультантов SAP (история происходит до ковида, если что), так как мы же молодцы, запараллелили все, что только можно. Но вот вопрос – где они будут сидеть в нашем офисе? Трех переговорок и пары свободных мест просто не хватит, будет коллапс, и мы просто будем сливать деньги, пока консультанты будут ждать своей очереди. Похоже, придется на год-два арендовать соседний офис, там как раз соседи съехали. Вот и бюджет проекта опять подрос. И еще вопрос – по требованиям информационной безопасности нашей компании мы выдаем каждому из них во временное пользование наш ноутбук с доступом в корпоративную сеть? У нас точно есть сейчас 80 бесхозных ноутбуков, или их придется купить, так как они всяко дешевле простоя консультантов? И бюджет снова подрос, и новые задачи в проекте появились.
Конечно, иерархическая структура работ – это в первую очередь инструмент планирования, но построенная структура пригодится вам и в ходе проекта. Если программист Вася внезапно решит, что он устал и уходит – вам не придется делать повторную оценку, вы просто вернетесь к структуре, посмотрите, есть ли в компании замена Васе и в зависимости от этого решите, насколько серьезный риск для проекта материализовался.
Инструменты для создания и управления иерархической структурой ресурсов
Каких-то прямо специальных инструментов для разработки иерархической структуры ресурсов я не знаю, да они и не нужны. Лично мне хватает майндмепов, иногда – просто экселя. MS Project, насколько помню, показывать ресурсы именно в форме иерархии не умеет, максимум, что там можно сделать – это отнести ресурс к какому-то типу (трудовой, материальный и т.д.) и к какой-то созданной вами группе (сотрудники, инфраструктура, транспорт и т.д.). Плюс MS Project в первую очередь в том, что он позволяет вести учет стоимости ресурсов и автоматически считать бюджет проекта с учетом этой стоимости, а так же выравнивать ресурсы в случае перегрузки, но это уже совсем другая история.
Надеюсь, стало немного понятнее, что за зверь такой – иерархическая структура ресурсов, и что вы вспомните о ней на первом же большом проекте. Еще раз подчеркиваю – это как раз тот самый случай, когда инструмент нужно применять только там, где он необходим, на небольших проектах это может стать лишней бюрократией, в которой так часто обвиняют классическое управление проектами.
Используете иерархическую структуру ресурсов в работе? Поделитесь!
Добавить комментарий