В очередной понедельник на планерке наш тимлид докладывал о задержках на проектах. Я смотрел на его отчеты и не понимал, как так вышло. Формально у нас было достаточно людей в команде, сроки казались реалистичными, но дедлайны все равно приходилось сдвигать. 

Я начал разбираться и увидел, где возникает проблема. Разработчики тонули в параллельных задачах, дизайнер был занят сразу на двух проектах и не успевал ни там, ни там, а аналитик ушел в отпуск — и на нем зависли критические вопросы.

Через несколько недель погружения стало понятно: дело не в том, что команда работает медленно или недостаточно старается. Мы просто никак не планировали ресурсы. Задачи брали по мере поступления и какое-то время справлялись, но в какой-то момент эта схема перестала работать.

Мы поговорили с менеджером проектов, который столкнулся с постоянными сдвигами сроков и попытался в этом разобраться. На основе его опыта написали этот материал. — Прим. ред.

Что такое ресурсное планирование

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

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

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

В Wincor Nixdorf, глобальной IT-компании, больше 50 менеджеров делили одних и тех же специалистов без единого инструмента — и постоянно обнаруживали, что люди перебронированы.

Масштабы разные, а корень один: без ресурсного плана проекта решения принимаются вслепую.

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

Я выделил для себя такие шаги:

Формулируем цели. Уточняем, что бизнес хочет получить в итоге проекта. Запуск мобильного приложения к определенной дате? Выход на новый рынок? Строительство объекта к фиксированному сроку? Пока цель размыта, будет сложно прикинуть ресурсы. 

Собираем требования и определяем потребности. Составляем список ресурсов для реализации проекта. Определяем, какие роли нужны, какие компетенции критичны, есть ли у нас эти специалисты.

Составляем график проекта. Разбиваем на этапы, распределяем работы, выделяем роли и прикидываем примерное время вовлечения этих ролей. Например: аналитик нужен на этапе инициации и проектирования; разработчики подключатся на этапе реализации; дизайнер — на старте проектирования и перед релизом. Здесь важно не просто перечислить роли, а увидеть зависимости: если конкретная роль недоступна, этап может забуксовать.

Оцениваем доступность ресурсов на время проекта.  Самое интересное начинается, когда мы соединяем структуру работ с рабочим календарем исполнителей. Этот шаг помогает оценить:

• кто из команды задействован одновременно в нескольких проектах;

• где загрузка специалиста превышает допустимый уровень;

• какие этапы зависят от одного специалиста.

На этом шаге фактически формируется ресурсный план проекта и одновременно происходит оценка рисков. Если один специалист критичен для нескольких задач, а его загрузка уже около 90%, это точка потенциального срыва. А если у этой роли нет замены, проект становится уязвимым, и нужно принимать стратегические решения, чтобы минимизировать риски.

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

Дополнительно я отметил ситуации, где ресурсный подход может быть особенно полезен:

• При запуске и ведении нескольких проектов одновременно. Когда одновременно идет несколько инициатив, пересечения по людям становятся неизбежными. Без прозрачной картины загрузки один и тот же специалист может оказаться «узким горлышком».

• Когда есть уникальные роли или узкая экспертиза. Если ключевые решения завязаны на одном человеке, проект становится хрупким. Любая перегрузка или недоступность такого специалиста сразу влияет на сроки.

• В проектах с жесткими рамками. Если дата релиза или сдачи объекта фиксирована, ошибки в оценке ресурсов напрямую ведут к переработкам или срыву обязательств. В таких условиях важно заранее понимать реальные возможности команды и уровень риска.

Подходы и методы ресурсного планирования

Я наткнулся на несколько устоявшихся подходов. Они не исключают друг друга — скорее расставляют разные акценты в зависимости от масштаба задач и уровня зрелости процессов.

Метод выравнивания ресурсов (Resource leveling). Его используют, когда план проекта требует больше ресурсов, чем есть в команде. В этом случае задачи перераспределяют или переносят так, чтобы специалисты не были перегружены и могли выполнять работу последовательно. Обычно это приводит к сдвигу сроков проекта. 

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

• Плюс — снижает перегруз и риск выгорания сотрудников.

• Минус — почти всегда затрагивает сроки. И здесь начинается конфликт ожиданий: бизнес хочет быстрее, а команда физически не может.

Метод сглаживания ресурсов (Resource Smoothing). Подход применяют, когда срок проекта менять нельзя, но нужно снизить пики нагрузки на команду. В этом случае задачи перераспределяют внутри доступного запаса времени, чтобы избежать периодов перегрузки. 

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

