Планирование Ресурсов. Часть 4.1. Прежде Чем Составить План Ресурсов

Планирование ресурсов для одного проекта — это большая тема, и мы разделим ее на несколько частей.

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

А во второй части мы поговорим о том, как составить ресурсный план.

В предыдущая статья Мы уже разобрали, от чего зависит ресурсный план.

Давайте подробнее рассмотрим самые важные моменты и дополним их полезными напоминаниями.

Что следует иметь в виду при выполнении WBS?

Разные компании используют разные шаблоны для подготовки и оценки структуры работы.

Хорошие шаблоны уже содержат чек-листы и соответствующие закладки для оценки рабочих модулей.

Общие вопросы

• Согласованы ли все бизнес-требования? Если не все, то как оценивались те части проекта, которые зависят от противоречивых требований?
• На каком уровне оценивался каждый модуль? Одно дело, когда компания уже много раз делала подобные вещи.

  В таких модулях обычно оценка уже максимально подробная (LLD — low level design).

  Другое дело, когда оценивался объем работ, которые раньше в таком виде не делались.

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

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

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

• Включен ли LOE (уровень усилий) в развертывание инфраструктуры проекта (система отслеживания ошибок, системное программное обеспечение, среды разработки и тестирования и т. д.)?
• Встроен ли LOE в систему контроля версий сторонних библиотек и используется ли стороннее программное обеспечение?
• Включен ли LOE в обучение пользователей?
• Включен ли LOE в подготовку и изменение документации? Подготовить примечания к выпуску?
• Включен ли LOE в обучение группы технической поддержки?
• Встроен ли LOE в тестирование и обеспечение безопасности системы (запутывание, тестирование на соответствие требуемым стандартам безопасности, приведение системы в соответствие с требуемыми стандартами безопасности)?
• Включен ли LOE в сертификацию системы?
• Включен ли LOE в проведение Lessons Learned (работа над ошибками по результатам проекта)?
• Какова вероятность получить на проект команду или хотя бы лидов и сеньоров, которые уже знакомы с системой и которым не нужно тратить много времени на погружение?

Отдельный список для части QA

Но обеспечение качества — это далеко не просто функциональное тестирование.

Ниже приведен список, который поможет вам не забыть некоторые важные вещи.

• Согласовано ли с заказчиком HWE (Hardware Estimation — оценка и набор требований к производственной и тестовой средам в контуре заказчика)? Если есть, то внимательно их прочтите, проанализируйте, насколько HWE соответствует NFR. Если нет, то спросите себя, как вы будете работать без этого?
• Согласованы ли с заказчиком NFR (нефункциональные требования)? Если да, пожалуйста, внимательно прочитайте эти документы.

  Если необходимо, уточните.

  Если согласованных НФР нет, то в ваших интересах как можно скорее разработать и согласовать этот документ с заказчиком.

  Отсутствие НФР или НФР с большими пробелами представляет собой огромный риск для проекта.

• Существует ли последовательный процесс развертывания системы в средах клиентов? Включен ли LOE для развертывания системы в средах разработки, тестирования и рабочей среды?
• Существует ли оценка SVT (объемное стресс-тестирование)? Если да, то что это включает? Какие NFR будут использоваться во время тестирования? На чьей среде будет проводиться нагрузочное тестирование? Все ли этапы СВТ включены в оценку? В каком формате следует представлять результаты СВТ? Как клиент воспримет результаты SVT?
• Существует ли оценка интеграционного тестирования? Какие системы клиента будут использоваться для интеграционного тестирования? В какой среде будет проводиться интеграционное тестирование? Как будут тестироваться системы, которые не будут доступны из тестовой среды? Если на заглушках, то есть ли соответствующий рейтинг?
• Как рассчитывается LOE для UAT (приемочное тестирование – этап финального тестирования системы пользователями заказчика при активной поддержке команды разработчиков)? Чье присутствие планируется в офисе клиента во время ЕАТ?
• Какова вероятность получить QA проекта, которые уже знакомы с системой и которым не нужно тратить много времени на погружение?

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

И вроде были даже HWE и NFR, и был план СВТ высокого уровня.

Только они не были согласованы друг с другом.

