Ресурсное планирование проектов: как учитывать ограниченную команду

Планы редко ломаются из-за того, что команда не знает список задач.

Гораздо чаще проблема в другом: несколько инициатив одновременно требуют одних и тех же людей.

Backend-разработчик нужен сразу трём проектам. Аналитик должен начать новую инициативу, но ещё занят текущей. QA подключается сразу к нескольким релизам. Дизайнер нужен только на несколько дней, но именно эти несколько дней блокируют следующий этап.

На уровне отдельных проектов всё может выглядеть выполнимо.

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

Именно этим занимается ресурсное планирование проектов.

Его задача — не просто распределить людей между задачами, а понять:

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

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

В простом виде ресурсное планирование — это сопоставление работ и ресурсов, необходимых для их выполнения.

В продуктовой разработке ресурсом чаще всего является человек или специализация:

• аналитик;
• backend-разработчик;
• frontend-разработчик;
• QA;
• дизайнер;
• DevOps;
• ML-инженер;
• архитектор.

Но планирование не сводится к таблице «сколько человек есть в команде».

Важно учитывать:

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

Только после этого можно говорить о реалистичных календарных сроках.

Почему одинаковая численность команды не означает одинаковую пропускную способность

Представим две команды по шесть человек.

В первой:

• два backend-разработчика;
• два frontend-разработчика;
• один аналитик;
• один QA.

Во второй:

• три backend-разработчика;
• один frontend-разработчик;
• один аналитик;
• один QA.

Формально размер одинаковый.

Но если основной поток инициатив требует много frontend-разработки, пропускная способность команд будет разной.

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

Нужно понимать структуру спроса на специализации.

В одной команде узким местом станет аналитик.

В другой — QA.

В третьей — единственный специалист по интеграциям.

Именно узкие места чаще всего определяют фактические сроки всего портфеля.

Главный вопрос: где находится ограничение

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

Проект A

Нужны:

• аналитик — 3 дня;
• backend — 8 дней;
• frontend — 5 дней;
• QA — 3 дня.

Проект B

Нужны:

• аналитик — 2 дня;
• backend — 6 дней;
• QA — 2 дня.

Проект C

Нужны:

• backend — 4 дня;
• frontend — 7 дней;
• QA — 3 дня.

Если в команде один backend-разработчик, то именно его очередь начнёт определять большую часть календаря.

Даже если аналитик и frontend свободны, проекты всё равно не смогут проходить через backend одновременно.

Поэтому при ресурсном планировании полезно искать не среднюю загрузку команды, а ресурс, который ограничивает общий поток работ.

Загрузка команды и доступность ресурса — не одно и то же

Можно сказать:

команда загружена на 80%.

Но для планирования этого недостаточно.

Средняя загрузка может выглядеть нормальной, хотя конкретный дефицитный специалист перегружен на месяцы вперёд.

Например:

• дизайнер свободен на 50%;
• frontend занят на 70%;
• аналитик занят на 90%;
• backend занят на 100% следующие шесть недель.

Среднее значение не показывает реальную проблему.

Если почти все новые инициативы требуют backend, именно он будет определять сроки.

Поэтому полезнее смотреть на доступность конкретных специализаций и людей, а не только на общий процент занятости команды.

Почему планирование в процентах часто вводит в заблуждение

В ресурсных таблицах часто встречается модель:

• 30% на проект A;
• 40% на проект B;
• 30% на проект C.

Для бюджетного или финансового планирования это может быть удобно.

Но в ежедневной разработке проценты не всегда превращаются в предсказуемый календарь.

Если специалист постоянно переключается между тремя инициативами, появляются:

• потеря контекста;
• дополнительные синхронизации;
• незавершённая работа;
• ожидание обратной связи;
• сложность определения фактической даты завершения.

Поэтому для календарного планирования часто полезнее видеть явную последовательность:

сначала этап проекта A, затем этап проекта B, затем проект C.

Это не означает, что параллельная работа всегда плоха.

Некоторые задачи действительно можно вести одновременно.

Но параллельность должна быть осознанной, а не следствием того, что один человек формально распределён на 150% будущего месяца.

Приоритеты определяют, кто получает ресурс первым

Ресурсное планирование невозможно отделить от приоритизации.

Представим, что два проекта одновременно готовы к backend-разработке.

Специалист один.

Как решить, что он делает первым?

Если заранее нет относительного приоритета инициатив, решение будет приниматься ситуативно:

