Ресурсное планирование в проектном менеджменте: классика и реальности Agile

Здравствуй, читатель. Я заметил что многие начинающие менеджеры в последнее время забывом и крайне важном подходе — ресурсном планировании. Поэтому я подготовил некраткую статью о том, как работает ресурсное планирование в управлении проектами, ориентируясь на «классический подход», но с учетом реалий гибридных и agile подходов (мы же все современные и в G/S/N и прочих школах сразу про скрам рассказывают).

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

Классический «водопадный подход» к планированию проектов предполагает последовательный переход от требований к расписанию. Хорошо описано у Селиховкина https://drive.google.com/file/d/1uCV7cu_1JgVGYk9pXP-LFCv1E1EdNF3m/view?usp=sharing

1. Сначала формируется матрица требований (матрица трассировки), чтобы связать каждый запрос заказчика с конкретными результатами проекта. Тут подробнее https://habr.com/ru/articles/831922/

2. Затем строится иерархическая структура работ (WBS) – декомпозиция проекта на более мелкие задачи. Одна из немногих вменяемых статей на этот счет https://kaiten.ru/blog/model-wbs/

3. После этого задачи упорядочиваются в сеть – создаётся сетевая диаграмма проекта, отображающая зависимости и последовательность работ. https://forpm.ru/сетевой-график/

4. На основе WBS и сети составляется ресурсный план, то есть определяются необходимые ресурсы для каждой задачи (команда, оборудование и пр.). Вменяемых статей особо не нашел, крупицы есть тут https://probusiness.io/master_class/529-chto-nado-znat-pro-raspredelenie-resursov-chtoby-ne-zagubit-dazhe-khoroshiy-plan-proekta.html

5. Параллельно оценивается трудоёмкость и продолжительность выполнения задач с учётом ресурсов.

6. В результате разрабатывается календарный план – график проекта, часто представленный в виде диаграммы Ганта, показывающий, когда и какие задачи будут выполняться и кем. Ниже мы подробно рассмотрим, как создаётся ресурсный план проекта и какие инструменты в этом помогают.

Этапы создания ресурсного плана проекта

Правильное ресурсное планирование отвечает на вопросы: кто будет выполнять задачи проекта, когда и в каком объёме будет задействован каждый ресурс, и хватит ли у нас ресурсов для выполнения всех работ в срок. Помни важное правильно — НИКОГДА НЕ НАЗЫВАЙ РЕСУРС РЕСУРСОМ ПРИ РЕСУРСЕ (профессионализмы могут быть странными и непогруженных могут обидеть).

Ключевые этапы разработки ресурсного плана следующие:

1. Оценка доступности ресурсов. На этом шаге менеджер определяет, какие ресурсы доступны для проекта и в какие периоды. Важно учесть всю текущую загрузку сотрудников (операционная работа, другие проекты и т.д.), а также не стоит забывать про отпуска, иначе план будет нереалистичным. Например, если специалист уже занят в поддержке, это должно быть отражено – иначе двойное планирование приведёт к перегрузке.

2. Оценка ёмкости ресурсов. Для каждого доступного ресурса оценивается его ёмкость, то есть сколько рабочего времени он может посвятить проекту. Обычно ёмкость измеряется в часах или как доля ставки (FTE) в определённом периоде (например, 0,5 от полной занятости в месяц). Но тут зависит от типов оценок принятых у вас.

   1. При этом важно не планировать 100% загрузку: люди берут отпуска, могут болеть и выполняют вспомогательные задачи;

   2. Например, разумно закладывать загрузку ~80% от рабочего времени, оставляя буфер на внеплановые отвлечения;

   3. И это 80% от того времени, когда люди доступны для выполнения задач. Вычитайте сразу время на все плановые и прогнощируйте объем внеплановых встреч. Если у вас каждый день дейли, раз в неделю груминг и еще что-то, то у вас нет 40 часов в неделю на человека.

3. Предварительный прогноз требуемого качества ресурсов. Оценка того для каких задач какие нужны ресурсы. Если по человечески — то вот эту архитектурную задачу может сделать только синьор. Специфику задач надо учитывать.

4. Аллокация ресурсов на задачи. Затем производится распределение ресурсов по задачам проекта. Менеджер назначает исполнителей или команды на каждую задачу в соответствии с необходимыми квалификациями и доступностью.

   1. Часто это делают, добавляя ресурсы на диаграмму Ганта или в таблицу ресурсов проекта.

   2. На этом этапе получается предварительное понимание, кто и когда будет выполнять каждую работу. Например, к задаче Разработка прототипа назначаются 2 разработчика, а к задаче Тестирование – 1 тестировщик на спринта.

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

6. Выровнивание ресурсов (resource leveling). Этот шаг тесно связан с предыдущим и часто выполняется итеративно. Выравнивание ресурсов означает устранение перегрузок: график корректируется так, чтобы ни один ресурс не был занят сверх своей ёмкости в любой момент времени. Вручную это делается с помощью сдвига задач во времени или изменения объёма работ. Многие инструменты (Microsoft Project, Spider Project и др.) умеют автоматически выравнивать ресурсы, откладывая некоторые задачи или распределяя нагрузку более равномерно. Результат – реалистичный календарный план, в котором учтены все ресурсные ограничения, и ни у кого из команды нет “двойного бронирования” на одно и то же время.

