Для кого
  • Владельцы бизнеса
  • Руководители
Знания и навыки
  • Управление ресурсами
  • Управление ИТ-проектами
  • Планирование
Время на чтение
  • 9 минут

Ко мне часто обращаются с задачей построить процесс управления ресурсами в рамках проекта по внедрению ИСУП на платформе Jira и не только. Я считаю, что внедрение ресурсного планирования — крайне непростое мероприятие, поэтому если ресурсы — это не первое по приоритету узкое место в ИСУП, то лучше начинать не с него. Но если вы понимаете, что это становится для вас приоритетным направлением, то я советую подойти к организации управления максимально тщательно. И поскольку на эту тему я встречал не так много дельных и целостных материалов, я решил изложить свой подход в этой статье.

Управление ресурсами — это процесс, который включает в себя планирование и учет времени персонала, которое потребуется для выполнения определенной работы, на основании информации о квалификации персонала и о степени его занятости на том или ином проекте.

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


Когда управление ресурсами становится особенно актуальным:

1) когда компания испытывает дефицит ресурсов из-за их нехватки, длительности получения, а неэффективное их использование больно бьет по карману;

2) когда мы можем спланировать и учесть все активности, в которых задействован сотрудник И тут очень важно определить периметр внедрения процесса. Мы не сможем выполнить планирование трудовых ресурсов проекта или осуществить планирование кадровых ресурсов проекта, если не учитываем все источники загрузки сотрудника (например, его текущую поддерживающую деятельность) и не понимаем, сколько времени ему требуется на завершение того или иного этапа работы. Поэтому для того, что осуществить планирование человеческих ресурсов проекта, необходимо заранее просчитать все трудозатраты.

Хочу подчеркнуть, что в компании или подразделении должен быть отдельно выделен специалист, ответственный за планирование и управление ресурсами проекта . Это особенно важно, если речь идет о больших пулах ресурсов и о частых циклах перепланирования (например, ежемесячных). Напомню, что ресурсный пул — совокупность ресурсов, объединенных по какому-либо общему признаку (например, по квалификации или специализации).


На отдельном проекте управление ресурсами возможно только в двух случаях:

1) ресурсы выделены на сто процентов,

2) для управления доступен определенный условный процент от общей загрузки того или иного специалиста.

В остальных случаях мы будем управлять ресурсными пулами, а не ресурсами отдельного проекта.

Начинать внедрять процесс управления ресурсами, как я сказал выше, нужно тогда, когда конкретные ресурсы находятся в дефиците или слишком дорого обходятся компании. На данный момент для большинства крупных и средних бизнесов таким узким местом чаще оказываются IT-специалисты. Однако и нагрузка компетентных специалистов, выполняющих бизнес-функции и задействованных в реализации проектов, часто находится на пределе. Даже если компания может «купить» специалистов на проект, при планировании не всегда учитывается время на поиск, обучение и адаптацию новых сотрудников.

Основная цель управления ресурсами — балансировка спроса и предложения на них. В данном случае спросом мы считаем то, что нужно сделать. То есть, по сути, это определенная потребность в часах или сторипойнтах (вес задачи в условных единицах, без привязки к реальной трудоемкости). А предложение — это доступные ресурсы соответствующей квалификации в определенном временном интервале. Сбалансировать спрос и предложение — значит с одной стороны сделать загрузку адекватной доступным ресурсам (ограничить загрузку под доступные ресурсы путем корректировки потребности), с другой — определить доступность ресурсов в определенном промежутке времени.


Это делается для того, чтобы:

1) выяснить, какого ресурса не хватает и где его можно взять (из своего пула ресурсов или из пула ресурсов подрядчика),

2) понять, как распределить имеющиеся ресурсы. Мы должны сформулировать наиболее эффективный сценарий: какие проекты мы можем сделать с учетом потенциально доступных ресурсов (тех, что можно «купить», нанять или мобилизовать из внутренних резервов компании).

Для грамотного управления ресурсами на IT-проектах также необходимо более детально разобраться с такими аспектами, как горизонт планирования и ресурсный стакан.

Горизонт планирования — период, который используется для планирования и прогнозирования загрузки и доступности ресурсов (PMLogix)

Ресурсный стакан — это объем ресурсов (часы или сторипойнты) в рамках горизонта планирования (или спринта или инкремента) и конкретного пула ресурсов (PMLogix)

Инкремент — ресурсный стакан, который формируется вокруг создания крупного продукта несколькими командами (PMLogix)

Когда мы говорим «ресурсный стакан текущего года команды N», то мы имеем в виду такую, пусть и крайне упрощенную, формулу:

Объем стакана = длительность горизонта * количество доступных ресурсов в часах или сторипоинтах за выбранный период.

Давайте рассмотрим три возможных горизонта планирования и варианты их реализации на платформе Jira.

Долгосрочное планирование

Цель: формирование бюджета компании на закупку ресурсов.

Горизонт планирования: от 6 месяцев до года.

