Пока каждый проект рассматривается отдельно, его график может выглядеть совершенно реалистично. У работ есть длительности, зависимости и исполнители, даты укладываются в ожидаемый срок.
Проблема появляется, когда эти планы накладываются друг на друга. Один и тот же дизайнер оказывается нужен двум проектам в одну неделю, разработчик должен начать следующую работу до завершения предыдущей, а отпуск ключевого специалиста влияет сразу на несколько графиков.
Поэтому управление несколькими проектами требует не просто собрать их в одну папку. Нужно видеть единый портфель ограничений и рассчитывать проекты с учётом общей доступности ресурсов.
Разберём это на примере трёх проектов.
| Проект | Основная цель | Приоритет |
|---|---|---|
| Проект А | Запуск нового сайта | 1 |
| Проект Б | Обновление личного кабинета | 2 |
| Проект В | Внутренний аналитический сервис | 3 |
Во всех трёх проектах участвуют одни и те же специалисты: дизайнер Анна и разработчик Сергей.
Создайте единый контур ресурсов
Если каждый проект живёт в отдельном файле, каждый файл видит только собственные назначения.
Допустим, руководитель проекта А планирует:
| Работа | Исполнитель | Период |
|---|---|---|
| Дизайн | Анна | 7–14 сентября |
| Разработка | Сергей | 15–28 сентября |
Проект Б отдельно выглядит так:
| Работа | Исполнитель | Период |
|---|---|---|
| Дизайн интерфейса | Анна | 10–17 сентября |
| Разработка | Сергей | 22 сентября – 2 октября |
И проект В:
| Работа | Исполнитель | Период |
|---|---|---|
| Прототип | Анна | 21–24 сентября |
| Разработка прототипа | Сергей | 29 сентября – 6 октября |
В каждом отдельном проекте сотрудник назначен один раз. Поэтому локально никаких проблем не видно.
Но если объединить назначения Анны:
| Период | Проект А | Проект Б | Проект В |
|---|---|---|---|
| 7–9 сентября | Дизайн | — | — |
| 10–14 сентября | Дизайн | Дизайн интерфейса | — |
| 15–17 сентября | — | Дизайн интерфейса | — |
| 21–24 сентября | — | — | Прототип |
С 10 по 14 сентября Анна одновременно нужна двум проектам.
Поэтому первым шагом портфельного планирования является единый контур ресурсов: один сотрудник должен существовать как один ограниченный ресурс для всех проектов, а не как три независимые записи.
Подробнее о механике такой загрузки: ресурсное планирование проекта.
Зафиксируйте приоритеты
Обнаружить конфликт недостаточно. Нужно понять, что делать, когда два проекта претендуют на одного человека одновременно.
Планировщик не способен самостоятельно определить бизнес-ценность проектов. Если сайт должен быть запущен к контрактной дате, а внутренний аналитический сервис можно перенести, это управленческая информация.
Поэтому портфель должен иметь понятную модель приоритетов.
В нашем примере:
| Приоритет | Проект | Правило |
|---|---|---|
| 1 | Проект А | Ресурс получает работу этого проекта первым |
| 2 | Проект Б | Использует оставшуюся доступность |
| 3 | Проект В | Планируется после более приоритетных обязательств |
Это не означает, что низкоприоритетный проект «плохой» или необязательный. Приоритет нужен для разрешения конкуренции за ограниченный ресурс.
Например, если Анна нужна проектам А и Б одновременно, наличие приоритета позволяет построить реалистичный вариант:
- сначала завершить дизайн проекта А;
- затем продолжить дизайн проекта Б;
- пересчитать последующие даты проекта Б.
Главное — не скрывать решение за техническим алгоритмом. Руководители должны понимать, почему один проект получил ресурс раньше другого.
Если приоритеты меняются, изменится и календарный результат портфеля.
Считайте проекты вместе
После объединения ресурсов и определения приоритетов проекты можно рассматривать как связанную систему.
Посмотрим на Сергея.
| Проект | Плановая работа | Исходный период |
|---|---|---|
| А | Разработка сайта | 15–28 сентября |
| Б | Разработка личного кабинета | 22 сентября – 2 октября |
| В | Разработка прототипа | 29 сентября – 6 октября |
Если Сергей способен полноценно работать только над одним проектом одновременно, этот график невозможен.
При приоритетах А → Б → В последовательность фактически станет другой:
| Проект | Что происходит |
|---|---|
| А | Работа выполняется первой |
| Б | Стартует после освобождения Сергея |
| В | Получает ресурс после проекта Б |
После этого необходимо пересчитать не только сами ресурсные назначения, но и зависимые этапы каждого проекта.
Если разработка проекта Б началась позже, позже начнётся и его тестирование. Новая дата тестирования может пересечься уже с загрузкой тестировщика в другом проекте.
Поэтому общий расчёт может давать цепочку последствий:
Именно по этой причине недостаточно просто нарисовать сводный Гант из нескольких независимых планов. Такая диаграмма покажет пересечение, но сама по себе не сделает график выполнимым.
Если даты должны получаться из зависимостей и реальной доступности, нужен общий календарно-ресурсный расчёт.
Подробнее о календарной логике: как построить календарный план проекта.
Не скрывайте конфликт усреднением
Одна из опасных метрик портфеля — средняя загрузка команды.
Предположим, в отделе пять специалистов:
| Сотрудник | Загрузка |
|---|---|
| Анна | 160% |
| Сергей | 150% |
| Олег | 50% |
| Мария | 40% |
| Ирина | 50% |
Средняя загрузка:
На уровне отдела показатель выглядит вполне здоровым — 90%.
Но два ключевых специалиста перегружены, а свободные сотрудники не обязательно обладают нужной квалификацией для их работ.
Среднее значение скрывает локальное ограничение.
Поэтому при планировании сроков важнее видеть:
- конкретного сотрудника;
- его доступную ёмкость;
- назначения по периодам;
- проект, который создаёт нагрузку;
- место конфликта в календаре.
То же относится к загрузке за месяц.
Сотрудник может иметь среднюю месячную загрузку 80%, но быть занят на 180% в первую неделю и почти свободен в последнюю. Для проекта, который должен стартовать именно в первую неделю, среднее значение бесполезно.
Пересчитывайте сценариями
Портфель постоянно меняется. Появляется новый проект, меняются оценки, сотрудник уходит в отпуск, руководство повышает приоритет инициативы.
Если каждое изменение сразу переписывает рабочий план, руководителю трудно понять последствия решения.
Удобнее сначала построить сценарий.
Предположим, появляется новый проект Г, который должен быть запущен в октябре и требует Сергея на пять рабочих дней.
Есть несколько вариантов.
Сценарий 1. Новый проект получает высокий приоритет
Проект Г встраивается раньше Б и В. Их работы сдвигаются.
| Проект | Последствие |
|---|---|
| А | Без изменений |
| Г | Получает Сергея после А |
| Б | Сдвигается |
| В | Сдвигается ещё дальше |
Сценарий 2. Новый проект ждёт
Существующие обязательства сохраняются, но проект Г получает более позднюю дату.
Сценарий 3. Добавляется другой ресурс
Если доступен второй подходящий разработчик, можно уменьшить влияние нового проекта на существующий график.
Сценарий 4. Меняется объём
Для первой версии нового проекта оставляют только критически необходимый объём, уменьшая потребность в ограниченном специалисте.
Смысл сценария в том, чтобы увидеть результаты до принятия решения.
После выбора варианта новая конфигурация может стать согласованным рабочим планом.
Что проверять при добавлении нового проекта
- какие сотрудники ему требуются;
- когда эти сотрудники уже заняты;
- какой приоритет имеет новый проект;
- какие существующие проекты сдвинутся;
- как изменятся даты зависимых этапов;
- не появятся ли новые конфликты после пересчёта;
- можно ли изменить ресурс, объём или последовательность.
Короткий чек-лист портфельного планирования
- каждый сотрудник существует как единый ресурс для всех проектов;
- рабочие календари не дублируются независимо по проектам;
- понятен порядок приоритетов;
- проекты рассчитываются с учётом общей занятости;
- видны интервалы конфликтов;
- средняя загрузка не заменяет анализ конкретных специалистов;
- сдвиг одной работы пересчитывает зависимые этапы;
- новые проекты сначала рассматриваются как сценарий;
- решение о приоритете принимает руководитель, а не алгоритм.
Что делать дальше
Для первой проверки портфеля не нужно переносить все проекты организации. Возьмите три текущих проекта и выпишите людей, которые участвуют хотя бы в двух из них.
Затем наложите их назначения на один календарь. Обычно уже на этом этапе становятся видны периоды, в которых разные планы рассчитывают на одного и того же человека одновременно.
После этого определите приоритет проектов и попробуйте последовательно распределить ограниченный ресурс. Получившийся график может оказаться длиннее исходных независимых планов — но именно эта разница показывает скрытые обязательства, которые раньше существовали только на бумаге.
КОРДО предназначен для такого портфельного планирования: один портфель объединяет свои проекты, сотрудников и календари, чтобы сроки можно было рассматривать в общем ресурсном контуре.