Как нетрудно догадаться, за это нам пришлось заплатить не одним десятком неоплачиваемых человеко-часов и кучей нервов.

Какие накладные расходы следует включить в план ресурсов?

Если, конечно, вы к ним не готовитесь.

Совместное использование бойцов с другими проектами

О каждом известном члене команды будет полезно узнать следующее:

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

  Часто бывает, что формально у вас есть старший менеджер, но на самом деле вы активно жонглируете им с другими проектами.

  Это то, что вам нужно знать, прежде чем разрабатывать план ресурсов.

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

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

Совместное использование и работа с технической поддержкой

• Есть ли у вашей техподдержки свои разработчики? Если да, то как они узнают о новых функциях, которые вы внедряете? Как это отражается в WBS? Если нет, то какие члены вашей команды (SA, BA, Dev, QA) и как часто будут отвлекаться на решение вопросов технической поддержки? Даже если в техподдержке есть свои разработчики, периодическое отвлечение членов команды разработчиков на техподдержку неизбежно.

• Включен ли LOE в передачу знаний сотрудникам службы технической поддержки?
• Входит ли LOE в гарантийную поддержку системы? Кто и как будет оказывать гарантийную поддержку?

Встречи и звонки

На собраниях.

Типичная картина: по графику старший разработчик тратит 40 часов на разработку в неделю, но на самом деле он регулярно тратит несколько часов в день на звонки и личные встречи с командой и заказчиком.

И вместо 40 часов у него осталось на работу 30 часов.

В результате разработчик либо не успевает, работает сверхурочно, либо выдаёт код не самого лучшего качества.

Еще более острая проблема обычно возникает среди бизнес-аналитиков.

С одной стороны, в силу характера своей деятельности они должны работать в тесном контакте с заказчиком.

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

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

Как вы понимаете, и то и другое плохо.

Если в первом случае вы искусственно создаете для своего коллектива изначально стрессовую ситуацию и предпосылки для бесконечных сверхурочных работ, то во втором случае вы просто перестаете понимать реальную структуру работы.

Хорошим вариантом решения проблемы встреч будет определение круга бойцов, которые будут регулярно участвовать во встречах, и явное включение этого ЛО? в оценку.

Для каждого такого бойца определите максимальное количество часов, которое он реально может потратить на разработку/анализ/проектирование и используйте это в ресурсном плане.

Решите немедленно, как управлять изменениями

За более чем 20 лет работы в IT я не участвовал ни в одном проекте, где бы требования не менялись по сравнению с исходной постановкой.

Требования обязательно изменятся.

И прежде чем готовить ресурсный план, лучше сразу решить, кто и как будет управлять изменениями и как вы это отразите в ресурсном плане.

Если у вас большой проект, вы сразу договорились с заказчиком об объёме возможных изменений и у вас есть CR Bucket (сумма LOE, уплаченная заказчиком, которая будет потрачена на изменения) — отлично.

Тогда у вас есть почти точное количество часов, которые вы должны заранее зарезервировать для еще неизвестных задач.

В зависимости от размера этого LOE и ожидаемого потока изменений полезно принять решение заранее.

В любом случае вам необходимо ответить на следующие вопросы:

• Известен ли объем предлагаемых изменений? Если согласованного CR Bucket нет, то вам нужно попытаться провести собственную оценку, исходя из рисков проекта и вашего видения ситуации.

• Сможете ли вы лично управлять изменениями или этим будет заниматься специально обученный человек (Change Manager)?
• Выделяете ли вы отдельную команду для обработки изменений или рабочая нагрузка будет распределяться между всеми членами команды? Хорошей практикой является назначение хотя бы отдельного бизнес-аналитика для работы с изменениями.

• Будете ли вы делать отдельный ресурсный план для работы с изменениями или все будет в одном ресурсном плане?

Подумайте о методологии учета и сбора фактического времени.

Его ценность определяется, в том числе, его актуальностью.

Задача руководителя проекта — не только обновлять план ресурсов на будущие периоды, но и точно собирать факты за прошлые периоды.

И хотя элементы, необходимые для планирования, мы уже рассмотрели достаточно подробно, собирать факты мы еще не приступили.

Факт не то же самое, что факт

• работать над своим проектом
• выполнение конкретных, заранее запланированных задач по проекту

