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

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

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

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

W=∆T*α*Q

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

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

M=H*W

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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