Отпуска, командировки, больничные и другие периоды отсутствия часто учитывают уже после того, как график проекта построен. В результате план показывает работу в те дни, когда назначенный сотрудник физически недоступен.
Самая простая реакция — вручную передвинуть дату окончания этапа. Но если сотрудник участвует в нескольких проектах, такого исправления недостаточно. Сдвинувшаяся работа может занять период, который уже был обещан следующему проекту, и создать новый ресурсный конфликт.
Поэтому отсутствие лучше рассматривать не как свойство отдельной задачи, а как часть календаря доступности самого сотрудника.
Храните отсутствие отдельно от проекта
Предположим, дизайнер Анна участвует одновременно в двух проектах.
| Проект | Работа | Плановый период |
|---|---|---|
| Проект А | Дизайн сайта | 7–18 сентября |
| Проект Б | Дизайн личного кабинета | 21–30 сентября |
Теперь известно, что с 14 по 18 сентября Анна будет отсутствовать.
Если записать отпуск только внутри проекта А, второй проект об этом ничего не узнает. Но отсутствие относится не к проекту А — оно относится к Анне.
Поэтому логическая модель должна быть примерно такой:
| Сущность | Что хранит |
|---|---|
| Сотрудник | Анна |
| Рабочий календарь | Обычные рабочие и нерабочие дни |
| Отсутствие | 14–18 сентября |
| Проект А | Назначение Анны на дизайн |
| Проект Б | Следующее назначение Анны |
При расчёте оба проекта используют одну и ту же реальную доступность сотрудника.
Это особенно важно для портфеля. Если проекты ведутся в разных файлах, каждый из них может содержать собственную копию календаря сотрудника. Тогда одно изменение приходится вручную синхронизировать в нескольких местах.
Подробнее о едином контуре сотрудников: как планировать несколько проектов одновременно.
Не вычитайте дни отсутствия из оценки
Второй важный принцип — отделять объём работы от календарной доступности.
Предположим, разработчику требуется 8 рабочих дней для выполнения этапа.
Он начинает работу 7 сентября, но после трёх рабочих дней уходит в отпуск на неделю.
Оценка работы при этом остаётся прежней:
| Показатель | До отпуска | После учёта отпуска |
|---|---|---|
| Трудоёмкость этапа | 8 рабочих дней | 8 рабочих дней |
| Уже выполнено | 3 дня | 3 дня |
| Осталось работы | 5 дней | 5 дней |
| Доступность в отпуске | — | 0 |
| Календарная дата окончания | Раньше | Позже |
Отпуск не превращает восемь дней работы в пятнадцать. Он создаёт период, в котором работа не выполняется.
Смешение этих двух понятий приводит к проблемам. Если каждый отпуск увеличивает оценку задачи, становится невозможно понять, действительно ли вырос объём работы или просто изменилась доступность исполнителя.
Для календарного расчёта полезнее последовательность:
- определить оставшийся объём работы;
- найти доступные рабочие интервалы сотрудника;
- распределить работу только по этим интервалам;
- получить новую календарную дату окончания.
Подробнее о связи рабочего времени и дат: как построить календарный план проекта.
Проверяйте последующие назначения
Главная сложность отпуска появляется не в самой отсутствующей неделе, а после неё.
Вернёмся к дизайнеру Анне.
Изначально:
| Проект | Работа | План |
|---|---|---|
| А | Дизайн сайта | 7–18 сентября |
| Б | Дизайн кабинета | 21–30 сентября |
Теперь добавим отсутствие с 14 по 18 сентября.
До отпуска Анна успевает выполнить только часть работы проекта А. Остаток переносится на период после возвращения.
Получается новый график:
| Период | Что происходит |
|---|---|
| 7–11 сентября | Проект А |
| 14–18 сентября | Отпуск |
| с 21 сентября | Оставшаяся работа проекта А |
Но именно 21 сентября должен был начаться проект Б.
Так одно отсутствие создаёт уже не просто сдвиг проекта А, а конфликт между двумя проектами.
Теперь руководителю нужно принять решение:
- сначала завершить проект А и сдвинуть Б;
- переназначить остаток работы;
- частично изменить объём;
- пересмотреть приоритет проектов;
- принять изменение обеих дат.
Поэтому после добавления отсутствия недостаточно проверить только ту работу, на которую оно непосредственно попало.
Нужно посмотреть:
- новую дату окончания текущего этапа;
- зависимые работы этого проекта;
- следующее назначение того же сотрудника;
- следующие проекты;
- новые конфликты других ресурсов после сдвига.
Это тот же каскадный эффект, который возникает при любом ресурсном ограничении.
Подробнее: как обнаруживать ресурсные конфликты до срыва срока.
Не переписывайте прошлое
Особенно интересная ситуация возникает, когда отсутствие стало известно уже после публикации плана.
Предположим, 1 сентября был согласован план:
| Показатель | Опубликованный план |
|---|---|
| Старт дизайна | 7 сентября |
| Окончание дизайна | 18 сентября |
| Запуск проекта | 15 октября |
5 сентября стало известно, что дизайнер будет отсутствовать с 14 по 18 сентября.
Можно просто открыть старый план и заменить даты. Но тогда теряется история:
- какая дата была согласована первоначально;
- почему она изменилась;
- когда возникло новое ограничение;
- каков был эффект решения.
Более управляемый подход:
- сохранить исходную опубликованную версию;
- добавить фактическое новое ограничение;
- выполнить новый расчёт;
- получить сценарий изменений;
- сравнить его с согласованным планом;
- после решения опубликовать новую версию.
Например:
| Показатель | Было | Стало |
|---|---|---|
| Окончание дизайна | 18 сентября | 25 сентября |
| Начало разработки | 21 сентября | 28 сентября |
| Запуск проекта | 15 октября | 23 октября |
Тогда руководитель может объяснить изменение:
Это намного полезнее, чем видеть только последнюю дату без причины.
Такой подход применим не только к отпускам. Аналогично можно работать с новой оценкой, изменением зависимости, переносом старта и другими существенными изменениями.
Учитывайте разные календари
Не все сотрудники работают по одинаковому календарю.
Даже внутри одной компании могут отличаться:
- рабочие дни недели;
- сменные графики;
- частичная занятость;
- региональные нерабочие дни;
- индивидуальные интервалы доступности;
- даты начала и окончания работы в компании.
Поэтому одного общего календаря проекта может быть недостаточно.
Рассмотрим условный пример:
| Сотрудник | График | Особенность |
|---|---|---|
| Анна | Пн–Пт | Полная занятость |
| Сергей | Пн–Пт | Доступен проекту на 50% |
| Мария | Вт–Сб | Другой набор рабочих дней |
Если этап требует Анну и Марию, одинаковая дата в календаре не обязательно является рабочей для обеих.
Поэтому расчёт должен учитывать календарь назначенного ресурса, а не только абстрактный календарь проекта.
Какие отсутствия имеет смысл учитывать
Не обязательно превращать проектный план в кадровую систему. Для расчёта важны интервалы, которые реально меняют доступность ресурса:
- отпуск;
- подтверждённая командировка;
- плановый период отсутствия;
- частичная недоступность;
- другие заранее известные ограничения рабочего времени.
При этом чувствительные кадровые детали планировщику обычно не нужны. Для расчёта достаточно знать сам интервал недоступности и его влияние на рабочее время.
Что происходит с частичной доступностью
Отсутствие не всегда означает 0%.
Например, сотрудник может быть доступен проекту только половину рабочего дня.
| Параметр | Значение |
|---|---|
| Трудоёмкость | 5 человеко-дней |
| Доступность | 50% |
| Ориентировочная календарная длительность | около 10 рабочих дней |
Опять же, объём работы остаётся пять человеко-дней. Меняется скорость использования доступной ёмкости.
Чек-лист учёта отсутствий
- отсутствие хранится у сотрудника, а не только внутри одного проекта;
- все проекты используют одну доступность ресурса;
- отпуск не изменяет трудоёмкость работы;
- работа распределяется только по доступному рабочему времени;
- после сдвига проверяется следующее назначение сотрудника;
- пересчитываются зависимые этапы;
- значимое изменение не уничтожает предыдущую версию плана;
- при необходимости учитывается частичная доступность;
- для разных сотрудников могут применяться разные рабочие календари.
Что делать дальше
Для быстрой проверки своего плана выберите одного сотрудника, который участвует сразу в нескольких текущих проектах.
Нанесите на одну временную шкалу его проектные назначения и известные периоды отсутствия. Затем проверьте не только работы, попадающие непосредственно на отпуск, но и первое назначение после возвращения.
Если сдвинувшаяся работа занимает период следующего проекта, вы обнаружили ресурсный конфликт, который отдельные проектные планы могли не показывать.
КОРДО предназначен именно для такого календарно-ресурсного расчёта: сотрудники, их календари, отсутствия и назначения рассматриваются в общем контуре портфеля.