Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
28 июня 2017 Все для начинающего РМа Золотой фонд
21 370 0

Что такое WBS проекта, и зачем она нужна

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

Хорошо, что лето в разгаре, заказчики по отпускам, и можно потеоретизировать. Сегодня у нас на очереди статья о том, что такое WBS проекта и зачем она нужна. Опытные РМы – пропускают, ничего нового там не будет. Новички – читают в обязательном порядке.

Что такое WBS проекта

WBS проекта (она же Work Breakdown Structure или ИСР, Иерархическая Структура Работ) – это разбиение проекта на конкретные результаты, которые должны быть достигнуты для достижения целей проекта.

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

На словах, как всегда, мало что понятно, поэтому любимый пример с ремонтом (картинка большая, для детального просмотра ее лучше открыть в новой вкладке):

Если кому-то нужен исходный файл (формат mmap для MindJet) – качаем тут – Ремонт.

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

В классическом подходе все блоки WBS (так называемые Work Packages) нумеруются, но в жизни я таких ответственных РМов видела буквально несколько раз. Сама я, как правило, нумеровать не то что бы ленюсь – просто не вижу смысла, так как после завершения планирования WBS использую как инструмент оперативного управления, и при нумерации становится сложнее поддерживать корректную интеграцию в проекте.

Зачем нужна WBS

WBS – крайне полезная вещь в планировании проекта и вот почему:

  1. WBS – если не единственный, но точно самый эффективный способ наглядно отразить весь объем проекта.
  2. WBS фокусирует внимание не на процессе а на ожидаемом результате, и создает нужный «посыл».
  3. В идеале в разработке WBS участвует заказчик или его представитель и вся команда, что позволяет а) обеспечить единое понимание результатов проекта и его объема б) увидеть важность и вклад отдельных элементов в общий результат
  4. С помощью WBS можно наглядно обосновать необходимости в финансах или человеческих ресурсах, так как против конкретного описанного объема возражать гораздо сложнее, чем против «да что там системку написать, посадите программиста и все».
  5. WBS помогает предотвратить риски и изменения или по крайней мере значительно (очень значительно!) снизить их вероятность и влияние, так как именно здесь всплывут многие неочевидные ранее вещи и «а мы хотели совсем другое» (и так и должно быть, для этого инструмент и предназначен).
  6. На уровне WBS уже можно определить и согласовать контрольные точки проекта (как для решений о продолжении проекта после очередного этапа, так и для контроля затрат человеческих и финансовых ресурсов).

Уже на этом этапе хорошо бы донести до заказчика вашу позицию «Если задач нет в WBS – их нет и в проекте». Во-первых, все постараются при разработке или при согласовании немного больше, а во вторых – у вас появится хороший рычаг влияния на будущее.

Группировка и декомпозиция WBS

Первый вопрос, который возникает в начале создания WBS – как группировать элементы WBS, по какому принципу?

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

Классические варианты группировки WBS:

  1. По стадиям жизненного цикла проекта (например, отдельно описываются результаты фаз планирования, анализа, разработки, приемки и проч.) – это самый простой и популярный подход, особенно если проект идет по утвержденному процессу и всем понятно, что должно быть на выходе какой фазы.
  2. По высокоуровневым результатам проекта (проект разбивается на ключевые результаты, например, готовая система, обученные пользователи, разработанная нормативная документация, согласованное использование системы с государственными органами и проч.) – я чаще всего использую именно этот вариант, мне нравится видеть конкретные результаты проекта и, на мой взгляд, этот формат лучше понимает заказчик.
  3. По организационной структуре (например, вы, заказчик, подрядчик(и) и проч.) – этот вариант удобен, когда вам надо жестко разграничить ответственность за результаты работ.
  4. Про срокам (например, по кварталам) – если для проекта критична привязка к срокам.
  5. По техническим областям (производство, маркетинг, закупки и проч.)
  6. По источникам финансирования (какая часть результатов за какие средства достигается или за бюджет какого года, например).
  7. По странам (такое видела однажды всего на одном из международных проектов, и показалось крайне неудобным).

Одним словом – можно любой свой вариант придумать, лишь бы было удобно.

