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

    Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? На что компания тратит больше всего денег? Какая статья затрат является самой большой? На обслуживание какого ресурса у вас уходит больше всего денег? Не сильно ошибусь, если скажу, что ответом на все эти вопросы является “Команда компании”. Именно ваша команда делает проекты, двигает вашу компанию вперед и зарабатывает деньги, и именно на зарплаты, бонусы, налоги, оборудование рабочих мест и прочие прямые и косвенные выплаты вашей команде приходится основная масса затрат компании.


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


    Тема ресурсного планирования на удивление скудно представлена и в специализированной литературе и на пространствах рунета. Предполагается, что руководители проектов и компаний сами знают, что это такое и как с этим работать. Как показывает опыт, это немного не так. Безусловно, все понимают, что платить зарплату сотруднику, который ничего не делает — это плохо. Также плохо, когда у тебя не хватает нужных ресурсов. Но этого понимания не всегда достаточно для того, чтобы наладить в компании эффективное ресурсное планирование. И что же делать? Попробую поделиться своим пониманием вопроса.


    Свое понимание планирую изложить примерно так:


    1. Что такое ресурсный план? Тут нарисуем картинку, дадим некоторые определения и расскажем, чем люди отличаются от денег.
    2. На что влияет ресурсный план? Рассмотрим сферы деятельности IT-компаний, которые, оказывается, напрямую зависят от качества ресурсного планирования. И если у вас ресурсное планирование не осуществляется на должном уровне или вдруг у вас его вообще нет, то, может быть, после прочтения этой части у вас появятся закономерные вопросы.
    3. Что влияет на ресурсный план? Рассматриваем обратную задачу — от чего зависит ресурсный план, что стоит на входе и определяет форму, размер и специфику ресурсного плана
    4. Ресурсное планирование в рамках изолированного проекта. Это ресурсное планирование с точки зрения руководителя конкретного проекта, у которого есть понимание задачи, бюджет и нужно сформировать команду и реализовать проект. Также, тут запланирован чек-лист, пробежав по которому можно будет понять, а все ли необходимое мы включили в ресурсный план?
    5. Ресурсное планирование портфеля проектов или программы. А это уже ресурсное планирование с точки зрения программного директора, руководителя портфеля проектов, ресурсного менеджера или руководителя компании, где одновременно идет множество проектов, все они находятся на разных фазах и во всех них и требуются и высвобождаются ресурсы.
    6. Долгосрочное ресурсное планирование. Если дойдем до этого пункта, то рассмотрим задачу управления ресурсными пулами компании в долгосрочной перспективе.

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


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




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


    Если попробовать погуглить на тему resource management/resource planning tool, то вы получите довольно внушительный список платных (в большинстве своем) и бесплатных инструментов, которые в той или иной мере помогают в решении задачи управления ресурсами. Ну а мы будем пользоваться старым добрым MS Excel.


    Теперь давайте договоримся о терминах:


    • Ресурс — специалист с необходимой специализацией и опытом. Причем, под опытом понимается не только совокупное количество лет, которое человек уже успел посвятить своей профессии, но и опыт работы с конкретными проектами. Это ключевой момент и мы к нему еще вернемся.

    • Внутренний ресурсный пул — отдел или подразделение, обладающее необходимыми ресурсами, которые могут использоваться на проекте. Примеры: отдел/департамент FrontEnd, отдел/департамент QA, отдел/департамент управления проектами и т.п. По сравнению с внешними ресурсными пулами, плюсы внутренних — эффективные коммуникации, гарантированная квалификация, хорошая управляемость. Минусы — плохо масштабируются.

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

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

    • Согласованный (застафленный) ресурсный план — это контракт на поставку ресурсов требуемого качества на конкретное время с владельцами ресурсных пулов. Отличие от предыдущего варианта — все прочерки заменены на реальные имена и фамилии.

    • Стафинг — процесс подбора и согласование ресурсов на незастафленные позиции ресурсного плана. Проще говоря, стафинг — это подбор команды на проект. Тут важно отметить, что очень редко бывает, что руководитель проекта получает на свой проект сотрудников, полностью соответствующих сформулированным требованиям. Все хотят на проект команду, на 100% состоящих из сеньерных дизайнеров, разработчиков, аналитиков и тестировщиков, но не все получают такие команды. Также не всегда удается получить людей к нужному сроку или на нужное время. По-этому, план может видоизменяться по мере стафинга. Если качество ресурсов хуже того, которое закладывалось при оценке проекта, то, очевидно, увеличивается количество часов для выполнения тех же самых работ. Если нужный ресурс высвобождается с другого проекта раньше или позже, чем вы планировали, то вы фиксируете это обстоятельство и переделываете план уже с учетом новых условий.

    Так чем же люди отличаются от денег?


    Для лучшего понимания сути управления ресурсами проведем аналогию с управлением финансами:


    Деньги Ресурсы
    В моменте не хватает своих денег (например, чтобы выплатить зарплату — кассовый разрыв) — занимаем в банке или у друзей. Нужен конкретный ресурс на небольшой период времени (например, чтобы сделать срочную работу без ущерба для основного скоупа) — договариваемся “пошарить” ресурс у соседнего проекта, где ресурс недозагружен
    Есть излишек денег — кладем их в банк или инвестируем в прибыльный проект. Разработка “заблочена” длительным согласованием требований заказчиком — отдаем людей во временное пользование проекту, где они нужнее. При этом, затраты на этот период переносятся на соседний проект, экономим бюджет своего.
    На рынке появились дешевые деньги — перекредитуемся. На соседнем проекте освободились свои разработчики, стоимость которых ниже, чем используемый на нашем аутсорсный ресурс — делаем замену

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


    В мире денег, если вы возьмете в банке в долг 100 000 рублей, вы сразу же сможете их начать тратить, инвестировать и т.п. — деньги сразу же начнут работать, их не нужно учить. В мире управления ресурсами, если вы возьмете “в долг” двух разработчиков, они, как правило, не могут сразу же начать приносить пользу вашему проекту. Потому что, в отличие от денег, ценность ресурса определяется не только его квалификацией и уровнем владения тем или иным инструментом, но и знанием специфики конкретно вашего проекта. А это знание можно приобрести только находясь внутри вашего проекта, потратив определенное время на его изучение.


    Именно на эту тему часто возникают споры с заказчиком, которому нужно в кратчайшие сроки реализовать ту или иную внеплановую функцию. Как правило, риторика заказчика бывает примерно такой “В вашей компании работает ХХХ десятков/сотен/тысяч людей, добавьте еще Y на проект и сделайте, что мы хотим”. Правда заказчика в том, что да, в вашей компании, как правило, действительно достаточно много квалифицированных людей, которые могли бы сделать то, что он хочет. Но он не учитывает тот факт, что для того, чтобы приступить к реализации этих требований, квалифицированным специалистам с других проектов нужно приобрести необходимые знания о вашем проекте, а на это нужно время, которого у вас нет.


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


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

    Интересна ли тема, стоит ли продолжнать?
    • 77.4%Да, интересно, жду продолжения24
    • 3.2%Нет, все и так понятно1
    • 19.3%Мне все равно6

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

    • +8
    • 10,5k
    • 6
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 6
    • 0
      Мне кажется, Вы недоговариваете, или недооцениваете риски, которые несёт в себе привлечение ресурсов со стороны. Время на обучение вполне предсказуемо. А вот качество изменений привнесённых «не родными» участниками гораздо сложнее прогнозировать. И дело не просто в возможно меньших компетенциях, которые бы отразились только на времени-стоимости их участия. А в том что вероятность получить результат низкого качества гораздо выше, а исправление этого результата будет существенно выше и сложнее, чем в случае с использованием только постоянной команды.

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

      Конечно приведённая ситуация субъективная, и в теории можно предусмотреть разные методологии снижающие эти риски. К тому же, жираф большой, ему видней: если тот дедлайн отвечает за жизнь проекта в принципе, то в этом и может быть смысл с точки зрения продакт-менеджера. Но для объективности картины, и принятия решений не забывайте: старый конь борозды не портит, а старый друг лучше новых двух.
      • 0
        Ну, недоговаривать мне смысла нет, а насчет подсвеченных рисков — конечно, они есть. Но я весь комплекс этот рисков упаковал в формулировку «негарантированное качество ресурсов», которое, как правило, нужно компенсировать более изощренным управлением, что и отражено в «дорогое управление» и «накладные расходы на администрирование».
      • +1
        Еще одно очень важное отличие людских ресурсов от денег — это востребованность. Деньги востребованы всегда :) Если у вас образовались лишние деньги, вы тут же можете ими воспользоваться — что-то купить, инвестировать, одолжить и т.д. А вот освободившиеся с проекта ресурсы по своей технической специализации, уровню компетенции или стоимости могут оказаться невостребованными в других проектах и зависнут в ресурсном пуле, возможно на долгое время, заметно увеличивая ваши накладные расходы.
        • 0
          Все верно говорите. Это если ограничиваться жизнью внутри компании. А за ее пределами? Я понимаю, что не все компании, особенно большие и очень большие, готовы продавать свои ресурсы на открытом рынке или даже партнерам. В этом случае, обычно, спасают внутренние проекты компании, на которые просто так никто ресурсы не выделит, а вот если ресурс простаивает — пожалуйста. В таком случае это уже сложно назвать неоправданными затратами на содержание простаивающих/недозагруженных ресурсов, это уже инвестиции в свой продукт/проект.
          • 0
            Внутренние/собственные проекты лучше продажи ресурсов. У продажи голов есть только один плюс — регулярный денежный поток. Все остальное — сплошные минусы.
        • 0
          Самое интересное в ресурсном планировании — это оценка потребности в ресурсах различной специализации и уровня в условиях, когда старты и завершения проектов носят весьма вероятностный характер. Проекты в разработке софта постоянно опаздывают, соотвественно и высвобождение ресурсов задерживается на неопределенный срок. Цикл продаж также очень длинный и реальный старт проекта может откладываться по нескольку раз.
          С нетерпением жду продолжения статьи :)

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

          Самое читаемое