7. Актуализация и контроль. После финализации ресурсного плана его необходимо поддерживать в актуальном состоянии. Проект – динамичный процесс, и по мере изменений (появление новых задач, изменение приоритетов, задержки, уход или приход сотрудников) ресурсный план пересматривается. Менеджер регулярно отслеживает фактическую загрузку (например, через табели учета времени) и сравнивает с планом, чтобы вовремя перераспределять силы. Также сюда можно отнести документирование политики управления ресурсами (как привлекаются внешние ресурсы, правила замен и т.п.) и коммуникацию с руководством о статусе ресурсного обеспечения проекта.

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

Следуя этим шагам, на выходе мы получаем ресурсный план – документ или файл, фиксирующий кто из ресурсов, в каком объёме и когда задействован в проекте. Формальность оформления может быть разной: от простого списка в слаке и до детализированной таблицы или диаграммы на несколько страниц. Главное, чтобы у всех участников проекта и стейкхолдеров было единое понимание ресурсных ограничений проекта.

Типичные подходы и техники планирования

Разные методологии и инструменты помогают менеджеру спланировать проектные работы и ресурсы. Вот некоторые из наиболее распространённых подходов:

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

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

• Метод Монте-Карло. Это техника моделирования, применяемая для анализа рисков и неопределенности в проектах. Метод Монте-Карло предполагает многократное случайное моделирование хода проекта с разными исходными данными, чтобы получить распределение вероятных сроков или бюджета (Метод Монте-Карло (Monte Carlo Analysis) – Бюро проектного менеджмента). Проще говоря, компьютер сотни или тысячи раз “проигрывает” проект, случайно варьируя длительности задач (в пределах заданных оценок) или затраты, а менеджер получает статистику: например, с 90% вероятностью проект завершится не позже X дней. В управлении проектами Монте-Карло помогает оценивать сроки и риски более обоснованно, чем единственная детерминированная оценка. Особенно это ценно в Agile-среде, где высокая неопределенность – нормальное явление, и полезно прогнозировать сроки релиза по данным о скорости команды.

• Метод критической цепи (CCPM). Этот подход развит на основе метода критического пути, но делает упор на ограничениях ресурсов. Метод критической цепи не предполагает жёстко фиксированных дат начала каждой задачи, вместо этого он выстраивает график с учётом ограничений по ресурсам и вставляет буферы времени на случай отклонений https://habr.com/ru/articles/25621/. Идея в том, чтобы снять избыточные локальные запасы времени с отдельных задач (которые всё равно часто расходуются впустую по принципу Паркинсона) и сосредоточить резервы в нескольких буферах – проектном, буферах этапов и ресурсов.

Примечание: В гибких методологиях (на основе Agile, например scrum) детальное планирование ресурсов на уровне каждого человека обычно вообще не формализовано. Команда рассматривается как неделимое целое, оценивается её общая пропускная способность (velocity), а задачи берутся в работу исходя из приоритетов, без долгосрочного закрепления конкретных исполнителей. Тем не менее, понимание классических техник планирования полезно и в Agile-среде – например, для грубой оценки больших проектов, планирования релизов или распределения людей между несколькими виртуальными командами.

Примеры: планирование ресурсов в Excel и Jira

Excel и шаблоны: Маленькие компании и начинающие руководители проектов часто начинают с Excel. Табличный формат наглядный и гибкий: можно составить список задач, указать для каждой требуемый ресурс, трудоемкость и сроки, а затем с помощью формул агрегировать данные (например, суммировать часы по сотрудникам или просчитать стоимость по ставкам). Конкретного шаблона не подскажу, там откуда я их брал все почистили, а ничего приличного в интернете не нашел кроме этого https://plaky.com/learn/work-tools-and-templates/resource-planning-templates/

Jira и специализированные плагины: В ИТ-проектах, особенно использующих Agile, часто применяются таск-трекеры вроде Jira. Стандартная Jira предоставляет базовые средства учёта трудозатрат (логирование часов, простые отчёты) и ведения бэклога. Однако для полноценного ресурсного планирования “из коробки” её возможностей может быть мал. В помощь приходят плагины и дополнительные модули. Например, Jira Plans (Advanced Roadmaps) – это встроенный инструмент (в подписке Premium), позволяющий планировать несколько команд и проектов, распределять задачи по исполнителям с учётом их емкости и строить дорожную карту проекта.

Также популярны сторонние плагины: BigPicture, Tempo Planner, Structure и др. https://reliex.com/blog/top-5-capacity-planners-for-jira/ Так, плагин BigPicture добавляет в Jira диаграмму Ганта и режим «Resources», где видно загрузку команды и отдельных сотрудников по календарю.

Естественно в это умеют системы вроде MS Project, но это вопрос отдельной статьи и легко гуглится.

Также много полезного можно найти в моем телеграм канале https://t.me/junior_pm !