
Ресурсное планирование проекта: команда, загрузка и распределение ресурсов
Ресурсное планирование проекта — это процесс определения того, какие ресурсы (люди, оборудование, материалы) потребуются проекту, в каком объёме и в какие сроки, а также распределение этих ресурсов между задачами с учётом их доступности и загрузки. Результат — план ресурсного обеспечения проекта, который связывает задачи с конкретными исполнителями, позволяет выявить дефицит и конфликты ресурсов до начала работ и служит основой для планирования сроков.
Что такое ресурсное планирование проекта
Ресурсное планирование проекта — это совокупность процессов, в ходе которых определяется потребность проекта в ресурсах, оценивается их доступность, распределяются ресурсы между задачами и выстраивается система их использования на протяжении всего жизненного цикла.
Проще говоря, ресурсное планирование отвечает на четыре вопроса:
- Какие ресурсы нужны? (люди с нужными компетенциями, оборудование, материалы)
- В каком объёме? (часы работы, количество единиц, объём материалов)
- Когда они нужны? (привязка к расписанию проекта)
- Откуда их взять? (штатные сотрудники, подрядчики, закупки, аренда)
Логика ресурсного планирования
Потребность проекта → Роли → Доступность → Capacity → Распределение → Проверка загрузки → Дефицит → Выравнивание → Ресурсный план
Важно различать три понятия:
- Ресурсное планирование — до и в процессе проекта: сколько ресурсов потребуется, когда они потребуются и как их распределить.
- Управление ресурсами — во время проекта: что делать, если доступность, приоритеты или состав команды изменились.
- Учёт трудозатрат — фиксация факта: сколько времени реально потрачено на задачи.
Зачем нужно ресурсное планирование
Без ресурсного планирования проект сталкивается с классическими проблемами: ключевые специалисты перегружены, нужные люди отсутствуют в нужный момент, оборудование простаивает или, наоборот, требуется, но его нет, а сроки срываются из-за того, что задачи некому выполнять.
Ресурсное планирование проекта позволяет:
- Заранее выявить дефицит ресурсов и найти решение до начала работ.
- Избежать перегрузки ключевых специалистов.
- Связать расписание проекта с реальной доступностью команды.
- Обосновать потребность в найме, подрядчиках или закупках.
- Распределить задачи между исполнителями с учётом их компетенций.
- Управлять многопроектной загрузкой в организации.
- Снизить риски срыва сроков из-за нехватки ресурсов.
Какие ресурсы нужны проекту
Ресурсы проекта — это всё, что необходимо для выполнения работ и достижения результата.
Основные виды ресурсов
| Вид ресурсов | Примеры | Особенность планирования |
|---|---|---|
| Трудовые (людские) | Разработчики, дизайнеры, аналитики, тестировщики, PM | Оцениваются в часах/днях, зависят от доступности и компетенций |
| Материальные | Оборудование, сырьё, комплектующие, строительные материалы | Требуют закупок, имеют сроки поставки |
| Оборудование и техника | Серверы, станки, транспорт, измерительные приборы | Оцениваются в единицах времени использования |
| Помещения и инфраструктура | Переговорные, рабочие места, лаборатории, площадки | Ограничены физически, требуют бронирования |
| Финансовые | Бюджет проекта, резервы | Оцениваются в денежном выражении |
| Информационные | Доступы, лицензии, документация, базы знаний | Требуют подготовки и предоставления |
| Внешние ресурсы | Подрядчики, консультанты, поставщики | Зависят от контрактов и сроков поставки |
По характеру ограничения
| Тип | Пример |
|---|---|
| Ограниченные по доступности | Специалисты, оборудование, переговорные |
| Потребляемые | Материалы, комплектующие |
| Финансовые | Бюджет, финансирование |
| Внешние | Подрядчики, поставщики |
| Информационные | Доступы, лицензии, документация |
Как определить состав команды проекта
Команда — главный ресурс большинства проектов. Планирование команды начинается задолго до старта работ.
Шаги планирования команды
- Определите необходимые роли и компетенции
На основе WBS (иерархической структуры работ) определите, какие специалисты нужны проекту.
Пример:
| Задача WBS | Необходимые роли | Требуемые компетенции |
|---|---|---|
| Проектирование архитектуры | Системный архитектор | Опыт работы с микросервисами, AWS |
| Разработка backend | Backend-разработчик | Python, FastAPI, PostgreSQL |
| Разработка frontend | Frontend-разработчик | React, TypeScript |
| Тестирование | QA-инженер | Автотесты, API-тестирование |
| Управление проектом | Project Manager | Agile, опыт в IT-проектах |
- Оцените потребность в ресурсах
Для каждой задачи определите трудозатраты и распределите их по времени.
Пример:
| Роль | Общая потребность | Период использования | Интенсивность |
|---|---|---|---|
| Архитектор | 80 часов | Месяцы 1–2 | 50% загрузки |
| Backend-разработчик | 320 часов | Месяцы 2–5 | 100% загрузки |
| Frontend-разработчик | 240 часов | Месяцы 3–5 | 100% загрузки |
| QA-инженер | 160 часов | Месяцы 4–6 | 75% загрузки |
| PM | 480 часов | Месяцы 1–6 | 100% загрузки |
- Определите источники ресурсов
- Штатные сотрудники — доступны, но могут быть заняты на других проектах.
- Подрядчики и фрилансеры — требуют времени на поиск и онбординг.
- Аутсорсинг — подходит для стандартизированных задач.
- Найм — требует времени и бюджета, но даёт долгосрочный ресурс.
- Составьте матрицу компетенций
Матрица компетенций помогает увидеть, кто в команде какими навыками обладает, и выявить пробелы.
Пример матрицы:
| Сотрудник | Python | React | AWS | DevOps | Тестирование |
|---|---|---|---|---|---|
| Иванов А. | ●●● | ○ | ●● | ○ | ○ |
| Петров Б. | ●● | ●●● | ○ | ○ | ● |
| Сидорова В. | ● | ●● | ●●● | ●● | ○ |
| Козлов Г. | ○ | ○ | ● | ●●● | ●●● |
●●● — эксперт, ●● — уверенный пользователь, ● — базовые знания, ○ — нет компетенции.
Как распределить роли и ответственность
Одна из главных проблем проектов — размытая ответственность. Когда «все отвечают за всё», по факту не отвечает никто.
Матрица RACI — инструмент распределения ответственности между участниками проекта.
Расшифровка ролей:
- R (Responsible) — непосредственно выполняет работу.
- A (Accountable) — несёт итоговую ответственность и принимает результат. На одну задачу желательно назначать одного A.
- C (Consulted) — консультирует, чьё мнение запрашивается.
- I (Informed) — получает информацию о результате.
Пример матрицы RACI:
| Задача | PM | Архитектор | Backend | Frontend | QA | Заказчик |
|---|---|---|---|---|---|---|
| Утверждение ТЗ | A | C | I | I | I | R |
| Проектирование архитектуры | A | R | C | I | I | I |
| Разработка API | A | C | R | I | I | I |
| Разработка UI | A | I | I | R | I | C |
| Тестирование | A | I | C | C | R | I |
| Приёмка результата | A | I | I | I | C | R |
Как рассчитать потребность в ресурсах
После определения состава команды и ролей необходимо детально оценить потребность в ресурсах для каждой задачи.
Методы оценки
- Оценка снизу вверх
Каждая задача WBS оценивается отдельно, затем результаты суммируются. Самый точный, но трудоёмкий метод.
- Экспертная оценка
Привлекаются опытные специалисты, которые оценивают потребность на основе своего опыта.
- Аналоговая оценка
Используются данные похожих завершённых проектов.
- Параметрическая оценка
Используются статистические зависимости (например, стоимость за строку кода, часы на 1 м² площади).
Формула расчёта потребности
Потребность в ресурсах = Трудозатраты задачи / Доступность ресурса
Пример:
- Задача: разработка модуля, 120 часов работы.
- Разработчик доступен на 80% (20% — митинги, обучение, другие проекты).
- Рабочая неделя: 40 часов.
- Доступное время в неделю: 40 × 0,8 = 32 часа.
- Длительность выполнения: 120 / 32 = 3,75 недели ≈ 4 недели.
Capacity: сколько ресурсов реально доступно
Capacity (ёмкость) — это максимальный объём работы, который ресурс может выполнить за определённый период с учётом его доступности.
Расчёт capacity
Шаг 1. Определите номинальную ёмкость
Стандартная рабочая неделя: 40 часов.
Шаг 2. Учтите доступность
Вычтите:
- Регулярные митинги и стендапы
- Обучение
- Административные задачи
- Работу на других проектах
Шаг 3. Рассчитайте проектный capacity
Пример расчёта недельного capacity:
| Параметр | Значение |
|---|---|
| Номинальная рабочая неделя | 40 часов |
| Регулярные митинги | −4 часа |
| Обучение | −2 часа |
| Работа на другом проекте (20%) | −8 часов |
| Проектный capacity в неделю | 26 часов |
Если сотрудник отсутствует (отпуск, больничный):
Если сотрудник отсутствует одну неделю, за месяц доступно не четыре, а три рабочие недели:
26 × 3 = 78 часов вместо 104 часов.
Work vs Duration vs Availability
Важно различать три понятия:
| Показатель | Что означает | Пример |
|---|---|---|
| Work (Трудоёмкость) | Сколько работы требуется | 120 часов |
| Availability (Доступность) | Сколько времени ресурс доступен | 50% (20 часов/неделю) |
| Duration (Длительность) | Сколько календарного времени займёт задача | 6 недель |
Пример:
- Трудоёмкость задачи: 120 часов
- Специалист доступен на 50% (20 часов/неделю)
- Длительность: 120 / 20 = 6 недель
Важно: 120 часов работы не означают, что задача займёт 3 недели. Если специалист доступен только на 50%, календарная длительность увеличивается.
Целевая загрузка
На практике часто оставляют резерв capacity и не планируют сотрудника на 100% доступного времени. Конкретный целевой уровень зависит от роли, типа работы и количества неплановой нагрузки. Например, команда может использовать ориентир 70–85%, но это не универсальный норматив.
Главное правило: плановая потребность не должна систематически превышать доступную ёмкость ресурса.
Как сопоставить потребность и capacity
После расчёта потребности и capacity необходимо сопоставить их и выявить дефицит или избыток ресурсов.
Demand vs Capacity
| Ресурс | Потребность (Demand) | Capacity | Дефицит/Избыток |
|---|---|---|---|
| Backend-разработчик | 420 ч | 320 ч | −100 ч (дефицит) |
| Frontend-разработчик | 240 ч | 320 ч | +80 ч (избыток) |
| QA-инженер | 180 ч | 240 ч | +60 ч (избыток) |
| Системный аналитик | 160 ч | 120 ч | −40 ч (дефицит) |
Вывод: Backend-разработчик и аналитик имеют дефицит, а Frontend и QA — свободную ёмкость, которую можно перераспределить.
Многопроектная загрузка
Когда сотрудник работает сразу на нескольких проектах, необходимо учитывать суммарную загрузку.
Пример:
| Проект | Плановая загрузка |
|---|---|
| Проект А | 50% |
| Проект Б | 30% |
| Проект В | 25% |
| Итого | 105% |
Формально каждый проект укладывается в доступность сотрудника, но суммарная загрузка составляет 105%. Такой план невыполним без изменения сроков, приоритетов или состава ресурсов.
Решение: использовать централизованное ресурсное планирование на уровне организации, чтобы видеть загрузку всех сотрудников по всем проектам и избегать перегрузок.
Как выявить дефицит и конфликт ресурсов
Что такое дефицит ресурсов
Дефицит ресурсов — ситуация, когда потребность проекта в ресурсах превышает их доступность.
Причины дефицита:
- Недостаточное количество специалистов нужной квалификации.
- Ключевые сотрудники уже заняты на других проектах.
- Ограниченное оборудование или помещения.
- Бюджет не позволяет нанять нужных подрядчиков.
- Сезонные факторы (отпуска, праздники).
Что такое конфликт ресурсов
Конфликт ресурсов — ситуация, когда один и тот же ресурс одновременно требуется нескольким задачам или проектам.
Виды конфликтов:
- Внутрипроектный — один сотрудник назначен на несколько параллельных задач.
- Межпроектный — сотрудник нужен одновременно в нескольких проектах.
- Временной — ресурс нужен в период, когда он недоступен (отпуск, командировка).
Как устранить дефицит и конфликты
Если ресурсов не хватает, есть три основных пути:
- Перераспределить работы
- Resource leveling (выравнивание ресурсов) — перераспределение задач с учётом доступности ресурсов. Может сдвигать сроки проекта.
- Resource smoothing (сглаживание ресурсов) — оптимизация загрузки в пределах существующих сроков, без изменения критического пути.
- Увеличить доступную ёмкость
- Добавить ресурсы (найм, подрядчики).
- Развить компетенции существующих сотрудников (cross-skilling).
- Уменьшить загрузку на других проектах.
- Изменить сроки или содержание
- Перенести задачи на более поздний срок.
- Сократить scope проекта, отказавшись от низкоприоритетных задач.
- Для сокращения сроков иногда используют fast-tracking, выполняя отдельные работы параллельно, если это допустимо.
Мини-алгоритм принятия решений при дефиците
Не хватает ресурса →
├── Можно ли перенести задачу?
├── Можно ли перераспределить её на другого сотрудника?
├── Есть ли свободный сотрудник с нужными компетенциями?
├── Можно ли привлечь подрядчика?
├── Можно ли обучить другого сотрудника?
├── Можно ли сократить scope?
└── Можно ли увеличить срок?
Как связать ресурсы со сроками проекта
Расписание проекта должно учитывать не только логическую последовательность задач, но и реальную доступность ресурсов.
Как связать расписание с ресурсами
- Постройте календарь доступности
Отметьте отпуска, больничные, праздники, корпоративные мероприятия, периодические недоступности.
- Определите зависимости по ресурсам
Некоторые задачи не могут начаться, пока не освободится нужный специалист.
- Проверьте загрузку ключевых ресурсов
Постройте ресурсную гистограмму — график загрузки каждого ресурса во времени.
- Выявите перегрузки
Если загрузка превышает capacity — это сигнал к перепланированию.
- Скорректируйте расписание
Используйте методы выравнивания и сглаживания ресурсов.
Визуализация загрузки ресурса
Пример ресурсной гистограммы для Backend-разработчика:
Capacity: 26 ч/неделю