• кто громче попросил;
• у кого ближе встреча;
• что проще начать;
• какая задача кажется срочнее сегодня.

Такой подход делает общий план нестабильным.

Поэтому приоритет должен иметь практический смысл:

при конфликте за ограниченный ресурс более приоритетная инициатива получает его раньше.

Это и превращает приоритет из метки в механизм планирования.

Но высокий приоритет не означает немедленный старт

Здесь важно не упростить модель слишком сильно.

Проект №1 может быть самым важным, но его следующий этап ещё не готов.

Например:

• аналитика не завершена;
• ждём внешний API;
• нужен результат предыдущего этапа;
• сотрудник ещё заканчивает критичную текущую работу.

В это время проект №2 может иметь независимый этап, который реально можно начать.

Поэтому приоритет должен определять порядок при наличии конфликта, а не блокировать всю остальную команду.

Хороший ресурсный план учитывает и важность, и фактическую готовность работ.

Зависимости меняют реальную загрузку

Представим цепочку:

аналитика → backend → frontend → QA

Frontend-разработчик может быть свободен сегодня.

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

И наоборот: пока frontend ждёт API, он может выполнять независимую работу другого проекта.

Поэтому ресурсное планирование должно учитывать не только календарь людей, но и зависимости между этапами.

Именно на пересечении двух ограничений появляются реальные даты:

• когда специалист свободен;
• когда работа готова к началу.

Как учитывать текущую работу

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

Но у неё почти всегда уже есть незавершённая работа.

Допустим, backend-разработчик занят ещё четыре дня.

Следующий проект требует семь дней.

В таком случае фраза:

backend оценил работу в семь дней

не означает:

через семь дней всё будет готово.

Сначала нужно дождаться окончания текущего этапа.

Поэтому любой новый план должен начинаться с фактического состояния:

• кто уже работает;
• над чем;
• сколько осталось;
• какие этапы после этого находятся в очереди.

И только затем добавлять новые проекты.

Как учитывать отпуска и отсутствия

Отсутствие одного специалиста может казаться локальным событием.

Но если этот человек находится на критическом пути нескольких проектов, последствия распространяются дальше.

Например:

1. Аналитик уходит в отпуск на неделю.
2. Аналитика проекта A завершается позже.
3. Backend проекта A стартует позже.
4. Backend проекта B тоже сдвигается, потому что специалист занят A.
5. QA получает обе работы позже.

Поэтому отсутствие должно быть частью календарной модели, а не примечанием в отдельном корпоративном календаре.

Если план учитывает рабочие и нерабочие дни заранее, прогноз становится значительно реалистичнее.

Как построить ресурсный план

Практический процесс можно разбить на семь шагов.

Шаг 1. Соберите все активные и запланированные инициативы

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

Нужен единый контур.

Шаг 2. Определите приоритеты

Зафиксируйте относительный порядок инициатив.

Это поможет разрешать конфликты за общий ресурс.

Шаг 3. Разложите проекты на этапы

Для каждого этапа должны быть понятны:

• содержание работы;
• длительность;
• исполнитель или специализация;
• зависимости.

Не нужно переносить каждый тикет.

Для верхнеуровневого ресурсного плана достаточно крупных осмысленных этапов.

Шаг 4. Зафиксируйте текущую занятость

Отметьте незавершённые работы.

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

Шаг 5. Добавьте отсутствия и рабочий календарь

Учитывайте:

• отпуска;
• выходные;
• праздники;
• другие заранее известные периоды недоступности.

Шаг 6. Разместите работы в календаре

При размещении учитывайте:

• приоритет;
• доступность специалиста;
• готовность предыдущих этапов;
• возможность параллельной работы.

Шаг 7. Проверьте итоговые сроки

После распределения ресурсов появляется реальная картина:

• когда начнётся каждый этап;
• где проекты ждут специалиста;
• кто является узким местом;
• когда завершится каждая инициатива.

Календарно-ресурсное планирование: почему важны оба измерения

Само слово «ресурсное» иногда заставляет сосредоточиться только на загрузке сотрудников.

Но цель не в том, чтобы красиво распределить людей.

Бизнесу нужен результат во времени.

Поэтому ресурсный план должен соединять два измерения.

Ресурсное

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

Календарное

Когда этап начнётся и закончится?

Именно поэтому полезно говорить о календарно-ресурсном планировании.