Второй любимый вопрос начинающего PMа – до какой степени нужно детализировать WBS? Забавно, но правильного ответа  на этот вопрос не существует. Степень декомпозиции зависит как от размера, так и от типа проекта, а также от количества времени, которое вы можете потратить на проработку.

Поэтому ответ очень простой – при планировании проекта и разработке WBS нужно просто определиться, какой объем работы на нижнем уровне для вас приемлем, чтобы вы могли ее контролировать. Слишком большие задачи – плохо, так как не будет понимания реальной картины, слишком маленькие – тоже плохо, так как найти время на контроль станет сложнее (например, если вы контролируете результат раз в неделю – нет смысла бить задачу на однодневные результаты, проверить все равно сможете только в комплексе).

При  подготовке к сдаче PMP в книжке Риты Малкахи приводятся такие усредненные рекомендации:

  • Для маленьких проектов – 4-40 часов,
  • Для средних проектов – 8-80 часов
  • Для больших проектов – в зависимости от масштаба, но желательно не более 300 часов.

В жизни такой идеальный баланс найти не всегда удается, поэтому в WBS попадают как небольшие задачи, результат которых критически важен для проекта, так и крупные. Так, например, в примере с ремонтом есть как «закрытие договора с текущим ЖЭКом» длительностью максимум 30 минут (ЖЭК у меня на 1м этаже сидит в соседнем подъезде), так и штукатурка по маякам, которая несколько дней займет (но мне с этим комфортно, так как проконтролировать промежуточный результат или как-то всерьез повлиять на скорость высыхания штукатурки я все равно не смогу).

В работе лично я стараюсь ориентироваться на планку «8 часов на нижнем уровне WBS».

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

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

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

Правильного ответа тоже нет, но есть варианты:

  1. Отражать итерации как способ группировки (каждый итерация или спринт идут отдельным блоком в WBS) – удобно, если результаты спринтов заранее известны.
  2. Разбивать каждый из результатов на итерации – удобно, если у вас делается сразу весь объем, а в дальнейшем только улучшается и детализируется (но тут нужно очень хорошо понимать объем проекта, что при agile бывает не так часто)
  3. Использовать обычную WBS и уточнять ее для каждой итерации (то есть количество WBS в итоге будет равно количествам итераций)
  4. Просто использовать обычную WBS и ограничиться этой степенью детализации.
  5. Любой другой вариант, дающий вам нужную степень понимания и детализации.

Инструменты для разработки WBS

Единственное правило тут – разрабатывать в том, в чем удобно. Если у вас есть какой-то инструмент для построения диаграмм – отлично, если нет – подойдет любой другой, например, Mind Manager, Excel, MS Project, Visio или любой онлайн-аналог.

Я последние пару лет перешла от диаграмм к майнд-мепам (ментальным картам), на мой взгляд, формировать структуру работ там очень удобно из-за гибкости инструмента. Самый неудачный выбор, на мой взгляд – это Excel или MS Project, так как они сводят создание WBS к работе со списками и не дают нужной наглядности.

Типовая ошибка тех, кто делает WBS в MS Project – одновременно пытаться описать результаты и указать зависимости (в самых тяжелых случаях – еще и трудоемкость и ресурсы).  Цель WBS – получить именно полное содержание проекта, а не закрыть задачу планирования одним махом. А еще так легко что-то упустить, так как представление в MS Project не наглядное.

WBS Dictionary или Словарь ИБС

WBS Dictionary (он же Словарь ИБС) – это описание на страничку А4 (или подробнее) для каждого пакета работ, включающее код пакета работ, его наименование, детальное описание результата, критерии приемки, ответственного (это, наверное, самое ценное в словаре), ограничения и допущения и вообще все, что кажется вам полезным.

Я сама в жизни это использовала буквально 2 или 3 раза, слишком уж трудозатратная вещь, тем более в очень динамичных проектах разработки ПО. В какой-нибудь стройке или энергетике, наверное, без этого никуда.

Это, наверное, все, что нужно знать о создании и использовании WBS для старта. Удачи!

P.S. И да, неполная, недостаточная и не совсем правильная WBS все равно гораздо лучше, чем ее отсутствие

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: