Ценность ресурсного планирования для IT-компании сложно подвергнуть сомнению. Ресурсные планы есть у многих. А действительно работающей системой ресурсного планирования похвалиться могут совсем немногие. Почему же? Давайте разберёмся. image


Что такое действительно работающая система ресурсного планирования?


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


  • 20-50 действующих проектов по разработке/внедрению;
  • 5-20 руководителей проектов (РП);
  • 100-300 человек в команде разработки (включаем туда всех сотрудников, кто принимает непосредственное участие в разработке и внедрении);
  • 5-10 линейных/ресурсных менеджеров/начальников отделов (РМ);
  • 2-5 сотрудников HR/рекрутёров (HR);
  • 2-7 продажников, у каждого из которых в работе от 3 до 6 потенциальных проектов (сейлы).

Тогда в работающей системе (упрощённо):


  • РП регулярно обновляет свои ресурсные планы, как с учётом отработанного факта, так и с учётом принятых запросов на изменение, прогнозов стафинга и рисков;
  • Cейлы регулярно обновляют список и вероятности заключения договоров по потенциальным проектам (пресейлы), на каждый пресейл сделана предварительная оценка, на каждый пресейл с высокой вероятностью продажи назначен РП, который регулярно обновляет ресурсные планы на эти пресейлы;
  • РМ регулярно анализируют сводную картину по своим ресурсным пулам, в короткие сроки стафит пустующие позиции, ведёт активную работу с внешними ресурсными пулами, регулярно обновляет долгосрочную потребность в ресурсах и её профиль;
  • HR регулярно получает от РМ сводную картину как по текущей, так и по долгосрочной потребности в ресурсах, от РПО (как вариант) приоритеты проектов и на основе полученной информации планирует/актуализирует планы по обучению, планы по подбору, планы работ с внешними ресурсными пулами.

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


  • реальную картину с утилизацией ресурсов (в неработающей системе очень многие РП прячут ресурсы в своих респланах и любой аналитике сложно верить);
  • достоверный прогноз по рентабельности каждого проекта, программы, компании в целом (в неработающей системе такой прогноз или совсем не считается или редко обновляется, а если и обновляется, то себестоимость проектов обычно завышена — в костах сидит много часов, которые, по хорошему, надо переносить на проект "doing nothing");
  • реальную краткосрочную и долгосрочную потребность в ресурсах и её профиль — может планировать развитие компании и бюджеты;
  • что все проекты, подготовленные для подписи, тщательно проанализированы и компания действительно знает, как и из кого будет сформирована команда проекта, и не будет запускать очередной аврал при подписании;
  • что люди в компании не перегружены и работают в оптимальном режиме, средняя себестоимость, как внутреннего, так и внешнего часа не завышена, компания не переплачивает за ресурсы;
  • что компания может себе позволить серьёзные темпы роста размера команды, количества проектов, их размеров и сложности.

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


Как обычно бывает на самом деле?


Безусловно, факторов, которые мешают работе системе ресурсного планирования, великое множество. Однако, даже если в компании все действующие лица правильно понимают всю схему и цели взаимодействия (вот поверьте мне на слово, даже это встречается не часто), нередко всё ломается/не взлетает по очень простой причине. Всё дело в ресурсных менеджерах.


Что с ними не так, спросите вы? А вот давайте разберёмся. С одной стороны, именно они должны играть ключевую роль в консолидации и валидации, стафинге респланов и планировании долгосрочной потребности на подбор для HR-службы. С другой стороны, именно ресурсные менеджеры часто работают в статусе «играющего тренера».


Если вы давно в ИТ, то наверняка слышали народную айтишную мудрость из разряда «из хорошего разраба очень быстро получается плохой лид», «из хорошего лида легко получить плохого техменеджера» и т.п. Суть везде одна и та же — при перемещении толкового сотрудника вверх по служебной лестнице, часто бывает так, что сотрудник не успевает перестроиться и по инерции или из принципа (как же я брошу кодить? Мне это так нравится/моя стоимость на рынке снизится) уделяет много времени важным на его взгляд, но не свойственным его текущей позиции активностям.


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


  • найти срочную багу на проде или обновить сводный респлан?
  • поревьювить код или проанализировать результаты работы партнёров/внешних ресурсных пулов?
  • помочь написать интересную и сложную интеграцию или обновить долгосрочную потребность в ресурсах?
  • поехать на сайт к заказчику на запуск новой версии платформы или подготовить продажу временно простаивающих внутренних ресурсов?