Оно связывает возможности команды с прогнозом сроков.

Как понять, что команда перегружена

Перегрузка не всегда выглядит как «у всех по 120%».

Есть более практичные признаки.

Новые инициативы постоянно ждут одного специалиста

Это явное узкое место.

Сроки меняются при каждом новом срочном запросе

Значит, запас мощности отсутствует или не отражён в плане.

Несколько проектов формально идут параллельно, но почти не двигаются

Возможно, люди слишком часто переключаются между ними.

Команда не может ответить, когда сможет взять следующую работу

Значит, нет понятной очереди ресурсов.

Roadmap регулярно переносится без явной причины

Часто причина именно в скрытых конфликтах за людей.

Что делать, если ресурсов не хватает

Ресурсное планирование полезно не потому, что автоматически создаёт дополнительные руки.

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

Вариантов несколько.

Изменить приоритет

Перенести менее важную инициативу.

Сократить объём

Уменьшить scope проекта.

Перестроить зависимости

Иногда часть работ можно начать раньше.

Добавить ресурс

Подключить дополнительного специалиста, если это действительно снимет ограничение.

Принять более поздний срок

Иногда это наиболее рациональный вариант.

Главное отличие управляемой ситуации — решение принимается до срыва, а не после него.

Почему добавление человека не всегда ускоряет проект

Если план показывает дефицит ресурса, первое желание — добавить специалиста.

Но это работает не всегда.

Новый человек может потребовать:

• onboarding;
• передачу контекста;
• доступы;
• ревью;
• помощь текущей команды.

Кроме того, ограничение может находиться не там, где кажется.

Например, можно добавить второго frontend-разработчика, но если оба всё равно ждут одного backend, общий срок почти не изменится.

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

Как работать с несколькими проектами одной командой

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

Допустим:

• проект A самый приоритетный;
• проект B уже в работе;
• проект C должен стартовать следующим.

Если проект A получает общий backend раньше, проект B может завершиться позже.

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

Поэтому план должен учитывать не только статический приоритет, но и текущее состояние работ.

Главная задача — получить общую последовательность, в которой видно:

что выполняется сейчас → что будет следующим → какой ресурс это определяет → когда закончится каждый проект.

Это гораздо полезнее, чем три независимых диаграммы Ганта.

Что происходит при изменении приоритета

Предположим, бизнес повышает проект C с третьего места на первое.

Если всем проектам нужен один backend, ресурсная очередь изменяется.

Но важно увидеть не только новую позицию C.

Нужно понять:

• какая работа будет прервана или отложена;
• когда теперь завершится A;
• когда завершится B;
• появятся ли новые конфликты у QA и frontend;
• какие обещанные сроки перестанут быть актуальными.

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

Именно тогда Product Owner понимает цену решения.

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

Есть риск уйти в противоположную крайность и начать планировать каждый час каждого сотрудника.

Для продуктового уровня это обычно избыточно.

Цель — не контролировать рабочий день человека.

Цель — понимать достаточную для планирования картину:

• какая работа закреплена за специалистом;
• сколько она примерно длится;
• что он сможет взять после;
• где появляются конфликты.

Ежедневное исполнение задач может оставаться в таск-трекере.

Ресурсный план нужен для управления потоком инициатив и сроками.

Где здесь KORDO

KORDO предназначен для планирования нескольких проектов в условиях общей ограниченной команды. Связанные разборы: управление несколькими проектами и оценка сроков разработки.

В нём этапы проектов связываются с исполнителями, оценками и зависимостями, а приоритет проектов определяет порядок получения ресурса при конфликте.

При этом учитывается текущая последовательность работ и доступность сотрудников.

Так Product Owner или руководитель получает не просто таблицу загрузки, а ответ на практический вопрос:

когда каждый проект сможет пройти через существующую команду?

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

KORDO не заменяет систему ежедневного управления задачами.

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

Главное

Ресурсное планирование проектов — это не попытка загрузить каждого сотрудника на 100%.

Его задача — сделать ограничения команды видимыми.

Практическая цепочка выглядит так:

проекты → приоритеты → этапы → ресурсы → зависимости → доступность → календарные сроки.

Если ресурсная часть отсутствует, сроки остаются пожеланиями.

Если есть только загрузка без календаря, непонятно, когда появится результат.

Исполнимый план возникает тогда, когда команда видит обе стороны одновременно:

кто сможет выполнить работу и когда это реально произойдёт.