В проектном бизнесе загрузка команды часто живёт в голове руководителя. Все примерно понимают, кто занят, кто перегружен, какой проект «тяжёлый», а какой можно взять сверху. Иногда это визуализируется: линии на календарном графике, примерная степень нагрузки по каждому проекту, цветовые отметки, ручные комментарии. На небольшом объёме это работает. Но чем больше проектов, тем опаснее становится такой подход.

Однажды я разбирал задачу ведения загрузки для компании, которая: - планирует загрузку с учётом перспективных контрактов; - работы ведутся разными командами по нескольким видам деятельности; - контракты идут по 1,5-2 года и многие работы ведутся параллельно; - в компании нет исторических данных по фактическим трудозатратам.

Главный вопрос был не только в том, заняты ли сотрудники, а в том хватит ли команды через несколько месяцев, если перспективные проекты станут реальными. Для этого недостаточно просто нарисовать график. Нужна модель, которая связывает между собой проекты, сроки, роли и конкретных сотрудников.

Я пошёл от стадии пресейла.

Когда компания готовит коммерческое предложение, руководители проектов, ГИПы и непосредственные исполнители оценивают планируемые трудозатраты. Не абстрактно, а на основании опыта прошлых проектов и понимания конкретного состава работ.

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

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

Дальше эти данные можно разложить по горизонтальному календарю с учётом параллельности работ. Не просто «проект идёт с марта по август», а «в апреле у конкретного сотрудника есть нагрузка по действующим договорам и возможная нагрузка по перспективным проектам».

Так появляется не один красивый график, а инструмент для управленческих решений, через который можно увидеть: — кто станет узким местом в ближайшие месяцы; — по каким должностям может возникнуть потребность в людях; — какого рода контракты и в какие кварталы стоит усиленно искать.

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

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

Ощущение может быть правильным, но его сложно проверить. А расчётную модель можно обсуждать: почему мы считаем нагрузку именно так, почему перспективный проект нужно учитывать или пока не учитывать.

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

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

Главный вывод для меня такой: загрузку в проектном бизнесе нужно вести не только от текущих задач, но и от воронки будущих проектов. Хорошая модель загрузки отвечает также на важный вопрос: какой ресурс компании нам понадобится, если коммерческие планы действительно начнут сбываться.