Как организовать управление ресурсами в IT-проектах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

W=∆T*α*Q

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

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

M=H*W

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cтатья подготовлена совместно с Делией Салахутдиновой