Операционный лизинг персонала: управление пропускной способностью проектов без роста ФОТ

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

Мы в «Диасофт» решаем это через подход, который называем операционным лизингом персонала. По сути, это способ более равномерно распределять нагрузку внутри проектной работы. Не за счет перевода сотрудников между подразделениями, а за счёт того, как распределяются задачи и время внутри проектов. Как при классическом операционном лизинге: берёте в аренду не сам актив, а его мощность на нужный срок. В результате срочные задачи закрываются без переработок, без выгорания и без роста ФОТ.

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

1. Единая картина проектных задач и спроса на ресурсы

Первое, с чего начинается управляемое перераспределение ресурсов, — единый пул задач. Здесь важно видеть не только планы и отчёты, но и фактический спрос на ресурс:

• какие задачи активны сейчас;
• какие находятся в ожидании или блокировке;
• какие сроки и бизнес-эффект у каждой из них.

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

В результате высвобождаются 10–15 часов загрузки. Эти часы и становятся объектом «операционного лизинга». Ресурс перераспределяется на приоритетную задачу, не затрагивая штатное расписание.

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

2. Оценка фактических ресурсов, а не должностей

Следующий шаг — оценка доступного ресурса. Мы смотрим не на роли и позиции, а на:

• реальные компетенции;
• текущую загрузку в часах;
• наличие временных окон между задачами.

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

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

И вот здесь мы можем временно перераспределить задачи: подключить аналитиков к вспомогательным активностям разработки. Разработка ускоряется, аналитики не простаивают, ФОТ не растёт.

3. Динамическая картина загрузки и узких мест

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

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

4. Общая очередь приоритетов как механизм защиты ресурса

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

• влиянии на выручку;
• рисках для клиентов;
• стратегической значимости;
• сроках выполнения и зависимостях задач. 

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

5. Планирование пропускной способности и опережающее выравнивание

Если предыдущие этапы позволяют управлять текущей загрузкой, то этот — помогает смотреть на неё вперёд. Накопление данных по задачам и ресурсам позволяет переходить от реакции к прогнозированию:

• где и когда возникнет дефицит ресурса;
• какие команды войдут в пиковую нагрузку;
• где появятся временные окна.

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

Реализация подхода на практике

В Диасофт этот подход реализован на базе платформы Digital Q.PM. Она обеспечивает единый контур задач, загрузки и приоритетов по срокам и важности, а также фиксирует перераспределение ресурсов и позволяет принимать решения на основе фактического состояния проектной системы.

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

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

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