На этой гистограмме видно, что в неделе 5 разработчик перегружен (32 часа при capacity 26 часов/неделю). Это сигнал к перепланированию.
Пример ресурсного плана проекта
Рассмотрим пример ресурсного плана для проекта «Разработка мобильного приложения».
Шаг 1. Есть потребность
| Роль | Потребность |
|---|---|
| Backend-разработчик | 380 часов |
| Frontend-разработчик | 240 часов |
| iOS-разработчик | 320 часов |
| QA-инженер | 200 часов |
Шаг 2. Есть capacity
| Роль | Capacity (4 месяца) |
|---|---|
| Backend-разработчик | 320 часов |
| Frontend-разработчик | 320 часов |
| iOS-разработчик | 320 часов |
| QA-инженер | 240 часов |
Шаг 3. Получаем дефицит
| Роль | Потребность | Capacity | Дефицит |
|---|---|---|---|
| Backend-разработчик | 380 ч | 320 ч | −60 ч |
| Frontend-разработчик | 240 ч | 320 ч | +80 ч |
| iOS-разработчик | 320 ч | 320 ч | 0 |
| QA-инженер | 200 ч | 240 ч | +40 ч |
Вывод: Backend-разработчик имеет дефицит 60 часов. Frontend и QA имеют свободную ёмкость.
Шаг 4. Варианты решения
- Привлечь второго backend-разработчика.
- Передвинуть часть задач на более поздний срок.
- Привлечь подрядчика на 60 часов.
- Сократить scope проекта.
- Увеличить длительность проекта.
Шаг 5. Что выбрали
Решение:
- 40 часов переданы второму разработчику (привлечён подрядчик на 2 месяца).
- 20 часов перенесены на следующий спринт (увеличена длительность на 1 неделю).
Итоговый ресурсный план
| Роль | М1 | М2 | М3 | М4 |
|---|---|---|---|---|
| Backend (основной) | 80 ч | 120 ч | 120 ч | — |
| Backend (подрядчик) | — | 40 ч | — | — |
| Frontend | — | — | 120 ч | 120 ч |
| iOS | — | 160 ч | 160 ч | — |
| QA | — | — | 100 ч | 100 ч |
| Роль | Дополнительный спринт | Итого |
|---|---|---|
| Backend (основной) | 20 ч | 340 ч |
| Backend (подрядчик) | — | 40 ч |
| Frontend | — | 240 ч |
| iOS | — | 320 ч |
| QA | — | 200 ч |
Проблема решена: в исходном четырёхмесячном окне основной backend-разработчик выполняет 320 часов в пределах своей capacity, подрядчик берёт 40 часов, а оставшиеся 20 часов переносятся в дополнительный спринт. Общая потребность в 380 часов закрыта без перегрузки основного разработчика.
Инструменты ресурсного планирования
| Инструмент | Для чего | Когда использовать |
|---|---|---|
| Матрица компетенций | Визуализация навыков команды | При формировании команды |
| Матрица RACI | Распределение ответственности | При назначении задач |
| Ресурсная гистограмма | Визуализация загрузки во времени | При проверке загрузки |
| Календарь доступности | Учёт отпусков, больничных, событий | При планировании сроков |
| Capacity-план | Расчёт доступной ёмкости ресурсов | При оценке потребности |
| Диаграмма Ганта с ресурсами | Связь задач и ресурсов во времени | При составлении расписания |
| Реестр ресурсов | Учёт всех ресурсов проекта | На протяжении всего проекта |
| Система управления проектами | Комплексное управление ресурсами | Для средних и крупных проектов |
Типичные ошибки ресурсного планирования
- Планирование без учёта реальной доступности. Закладывается 100% загрузка без учёта митингов, отпусков, переключений.
- Игнорирование многопроектной загрузки. Сотрудник назначен на 3 проекта по 100% — физически это невозможно.
- Зависимость от единственного специалиста. Если ключевой специалист заболеет или уволится, проект встанет.
- Планирование без матрицы компетенций. Назначение задач без учёта реальных навыков исполнителей.
- Отсутствие резерва на ресурсы. Нет плана на случай болезни, увольнения или задержки подрядчика.
- Планирование в отрыве от расписания. Ресурсы назначены, но не привязаны к конкретным датам.
- Игнорирование контекстных переключений. Сотрудник работает на 5 проектах одновременно — эффективность падает.
- Отсутствие регулярного контроля загрузки. Загрузка не отслеживается, перегрузки обнаруживаются постфактум.
Чек-лист ресурсного планирования
Перед стартом проекта проверьте:
- Определены все необходимые роли и компетенции
- Составлена матрица компетенций команды
- Потребность в ресурсах оценена для каждой задачи WBS
- Рассчитан capacity каждого ресурса с учётом доступности
- Распределение задач оформлено через матрицу RACI
- Сопоставлена потребность и capacity (Demand vs Capacity)
- Выявлены дефициты и конфликты ресурсов
- Разработан план устранения дефицита (найм, подрядчики, cross-skilling)
- Учтены отпуска, праздники, корпоративные события
- Заложен резерв на непредвиденные обстоятельства
- Ресурсный план связан с календарным планом проекта
- Построена ресурсная гистограмма
- Учтена многопроектная загрузка сотрудников
- Определён порядок контроля загрузки в ходе проекта
FAQ: Частые вопросы о ресурсном планировании
Что такое ресурсное планирование проекта?
Это процесс определения потребности проекта в ресурсах (люди, оборудование, материалы), оценки их доступности, распределения между задачами и контроля использования на протяжении всего жизненного цикла проекта.
Чем ресурсное планирование отличается от учёта трудозатрат?
Ресурсное планирование — это планирование будущего: сколько ресурсов понадобится и как их распределить. Учёт трудозатрат — это фиксация факта: сколько времени реально потрачено на задачи.
Какие ресурсы бывают в проекте?
Трудовые (люди), материальные (сырьё, комплектующие), оборудование, помещения, финансовые, информационные и внешние ресурсы (подрядчики, поставщики).
Что такое capacity ресурса?
Capacity (ёмкость) — максимальный объём работы, который ресурс может выполнить за период с учётом его реальной доступности. Рассчитывается как номинальное рабочее время минус митинги, обучение, другие проекты.
Как избежать перегрузки сотрудников?
Планировать загрузку с учётом реальной доступности, использовать ресурсные гистограммы для визуализации, выявлять конфликты ресурсов на этапе планирования, применять методы выравнивания (resource leveling).
Что делать, если нужного специалиста нет в команде?
Варианты: нанять нового сотрудника, привлечь подрядчика или фрилансера, использовать аутсорсинг, развить компетенции существующих сотрудников (cross-skilling), пересмотреть скоуп проекта.
Как учитывать многопроектную загрузку?
Суммировать загрузку сотрудника по всем проектам, не допускать суммарной загрузки более 100% capacity, использовать централизованный ресурсный пул на уровне организации, применять приоритизацию проектов.
Что такое матрица RACI?
Инструмент распределения ответственности: R (Responsible) — исполнитель, A (Accountable) — ответственный, C (Consulted) — консультант, I (Informed) — информируемый. Помогает избежать размытия ответственности.
Как связать ресурсное планирование с расписанием проекта?
Построить календарь доступности ресурсов, учесть зависимости по ресурсам, проверить загрузку ключевых специалистов, использовать ресурсную гистограмму для выявления перегрузок, при необходимости скорректировать расписание.
Что такое resource leveling и resource smoothing?
Resource leveling — перераспределение задач с учётом доступности ресурсов, может сдвигать сроки проекта. Resource smoothing — оптимизация загрузки в пределах существующих сроков без изменения критического пути.
Нужен ли резерв на ресурсы?
Да. Резерв закладывается на случай болезни, увольнения, задержки подрядчиков, роста объёма работ. Фиксированный процент не является универсальным правилом. Размер резерва зависит от критичности проекта, доступности специалистов, взаимозаменяемости команды и неопределённости работ.
Как понять, хватает ли ресурсов на проект?
Сопоставить потребность (demand) и доступную ёмкость (capacity) по каждому ресурсу. Если потребность превышает capacity — есть дефицит, который нужно устранить до начала работ.
Итог
Ресурсное планирование проекта — это не просто назначение исполнителей на задачи. Это системный процесс, который связывает содержание проекта с реальными возможностями команды и организации.
Ключевые принципы эффективного ресурсного планирования:
- Планируйте заранее. Выявляйте дефицит и конфликты до начала работ, а не в процессе.
- Учитывайте реальную доступность. Capacity — это не номинальные 40 часов в неделю, а реальное время, доступное для проекта.
- Не перегружайте команду. Оставляйте резерв capacity, не планируйте сотрудника на 100% доступного времени.
- Распределяйте ответственность чётко. Используйте матрицу RACI, чтобы каждый знал свою роль.
- Развивайте cross-skilling. Снижайте зависимость от единственного специалиста.
- Связывайте ресурсы с расписанием. План без привязки к датам — не план.
- Контролируйте загрузку регулярно. Ресурсная гистограмма должна обновляться в ходе проекта.
- Учитывайте многопроектную загрузку. Суммарная загрузка сотрудника не должна превышать 100% capacity.
Правильно выстроенное ресурсное планирование — это инвестиция в предсказуемость проекта. Оно позволяет избежать срыва сроков из-за нехватки людей, снизить риск выгорания команды и обеспечить проект нужными ресурсами в нужный момент.
Планируйте ресурсы проекта в едином пространстве
Когда задачи, исполнители, загрузка и расписание находятся в одном месте, управление командой становится значительно проще. Интабия Платформа позволяет связать все аспекты ресурсного планирования в едином рабочем пространстве.
- ✅ Трекер задач
- ✅ Документы и база знаний для хранения ресурсных планов
- ✅ Корпоративный чат для координации команды
- ✅ Хранение данных в РФ, обработка персональных данных с учётом требований 152-ФЗ
- ✅ Бесплатно для команд до 5 человек
Создать рабочее пространство и начать ресурсное планирование →




