Ресурсное планирование. Часть 1. О чем это вообще?
Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? На что компания тратит больше всего денег? Какая статья затрат является самой большой? На обслуживание какого ресурса у вас уходит больше всего денег? Не сильно ошибусь, если скажу, что ответом на все эти вопросы является “Команда компании”. Именно ваша команда делает проекты, двигает вашу компанию вперед и зарабатывает деньги, и именно на зарплаты, бонусы, налоги, оборудование рабочих мест и прочие прямые и косвенные выплаты вашей команде приходится основная масса затрат компании.
Если в нужный момент у вас будет недостаточное количество вашего ключевого ресурса, то вы не сможете сделать важный проект и упустите выгоду. А если у вас будет избыток ресурсов, то вы будете нести убытки, оплачивая простаивающую часть вашей команды. Поговорим о ресурсном планировании.
Тема ресурсного планирования на удивление скудно представлена и в специализированной литературе и на пространствах рунета. Предполагается, что руководители проектов и компаний сами знают, что это такое и как с этим работать. Как показывает опыт, это немного не так. Безусловно, все понимают, что платить зарплату сотруднику, который ничего не делает — это плохо. Также плохо, когда у тебя не хватает нужных ресурсов. Но этого понимания не всегда достаточно для того, чтобы наладить в компании эффективное ресурсное планирование. И что же делать? Попробую поделиться своим пониманием вопроса.
Свое понимание планирую изложить примерно так:
- Что такое ресурсный план? Тут нарисуем картинку, дадим некоторые определения и расскажем, чем люди отличаются от денег.
- На что влияет ресурсный план? Рассмотрим сферы деятельности IT-компаний, которые, оказывается, напрямую зависят от качества ресурсного планирования. И если у вас ресурсное планирование не осуществляется на должном уровне или вдруг у вас его вообще нет, то, может быть, после прочтения этой части у вас появятся закономерные вопросы.
- Что влияет на ресурсный план? Рассматриваем обратную задачу — от чего зависит ресурсный план, что стоит на входе и определяет форму, размер и специфику ресурсного плана
- Ресурсное планирование в рамках изолированного проекта. Это ресурсное планирование с точки зрения руководителя конкретного проекта, у которого есть понимание задачи, бюджет и нужно сформировать команду и реализовать проект. Также, тут запланирован чек-лист, пробежав по которому можно будет понять, а все ли необходимое мы включили в ресурсный план?
- Ресурсное планирование портфеля проектов или программы. А это уже ресурсное планирование с точки зрения программного директора, руководителя портфеля проектов, ресурсного менеджера или руководителя компании, где одновременно идет множество проектов, все они находятся на разных фазах и во всех них и требуются и высвобождаются ресурсы.
- Долгосрочное ресурсное планирование. Если дойдем до этого пункта, то рассмотрим задачу управления ресурсными пулами компании в долгосрочной перспективе.
Что такое ресурсный план?
Для затравки приведу пример ресурсного плана
На примере мы видим ресурсный план для условного проекта вместе с финансовой информацией и некоторой аналитикой. В зависимости от уровня доступа руководителя проекта и специфики внутренних процессов, ресурсный план может видоизменяться в широких пределах. В частности, убрав зарплаты и часовые ставки, можно ограничиться только планированием человеко-часов.
Если попробовать погуглить на тему resource management/resource planning tool, то вы получите довольно внушительный список платных (в большинстве своем) и бесплатных инструментов, которые в той или иной мере помогают в решении задачи управления ресурсами. Ну а мы будем пользоваться старым добрым MS Excel.
Теперь давайте договоримся о терминах:
- Ресурс — специалист с необходимой специализацией и опытом. Причем, под опытом понимается не только совокупное количество лет, которое человек уже успел посвятить своей профессии, но и опыт работы с конкретными проектами. Это ключевой момент и мы к нему еще вернемся.
Внутренний ресурсный пул — отдел или подразделение, обладающее необходимыми ресурсами, которые могут использоваться на проекте. Примеры: отдел/департамент FrontEnd, отдел/департамент QA, отдел/департамент управления проектами и т.п. По сравнению с внешними ресурсными пулами, плюсы внутренних — эффективные коммуникации, гарантированная квалификация, хорошая управляемость. Минусы — плохо масштабируются.
Внешний ресурсный пул — компания или специалисты, внешние по отношению к компании, которая реализует проект, которые имеют необходимые ресурсы и готовы предоставлять их проекту во временное пользование. Примеры: сайты фрилансеров, компании, специализирующиеся на аутсорсе, партнерские компании с временно недозагруженными ресурсами. Плюсы по сравнению с внутренними ресурсными пулами: отлично масштабируются. Минусы: сложность коммуникаций, дорогое управление, негарантированное качество ресурсов, стоимость, накладные расходы на администрирование.
Несогласованный (незастафленный) ресурсный план — это заявка на ресурсы для выполнения проекта. Такой ресурсный план говорит о том, какие ресурсы, когда, в каком количестве и на какой период нужны вам для того, чтобы вы успешно выполнили свой проект. При этом, вместо имен и фамилий в таком плане стоят прочерки или пробелы — реальных людей еще нет, вы их только хотите получить. Пока вы только можете определить требования к специалистам, которые вам нужны, и, может быть, сформулировать пожелания к ресурсным менеджерам относительно конкретных кандидатур, которых вы хотели бы видеть у себя на проекте. Некоторые позиции, конечно же, могут быть уже “застафлены” — прописаны конкретные имена людей, в отношении которых вы уже имеете подтверждение об их участии в вашем проекте.
Согласованный (застафленный) ресурсный план — это контракт на поставку ресурсов требуемого качества на конкретное время с владельцами ресурсных пулов. Отличие от предыдущего варианта — все прочерки заменены на реальные имена и фамилии.
Так чем же люди отличаются от денег?
Для лучшего понимания сути управления ресурсами проведем аналогию с управлением финансами:
| Деньги | Ресурсы |
|---|---|
| В моменте не хватает своих денег (например, чтобы выплатить зарплату — кассовый разрыв) — занимаем в банке или у друзей. | Нужен конкретный ресурс на небольшой период времени (например, чтобы сделать срочную работу без ущерба для основного скоупа) — договариваемся “пошарить” ресурс у соседнего проекта, где ресурс недозагружен |
| Есть излишек денег — кладем их в банк или инвестируем в прибыльный проект. | Разработка “заблочена” длительным согласованием требований заказчиком — отдаем людей во временное пользование проекту, где они нужнее. При этом, затраты на этот период переносятся на соседний проект, экономим бюджет своего. |
| На рынке появились дешевые деньги — перекредитуемся. | На соседнем проекте освободились свои разработчики, стоимость которых ниже, чем используемый на нашем аутсорсный ресурс — делаем замену |
Этими кейсами аналогия не исчерпывается. Общая подмеченная закономерность — почти в каждом случае управления ресурсами можно найти аналогию из управления финансами и наоборот. Однако, между деньгами и ресурсами есть очень существенная разница, которая определяет специфику этой предметной области.
В мире денег, если вы возьмете в банке в долг 100 000 рублей, вы сразу же сможете их начать тратить, инвестировать и т.п. — деньги сразу же начнут работать, их не нужно учить. В мире управления ресурсами, если вы возьмете “в долг” двух разработчиков, они, как правило, не могут сразу же начать приносить пользу вашему проекту. Потому что, в отличие от денег, ценность ресурса определяется не только его квалификацией и уровнем владения тем или иным инструментом, но и знанием специфики конкретно вашего проекта. А это знание можно приобрести только находясь внутри вашего проекта, потратив определенное время на его изучение.
Именно на эту тему часто возникают споры с заказчиком, которому нужно в кратчайшие сроки реализовать ту или иную внеплановую функцию. Как правило, риторика заказчика бывает примерно такой “В вашей компании работает ХХХ десятков/сотен/тысяч людей, добавьте еще Y на проект и сделайте, что мы хотим”. Правда заказчика в том, что да, в вашей компании, как правило, действительно достаточно много квалифицированных людей, которые могли бы сделать то, что он хочет. Но он не учитывает тот факт, что для того, чтобы приступить к реализации этих требований, квалифицированным специалистам с других проектов нужно приобрести необходимые знания о вашем проекте, а на это нужно время, которого у вас нет.
Отсюда вывод — при управлении ресурсами всегда нужно помнить о том, что вновь добавленный ресурс, каким бы квалифицированным он не был, потребует определенного времени на погружение в проект и только потом начнет приносить результат. Время, которое требуется на погружение, зависит от квалификации ресурса, степени его знакомства с предметной областью и проектом, информационной инфраструктуры проекта и наличия людей рядом, которые смогут в доступной форме рассказать про проект и показать, как он устроен.
На этом с первой частью закончим. В следующей части поговорим о том, на что влияет ресурсный план и качество ресурсного планирования.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Источник
6 важных моментов, которые надо учесть при планировании ресурсов в компании
Директор по производству «Технократии» Игорь Котов рассказывает, на что нужно обратить внимание при улучшении такого рабочего процесса, как планирование ресурсов.
В каждой небольшой компании наступает момент, когда количество проектов и сотрудников вырастает до такого количества, что уже сложно удержать в голове кто чем занимается. Если у вас компания ориентирована на заказную разработку небольших проектов, то ситуация становится особенно острой, так как в таких условиях изменения происходят достаточно часто. Сегодня я расскажу, что можно сделать в первую очередь для того, чтобы начать планировать ресурсы или улучшить существующий процесс.
Невозможно добиться эффективного планирования, если разработчиков дёргают несколько человек, а приоритеты меняются на ходу. На первых годах жизни компании нет смысла нанимать отдельного человека. Все менеджеры делят функции между собой. Так что таким ресурс-менеджером может стать любой человек, осведомленный в проектах.
Однако стоит осторожно передавать эту функцию менеджеру проектов. Если он работает не один на этой позиции, то конфликт интересов неизбежен, так как он заинтересован в первую очередь закрыть свои проекты.
У вас может не быть ещё плана «на бумаге», но собираться и проговаривать загрузку вы наверняка уже начали. Проводите их регулярно и с необходимой частотой. Здесь всё зависит от количества проектов и размеров команды, но, думаю, раз в неделю (в начале или конце) будет идеальным вариантом для большинства. Необходимо сделать это привычкой, как чистка зубов.
Даже если проекты у вас долгие, а команды небольшие, за неделю обычно происходит достаточно событий, чтобы проект успел свернуть не туда и требуется корректировка плана.
Это может быть маркерная доска, табличка в Excel, страничка в блокноте, как угодно. Ваши договоренности должны быть записаны. К ним необходимо будет возвращаться и память начинает подводить всех, что провоцирует споры и конфликты. Данный пункт звучит очень очевидно, но также очевидно, что в начале своего пути не все так делают. Поэтому выберите удобную для себя форму и начните это делать.
Творческая работа, а разработка ПО включает в себя творчество, не может нормироваться точными цифрами. Для оценки проекта, отдельного спринта или каждой задачи разработчик может высказать предположение о сроках, которые, в зависимости от опытности сотрудника, будут иметь большую или меньшую вероятность.
Поэтому и при планировании учитывайте реальное рабочее время в течение дня (спойлер: никто не работает 8 часов из 8), коэффициенты рисков, багфикса и прочие моменты. Так ваш план будет реалистичнее и даст вам представление о том, когда тот или иной сотрудник действительно может освободиться.
Те договорённости, что вы обсудили на планерке должны стать внутренним документом, который будет доступен всем заинтересованным лицам. Их, как раз, вам и следует определить. Мы в компании изначально планировали и делились планами только с менеджерами проектов. Сильно позже, когда команда выросла, мы добавили весь состав управления и тимлидов. По понятным причинам не надо открывать план на всю компанию, если вы хотите, чтобы разработчики отвечали за свои сроки, а менеджеры проектов имели возможности управлять рисками.
Разработка программного обеспечения – процесс с высокой степенью энтропии. Оценки, которые дают разработчики, не всегда сбываются, а функционал имеет обыкновение меняться. Помимо этого, работа с людьми — это всегда человеческий фактор. Так что будьте готовы к тому, что план поменяется, но от этого работа не должна вставать. У ресурс-менеджера всегда должны быть варианты, как поступить: подключить кого-то на овертайм, перераспределить людей с других проектов, подключить субподряд и т.д. Продумайте их заранее и настройте процессы для экстренного реагирования.
Эти простые и для кого-то очевидные пункты помогут вам начать системную работу по планированию ресурсов и сделать процесс более прозрачным для остальных. Если у вас есть предложения, какие еще практики стоит применять или вы не согласны с моими, пишите свое мнение в комментариях.
Сейчас мы разрабатываем внутренний менеджер ресурсов, который пока носит простое название RMS — Resource Manager System. Прототип его дизайна уже есть на Behance. Обо всех его фичах расскажем в ближайшее время, а пока вы можете подписаться на наш телеграм-канал, где мы публикуем новости из мира ИТ и обсуждаем интересные инфоповоды.
Источник