• Плюс — дедлайн сохраняется, пиковая нагрузка снижается.

• Минус — требует аккуратной работы с зависимостями и понимания, где есть запас времени. Если у задач нет временного запаса, сгладить нагрузку не получится.

Метод критической цепи CCPM (Critical Chain Project Management). Критическая цепь — это самая длинная последовательность задач в проекте с учетом не только логических зависимостей между ними, но и ограниченности ресурсов. В отличие от классического критического пути, она учитывает, что один специалист не может одновременно работать над несколькими задачами, и это может удлинить цепочку

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

Например, команда разрабатывает новую функцию. План проекта выглядит так:

• аналитика — 3 дня;

• дизайн — 4 дня;

• разработка — 6 дней;

• тестирование — 3 дня.

Обычно каждая задача оценивается с небольшим запасом, поэтому суммарный срок проекта может увеличиться, например, до 20 дней. В CCPM индивидуальные запасы убирают из задач и объединяют в общий буфер проекта. Например, сами задачи планируют на 16 дней, а оставшиеся 4 дня выносят в буфер.

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

• Плюс — прозрачность: видно, сколько запаса времени осталось у проекта.

• Минус — сложнее внедрить и есть зависимость от исполнителей, которые все равно могут неосознанно закладывать личные запасы времени, что обесценивает метод.

Как организовать процессы ресурсного планирования

Когда я более-менее разобрался в теории, оставалось понять, как внедрить планирование в реальную команду. Я поговорил с парой менеджеров, которые прошли этот путь, и собрал практические советы:

1. Начните с прозрачности. Создайте простую визуализацию загрузки команды в Excel на 4–6 недель вперед: кто занят, кто частично доступен, где есть пересечения. Не нужно детально расписывать все по часам — это только вызовет сопротивление. Сначала достаточно видеть общую картину.

2. Честно оцените трудоемкость. Не стоит планировать рабочее время на 100% задачами проекта, потому что из них 30—40% могут уходить на встречи, административные и операционные задачи. 

3. Назначьте ответственного. Должен быть человек, который собирает требования и данные и поддерживает план актуальным. Например, это может быть руководитель проекта.

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

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

Ресурсное планирование на практике

Сначала я нашел в сети шаблон для ресурсного планирования в Excel и попробовал вести в нем загрузку команды. Для 1 проекта это работало нормально, но когда я попытался контролировать 2 проекта одновременно, стало неудобно: приходилось переключаться между вкладками, сводить данные вручную и все равно держать в голове, где какой специалист занят. Стало понятно, что нужен инструмент, который покажет все это в одном месте.

Тогда начал искать подходящий инструмент, который помог бы заранее видеть конфликты ресурсов. Среди подходящих сервисов я подробнее изучил Kaiten — в нем ресурсное планирование реализовано через модуль «Гант и Ресурсное планирование», который был доступен на пробной версии. Затем купил подписку на 3 месяца, чтобы продлить тестирование и наверняка убедиться в том, подойдет нам инструмент или нет.

Что мне показалось удобным в системе:

— Загрузка каждого сотрудника считается не в рамках одного проекта, а по всем его задачам сразу. Если дизайнер участвует в двух проектах, это видно в одном месте, а не выясняется позже на планерке.

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

— Модуль позволяет собирать задачи из разных пространств на единой временной шкале, планировать сроки на календарной сетке и выстраивать зависимости между задачами. Можно отмечать контрольные точки вехами проекта и детализировать крупные задачи через родительско-дочерние связи.

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

Более подробно о том, как планировать проекты в Kaiten с помощью диаграммы Ганта и ресурсного планирования, написано в этой статье. — Прим. ред.

Продолжим работу в таком формате

Когда я предложил команде вести загрузку, первая реакция была предсказуемой — «еще одна табличка, которую никто не будет заполнять». И первые пару недель так и было: данные устаревали, кто-то забывал обновить статус, кто-то вписывал задачи задним числом.

Тогда мы договорились о минимальном правиле: при постановке задачи обязательно указывать примерные трудозатраты и срок. Не нужно было высчитывать все до часа — достаточно было прикинуть: «это дня на 2 работы, нужно закрыть до конца следующей недели». Когда эти данные появились, картина загрузки на ресурсном плане стала хоть на что-то похожа.

Что-то сдвинулось примерно через 3 недели. На очередной планерке мы впервые не обсуждали, почему что-то задерживается. Вместо этого смотрели на загрузку на ближайшее время недели и решали, как лучше распределить задачи.

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

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