- Регистрация
- 23 Авг 2023
- Сообщения
- 3,969
- Реакции
- 0
- Баллы
- 36
Ofline
В очередной понедельник на планерке наш тимлид докладывал о задержках на проектах. Я смотрел на его отчеты и не понимал, как так вышло. Формально у нас было достаточно людей в команде, сроки казались реалистичными, но дедлайны все равно приходилось сдвигать.
Я начал разбираться и увидел, где возникает проблема. Разработчики тонули в параллельных задачах, дизайнер был занят сразу на двух проектах и не успевал ни там, ни там, а аналитик ушел в отпуск — и на нем зависли критические вопросы.
Через несколько недель погружения стало понятно: дело не в том, что команда работает медленно или недостаточно старается. Мы просто никак не планировали ресурсы. Задачи брали по мере поступления и какое-то время справлялись, но в какой-то момент эта схема перестала работать.
Мы поговорили с менеджером проектов, который столкнулся с постоянными сдвигами сроков и попытался в этом разобраться. На основе его опыта написали этот материал. — Прим. ред.
Ресурсное планирование — это процесс, который помогает понять, какие ресурсы нужны проекту, когда они доступны и хватит ли их, чтобы закончить работу в срок. В IT-проектах основной ресурс — люди: их рабочее время, загрузка, компетенции и инструменты, которые могут понадобиться.
На старте проекта такое планирование помогает трезво оценить сроки, бюджет и загрузку команды. А когда становится понятна фактическая картина, бизнес начинает принимать более осознанные решения: какие проекты запускать, где не хватает людей и когда стоит перераспределить приоритеты.
Пока я разбирался в теме, заметил, что с проблемами ресурсного планирования сталкиваются все: от небольших студий до корпораций. Например, в одном крупном российском банке сотрудники работали на нескольких проектах одновременно, а руководители распределяли загрузку интуитивно — пока не внедрили систему, где конфликты по ресурсам видно заранее.
В Wincor Nixdorf, глобальной IT-компании, больше 50 менеджеров делили одних и тех же специалистов без единого инструмента — и постоянно обнаруживали, что люди перебронированы.
Масштабы разные, а корень один: без ресурсного плана проекта решения принимаются вслепую.
Я выделил для себя такие шаги:
Формулируем цели. Уточняем, что бизнес хочет получить в итоге проекта. Запуск мобильного приложения к определенной дате? Выход на новый рынок? Строительство объекта к фиксированному сроку? Пока цель размыта, будет сложно прикинуть ресурсы.
Собираем требования и определяем потребности. Составляем список ресурсов для реализации проекта. Определяем, какие роли нужны, какие компетенции критичны, есть ли у нас эти специалисты.
Составляем график проекта. Разбиваем на этапы, распределяем работы, выделяем роли и прикидываем примерное время вовлечения этих ролей. Например: аналитик нужен на этапе инициации и проектирования; разработчики подключатся на этапе реализации; дизайнер — на старте проектирования и перед релизом. Здесь важно не просто перечислить роли, а увидеть зависимости: если конкретная роль недоступна, этап может забуксовать.
Оцениваем доступность ресурсов на время проекта. Самое интересное начинается, когда мы соединяем структуру работ с рабочим календарем исполнителей. Этот шаг помогает оценить:
На этом шаге фактически формируется ресурсный план проекта и одновременно происходит оценка рисков. Если один специалист критичен для нескольких задач, а его загрузка уже около 90%, это точка потенциального срыва. А если у этой роли нет замены, проект становится уязвимым, и нужно принимать стратегические решения, чтобы минимизировать риски.
Мониторинг и корректировка плана. План стоит регулярно обновлять, чтобы видеть реальную картину. Проект меняется: появляются новые задачи, смещаются приоритеты, сотрудники уходят в отпуск или подключаются к другим инициативам. Если не пересматривать план, ресурсное обеспечение проекта быстро превращается в набор устаревших допущений, которые уже не отражают реальную картину.
Дополнительно я отметил ситуации, где ресурсный подход может быть особенно полезен:
Я наткнулся на несколько устоявшихся подходов. Они не исключают друг друга — скорее расставляют разные акценты в зависимости от масштаба задач и уровня зрелости процессов.
Метод выравнивания ресурсов (Resource leveling). Его используют, когда план проекта требует больше ресурсов, чем есть в команде. В этом случае задачи перераспределяют или переносят так, чтобы специалисты не были перегружены и могли выполнять работу последовательно. Обычно это приводит к сдвигу сроков проекта.
Например, у вас в команде 4 разработчика, а по плану одновременно нужно 7. В этом случае задачи перераспределяются или растягиваются во времени. Нагрузка становится реалистичной, но общий срок проекта увеличивается, чтобы команда могла закрыть работы текущими силами.
Метод сглаживания ресурсов (Resource Smoothing). Подход применяют, когда срок проекта менять нельзя, но нужно снизить пики нагрузки на команду. В этом случае задачи перераспределяют внутри доступного запаса времени, чтобы избежать периодов перегрузки.
Например, у разработчика на одной неделе стоят две задачи: реализация новой функции и оптимизация старого модуля. Оптимизация не влияет на текущий релиз и имеет небольшой запас времени. В этом случае ее переносят на следующую неделю, чтобы разработчик сначала завершил критическую задачу.
Метод критической цепи CCPM (Critical Chain Project Management). Критическая цепь — это самая длинная последовательность задач в проекте с учетом не только логических зависимостей между ними, но и ограниченности ресурсов. В отличие от классического критического пути, она учитывает, что один специалист не может одновременно работать над несколькими задачами, и это может удлинить цепочку
Ключевая идея метода — не распределять запас времени по отдельным задачам, а собрать его в один общий резерв и управлять им централизованно. Также добавляют питающие буферы — резервы на стыке некритических цепочек задач с критической цепью. Они нужны, что задержки в побочных ветках не повлияли на основную последовательность.
Например, команда разрабатывает новую функцию. План проекта выглядит так:
Обычно каждая задача оценивается с небольшим запасом, поэтому суммарный срок проекта может увеличиться, например, до 20 дней. В CCPM индивидуальные запасы убирают из задач и объединяют в общий буфер проекта. Например, сами задачи планируют на 16 дней, а оставшиеся 4 дня выносят в буфер.
Менеджер следит не за тем, укладывается ли каждая задача в свою оценку, а за тем, как быстро расходуется этот буфер. Если он начинает быстро сокращаться, значит проект выходит из графика и нужно вмешаться.
Когда я более-менее разобрался в теории, оставалось понять, как внедрить планирование в реальную команду. Я поговорил с парой менеджеров, которые прошли этот путь, и собрал практические советы:
Сначала я нашел в сети шаблон для ресурсного планирования в Excel и попробовал вести в нем загрузку команды. Для 1 проекта это работало нормально, но когда я попытался контролировать 2 проекта одновременно, стало неудобно: приходилось переключаться между вкладками, сводить данные вручную и все равно держать в голове, где какой специалист занят. Стало понятно, что нужен инструмент, который покажет все это в одном месте.
Тогда начал искать подходящий инструмент, который помог бы заранее видеть конфликты ресурсов. Среди подходящих сервисов я подробнее изучил Kaiten — в нем ресурсное планирование реализовано через модуль «Гант и Ресурсное планирование», который был доступен на пробной версии. Затем купил подписку на 3 месяца, чтобы продлить тестирование и наверняка убедиться в том, подойдет нам инструмент или нет.
Что мне показалось удобным в системе:
— Загрузка каждого сотрудника считается не в рамках одного проекта, а по всем его задачам сразу. Если дизайнер участвует в двух проектах, это видно в одном месте, а не выясняется позже на планерке.
На одном экране совмещены план работ во времени и загрузка людей: слева таблица задач, справа временная шкала, снизу таблица ресурсов сотрудников
— Можно настроить реальный график работы каждого человека: частичную занятость, отпуска или нестандартное расписание. На основе этого инструмент автоматически подсвечивает перегруз, когда сотрудник выходит за пределы своей доступности.
— Модуль позволяет собирать задачи из разных пространств на единой временной шкале, планировать сроки на календарной сетке и выстраивать зависимости между задачами. Можно отмечать контрольные точки вехами проекта и детализировать крупные задачи через родительско-дочерние связи.
Все это видно на одной шкале по всем проектам сразу, что позволяет принимать решения до того, как ситуация стала критической.
Нагрузка считается автоматически, если выбрать один из 3 режимов расчета: с фиксированными трудозатратами, с фиксированной длительностью или с фиксированными трудозатратами и длительностью
Более подробно о том, как планировать проекты в Kaiten с помощью диаграммы Ганта и ресурсного планирования, написано в этой статье. — Прим. ред.
Когда я предложил команде вести загрузку, первая реакция была предсказуемой — «еще одна табличка, которую никто не будет заполнять». И первые пару недель так и было: данные устаревали, кто-то забывал обновить статус, кто-то вписывал задачи задним числом.
Тогда мы договорились о минимальном правиле: при постановке задачи обязательно указывать примерные трудозатраты и срок. Не нужно было высчитывать все до часа — достаточно было прикинуть: «это дня на 2 работы, нужно закрыть до конца следующей недели». Когда эти данные появились, картина загрузки на ресурсном плане стала хоть на что-то похожа.
Что-то сдвинулось примерно через 3 недели. На очередной планерке мы впервые не обсуждали, почему что-то задерживается. Вместо этого смотрели на загрузку на ближайшее время недели и решали, как лучше распределить задачи.
Не скажу, что теперь все работает гладко. Оценки трудоемкости по-прежнему бывают далеки от реальности — мы стабильно недооцениваем задачи, связанные с интеграциями. План приходится обновлять вручную, и без напоминаний это делает от силы половина команды. Но разница ощутимая: за последние 3 месяца мы сдвинули дедлайн по одному проекту из пяти. До этого сдвигалось почти все.
Если пользуетесь инструментами для ресурсного плана проекта планирования ресурсов, то поделитесь своим опытом. И как сделать так, чтобы люди обновляли план в системе без постоянных пинков?
Я начал разбираться и увидел, где возникает проблема. Разработчики тонули в параллельных задачах, дизайнер был занят сразу на двух проектах и не успевал ни там, ни там, а аналитик ушел в отпуск — и на нем зависли критические вопросы.
Через несколько недель погружения стало понятно: дело не в том, что команда работает медленно или недостаточно старается. Мы просто никак не планировали ресурсы. Задачи брали по мере поступления и какое-то время справлялись, но в какой-то момент эта схема перестала работать.
Мы поговорили с менеджером проектов, который столкнулся с постоянными сдвигами сроков и попытался в этом разобраться. На основе его опыта написали этот материал. — Прим. ред.
Что такое ресурсное планирование
Ресурсное планирование — это процесс, который помогает понять, какие ресурсы нужны проекту, когда они доступны и хватит ли их, чтобы закончить работу в срок. В 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 дня выносят в буфер.
Менеджер следит не за тем, укладывается ли каждая задача в свою оценку, а за тем, как быстро расходуется этот буфер. Если он начинает быстро сокращаться, значит проект выходит из графика и нужно вмешаться.
Плюс — прозрачность: видно, сколько запаса времени осталось у проекта.
Минус — сложнее внедрить и есть зависимость от исполнителей, которые все равно могут неосознанно закладывать личные запасы времени, что обесценивает метод.
Как организовать процессы ресурсного планирования
Когда я более-менее разобрался в теории, оставалось понять, как внедрить планирование в реальную команду. Я поговорил с парой менеджеров, которые прошли этот путь, и собрал практические советы:
Начните с прозрачности. Создайте простую визуализацию загрузки команды в Excel на 4–6 недель вперед: кто занят, кто частично доступен, где есть пересечения. Не нужно детально расписывать все по часам — это только вызовет сопротивление. Сначала достаточно видеть общую картину.
Честно оцените трудоемкость. Не стоит планировать рабочее время на 100% задачами проекта, потому что из них 30—40% могут уходить на встречи, административные и операционные задачи.
Назначьте ответственного. Должен быть человек, который собирает требования и данные и поддерживает план актуальным. Например, это может быть руководитель проекта.
Задайте ритм пересмотра. Ресурсное планирование — это цикл, поэтому короткий еженедельный обзор загрузки и более глубокий ежемесячный пересмотр позволяют заранее увидеть перегруз и скорректировать план.
Подберите инструмент под процесс. На старте может хватить таблицы или другого простого визуального инструмента. По мере увеличения количества задач и проектов станет понятно, нужен ли инструмент, который показывает загрузку людей, пересечения и распределение часов.
Ресурсное планирование на практике
Сначала я нашел в сети шаблон для ресурсного планирования в Excel и попробовал вести в нем загрузку команды. Для 1 проекта это работало нормально, но когда я попытался контролировать 2 проекта одновременно, стало неудобно: приходилось переключаться между вкладками, сводить данные вручную и все равно держать в голове, где какой специалист занят. Стало понятно, что нужен инструмент, который покажет все это в одном месте.
Тогда начал искать подходящий инструмент, который помог бы заранее видеть конфликты ресурсов. Среди подходящих сервисов я подробнее изучил Kaiten — в нем ресурсное планирование реализовано через модуль «Гант и Ресурсное планирование», который был доступен на пробной версии. Затем купил подписку на 3 месяца, чтобы продлить тестирование и наверняка убедиться в том, подойдет нам инструмент или нет.
Что мне показалось удобным в системе:
— Загрузка каждого сотрудника считается не в рамках одного проекта, а по всем его задачам сразу. Если дизайнер участвует в двух проектах, это видно в одном месте, а не выясняется позже на планерке.
На одном экране совмещены план работ во времени и загрузка людей: слева таблица задач, справа временная шкала, снизу таблица ресурсов сотрудников
— Можно настроить реальный график работы каждого человека: частичную занятость, отпуска или нестандартное расписание. На основе этого инструмент автоматически подсвечивает перегруз, когда сотрудник выходит за пределы своей доступности.
— Модуль позволяет собирать задачи из разных пространств на единой временной шкале, планировать сроки на календарной сетке и выстраивать зависимости между задачами. Можно отмечать контрольные точки вехами проекта и детализировать крупные задачи через родительско-дочерние связи.
Все это видно на одной шкале по всем проектам сразу, что позволяет принимать решения до того, как ситуация стала критической.
Нагрузка считается автоматически, если выбрать один из 3 режимов расчета: с фиксированными трудозатратами, с фиксированной длительностью или с фиксированными трудозатратами и длительностью
Более подробно о том, как планировать проекты в Kaiten с помощью диаграммы Ганта и ресурсного планирования, написано в этой статье. — Прим. ред.
Продолжим работу в таком формате
Когда я предложил команде вести загрузку, первая реакция была предсказуемой — «еще одна табличка, которую никто не будет заполнять». И первые пару недель так и было: данные устаревали, кто-то забывал обновить статус, кто-то вписывал задачи задним числом.
Тогда мы договорились о минимальном правиле: при постановке задачи обязательно указывать примерные трудозатраты и срок. Не нужно было высчитывать все до часа — достаточно было прикинуть: «это дня на 2 работы, нужно закрыть до конца следующей недели». Когда эти данные появились, картина загрузки на ресурсном плане стала хоть на что-то похожа.
Что-то сдвинулось примерно через 3 недели. На очередной планерке мы впервые не обсуждали, почему что-то задерживается. Вместо этого смотрели на загрузку на ближайшее время недели и решали, как лучше распределить задачи.
Не скажу, что теперь все работает гладко. Оценки трудоемкости по-прежнему бывают далеки от реальности — мы стабильно недооцениваем задачи, связанные с интеграциями. План приходится обновлять вручную, и без напоминаний это делает от силы половина команды. Но разница ощутимая: за последние 3 месяца мы сдвинули дедлайн по одному проекту из пяти. До этого сдвигалось почти все.
Если пользуетесь инструментами для ресурсного плана проекта планирования ресурсов, то поделитесь своим опытом. И как сделать так, чтобы люди обновляли план в системе без постоянных пинков?