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

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

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

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

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

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

В конце поста будут ссылки на скачивание этого и других примеров WBS!

Важно понимать, что в 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 все равно гораздо лучше, чем ее отсутствие

Cкачать пакет примеров реальных WBS с различных проектов вы можете всего за 199 руб. После оплаты  на почту вы получите архив с WBS по трем реальным проектам и – бонусом! – WBS приведенного в посте примера с ремонтом, в котором уже настроено удобное форматирование для построения своего варианта. В пакет входят WBS для проектов разного типа – создания новой ИТ-системы с нуля, доработки существующей системы и миграции с одной системы на другую. Также в них разный фокус и разный уровень детализации, чтобы, ознакомившись с примерами WBS, вы смогли сделать свою WBS  такой, какая нужна именно вам. Все файлы WBS представлены как в исходном формате mmap (открываются в Mindjet MindManager), так и в jpg с высоким разрешением на тот случай, если у вас не установлен MindJet. Воспользуйтесь чужим опытом и сэкономьте свое время, оно стоит намного дороже! Скачайте примеры, изучите их и начните строить WBS для вашего проекта на основе лучших практик прямо сейчас!

Купить шаблоны за 199 руб.