Источник ресурсов: внутренний ресурсный пул, аутсорсинг (новые и заключенные договоры), найм.

Подход к планированию: на долгосрочном горизонте мы планируем ресурсы по каждому пулу (или центру компетенций), то есть по квалификациям (например, Java-разработчик, тестировщик и т. д.) или командам (для выделенных кросс-функциональных команд). В исключительных случаях загрузка планируется по Ф. И. О. Но я не рекомендую это делать при долгосрочном планировании, так как сложнее предсказать, будет ли работать конкретный сотрудник все это время в компании.

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

Таким образом, мы можем сформировать реалистичный портфель проектов или иных активностей, которые реализуются с учетом связей и доступных ресурсов. Также это позволит запланировать бюджет на необходимые ресурсы исходя из внутренних ставок и лимита на аутсорс. Дополнительно мы можем составить дорожную карту портфеля с учетом доступных ресурсов и взаимосвязей.

С задачей планирования бюджета и отбора проектов в портфель отлично справляется плагин Structure в Jira. Этот инструмент позволяет наблюдать агрегированные данные по отсортированным и сгруппированным задачам. Объектом планирования является одна загрузка (объем необходимого времени) на проект по требуемой квалификации. Каждый проект превращается в набор загрузок, соответствующих его длительности. Загрузку можно определять по проценту вовлечения и количеству специалистов. В этом случае формула расчета загрузки будет выглядеть так:

W=∆T*α*Q

Где W — загрузка, ∆T — длительность периода, α — процент вовлеченности, Q — количество сотрудников.

Соответственно, бюджет вычисляется перемножением ставки на загрузку:

M=H*W

Где М — бюджет, H — ставка.

Пример такой структуры приведен на рис. 1.

Рис. 1. Аналитика бюджета по портфелю

Дополнительно можно использовать плагин BigPicture в представлении «Ресурсы» (Resources) для наглядной картины загруженности команд на выбранный период.

Среднесрочное планирование

Цель: мобилизовать необходимые ресурсы.

Горизонт планирования: от 1 до 6 месяцев.

Источник ресурсов: внутренний ресурсный пул, аутсорсинг (новые и заключенные договоры) и найм.

Подход к планированию: на данном горизонте планирования все еще достаточно неточные прогнозы по конкретным работам, поэтому планировать по задачам я не рекомендую, по Ф. И. О. — только выборочно. Планируя загрузки, учитываем специфику деления проекта на этапы, так как на разных этапах проекта — разная загрузка и востребованность квалификаций. Кроме того, между разными видами работ могут возникать взаимосвязи, которые влияют на потребность в ресурсах.

В качестве единицы планирования можно использовать либо универсальную единицу сторипойнты, либо нормочасы — необходимое время для выполнения какой-либо работы. Как правило, это время рассчитывается с помощью эксперта, который ранее сталкивался с подобными задачами. Сторипойнты хорошо работают в Scrum, где есть график сгорания (Burndown chart). Все задачи нормированы в сторипойнтах, и в них же ведется учет производительности команды. Нормочасы — наиболее универсальный инструмент, который используется при оценке трудоемкости. Однако их минус в том, что они привязаны к реальному времени и их чаще пытаются оспорить заказчики.

Для планирования загрузок в масштабе этапов проекта мы используем плагин BigPicture в представлении «Ресурсы». Здесь можно посмотреть загрузки, назначенные на команду и на каждого конкретного сотрудника в отдельности.

Пример интерфейса программы BigPicture представлен на рис. 2.

Рис. 2. Резервирование загрузки специалистов

Слева находятся команды/сотрудники, сверху — временная шкала. На пересечениях можно заметить ячейки различных цветов: зеленые, желтые и красные. Цвет блока сигнализирует о текущей загруженности команды/сотрудника (красный означает перегрузку, желтый — загрузку, близкую критичной, зеленый — недогрузку). Сами загрузки находятся ниже ячеек с оставшейся трудоемкостью и могут быть перемещены в режиме перетаскивания (drag&drop) как между ресурсными пулами, так и между исполнителями.

Краткосрочное планирование

Цель: закрепить имеющиеся ресурсы на конкретные виды активности, подтвердить реалистичность ожиданий по срокам, учесть взаимосвязи между задачами и этапами.

Горизонт планирования: меньше 1 месяца.

Источник ресурсов: внутренний ресурсный пул, аутсорсинг (заключенные договоры).

Подход к планированию: планирование по конкретным работам.

На краткосрочном горизонте задачи не могут быть спланированы в полном объеме на весь временной период. Что-то может быть спланировано на неделю вперед, что-то на пару дней, а что-то еще не спланировано вовсе. Это может не обеспечивать стопроцентную загрузку персонала, так как часть задач будет завершена в другом периоде (среднесрочный горизонт). Если на среднесрочном горизонте мы одновременно используем загрузку по этапам, а на краткосрочном — по задачам, то где-то произойдет наложение (дублирование загрузки), а где-то останутся незаполненные временные ресурсы (из-за того, что не знаем всех задач до конца периода).

