Дорожная карта развития ресурсного планирования

Мы активно развиваем ресурсное планирование в Timetta, и пора поделиться, каким мы видим конечный результат.

Первое крупное изменение уже запланировано на май — https://www.getTimetta.ru/blog/novye-vozmozhnosti-planirovanie-i-uchet-rabochego-vremeni-po-rolyam. Цель обновления — упорядочивание работы с ролями, универсальными ресурсами, планирование и учет рабочего времени в разрезе ролей.

Следующие релизы ожидаются в течение ближайших месяцев.

Один в поле не воин

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

Для цифровизации управления проектами, в том числе в консалтинге, требуется несколько разнородных компонент:

1. Учетная система. Цель — управленческий учет, планирование и контроль. Владельцы такой системы — менеджеры всех уровней. В нашем случае такая система — это Timetta.
2. Система организации потока работ. Цель — оперативное планирование, постановка и контроль исполнения задач. Для гибкого управления проектам — это основная система, в том числе, например, реализующая agile-подходы.
3. Система объемно-календарного планирования. Цель — спланировать работы на весь проект, определить связи между задачами и пр. Требуется не всегда, в том числе ввиду внедрения гибких методов управления проектами.
4. Документооборот, мессенджеры и онлайн коммуникации и т. д.

Timetta не стремиться решить все эти задачи, он реализует учетную функцию. При этом интеграция между системами не должна становиться самоцелью.

Надо общаться

Мы исходим из того, что в компании активно развиты коммуникации. Timetta не стремиться бюрократизировать процесс и исключить человеческое общение, напротив, мы полагаем, что только личное общение позволяет работать эффективно.

Например, у нас нет инструментов, позволяющих менеджеру проекта формально и «в системе» сообщить команде, какие работы запланированы. Мы считаем, что «цифры» ничего не скажут, а команде надо собираться, проговаривать задачи и добиваться единого понимания.

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

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

Целевой бизнес-процесс

Для начала взглянем на целевой процесс планирования проекта в целом.

• PM (Project Manager) — проектный менеджер.
• RM (Resource manager) — ресурсный менеджер.

Если в компании выделятся ресурсный менеджер, который централизованно принимает запросы на выделение и бронирование ресурсов, то схема выглядит следующим образом:

Описание шагов процесса:

1. Создаем команду проекта. Команда может состоять из универсальных ресурсов (ролей) или пользователей. Если в команду включаются пользователи, то менеджер проекта может сразу забронировать их емкость и отдельное согласование с ресурсным менеджером не потребуется.
2. Создаем задачи проекта. Обычно менеджер проекта задает основные этапы проекта, в разрезе которых будет планировать работы.
3. Формируем ресурсный план. Планируем потребность проекта по задачам и временным слотам (дням, неделям или месяцам).
4. Формируем требование ресурсов. Для каждого универсального ресурса в команде создается отдельная сущность — запрос ресурсов. Запрос фиксирует: необходимый для бронирования объем часов, роли и навыки ресурсов, предпочитаемые для назначения работники и пр. Запрос можно отправить на исполнение ресурсному менеджеру.
5. Подбор команды. Ресурсный менеджер получает запрос, подбирает пользователей, бронирует их емкость и закрывает потребность.
6. Корректировка плана. Забронированная емкость и состав команды после отработки требований могут отличаться от первоначального плана. Необходимо выполнить согласование забронированной и запланированной на проекте емкости.
7. Готовим бюджет. На основании ресурсного плана формируем бюджет проекта.

Важно отметить:

1. Уже поле этапа (3) можно сформировать оценочный бюджет. Себестоимость работ будет базироваться на ставках себестоимости ролей, но этого достаточно для оценки проекта в целом и, возможно, подготовки предложения клиенту.
2. Если в компании нет функции ресурсного менеджера, то подбор ресурсов из требования может сделать менеджер проекта самостоятельно. Подобная децентрализованная схема гибче, однако не подходит для больших команд.

Запрос ресурсов

Запрос создается для универсальных ресурсов (членов команды без назначенных пользователей) и используется для описания потребности:

1. Необходимой емкости.
2. Требуемых навыков.
3. Списка предпочитаемых ресурсов (конкретных работников) и пр.

Основные возможности:

• Запрос создается из команды проекта.
• В запрос «копируется» данные из ресурсного плана, а при закрытии запроса фиксируется забронированная (на момент закрытии) ёмкость. Тем самым в истории остаются сведения «сколько запрошено» и «сколько выделено».
• Запрос ресурсов может быть в состоянии: «В работе», «Отменено» и «Обработано».
• Запрос можно поместить в очередь исполнения.
• Запрос отправляется на исполнение ресурсному менеджеру, который для его закрытия должен подобрать ресурсы и выделить (забронировать) их емкость.
• В интерфейсе приложения «Ресурсы» доступен список всех запросов.

Немного визуализации интерфейса подбора ресурсов:

1. Строка запрошенного ресурса.
2. Индикатор «Уже забронировано -> Всего надо забронировать».
3. Подобранные ресурсы и забронированная по ним емкость.
4. Детальный фильтр для поиска ресурсов.
5. Найденные ресурсы.
6. Емкость, которую еще можно забронировать.

После закрытия требования есть два сценария:

1. Если был подобран один ресурс, то запрашиваемый универсальный ресурс будет удален из команды, а все назначения на задачи перейдут к подобранному ресурсу.
2. Если подобрано более одного ресурса, то универсальный ресурс не удаляется и все назначения сохраняются. Такое поведение необходимо, поскольку невозможно определить правило для перераспределения назначений и эту работу должен выполнить менеджер проекта.

Ресурсный план проекта

Ресурсный план в карточке проекта также претерпит изменения. Прежде всего появится группировка по задачам и появится секция «Отклонение от бронирования».

Немного визуализации (конечный UI может отличаться):

1. Секция «Отклонение от бронирования» показывает разницу между забронированной емкостью и запланированной ниже.
2. Забронированные ресурсы.
3. Остаток емкости, т. е. разница между распределенной (выделенной) на проект емкостью и уже запланированной емкость. Если значение положительное — еще есть емкость для планирования, отрицательное — перебор.
4. Секция «План» используется, собственно, для планирования.
5. Структура задач проекта.
6. Запланированная емкость (в часах, FTE или %% от расписания).

Заключение

Мы описали изменения в общих чертах, не перегружая текст деталями и подробностями реализации. Важно, что мы опираемся на практический опыт наших клиентов, поэтому всегда рады обратной связи. Если у вас есть идеи, предложения и пожелания — пишите нам.