Модель WBS: как сделать большие проекты управляемыми
Секреты успешного проектного управления с помощью структурной декомпозиции работ
Знаете, что общего между шведским столом и успешным проектом? В обоих случаях всё должно быть разложено по полочкам: здесь салат, за следующим столом — горячее, а десерты в самом конце зала.
Также и в управлении проектами. Чтобы не утонуть в океане задач и сроков, нужна четкая структура, которая поможет организовать проект по полочкам. В этом может помочь модель WBS, она же структурная декомпозиция работ.
О том, что это за модель, для чего нужна WBS и как построить структурную декомпозицию работ, рассказала Арина Барлова — сертифицированный проектный менеджер с общим опытом более 10 лет, а в IT и роли РМ и БА — более 6 лет.
Что такое структурная декомпозиция работ
Модель WBS ( англ. «work breakdown structure») расшифровывается как структурная декомпозиция работ. В русскоязычном управлении проектами чаще используется термин ИСР — иерархическая структура работ.
PMI определяет WBS как «ориентированную на результат иерархическую декомпозицию работы, которую должна выполнить команда для достижения целей и создания необходимых результатов».
Простыми словами, WBS — это перечень работ, которые выполняет команда, чтобы достичь цели проекта. То есть получить желаемый результат.
Почему модель называют структурной, или иерархической, декомпозицией
Потому что обычно WBS имеет достаточно жесткую структуру. Объясню на примере — мы берем проект и разбиваем его на какие-то результаты, которые нужно получить, чтобы достигнуть цели проекта. Работая с WBS, работы по достижению этих результатов группируются:
- по этапам проекта: инициация, планирование, исполнение, контроль и завершение;
- по видам работ: например, проект «отпуск» можно разбить на блоки «отель», «билеты», «развлечения»;
- по срокам: что будет сделано в 1, 2 и 3 месяцы;
- по центрам ответственности: блоки работ для производства, отдела продаж, отдела снабжения, отдела маркетинга и т. д.;
- по территориальным объектам: например, для офиса в Москве и для офиса в Санкт-Петербурге.
Поэтому WBS — это всегда жесткая структура с понятными уровнями детализации от общего к частному.
Самое важное, что есть в определении WBS — это результат работы с задачами, которые мы выделяем и обсуждаем.
То есть мы не пытаемся сформулировать четкое название или ТЗ задачи сразу же. В первую очередь мы определяем и фиксируем свои ожидания: «Что мы хотим получить?»
Приведем пример. Допустим, кто-то собирается в отпуск. Тогда проектом будет «Подготовка к отпуску». В нем есть блок «Проживание». Когда мы рассматриваем задачи для того, чтобы забронировать номер в отеле, по ИСР мы пишем не «забронировали номер в отеле», а указываем желаемый результат — «подтвержденная бронь номера в отеле».
Некоторые эксперты в теории управления проектами до сих пор спорят между собой о том, какая же модель должна использоваться при создании ИСР:
- процессно-ориентированная — когда мы описываем, что нужно сделать, используя глаголы;
- объектно-ориентированная — когда мы определяем с помощью существительных, что хотим получить.
По сути, в Европе чаще используется процессно-ориентированная (активности и глаголы), а в США — объектно-ориентированная.
Я придерживаюсь рекомендаций для разработки ИСР книгу «Practice Standard for Work Breakdown Structures», третье издание которой вышло в 2019 году. Там акцент — на объектно-ориентированную модель.
Для чего нужна ИСР
WBS решает 2 блока задач, а именно:
1. Формирует список ожиданий от реализации проекта. В этом случае я понимаю, какие именно результаты у выделенных задач нужно получить, чтобы соблюсти все требования и достичь верхнеуровневой цели проекта.
Поэтому я как менеджер могу управлять ожиданиями при работе со стейкхолдерами, не допускать ненужного расширения требований, работ, контролировать изменения по ходу реализации проекта.
2. Формирует структуру, последовательность и ограничения реализации проекта. В этом случае я понимаю:
- какая должна быть последовательность работ,
- как оценить сроки и стоимость,
- как запланировать параллельную реализацию части работ,
- какие заложить контрольные точки — вехи,
- кого определить как ответственных,
- как увидеть взаимосвязи между задачами (что без чего не получится достичь),
- как оценить риски (что случится, если какой-то результат не будет достигнут) и т. д.
Если обобщить оба блока, то ИСР — это инструмент для оценки и планирования проекта. Работая с моделью, пользователь понимает, что ему нужно сделать, чтобы достичь результатов. Также он может оценить, сколько это будет стоить (в деньгах, людях, сроках, иных ресурсах).
Готовая WBS помогает понять, что из работ и результатов нам важнее, за что мы будем себя хвалить, когда выполним эту часть работ.
Принципы и рекомендации декомпозиции работ
Если говорить про принципы, правила и рекомендации по созданию ИСР, то я бы предложила ориентироваться на PMI. Раздел 5.4 в PMBOK полностью посвящен созданию ИСР.
«В контексте ИСР работы означают продукты или поставляемые результаты, являющиеся результатами операций, но не сами операции».
Помимо этого, для руководства есть отдельный стандарт для разработки ИСР: Practice Standard for Work Breakdown Structures.
Еще есть так называемое «правило 100%»: WBS включает 100% работ проекта и фиксирует все результаты — внутренние, внешние и промежуточные.
Правило применяется на всех уровнях иерархии: сумма работы на «дочернем» уровне (пакет работ) должна равняться 100% работы представленной «родителем» (блоков работ — первого уровня декомпозиции).
То есть WBS не должна включать в себя какую-либо работу, выходящую за рамки фактического объема работы. Если упростить, то по мере выполнения ИСР не должно получиться, что в ней больше 100% работы. Никаких задач «за компанию» попадать в уже созданную структуру не должно.
Принципы
Если говорить именно о принципах создания ИСР, то предлагаю ориентироваться на статью «Базовые принципы WBS» от Фрэнсиса Мэриона Вебстера. Ниже оставляю упрощенный вариант.
→ Уникальность. Один дочерний элемент работы связан только с одним родительским элементом. Проще говоря, у одной дочерней подзадачи не может быть несколько родителей. Результаты должны быть определены так, чтобы исключить дублирование объемов работ внутри элементов WBS, в целом по организации или отдельными ответственными за выполнение работ.
→ Ответственность. Каждый элемент должен иметь конкретного ответственного. Он, в свою очередь, должен четко понимать свою часть работы, осознавать и выполнять требования для достижения результата.
→ Причастность. Менеджер может самостоятельно составить ИСР, но для этого обязательно должна быть обратная связь от ответственных сотрудников за выполнение задач — элементов ИСР. Поэтому в работе с проектом все задачи обязаны согласовываться с ответственными. Так у сотрудника появится мотивация реализовать то, к чему он причастен, как член команды. А значит, ему будет проще контролировать задачу и исполнение ИСР.
→ Стандартизированность. Здесь объединены принципы документирования ИСР. То есть WBS не может существовать просто как идея без оформления (на бумаге или документе) и согласованности. Также все определения и термины, порядок нумерации элементов для построения иерархии должны быть единообразными для всего проекта.
→ Необходимость и достаточность. Сюда относится и правило 100%, и рекомендация не создавать больше элементов, чем нужно. Не стоит дробить проект на огромное количество мелких задач. И не нужно оставаться на самых верхних уровнях для одних видов работ, детализируя другие. Каждый элемент WBS должен обеспечивать достижение ощутимого результата.
Как построить структурную декомпозицию работ
Давайте построим ИСР для какого-то конкретного проекта. Например, мы хотим провести мероприятие для партнеров нашей фирмы.
Шаг 1. Определить цель и требования к результату проекта
На этом шаге нужно четко описать идею о конференции: какая конференция, зачем она нужна, для кого, где и когда.
Цель: провести офлайн-встречу в Москве для всех российских партнеров фирмы. Нужно презентовать последние продукты, новые правила партнерской программы и познакомить с новыми ЛПР-ами компаний-партнеров.
Здесь мы понимаем, какие у нас требования к этому ивент-проекту:
- это должно быть очное мероприятие,
- нужно будет выбрать место проведения,
- возможно, организовать проживание и транспорт для иногородних участников,
- подготовить список участников,
- составить программу мероприятия,
- продумать развлекательную часть,
- кейтеринг,
- возможно, подготовить какие-то раздаточные материалы или мерч, и много чего еще.
В итоге на этом шаге мы определили, что это будет мероприятие на 2 дня в загородном клубе с их кейтерингом, проживанием, официальной и неофициальной частью программы.
Шаг 2. Определить первый уровень иерархии
Обычно нулевым уровнем является сам проект, а первый уровень — ключевые блоки, по которым и строится иерархия всей структуры.
Давайте сделаем группировку по видам результатов (достижимые конкретные результаты работы). Чтобы проект состоялся нужно, чтобы у нас были:
- Участники.
- Программа.
- Место проведения.
- Транспорт.
- Раздаточные материалы.
Без этого встреча точно не получится.
Шаг 3. Декомпозировать работы (результаты) на пакеты работ
Пакет работ — это минимальный элемент ИСР, который может быть реалистично оценен и измерен, а позже передан для исполнения конкретному исполнителю.
Обычно именно пакет работ декомпозируется уже на операции и задачи, поэтому глубина декомпозиции (количество уровней между самым первым и последним) определяется менеджером самостоятельно в контексте требований к проекту, правил компании и потребности в детализации.
В любом случае декомпозиция проводится итеративно, чтобы было проще понять, когда нужно остановиться.
Давайте декомпозируем один из блоков. Мы знаем, что участниками встречи будут партнеры и сотрудники компании. Также будет присутствовать обслуживающий персонал (регистрация, проведение мероприятия и кейтеринг, например).
Какие у меня требования к этому блоку? Я хочу сделать списки участников, чтобы там были: ФИО, компания, роль, задачи на мероприятии.
Что дальше? У меня есть определенная бумажная работа по этим участникам. Так, мне нужно разослать приглашения и получить подтверждения участия от партнеров. Своим сотрудникам нужно оформить командировочные, а для внештатных сотрудников — обязательно сделать договоры и закрывающие документы.
Нужно отразить это на следующих уровнях декомпозиции:
Сейчас максимальный уровень декомпозиции — четвертый. Но пока не понятно, какая у этого будет реализация. Возможно, весь внештатный персонал будет предоставлен одной компанией. Тогда декомпозиция получится, как мы описали выше.
Но, может быть, будет несколько фирм, которые предоставляют персонал для мероприятий. Тогда работа персонала будет включена в условия договора аренды помещения для проведения.
Если этот момент непонятен, лучше зафиксировать именно маленькие результаты каких-то работ, без которых не получится провести встречу. Без договора и закрывающих не получится точно, какими они будут — это вопрос на попозже.
Самый простой способ убедиться, что больше декомпозировать не нужно, это поставить конкретную задачу одному исполнителю для выполнения указанного пакета работ. Когда ответственных несколько и выделить кого-то одного нельзя, значит, нужно декомпозировать дальше.
Шаг 4. Распределить пакеты работ на управляемые задачи и распределить задачи
Итак, у меня есть такие пакеты работ в блоке «участники-партнеры»:
1.1.1 Список партнеров, приглашенных на встречу
1.1.2 Приглашения партнерам
1.1.3 Подтверждение участия (письменное) от партнера
Как мне это распределить на задачи? Нужно так и писать, обозначая требования к результату, который я в самой ИСР отразила ранее:
Или вот тут есть более глубокая декомпозиция:
Что здесь не так? Нет принятого решения. Например, какие будут приглашения: печатные или электронные. Нет ТЗ на дизайн, на текст, поэтому невозможно поставить одного ответственного.
Значит, когда я декомпозировала работы, я здесь не дошла до уровня пакета работ. Следовательно, мне нужно вернуться на предыдущий шаг и продолжить декомпозицию:
1.1.2 Приглашения партнерам
1.1.2.1 Выбор формата приглашений
1.1.2.2 Дизайн приглашений (шаблон)
1.1.2.3 Текст приглашений (шаблон)
1.1.2.4 Готовые к отправке персонализированные приглашения
И тут уже становится понятен формат: бумажный или электронный. Руководитель выбрал электронные приглашения, а значит, печать не понадобится. Нужны будут только электронные шаблоны, и работать с ними может кто-то из того же отдела.
Тогда я смогу поставить задачи дизайнеру, копирайтеру и сотруднику отдела по работе с партнерами. И определю созависимости и сроки.
Важно: распределение на задачи проводится, после того как по всем блокам проекта завершена декомпозиция. В процессе распределения на задачи могут быть выяснены зависимости между ними. Так, например, наш список докладчиков из пункта ИСР 1.2.1 необходим для составления программы во втором блоке работ. А список подтвердивших свое участие партнеров нужен для бронирования проживания и организации транспорта.
Шаг 5. Согласовать и скорректировать ИСР
Предварительный список результатов, пакетов работ, разбитый на задачи и ответственных, скорректируется после обсуждения с командой. Они предложат более детализированные результаты, структуру, помогут скорректировать сроки с учетом запасов, и подсветят, какие дополнительные работы могут понадобиться.
Например, есть параллельный проект по переоформлению брендбука, и там не успевают закончить всё до того, как надо будет на вашем проекте готовить брендированные раздаточные материалы, а это риски, сроки, деньги.
Если менеджер проекта может подготовить ИСР самостоятельно, то утверждение, согласование и корректировка пунктов в ней — это обязательный публичный шаг.
На какие вопросы нужно ответить, чтобы проверить, что ИСР сделана корректно и закрывает все наши потребности? Вот примерный список:
- Все основные блоки определены на верхнем уровне?
- Проведена полная декомпозиция? То есть можно поставить конкретную задачу одному исполнителю для выполнения указанного пакета работ?
- Можно ли из элементов WBS составить расписание и бюджет?
- Проверены все созависимости элементов, нет неиспользуемых элементов и результатов?
Шаг 6. Определить вехи
Когда всё уже утверждено и согласовано, можно пройтись по ключевым моментам проекта. Что из списка результатов можно отнести к ключевым событиям? Что можно будет отметить всей командой проекта и понять, что мы на правильном пути и не выбиваемся из графика?
В нашем примере это может быть получение подтверждений от партнеров (все подтвердили в срок, всё хорошо, мы можем продолжать работу). Создание программы, подтверждение от отеля, печать в СМИ и т. д.
Как оформлять WBS
Правильного ответа нет. Руководствуемся исключительно стандартами и правилами внутри компании, а также потребностями команды и проекта. Есть вот такие доступные варианты для оформления ИСР:
1. Контурная структура. Это просто нумерованный список, первый уровень декомпозиции — это 1, второй — 1.1, третий — 1.1.1, и т. д. В списке все пункты расположены друг под другом и идентифицируются по номеру.
2. Иерархическая таблица. Есть уровень декомпозиции, порядковый номер элемента, название, описание, ответственный, сроки, стоимость, зависимости (ссылка на пункт таблицы, с которым у текущего пункта есть связь). Всё это сведено в таблицу и позволяет суммировать работы и результаты в план-график и бюджет по итогу.
3. Древовидная структура. Самая наглядная форма представления ИСР, потому что разветвление показано очень просто от корня (проекта) к ветвям (блокам) и веточкам поменьше (результатам), листикам (задачам). Как вариант — реализовывать в виде майндмэпа, выписывая только результаты (во фреймворке P3.express, например, именно этот вариант ИСР используется для создания Карты результатов).
4. Диаграмма Ганта. Она состоит из отрезков, расположенных на временной оси. Отрезки — это задачи, у которых есть ответственные и сроки. Диаграмма Ганта отображает, когда будут выполняться задачи и сколько на это уйдет времени, а также позволяет отслеживать зависимости и вехи.
Создавать ИСР можно стикерами на доске, в приложениях для визуализации (например, Miro), в таблицах, таск-трекерах, текстовых документах и любых иных документах, удобных для составления и редактирования.
Я предпочитаю черновики писать от руки, а потом переносить в документы и согласовывать с коллегами.
Коротко о главном
WBS — это ваш проектный компас. Структурная декомпозиция работ помогает разбить ваш большой проект на части, чтобы команда понимала, с чего начать и куда двигаться дальше.
У декомпозиции работ есть множество плюсов.
- Минимизация рисков. Отсекая лишнее и сосредотачиваясь на ключевых задачах, вы избегаете путаницы и потенциальных ошибок. Сложный проект становится проще, а значит, и безопаснее для вашего времени и ресурсов.
- Эффективность командной работы. Каждый член команды видит свою зону ответственности и понимает, как его работа вписывается в общую картину. Это повышает мотивацию и улучшает координацию.
- Удобство мониторинга и контроля. С WBS вы точно знаете, какие сегменты проекта уже выполнены, а что еще предстоит сделать. Это делает процесс управления проектом гибким и адаптивным.
- Оптимизация ресурсов. Разбивка проекта на части позволяет более рационально распределять ресурсы, избегая излишних трат и временных задержек.
Чтобы создать WBS, нужно ориентироваться на нужды и специфику конкретного проекта. Волшебной таблетки или универсальной формулы нет. Но за основу можно взять 6 шагов из нашей статьи.
