Общая боль руководителей при планировании работы: как равномерно распределить задачи так, чтобы проекты шли по плану, а люди не выгорали. Чаще всего причиной провалов проектов становится неэффективное управление ресурсами: кто-то «тонет» в задачах, кто-то простаивает, а самый опытный аналитик оказывается недоступен в критические моменты. Говоря о планировании и распределении ресурсов, мы в первую очередь помним, что речь идет о людях — с их уникальными навыками, усталостью, мотивацией и потребностями.
Всем привет, я Айрат Адиятуллин — руководитель отдела аналитики и внедрения BI в «БАРС Груп». В этой статье поделюсь нашим опытом перехода на data-driven подход в распределении ресурсов команды data-аналитиков. Надеюсь, будет полезным для бизнес-юнитов (у нас в компании они называются Бизнес-центры), у которых десятки проектов — от небольшого саппорта до полноценной заказной разработки. Этот подход может помочь вам управлять ресурсами команды так, чтобы она не выдыхалась и всегда была мотивированной, а задачи выполнялись в установленные сроки.
Еще это возможность максимально объективно оценить эффективность распределения аналитиков по проектам. Раньше мы этому уделяли меньше времени, в основном анализировали по окончании крупных проектов, к концу года или по запросу руководства. Подход хромал, как с точки зрения высоких трудозатрат на его сбор в ручном режиме, так и полноты картины эффективности распределения.
Как мы распределяем аналитиков на проекты
С 2023 года мы работаем на BI-платформе AW BI, которая помогает анализировать загрузку и распределение ресурсов команды на проектах с помощью сбора, обработки и визуализации данных.
У нас принята матричная структура управления командами, когда ресурсный менеджер распределяет аналитиков между проектами. Руководители этих проектов ежемесячно актуализируют ресурсный запрос на команду аналитиков в зависимости от потребностей — объема, сложности и специализации работ.
Запросы подаются в доле FTE (Full-Time Employee), где 1 = 100% ресурса аналитика на проект с перечнем задач. После ресурсный менеджер распределяет загрузку аналитиков по матрице ролей в команде в зависимости от приоритета проекта по сроку, сложности и другим параметрам.
Пример: руководитель небольшого проекта запрашивает 0.5 FTE для сбора и формализации требований. Ресурсный менеджер понимает, что эта задача бизнес-аналитика определенного грейда и после анализа доступности ресурсов бизнес-аналитиков относительно всех запросов принимает решение о выделении ресурса.
Отправная точка
Итак, пару лет назад процесс выглядел так:
Форма запросов ресурсного планирования;
13 аналитиков разных ролей от бизнес до data-science аналитиков;
~ 20-25 проектов совершенно разных проектов: как полноценные внедрения BI с DWH, так и небольшие саппорты с нестабильным потоком заявок.
Запросы от руководителей проектов все чаще составляли не полную загрузку 1 FTE, а 0.1, 0.2, 0.3 и т.д. И мы столкнулись с проблемами:
Все сложнее становилось понять, насколько запросы проектов удовлетворяются, потому что дефицит на дистанции приводил к срыву сроков на проектах.
Потерялась прозрачность распределения ресурса. Из-за большого количества задач стало сложно контролировать освоение ресурсов проектами. По этой причине руководителям проектов приходилось дублировать запросы из месяца в месяц, потому что аналитик работал над более важными задачами на других проектах, а иногда ресурсы «перезакладывались» из месяца в месяц на форс-мажорные обстоятельства, которые никак не наступали — это приводило к неэффективному использованию ресурсов команды.
Руководителям проектов в какой-то момент пришлось заниматься (неосознанным) перетягиванием ресурсов, потому что аналитик в самый нужный момент оказывался занят, хотя мог быть распределен на проект.
Распределение задач был настолько хаотичным, что некоторые сотрудники были перегружены и не всегда из-за объема задач, сколько из-за количества переключений: далеко не каждому удавалось лихо «жонглировать» проектами. К тому же ресурсы некоторых аналитиков простаивали и/или неэффективно использовались, например, если подача ресурса была с завышенными рисками.
Недостаток в прогнозировании в среднесрочной перспективе не позволял в полной мере управлять необходимой мощностью команды. К окончанию проекта всегда был некий люфт, когда аналитик еще не был распределен на другой проект и ресурс мог не использоваться в полной мере.
Нами был инициирован проект для мониторинга показателей:
Мониторинг ресурсного планирования (как раз о нем мы поговорим ниже)
Анализ производственных метрик
Анализ финансовых метрик
Были определены стейкхолдеры: ресурсный менеджер — Product Owner, директор направления и руководитель проектного офиса.
Первым делом проанализировали бизнес-процессы, влияющие на данные:
Запросы на ресурсы руководителей проектов: владелец бизнес-процесса — руководитель проектного офиса.
Распределение ресурсов аналитиков: владелец бизнес-процесса — ресурсный менеджер.
Фактический учет рабочего времени команды аналитиков: владелец бизнес-процесса — ресурсный менеджер.
Прогнозные запросы руководителей проектов: владелец бизнес-процесса — руководитель проектного офиса.
Определили ключевые аспекты TO BЕ:
Возможность оперативного мониторинга планирования (распределения) и загрузки ресурсов.
Гибкий анализ в зависимости от уровня пользователя, а также по типам проектов, по статусам с детализацией до проекта (руководителя проекта).
Самый очевидный пункт — автоматизация, которая позволит снизить трудозатраты на ручной сбор по запросу «сверху».
Источники данных:
Учет трудозатрат - task-трекер
Реестры: проектов, сотрудников (мощность команды) — внутренняя ERP
Подача запросов на ресурсы (план/прогноз) — веб-формы
Обозначали регламенты обновления данных: ежесуточно с учетом трекинга времени — в конце каждого рабочего дня. И также иметь возможность обновления данных вручную.
Метрики
Важный этап перед внедрением data-driven подхода — определиться с показателями, которые вы собираетесь анализировать. Без этого — огромные риски остаться с бесполезными (но возможно красивыми) «картинками», которые не дают пользователям бизнес-ценности = ресурсы на проект потрачены зря. Поэтому сперва методология (расчеты показателей, возможные срезы, сценарии использования), а потом реализация и обязательно все это сопровождать документацией.
Мы отобрали следующие метрики для анализа:
Удовлетворение запросов руководителей проектов: поможет понять насколько ресурсы аналитиков обеспечены объемом работ.
Положительное отклонение в соотношении «запрос—выделение» будет говорить о профиците ресурсов. В зависимости от объема профицита — позволяет
принимать решение о балансировке ресурсов — на задачи развития текущих проектов, упаковку новых продуктов или подключение на внутренние проекты компании. Отсутствие решений может привести к критичным затратам, не обеспеченным доходными сделками и/или простою ресурса.
Отрицательное отклонение подтвердит дефицит ресурсов. В зависимости от объема показателя позволит принимать решение о необходимости усиления: работа с приоритетами задач, овертаймы или привлечение внешних специалистов. Отсутствие решений может привести к срывам сроков, к незапланированным расходам, высокой нагрузке на сотрудника, демотивации команды.
Среднее значение запроса на ресурсы за период: показатель обратит внимание на среднее отклонение от общей загрузки команды.
Положительное отклонение в средне/долгосрочной перспективе сигнализирует о том, что есть потребность в оптимизации ресурсов команды. Решение при таком исходе напрямую может зависеть от наполнения портфеля проектов и его стабильности. Отсутствие решений может привести к дополнительным расходам, не обеспеченным доходными сделками.
Отрицательное отклонение в средне/долгосрочной перспективе может привести к тому, что команда будет работать на пределе неопределенный срок, что приведет к выгоранию сотрудников или увеличению сроков сдачи проектов. Отсутствие решений может привести к срывам сроков, к незапланированным расходам, высокой нагрузке на сотрудник, демотивации команды.
Освоение ресурсов
Метрика позволит определить, действительно ли запрошенные ресурсы утилизируются согласно плану. Отклонения могут говорить, как о том, что руководители проектов при подаче излишне перезакладываются и ресурсы могут неэффективно утилизироваться, так и о том, что систематические превышения могут израсходовать бюджет раньше срока исполнения обязательств. При анализе метрики важно учитывать типы проектов, потому что в некоторых ситуациях отклонение — это нормальная практика. Например, проекты поддержки зависят от количества запросов (которых иногда может не быть) пользователей.
Прогноз загрузки ресурсов
Для эффективного перераспределения ресурсов по окончанию проектов возникла необходимость в планировании ресурсов на срок до 1–2 кварталов. Такое гибкое управление ресурсами позволило бы плавно освобождать ресурсы для подключения к новым проектам или озадачиться необходимостью усиления ресурсами на рынке. Отсутствие решений также могло приводить как к простоям ресурсов, так и к тому, что проекты не будут обеспечены нужным ресурсом.
Само по себе значение метрики не раскрывает всей сути, поэтому определили пороговые значения метрик.
При удовлетворении ресурсов любое отклонение > 10% FTE в любую сторону — это тревожный знак. Отклонение 10% мощности команды, который при дефиците можно восполнить внутренними силами (например, овертаймы) или перераспределением приоритетов (например, проекты внедрения и развития в моменте приоритетнее внутренних задач развития отдела/компании). В случае профицита ресурс можно использовать для внутренних задач или предложить сотруднику небольшой отпуск. Если отклонения > 10%, то это может говорить о необходимости оптимизации (при профиците) или усилении команды (при дефиците).
При освоении ресурсов пороговое значение > 20% от выделенного ресурса — определенный маркер. Положительное отклонение говорит о неполном освоении ресурса. Это повод в будущих периодах уменьшать распределение на запрашиваемый ресурс, либо возможно не верно были расставлены приоритеты аналитиком.
Отрицательное отклонение сообщает о том, что ресурсы излишне расходуются и необходимо анализировать насколько объем работ релевантен запросу.
Метрики важны, но без анализа распределения ресурсов не получится прийти к общему знаменателю и ответить на локальные вопросы:
На каких проектах можно ожидать проблемы из за недостатка выделения ресурсов?
Рационально ли распределяются ресурсы согласно приоритетов?
Когда ожидается пиковая нагрузка на команду? А когда будет спад?
Кто «жжет» больше всех ресурсов? А кто излишне осторожничает?
Здесь мы используем реестры (справочники) в ERP-системе:
Сущность проекта и его атрибуты: наименование, тип проекта, статус проекта в воронке и др.
Бизнес-центры
Периоды — с любой гранулярностью: год, квартал, месяц, день
Руководители проектов
Документация
Так как проект внутренний, строгой документации не было — нам хотелось избежать лишней бюрократии. Для нашего кейса мы разработали глоссарий, который включает:
Терминологию (в том числе аббревиатуры, сокращения и тд). Без согласованности терминологии будет сложно говорить на одном языке
Описание базовых показателей с минимальными расчетами. Например: сумма запросов
Производные показатели с более сложными расчетами. Например: процент освоения ресурсов = Фактические затраты/Выделенные ресурсы.
Матрица аналитических задач: описание аналитических задач решаемых в рамках проектах.
Паспорт отчета: документ, который фактически объединяет два первых документа и описывает требования к реализации.
Для решения наших задач мы выбрали платформу AW BI. Функциональные характеристики, которые нам были важны:
Наличие ETL-модуля. Предстояло извлечение данных из различных источников, настройка связей между ними, обогащение данных. Понимали, что на этапе загрузки появятся проблемы с качеством данных, поэтому хотелось иметь возможность работы в self-service режиме для ускорения работы без необходимости обращения к разработчикам. Например, при анализе статусов проектов в воронке была необходимость явно выделить проекты других бизнес-центров и общехозяйственные нужды (отпуска, больничные и т.д.), потому что в доходной деятельности нашего бизнес-центра они роли не играют.
Автоматическое обновление данных. Для уменьшения трудозатрат на обновление необходимо было иметь возможность, как обновления данных «руками» так, и по планировщику.
Визуализация: линейные, столбчатые, круговые диаграммы. Хотелось иметь под рукой понятные графики для ежедневной работы, а не презентационный формат.
Фильтры данных в визуализации: изменение периода, бизнес-центра, типа проектов и т.д.
Детализация, или так называемый drill-down, для более глубокого анализа метрик. Например, от года к месяцу, от типа проекта к проекту и т.д.
Визуализация процесса на платформе
Теперь отчет по ресурсному планированию имеет визуализацию. Платформа позволяет указать фильтры по году, бизнес-центру, статусы в воронке. Ключевые метрики анализируются в разрезе статусов проектов — «Контракт» для заключенных договоров и, так называемые, pre-sale сделки для B2B проектов в зависимости от вероятности заключения сделки — от 60 до 90%.
Детализация ключевых показателей демонстрирует:
Динамику запроса по отношению к выделенному ресурсу и отклонение с условным форматированием
Покрытие потребности по статусам в воронке: сравнение запроса и выделенного ресурса, отклонение с условным форматированием в разрезе статусов в воронке и возможностью drill-down до проектов
Прогнозные запросы по типам проектов: доля прогнозных запросов в разрезе типов проектов и возможностью drill-down до проектов
Освоение выделенных ресурсов по статусам в воронке: сравнение объемов выделенного и освоенного ресурса и отклонение с условным форматированием в разрезе статусов в воронке и возможностью drill-down до проектов
Освоение выделенных ресурсов по типам проектов: сравнение выделения/освоения ресурса и отклонение с условным форматированием в разрезе типов проектов и возможностью drill-down до проектов.
Разберем один из сценариев работы с данными на платформе. C начала 2025 года соотношение выделенного и запрашиваемого ресурса был на отметке «средний дефицит» и составлял более 2,5 FTE. Тревожный знак: команде не хватает 3 человек. На короткой дистанции это может быть не так заметно, но вдолгую может привести, как к срывам сроков, так перегруженности команды. Для более детального анализа метрики посмотрим, по каким статусам проектов наибольший дефицит. График «Покрытие потребности по статусам в воронке» показывает, что это проекты в статусе «контракт» — 6,8 FTE за 4 месяца (график дает анализировать, как сумму, так и среднее значение).
Несколько проектов находится в красной зоне. Самый высокий показатель отклонения (2,3 FTE). Для кросс-фильтрации выберем этот проект и увидим, что у него несмотря на недостаток в удовлетворении ресурса по освоению ресурса, ситуация стабильная и ощутимого перерасхода нет, даже несмотря на меньшее выделение ресурса (график «Освоение выделенных ресурсов по статусам в воронке») — всего лишь 0,4 FTE за 4 месяца.
Возможно, имеет место быть излишний запрос.
После анализа дефицита ресурса на себя обращают внимание статусы по проектам с возможностью контрактования 60%, но тут все достаточно просто — вклад в будущие проекты (текущие pre-sale) важен, но при расставлении приоритетов и распределению ресурсов всегда нужно иметь в виду, что конверсия далеко не всегда 100%.
В освоение ресурсов по типам проектов рассмотрим закрытый месяц. Для этого достаточно выбрать на графике «Динамика запроса к выделенным ресурсам» один из прошедших месяцев, например, «февраль».
Здесь в критической зоне находятся контракты — выделенные ресурсы не осваиваются. По отрицательным отклонениям указываются ресурсы, которые могли быть освоены законтрактованными сделками. Большая часть приходится на внутренние проекты компании и завышенное списание на общехозяйственные расходы. Данные по внутренним проектам компании, как правило, могут быть завышены, если у аналитика на параллельных проектах есть простои — обычно мы оставляем себе 0.2–0.3 FTE сотрудника на возможные срочные задачи, но в феврале таких не оказалось. Завышенные общехозяйственные расходы связаны с незапланированным отпуском сотрудника.
Прогнозные значения по загрузке ресурсов
Прогнозное значение на ближайшие 3 месяца покрывает объем команды, при этом средний запрос скорее всего упадет почти на 3 FTE. В динамике видно, что с июня у нас будет профицит 1,55 FTE . В анализе прогнозных ресурсов также важно учитывать типы проектов: сейчас чуть более 50% ресурсов на ближайший квартал обеспечены контрактом, около 20% — идет подготовка ТЗ. В условиях, когда портфель проектов еще не доукомплектован к летнему периоду появляется возможность инициировать большую часть отпусков.
Принципы data-driven подхода
Суть data-driven подхода заключается в принятии управленческих решений на основе данных. После утверждения ключевых метрик ресурсного планирования, визуализации в BI и анализа, который был описан выше, мы приняли следующие решения:
Учитывать при распределении на конкретный проект процент освоения ресурсов за последние несколько закрытых периодов.
Если выделение ресурса стабильно выше освоения на конкретный проект, то стоит рассмотреть уменьшение количества ресурса в будущих периодах, но быть аккуратным, чтобы не пропустить проекты, в которых недостаток освоения был связан с неправильно расставленными приоритетами и объем работ все еще достаточно высокий.
Если выделение стабильно меньше освоения — провести аналитику по задачам в таск-трекере и определении того, в связи с чем перерасход. Среди причин — неверно определен объем работ при подаче ресурса или аналитик(и) не справляются с теми задачами, которые перед ними поставлены.
Точечный запрос объема работ
Запрос на ресурс аналитика сопровождается с учетом работ в рамках проекта — это позволяет избегать излишне перестраховочных запросов. Product Owner определяет насколько объем соответствует запрошенному ресурсу вместе со старшим проектным аналитиком. Совместное распределение дает более четкую схему планирования. Например, вовремя скорректировать запрос либо перенести объем на более поздний период, если сроки и приоритет проекта позволяют это сделать.
Оптимизация количества проектов на одного аналитика
Одна из причин выбросов в освоении ресурсов — высокие затраты при переключении между проектами и часто меняющимися приоритетами. Мы уменьшили нагрузку до двух проектов на аналитика. Идеальная ситуация: проект Внедрения/Развития + ГП, что позволит достаточно равномерно и стабильно распределять нагрузку.
Планирование ресурсов в зависимости от прогнозных значений
Анализ прогнозных значений на будущие проекты и окончания запросов текущих мы можем управлять потенциальным выделением ресурсов заранее.
При небольшом дефиците ресурсов мы можем заранее договориться об овертаймах с сотрудниками. В таком случае они гораздо проще воспринимаются, потому что есть возможность планирования заранее. При умеренном — возможность договориться с отделами, которые внутри компании имеют подходящие компетенции для привлечения внешних ресурсов. При высоком (например, старт проекта) — подбор нового сотрудника, при этом также нужно учитывать, что делать с распределением ресурсов после окончания проекта - возможно, нужен универсальный сотрудник с возможностью подключения к очень разному спектру задач.
При профиците ресурсов можно рассмотреть варианты с подключением к задачам отдела на описание регламентов, продвижения (реализация демо-стендов), либо отпустить сотрудника в отпуск или на развитие внутренних продуктов/проектов компании.
Что мы получили от перехода на data-driven
Избежали потенциальные затраты на подбор дефицитных FTE. Согласно отчету 2024 года, средний дефицит составлял почти 3 FTE, что приводило к мысли о необходимости усиления команды новыми ресурсами. Но благодаря анализу освоения ресурсов стало понятно, что запросы нередко были завышены, а реальный дефицит составлял сильно меньше и его удавалось компенсировать внутренними силами (мотивационная схема/овертаймы и тд). Несмотря на то, что потенциальные затраты явно не оцифровать, но их точно не стоит недооценивать. Сюда относятся время рекрутеров и руководителя отдела на десятки CV, встречи с соискателями, отбор может заметно затянуться, а при отсутствии прогнозирования запросов через пару месяцев может оказаться расходами бюджета без результата.
Оптимизировали запросы на ресурсы. Благодаря запросам объемов работ на конкретные запрошенные FTE удалось избежать лишних затрат. Мы увидели, что по некоторым проектам была возможность «сдвинуть в право» — например, плановое обновление системы на новый релиз без критичных багфиксов или отсутствия потенциальных важных фич для конкретного проекта можно «отложить» на следующий месяц, иначе обновление могло проводиться в овертаймы, что несет дополнительные затраты. При этом важно учитывать прогнозные запросы, чтоб выполнение данной задачи не стало риском закрытия обязательств, а впоследствии проблемой, потому что поддержание актуальных релизов — важная задача для оптимальной поддержки системы.
Уменьшили затраты на не законтрактованные проекты. Этап pre-sale важная часть в поддержании стабильных продаж и портфеля проектов, но без анализа запросов по статусам проектов в воронке и объема запроса есть высокие риски израсходовать бюджет без получения реальной прибыли. По некоторым подобным проектам нам удалось снизить выделение ресурсов до 50% и перераспределить команду на доходные проекты или развитие новых продуктов компании.
Повысилась эффективность команды за счет подъема мотивации команды. Наш главный ресурс — команда. Уменьшение количества переключений между проектами позитивно сказалось на работе аналитика. Затраты снизились на постоянный «поиск» контекста при переключении, аналитики все реже задаются вопросом «какая задача в данный момент важнее?». Кроме того, повысилась продуктивность за счет возможности сосредоточиться на конкретных задачах. Также за счет прогнозных запросов удалось оптимально спланировать график отпусков: теперь аналитику не приходится «потерпеть» еще немного, чтобы не сорвать сроки.
Планы
Мы получили первые положительные результаты и хотим развивать подход в других направлениях. Ресурсное планирование – это отправная точка для data-driven подхода в других процессах нашего подразделения.
Проектное управление. Процент выполнения проектов, «сгорания сроков», контроль план/факт затрат на реализацию проектов, по статьям бюджета (конкретно — ФОТ) и тд напрямую влияют на ресурсное планирование, но могут еще повысить эффективность процессов нашего отдела.
Производственные метрики. Процент попадания в оценку, закрытия спринтов, количество возвратов задач на доработку и т.д. могут нам позволить более эффективно оценить совершенство нашего процесса ресурсного планирования.
Масштабировать кейс на другие подразделения компании, где работают больше 3 000 сотрудников, десятки разных бизнес-центров. «Обкатка» на нашем небольшом подразделении могла бы помочь другим руководителям проектов повысить эффективность управления ресурсами в рамках всей компании.
Заключение
Управление ресурсами — достаточно непростой процесс, особенно для интегратора: специфика (отраслевая, организационная, управленческая и тд) проектов всегда разная, сроки сжатые (тут все как у всех). Важна универсальность компетенций аналитиков и умение быстро переключаться между проектами. Этот процесс, в котором сложно найти идеальный шаблон, по которому можно один раз настроить себе отчет и забыть об этом, поэтому мы считаем, что гибкое принятие решений на основе данных важный элемент управления командой, который призван оптимизировать процесс распределения ресурсов и сократить трудозатраты на принятие решений. Всем желаю эффективных управленческих кейсов на основе данных!
Мы в «БАРС Груп» разрабатываем цифровые решения для государства, бизнеса и людей. Принимаем активное участие в реализации Национального проекта «Цифровая экономика» и создаем цифровые решения для импортозамещения программного обеспечения – 88 решений компании зарегистрировано в реестре российского ПО. Рассказываем о наших продуктах и ИТ-трендах в Telegram-канале.