И, более того, если в компании на ролях ресурсных менеджеров находятся лучшие в недавнем прошлом аналитики/разработчики/QA, то кого чаще всего бросают в пекло горящего проекта? Ну конечно же руководителей отделов/ресурсных менеджеров.


Безусловно, это можно и нужно делать, но только на небольшой срок и только в виде больших исключений. Но, как пел великий современник с гитарой:


А что *** если нет?


И вот этот сценарий, по моим наблюдениям, как раз и реализуется чаще всего. Очень многие компании работают в режиме аврала большую часть времени. Ресурсные/функциональные менеджеры задействованы на одном или нескольких проектах в качестве ведущих разработчиков/архитекторов и других героических героев. И, как легко можно догадаться, на выполнение своих обязанностей ресурсного менеджера у наших героев времени просто не остаётся. По совершенно, казалось бы, объективным причинам. Что имеем в сухом остатке:


  • резко проседает качество ресурсного планирования;
  • HR-служба перестаёт понимать, что происходит и снижает качество подбора;
  • руководители проектов начинают вести между собой партизанские войны и вступать в открытые конфронтации за ресурсы;
  • стремительно увеличивается количество конфликтов за ресурсы;
  • часть ресурсов кратно перегружена, часть «спрятана» в фиктивных респланах на будущее и простаивает;
  • горизонт планирования сводной потребности в ресурсах снижается до 1-2 месяцев и менее;
  • компания начинает затыкать дыры покупкой дорогих внешних ресурсов и выплатой регулярных овертаймов измождённым сотрудникам;
  • режим аврала становится основным режимом работы компании;
  • о развитии внутренних ресурсных пулов вспоминают всё реже и реже;
  • сотрудники перестают считать такую компанию комфортным местом работы и теряют к ней лояльность;
  • акционеры недополучают свои деньги.

Я тут немного сгустил краски, но вектор развития событий вполне достоверный.


Что делать?


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


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

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


  • будут сформулированы правила и принципы ресурсного планирования в конкретной компании;
  • спроектированы и прописаны соответствующие бизнес-процессы;
  • будут разработаны метрики качества исполнения каждого этапа бизнес-процесса;
  • будут сделаны замеры текущих значений ключевых метрик;
  • будут поставлены целевые значения всех метрик;
  • будет принято решение о способе и инструментах автоматизации процессов ресурсного планирования;
  • все ключевые сотрудники компании (а не только руководители проектов) будут ознакомлены с правилами и принципами ресурсного планирования и пройдут обучение;
  • будут внесены изменения в систему мотивации участников системы ресурсного планирования;
  • будет проводиться регулярный мониторинг качества ресурсного планирования, анализ причин отклонения и внесение в систему корректирующих воздействий.

Очевидно, что успех такого проекта кратно перекроет затраты на его реализацию уже в первый год. Можно, конечно, идти и более плавным способом, шаг за шагом внося изменения в систему управления. У каждого подхода свои плюсы и минусы. Но если вы добьётесь своего и заставите правильно работать систему ресурсного планирования, то ваша компания просто перейдёт в другую лигу.


Предыдущие статьи на тему ресурсного планирования:


Ресурсное планирование. Часть 1. О чем это вообще?
Ресурсное планирование. Части 2 и 3. Что зависит от ресурсного плана. От чего зависит ресурсный план

Комментарии (2)


  1. DEM_dwg
    28.08.2019 09:40

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


  1. meranged Автор
    28.08.2019 10:10

    Оценка проектов — это отдельная большая тема. Даже если предположить, что техлид/архитектор/команда/иное, оценивающий проект, хочет это сделать максимально объективно, всегда есть внешнее давление или соблазн завысить оценки/подстраховаться. Сейлы, принимающие участие в утверждении оценок, всегда стремятся занизить оценку (снизить себестоимость, увеличить свои бонусы). И тут всегда имеет место борьба/игра. Так что тема миграции специалистов между командами, безусловно, полезна, но решающего значения при оценке проектов это иметь не будет. Нужно всё решать, опять же, проектированием правильных процессов и мотивацией.