Но как собрать факт? Подходя к этому вопросу, нужно осознавать разницу между часами планирования ресурсов и LOE, выделяемым на выполнение задачи.

Например, разработчик за день закрыл две ошибки, потратив на каждую по 3 часа.

Всего он работал над заданиями 6 часов.

В Jira списали 6 часов.

Но он получит зарплату за 8 часов, а он в тот день работал над проектом 8 часов.

И это нормально — часы, потраченные на проект, никогда не будут равны комфорту, потраченному на решение проектных задач.

Есть много непроизводственных задач, которые отнимают время, и здесь нужно хорошо понимать, как вы будете учитывать это время.

Что вы поместите как факт в ресурсный план? Иногда сторипоинт-оценки помогают решить эту проблему.

Как собрать факт в ресурсный план?

Вариант №1. Полностью полагаемся на таск-трекер (например, Jira)

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

• велик риск получить либо завышенное время выполнения задач (большинство традиционно доводят время выполнения задач до 8 часов в день — никто не любит списывать время на задачи типа «ничего не делать»), либо слишком подробную классификацию задач, что тогда будет сложно работать.

Вариант №2. Используем систему табелей учета рабочего времени

• однозначное разделение часов, затраченных на проект (в табелях) и LOE проекта (в таск-трекере)
• все преимущества варианта 1

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

Вариант №3. Две крайности

Как ни странно, полностью ручной вариант сбора и анализа тоже имеет свои преимущества.

Самое главное, что ручной вариант внесения факта в ресурсный план требует глубокого погружения руководителя проекта в работу своей команды.

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

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

С другой стороны, этот процесс гораздо менее трудоемкий и может применяться к проектам различного масштаба.

Как учитывать сверхурочную работу?

• будешь ли ты платить за сверхурочную работу в будние дни?
• Допустимо ли списание более 8 часов в будние дни? Здесь нет правильных ответов; каждый подход имеет свои плюсы и минусы.

  Как показывает моя практика, наименее проблемный набор здесь такой:

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

В следующей части мы наконец приступим к созданию ресурсного плана.

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

Войти , Пожалуйста.

Какие инструменты вы используете в своей компании для сбора фактического отработанного времени? 66,67% только таск-менеджер (Jira и т.п.

), часы берутся оттуда 8 0% используем и разрабатываем самописную систему, где все учтено 0 0% у нас есть купленная система управления проектами с функцией планирования ресурсов и учета рабочего времени 0 8.33% мы используем диспетчер задач и табели учета рабочего времени 1 25% нас вообще не заморачивает такая ерунда 3 Проголосовали 12 пользователей.

4 пользователя воздержались.

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

Войти , Пожалуйста.

Вы платите за сверхурочную работу? 28.57% Да и сверхурочно в будние дни тоже можно 4 21.43% Да, но сверхурочно в будние дни нельзя 3 50% Сверхурочные работы не оплачиваются на галерах 7 Проголосовали 14 пользователей.

4 пользователя воздержались.

Теги: #Управление развитием #Управление проектами #Управление персоналом #план ресурсов #планирование ресурсов

• Управляйте Оповещениями С Помощью Alerta.io

  19 Oct, 24

• Две Модели Лучше, Чем Одна. Опыт Яндекс.переводчика

  19 Oct, 24

• «Хочу Сверить Часы» - Вежливые Штампы Из Почтовой Переписки И Их Восприятие

  19 Oct, 24

• Китайский Илон Маск Планирует Составить Конкуренцию Tesla Motors

  19 Oct, 24

• Я Пишу

  19 Oct, 24

• Как Правильно Исключить Подразумеваемые Гарантии Из Контракта На Разработку Программного Обеспечения (Часть 3)

  19 Oct, 24

• Restless Hearts Или Другой Способ Написать 3D Игру В Свободное Время Без Вреда Для Здоровья

  19 Oct, 24

• Цифровая Трансформация Рекламы В Интернет-Ритейле. По Стопам «Видеоаналитики В Ритейле»

  19 Oct, 24

• Распределенный Поиск Majestic-12 Мечтает О Лаврах Google

  19 Oct, 24

• Стартап Из Кафе (Время Мск)

  19 Oct, 24