В продолжение первой вводной части рассмотрим сразу две важных темы. С одной стороны, эти темы больше отношения имеют к управлению программой проектов или компанией в целом, чем к управлению отдельно взятым проектом. С другой стороны, понимание конкретным руководителем проектов роли ресурсного планирования в ключевых процессах компании существенно облегчают его коммуникации с руководством и делают неуместными дискуссии относительно необходимости ресурсного планирования и качества ресурсных планов.
Что зависит от ресурсного плана?
Да, ресурсное планирование — не самая творческая задача и актуализация ресурсного плана многими воспринимается, как неизбежное зло. Но давайте разберёмся, зачем мы должны тратить столько времени на раскрашивание табличек в экселе, перенос и проверку актуальных часов из таймшитов в ресурсный план и планирование часов на оставшуюся часть проекта с учетом дефицита сотрудников, форс-мажорами у клиента и нового, согласованного скоупа.
- Корректность расчета маржинальности проекта и финансовый план. В каждой компании планируют финансы. Доходная часть компании — это прибыль проектов. Если проекты будет менее прибыльным, чем это прогнозировалось при его старте, компания недополучит денег, на которые рассчитывала. Хорошо, если речь идёт только о незначительном изменении премиального фонда или акционерного дохода. А если компания живет на заемные деньги? Тогда компания будет вынуждена ещё больше переплачивать за банковский процент и снижать свою прибыль. И даже если ресурсный план сделан, наоборот, с запасом и по факту себестоимость проекта в месяц меньше запланированной — это тоже плохо. Особенно, если компания живет на все те же заемные деньги и вынуждена оплачивать стоимость денег, которые не будут востребованы.
- Своевременность закрытия открытых позиций в команде проекта. Это — самое очевидное последствие корректного и не очень корректного планирования. Тут все просто — заблаговременно сделал реалистичный ресурсный план — дал возможность ресурсным менеджерам и HR хорошо подготовиться к своему проекту и подобрать нужных специалистов. А вот если план нереалистичный, в него постоянно вносятся изменения или он вообще появляется на свет перед самым стартом проекта, то шансов своевременно получить полностью укомплектованную команду почти нет. А если проект важный и приоритетный, то такие планы ещё и по карману компании сильно бьют — мы вовремя не можем набрать правильных людей, начинаем с недостафленной командой, сроки начинают ехать, люди постоянно овертаймят и мы сразу же обременяем проект ненужными рисками.
- Загрузка HR-службы. Что получает в работу HR? Вернее, не так. Что должен получать в работу HR? В правильных компаниях HR получает в работу результат анализа сводных ресурсных планов ресурсным менеджерами в виде плана неудовлетворенной потребности в тех или иных специалистах. Можно, конечно, ориентироваться на чутьё директора или мнение некоторых ресурсных менеджеров, но анализ и оптимизация ресурсных планов — самый простой и понятный способ. При таком подходе и HR понимает, над чем он работает, видя сводную картинку по всем проектам, и ресурсные менеджеры видят ресурсные риски проектов и имеют возможность готовить альтернативные варианты на случай, если HR не успевает. А как он будет успевать, если вакансии генерятся в режиме “срочно”, “завтра”, “эскалация” и т.п? Конечно, никак. Корректные и своевременные ресурсные планы всех спасут.
- Загрузка АХО. Чтобы новые сотрудники своевременно получили оборудование, для них были подготовлены рабочие места, отдел АХО должен видеть план набора персонала в деталях. В деталях потому что требования к рабочему месту дизайнера и разработчика как правило разные. А план набора — это первая производная от сводного ресурсного плана. Вообще, в этом пункте вместо АХО можно было поставить любое обслуживающее подразделение — финансы, бухгалтерию, транспортный отдел и т.п.
- Размер и комфортность офиса. Если компания переживает активные период в своей жизни и либо активно растёт, либо оптимизируется, ресурсное планирование приобретает особенно важное значение. И риски тут вполне осязаемые. Компания либо вынуждена часто менять офис, либо переплачивать за неиспользуемые площади.
- Оптимальность использования ресурсов. К этому пункту мы ещё вернёмся, когда будем рассматривать ресурсное планирование отдельно взятого проекта. Но если коротко коснуться этого пункта, то получить один и тот же результат можно разными способами. Можно нарисовать такой ресурсный план, что часть сотрудников будет недозагружена (оплачиваем часы простоя), а часть — перегружена (оплачиваем переработки по двойному тарифу). Для того, чтобы таких ситуаций избегать, ресурсные планы оптимизируются как на уровне руководителя конкретного проекта, так и на уровне руководителей программ и ресурсных менеджеров.
- Эффективность работы компании в целом. Вывод, который напрашивается сам собой — компания, где хорошо поставлено ресурсное планирование, с большой долей вероятности является эффективной компанией. И наоборот — если ресурсное планирование хромает, то компания постоянно испытывает то дефицит, то избыток ресурсов и себестоимость человеко-часа, по сравнению с компанией первого типа, при прочих равных существенно выше. А, значит, ниже прибыль, которую можно было бы направить на развитие компании со всеми вытекающими.
Неплохо, да? Оказывается, ресурсный план влияет едва ли не на всё в IT-компании, да ещё как влияет!
Теперь рассмотрим обратную задачку и попробуем разобраться, от чего зависит ресурсный план и его качество?
От чего зависит ресурсный план?
Давайте подумаем, какие у нас должны быть вводные для того, чтобы мы сделали хотя бы первую версию ресурсного плана. Основные вводные, очевидно, это оценка (в виде work breakdown structure) трудоемкости, сроки, сложность и связность работ, бюджет и delivery methodology. Все остальное, как правило, можно учесть в виде поправок к ресурсного плану. Итак, давайте рассмотрим, как каждый из этих и некоторых других пунктов влияет на ресурсный план.
- Корректность первоначальной оценки основного скоупа. Подробнее эту тему мы рассмотрим чуть позже, но давайте уже сейчас задумаемся, а на основе чего вообще мы делаем ресурсные планы? Наверное, если совсем грубо, то будет что-то вроде “берём трудоемкость проекта, берём длительность проекта, группируем работы по типам исполнителей и вычисляем необходимое количество исполнителей каждого типа и сроки занятости на проекте”. В реальной жизни все гораздо сложнее, но что остаётся неизменным, так это прямая зависимость качества ресурсного плана от качества оценки трудоёмкости. Да, можно сделать плохой ресурсный план на основе хорошей оценки, но никому не под силу сделать хороший ресурсный план, если на вход поступила неверная оценка трудоемкости. Ошибки в оценке трудоёмкости проекта, как правило, выливаются или в значимые переработки или в срыв сроков. Ни то ни другое не является тем, что радует руководителя проекта и акционеров компании.
- Корректность и реалистичность сроков проекта. Частенько бывает так, что заказчик ставит очень жесткие сроки исполнения работ. Как правило, чтобы подстраховаться и иметь запас времени на случай, если что-то пойдёт не так. В общем случае работает правило: “сокращение сроков можно компенсировать дополнительными исполнителями”. Однако, это правило работает в очень небольшом диапазоне сроков и при ряде условий. А с определенного момента все начинают вспоминать про девять женщин и вероятности рождения ими ребёнка за один месяц. На эту темы можно долго рассуждать, но пока можно констатировать, что сокращение сроков проекта (при заданной трудоёмкости) приводит не только к увеличению количества исполнителей, но и к увеличению накладных расходов (как минимум речь идёт о дополнительных тимлидах и усложнению системы управления) на управление проекта. Что, разумеется, должно найти своё отражение в ресурсной плане.
- Delivery methodology. Тут все просто — работаем ли мы по одной из гибких методологий, классическому или итерационному водопаду, каждая методология требует определенной структуры и логики управления проектом, что выражается в разном объёме управленческих оверхэдов, структуре команды и конфигурации ресурсного плана.
- Сложность и связность работ. На самом деле, в большинстве случаев невозможно сделать качественный ресурсный план без предварительного анализа структуры работ и выявления зависимостей между компонентами проекта. Наглядной и типичной иллюстрацией этого утверждения служат проекты трансформации существующих информационных систем. В составе таких проектов почти всегда присутствует такая замечательная вещь, как миграция данных из легаси-систем в новую. Особенно, если имеет место многоступенчатая миграция с многочисленными промежуточными этапами по обогащению и улучшению качества данных. Наличие такой красоты накладывает жёсткие требования на очередность, сроки реализации и внедрения связанных системных компонентов. И в этом случае ресурсное планирование нужно уже проводить с четким пониманием выявленных взаимозависимостей.
- Бюджет. Оставить разработку внутри компании, отдать на аутсорс или сделать комбинированную команду. Можете вы позволить себе купить высокопроизводительных профессионалов или работаете с теми, кто есть. Первые сделают заданный объём работ гораздо быстрее и с лучшим качеством — соответственно, потратят меньше часов. Однако, если наш горизонт планирования превышает сроки одного проекта и наша задача растить свой пул профессиональных разработчиков, то даже если бюджеты и позволяют, есть большой смысл ставить в пару к сеньерным разработчикам начинающих. Да, для того, чтобы они получали необходимый опыт на реальных проектах путём увеличения себестоимости конкретного проекта. Однако, зачастую, это единственный способ вырастить из начинающих специалистов настоящих профессионалов. В любом случае, размер бюджета является одним из определяющих факторов при выборе команды и ресурсном планировании.
- Наличие в контракте гарантийных обязательств. Об этом этапе работ очень многие забывают. Зачастую ресурсное планирование заканчивается этапом сдачи системы в рабочую эксплуатацию. А то, что потом ее ещё год нужно обслуживать по гарантии — этого нет ни в ресурсное плане, ни в расчете экономики проекта. На самом деле такой подход правомерен только если мы ожидаем заключения отдельного контракта на техническую поддержку. В любом другом случае отсутствие ресурсов, предусмотренных для осуществления гарантийного сопровождения, будет ошибкой, которая усложнит жизнь ресурсным менеджерам, сделает неверным финансовый прогноз и исказит экономические параметры проекта.
- Универсальность членов команды. Очень важный аспект. Если пофантазировать и представить, что проект укомплектован универсальными бойцами, каждый из которых умеет и проектировать архитектуру новых компонентов и оценивать трудоёмкость разработки и вести разработку как на уровне фронта, так и на уровне серверов приложений и баз данных, и писать тест-кейсы и тестировать и делать деплой и писать релиз-ноутсы и все это с высоким качеством и с хорошей скоростью, то это будет просто команда-мечта. И ресурсный план для такой команды будет выглядеть очень просто — берём количество часов и равномерно распределяем их между всеми членами команды. В реальности мы вынуждены учитывать ограничения, которые накладывают на ресурсное планирование конкретные скилсеты членов проектной команды.
- Качество и подход к управлению изменениями. Это отдельная и очень большая тема. Хорошо, если вы живете в рамках одной из гибких методологий, которые, как известно, приветствуют изменения. Но если вы живёте в вотерфолле или только делаете вид, что живёте в эджайле, то управление изменениями — это один из ключевых навыков руководителя проекта. Или чейндж-менеджера, если мы говорим о программе или большом проекте. На этапе ресурсного планирования очень важно понимать, под какой объём изменений заранее зарезервировать ресурсы, какие ресурсы резервировать, в какой период эти ресурсы будут задействованы и т.п.
- Распределенность команды. Как правило, производительность команды, которая находится в одной локации (а лучше — в одной комнате), будет существенно превышать производительость той же самой команды, но члены которой распределены по нескольким локациям. Вроде и люди те же самые и на зарплаты тратим примерно столько же, но производительность команды существенно ниже. При ресурсном планировании очень важно понимать, какая команда будет делать проект, насколько она распределена и можно ли её собирать в одном месте в критические для проекта моменты.
- Возможность совместного использования ресурсов. Если мы говорим не об изолированном проекте, а, скажем, о программе, где можно шарить ресурсы с коллегами с соседних проектов, то условия ресурсного планирования становятся гораздо комфортнее — у вас появляется возможность планировать ½, ⅓, ¼ FTE (full time employee), так как остальное время будет задействовано на других проектах (на само деле это уже отдельная задача для ресурсных менеджеров, но она вполне решаема). На изолированном проекте такой роскоши нет — мы не можем принять на работу ⅓ разработчика или тестировщика. Но чаще всего такая ситуация складывается с руководителями проектов. Неравномерная нагрузка по ходу проекта приводит к неоптимальному использованию управленческого ресурса.
- Отпуска. В первой версии ресурсного плана, когда идёт грубая оценка в потребности в персонале, вполне допустимо не заморачиваться с учётом отпусков. А вот когда речь идёт о ресурсное плане, как об инструменте ежедневного управления проектом, то тут уже становиться очень опасным не учитывать нерабочие дни. В году 52 недели и как минимум по 2 из них каждый член команды проведёт в отпуске. Если речь идёт о команде численностью всего в 10 человек, то это означает, что вы сразу закладываете около 2 х 5 х 10 = 100 человеко-дней дефицита. Которые будут покрываться, например, овертаймами.
- Праздники. Полторы недели новогодних праздников, майские праздники, 23 февраля, 8 марта и иже с ними отнимают от 52 недель в году ещё 2-3. А если говорить о распределённых командах, где трудятся люди из разных стран, то все становится ещё нетривиальнее. В каждой стране свои национальные праздники и руководителю проекта просто придётся хоть немного поизучать культуру стран, где трудятся члены его команды, чтобы составить точный ресурсный план с учётом праздников. А если нет — можно вернуться к предыдущему пункту и удвоить сознательно закладываемый дефицит трудочасов и сложностей в проект.
Этот список, безусловно, можно продлять и далее, но основные темы мы подсветили. Получается, что качество ресурсного планирования влияет едва ли не на всё в IT-компании, а на качество самого ресурсного плана влияет довольно много факторов, для правильного учета которых нужна определенная сноровка.
В следующей части мы перейдём к более практическим вещам и рассмотрим тему ресурсного планированию в рамках изолированного проекта.
Автор: Андрей Деренченко