Обычно планирование ресурсов на месяц нецелесообразно, так как ресурсная ситуация меняется постоянно: кто-то уходит в отпуск, кто-то заболевает и т. д.

Мы моделируем работу в нормочасах, как на заводе, но не учитываем то, что в реальности в IT-сфере производительность людей может сильно отличаться у различных исполнителей. Если на длительном и среднем горизонтах ошибки с вариативностью производительности и с доступностью людей сглаживаются за счет дополнительного временного буфера, который может быть использован в случае необходимости, то на коротком горизонте это не работает. Неточности декомпозиции задач и оценок, отсутствие задач в плане накладываются друг на друга, и краткосрочный план становится подвержен изменениям. Поэтому тратить время на оценку и планирование ресурсов на краткосрочном горизонте мы не рекомендуем. Предпочтительно использовать канбан-метод, работать с очередью входящих или запланированных задач, выявлять узкие места за счет контроля времени цикла на каждом этапе обработки (в ресурсном пуле или центре компетенции).

В Jira назначить загрузку на задачу можно на карточке Issue (поле «Учет времени»), а также с помощью плагина Tempo, где можно спланировать задачи на команду и оценить их трудоемкость.

Пример планирования загрузки в Tempo можно увидеть на рис. 3.

Рис. 3. Планирование загрузки с помощью плагина Tempo


Теперь давайте рассмотрим, какие сложности могут возникать при планировании ресурсов на реализацию проекта.

Ресурсное планирование — очень сложный и тяжелый процесс как с точки зрения внедрения, так и с точки зрения его поддержания в работоспособном состоянии. Для его реализации должно быть соблюдено несколько условий:

  • планы проектов уже ведутся,
  • проекты описаны,
  • производится регулярный мониторинг проектов.

Ресурсное планирование связано с другими процессами. Помимо информации по ресурсам, оно требует информации по срокам из планов проектов. Мы не можем рассматривать ресурсное планирование изолированно от других процессов, так как это приводит к нереалистичности планов.

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

Кроме того, этот процесс требует переговоров (например, когда есть конкуренция между проектами). Может показаться, что планирование ресурсов и бюджета проекта — это просто укладывание «кирпичиков» в ресурсный стакан. Но он сложен не только с технической точки зрения из-за необходимости моделирования и сравнения различных сценариев, но и с переговорной. Необходимо согласовать спрос и предложение, соблюсти баланс интересов всех заинтересованных сторон. Из-за того, что не все проекты и задачи могут быть обеспечены ресурсами и кому-то точно придется отказать, процесс ресурсного планирования часто становится политизированным. Важно понимать, что информационная система — лишь инструмент для решения конфликта между спросом и предложением в руках умелого переговорщика, отвечающего за балансировку ресурсов.

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

Профиль загрузки даже в рамках одного этапа может отличаться — например, загрузка может быть более интенсивной в начале этапа. Моделирование на уровне декомпозиции задач не прибавляет точности. Поэтому возникает вопрос к инструменту: можем ли мы этот профиль поправить после того, как первично спланируем загрузку? Эта проблема возникает в двух случаях: отсутствует развитый навык оценки или оценка используется как обязательство и на ее основании премируют или наказывают сотрудника.

Без типизации задач (возможности сравнивать аналогичные задачи для того, чтобы собирать статистику и уточнять модель в части оценок) будет сложно накапливать аналитику, которую можно в дальнейшем использовать для уточнения базовой оценки.

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

Итак, давайте подведем краткие итоги.

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

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

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

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogix

Авторы статьи:
Андрей Малахов, Делия Салахутдинова
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Смотрите также:
13 Мая 2024
Что такое уровни управления
Уровни управления в организации — это ступени иерархической структуры, которая обеспечивает порядок, а также распределение ответственности и полномочий между сотрудниками. Во главе структуры стоит тот, кто управляет компанией: генеральный или исполнительный директор, которому подчиняются управленцы нижестоящего уровня. Менеджеры, стоящие “под” главой предприятия, контролируют следующий, также нижестоящий, уровень руководителей.
26 Апр 2024
Что такое проектный треугольник и зачем он нужен проджекту
Что из себя представляет проектный треугольник и как его применяют в  управлении проектами? Как использование этого инструмента позволяет объяснить заказчику, что качественный продукт, сделанный в короткие сроки, стоить дешево не может?  В чем отличия треугольника при использовании в гибких методологиях от применения в классическом подходе Waterfall?
16 Апр 2024
Что такое декомпозиция и чем она отличается от других видов планирования
Декомпозиция – это метод разделения большой цели, продукта, задачи, работы или процесса на маленькие части, этапы, подзадачи. Часто декомпозицию применяют для составления плана работ и контроля реализации большого сложного проекта. Как её применять, читайте в этой статье.
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена