WBS — иерархическая структура работ

Назначение: структура полного scope проекта; основа для расписания, бюджета, RACI и risk register.

Аудитория: PM, team leads, функциональные руководители.

Статус: устоявшийся (PMBOK Guide, MIL-STD-881).

Не путать с: декомпозицией проекта в разработке ПО (разбиение по модулям и фичам), диаграммой Ганта (расписание тех же работ во времени) и организационной структурой команды (иерархия людей, а не работ).

Общее #

WBS (Work Breakdown Structure, иерархическая структура работ) — поэтапная декомпозиция полного объёма работ проекта на всё более мелкие элементы: от верхнего уровня «проект целиком» через промежуточные уровни до work packages (пакетов работ) — элементов нижнего уровня, которые уже можно оценить, назначить исполнителя и проконтролировать. WBS отвечает на вопрос «из чего состоит проект», и только на него: в ней нет дат, исполнителей, бюджетов и зависимостей — это чистая структура результата.

WBS — один из старейших формальных инструментов проектного управления. Метод вырос из практики Министерства обороны США 1950-х годов: крупные оборонные программы требовали единой системы разбиения работ подрядчиков на сопоставимые и контролируемые элементы. Оттуда же происходят и родственные инструменты той эпохи — PERT и сетевое планирование (см. «Сетевое планирование»). В 1968 году DoD закрепил требования к структуре работ стандартом, который развился в MIL-STD-881 «Work Breakdown Structures for Defense Materiel Items» — с шаблонами WBS для кораблей, самолётов, ракет и информационных систем. Гражданский аналог стандарта — PMBOK Guide Института управления проектами (PMI), где WBS занимает центральное место в области знаний «Управление содержанием проекта» (Project Scope Management): структура работ — основной выход процессов определения и создания иерархической структуры работ.

Ключевой принцип, отличающий каноническую WBS от просто «списка задач»: декомпозиции подвергается результат (deliverable), а не действия. Элементы дерева — это не «что делают люди», а «что получает проект»: не «разработка», а «сервис заказов»; не «тестирование», а «прошедший приёмочные тесты релиз». Такой подход называется deliverable-oriented WBS. Альтернатива — activity-oriented WBS, где элементами являются активности («проектирование», «кодирование», «сборка») — в стандартах считается менее предпочтительной: действия повторяются от элемента к элементу, их начало и конец размыты, а полноту охвата невозможно проверить. Результат, в отличие от процесса, можно принять: он либо есть, либо нет — и потому становится точкой контроля.

WBS не описывает и последовательность работ: элемент «сервис заказов» не «идёт раньше» элемента «мобильное приложение» — они просто оба входят в проект. Порядок и сроки появляются на следующих шагах планирования, когда work packages раскладываются на расписание. Смешение структуры состава работ с их временнóй логикой — одна из типичных ошибок при построении WBS (разобрана в конце статьи).

Ключевые правила #

Правило 100% #

Фундаментальный инвариант WBS: сумма работ дочерних элементов составляет 100% работы родительского элемента — и ничего больше. Если «сервис заказов» распадается на API, оплату и уведомления, то эти три пакета вместе покрывают сервис целиком: ни одна работа не потеряна (нет «дыр» в scope) и ни одна не добавлена лишняя (нет «хвостов», относящихся к другим ветвям). Правило применяется каскадно на всех уровнях, поэтому дерево целиком покрывает 100% объёма работ проекта.

Практический смысл правила двоякий. Вверх: WBS становится инструментом проверки полноты содержания — на этапе планирования легче заметить пропущенный блок, глядя на дерево целиком, чем на плоский список из сотен задач. Вниз: правило защищает от скрытого расширения объёма — работы «по пути» (кто-то добавил скрипт миграции в ветку, где его нет) немедленно ломают арифметику «родитель = сумма детей» и становятся видимыми. Без правила 100% WBS — просто нумерованный список; с ним — система двойной записи, в которой пропуск или избыток работ виден математически.

Проверка правила выполняется на каждом уровне: для каждого родителя перечисляются дети, и команда отвечает на два вопроса — «если сделать всё это, будет ли сделан родитель?» (полнота) и «останется ли в детях хоть что-то, что не относится к родителю?» (чистота). Отрицательный ответ на первый вопрос или положительный на второй — сигнал пересобрать уровень.

Взаимное исключение (MECE) #

Ветви дерева не должны пересекаться: одна и та же работа не может находиться в двух местах WBS одновременно. Принцип соответствует известной схеме MECE (Mutually Exclusive, Collectively Exhaustive — «взаимно исключающие, в совокупности исчерпывающие»): правило 100% даёт исчерпанность, взаимное исключение — непересекаемость.

Нарушение выглядит так: «тестирование производительности» числится и в ветке «сервис заказов», и в ветке «инфраструктура». Последствия каскадные: работу посчитают дважды при бюджетировании, назначат двух ответственных, а в статус-отчётах она будет фигурировать с противоречивыми состояниями. Типичные источники пересечений — «сквозные» работы (документация, безопасность, тестирование), которые тянутся через весь проект: для них либо выделяют отдельную ветку верхнего уровня, либо жёстко относят к той ветке, чей результат обслуживают.

Границу между ветвями полезно формулировать через признак разбиения: внутри одного родителя дети разделяются по одному основанию (по результатам, по компонентам, по локациям — но не вперемешку). Смена основания разбиения от уровня к уровню допустима, внутри одного уровня — нет.

Гранулярность: work package 8–80 часов #

Нижний уровень WBS — work package — должен быть достаточно мал, чтобы его можно было достоверно оценить, и достаточно крупен, чтобы имело смысл им управлять. Распространённое эмпирическое правило (rule of thumb) — от 8 до 80 часов труда: package меньше 8 часов превращает WBS в микроплан из тысяч элементов, больше 80 часов — слишком крупен, чтобы оценка была точной, а контроль — своевременным. В отраслевых вариантах то же правило формулируют как «от двух дней до двух недель» или «не длиннее одного отчётного периода»: статус работы должен обновляться не реже, чем о ней отчитываются.

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

Глубина дерева при разумной гранулярности получается небольшой: для типичного проекта 3–4 уровня. Глубина свыше 5–6 уровней — обычно признак того, что в WBS пытаются закодировать расписание или архитектуру решения, а не состав работ.

Декомпозируем deliverable, а не процесс #

Частая ошибка при построении WBS — заполнение дерева фазами жизненного цикла: «анализ → проектирование → разработка → тестирование → внедрение». Такая структура описывает процесс, а не результат: она одинакова для всех проектов подряд, не показывает состав продукта и не поддаётся проверке правилом 100% (что значит «100% проектирования» — не определено). Фазовая структура работ не бесполезна — но её место в расписании, а не в WBS; фазы и WBS ортогональны: одна ось описывает «когда и в каком порядке», другая — «из чего состоит проект».

Практический тест для каждого элемента: можно ли передать результат этого элемента кому-то и принять его? Если да — перед вами deliverable. Если ответ «это деятельность, у неё нет передаваемого результата» — либо элемент сформулирован неверно, либо это работа более высокого порядка (управление проектом, которое в стандартах выделяется отдельной веткой верхнего уровня), либо декомпозиция пошла по процессному пути и её надо пересобирать.

Пример дерева #

Иерархия проекта «Мобильное приложение доставки еды» (три уровня, work packages — на нижнем):

Проект «Приложение доставки»
│
├── 1. Backend
│   ├── 1.1. Сервис заказов
│   │   ├── 1.1.1. API приёма заказов
│   │   ├── 1.1.2. Модуль оплаты
│   │   └── 1.1.3. Статусы и уведомления
│   ├── 1.2. Сервис геолокации
│   │   ├── 1.2.1. Трекинг курьера
│   │   └── 1.2.2. Расчёт времени доставки
│   └── 1.3. Административная панель
│       ├── 1.3.1. Управление меню заведений
│       └── 1.3.2. Отчётность
│
├── 2. Мобильное приложение
│   ├── 2.1. Каталог и корзина
│   │   ├── 2.1.1. Экран каталога
│   │   └── 2.1.2. Корзина и оформление заказа
│   ├── 2.2. Отслеживание заказа
│   │   ├── 2.2.1. Карта курьера
│   │   └── 2.2.2. Push-уведомления
│   └── 2.3. Профиль пользователя
│
└── 3. Управление проектом
    ├── 3.1. План и отчётность
    └── 3.2. Приёмочные испытания и релиз

Как читать пример:

• элементы всех ветвей, кроме третьей, — результаты: сервис, экран, модуль можно передать, продемонстрировать и принять;
• ветка «Управление проектом» — допустимая практика: работы PM — тоже часть scope, их выделяют отдельной веткой верхнего уровня;
• каждый родитель проверен правилом 100%: например, «сервис геолокации» полностью состоит из трекинга и расчёта времени — и ничего из этого не дублируется в других ветвях;
• нижние элементы по масштабу близки к 8–80 часам — это work packages, пригодные для назначения и оценки.

Типы WBS #

Основание декомпозиции — вопрос, по которому родитель делится на детей — определяет тип структуры. Каноническим типом считается декомпозиция по результатам, остальные применяются по контексту.

Deliverable-oriented (по результатам) #

Дети — передаваемые результаты: подсистемы, компоненты продукта, документы, услуги. Тип описан в PMBOK Guide как основной и в MIL-STD-881 как обязательный для оборонных контрактов. Сильные стороны: проверяемость правилом 100%, естественная привязка приёмки (каждый deliverable можно принять и подписать) и устойчивость — результат не меняется от того, в каком порядке его достигают. Слабость — требует понимания состава результата до начала работ, что не всегда доступно в исследовательских проектах.

Phase-oriented (по фазам) #

Дети — фазы жизненного цикла: инициирование, планирование, исполнение, завершение. Структура проста в построении и знакома всем участникам, но описывает процесс, а не продукт: две разные разработки с одинаковым «наполнением» получат одинаковую WBS, и проверить полноту охвата по фазам невозможно. Применяется как временная мера на ранних стадиях, когда состав результата ещё не ясен, с постепенным замещением фазовых веток результатными по мере проработки содержания.

Org-oriented (по организационным единицам) #

Дети — подразделения или команды: «работы бэкенд-отдела», «работы маркетинга». Такая структура удобна для бюджетирования и закупок (денежные потоки привязаны к центрам затрат), но скрывает продукт: невозможно проверить, что команда действительно покрывает весь объём, а работы на стыке подразделений систематически выпадают или дублируются. Используется в крупных организациях как надстройка над результатной WBS — для сверки «что кому поручено», а не как замена ей.

Geographical (по локациям) #

Дети — места выполнения работ: регионы развёртывания, площадки, страны. Естественный выбор для строительных, инфраструктурных и network-проектов с физически распределённым результатом; в ИТ встречается при развёртываниях в нескольких дата-центрах или юрисдикциях. Ограничение то же, что и у орг-структуры: локация — не результат, и «сквозные» компоненты (единое ПО, общая документация) требуют отдельной ветки.

Сводная таблица #

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

WBS Dictionary #

Словарь WBS (WBS Dictionary) — сопроводительный документ, в котором каждый work package описан отдельной записью. Само дерево отвечает только на вопрос «что входит в проект»; всё, что нужно для управления пакетом, живёт в словаре. В PMBOK Guide словарь — обязательный спутник структуры работ; в MIL-STD-881 роль словаря выполняют контрактные приложения, где каждая запись имеет юридическую силу описания объёма.

Типовой состав записи словаря:

Пример фрагмента словаря для дерева из предыдущего раздела:

Словарь ведётся в таблице или вики-странице рядом с деревом; критично только одно: формулировки описаний и границ должны быть доступны всем участникам в актуальной версии. Записи «что не входит» — самая ценная часть словаря: именно они гасят пограничные конфликты до их возникновения. При изменении содержания проекта (новые работы, исключение старых) обновляются оба артефакта одновременно: дерево без словаря теряет точность, словарь без дерева — структуру.

Связь с другими артефактами PM #

WBS редко используется изолированно — это фундамент, на который опираются остальные плановые артефакты проекта. Набор связей практически однозначен: у каждого последующего инструмента WBS поставляет исходные данные.

WBS → диаграмма Ганта #

Work packages (или их задачи) становятся строками диаграммы Ганта: сначала состав работ определяется «что», затем расписание раскладывает это «что» по оси времени, добавляя даты, длительности и зависимости. Порядок строгий: расписание без готовой WBS строится от выдуманных задач и требует переделки при первом же уточнении состава. Обратная связь тоже работает: пакет, который на Гантте выглядит одной полосой в несколько месяцев, слишком крупен для WBS — его декомпозируют.

WBS → RACI-матрица #

Строки RACI-матрицы — задачи одного уровня детализации; WBS — их естественный источник. Work packages верхнего уровня или укрупнённые ветки ложатся в строки матрицы, и каждая строка получает ответственного. Связь двусторонняя: RACI не изобретает работы, а распределяет уже декомпозированные; если в матрице появилась строка, которой нет в WBS, — либо scope неполон, либо задача чужая этому проекту.

WBS → бюджет и контроль затрат #

Оценка затрат собирается снизу вверх: каждый work package оценивается отдельно (в часах или деньгах), суммы агрегируются по дереву до бюджета проекта. Вершина дерева образует cost baseline — базовый план по стоимости. В развитых практиках (EVM — Earned Value Management) на WBS размечаются контрольные счета (control accounts) — точки, в которых сверяются план, факт и освоенный объём; без WBS сопоставление «сколько планировали на эту работу» теряет адресность. Оценка сложности самих пакетов — отдельная тема оценки проекта.

WBS → реестр рисков #

Дерево работ — систематический источник идентификации рисков: команда проходится по веткам и для каждого элемента спрашивает «что может помешать получению этого результата?». Такой обход полнее брейншторма «какие у нас риски», потому что покрыт каждый элемент scope, а не то, что пришло в голову. Найденные риски попадают в реестр рисков со ссылкой на элемент WBS; пакеты с высокой концентрацией рисков дополнительно декомпозируются, чтобы зоны неопределённости были видны точечно.

WBS → критический путь #

Зависимости между work packages (из словаря) образуют сеть работ, на которой вычисляется критический путь — самая длинная цепочка, определяющая длительность проекта. WBS поставляет узлы сети, словарь — дуги; критичность затем отображается подсветкой на диаграмме Ганта. Работы на критическом пути — первые кандидаты на дополнительную декомпозицию: чем крупнее пакет, тем грубнее оценка его длительности и тем сильнее он угрожает сроку.

Сводная схема #

                ┌──────────────────┐
                │       WBS        │  состав работ (scope)
                └────────┬─────────┘
        ┌────────┬───────┼────────┬─────────────┐
        ▼        ▼       ▼        ▼             ▼
     Гантт     RACI   Бюджет   Реестр      Критический
  (расписание) (роли) (EVM,    рисков       путь
                cost    (идентификация  (зависимости,
               baseline)  по элементам)   длительности)

Изменение WBS каскадно обновляет все производные артефакты — поэтому зрелые процессы изменения содержания (change control) начинают именно с вопроса «какой элемент WBS затрагивает изменение».

WBS vs PBS vs декомпозиция в разработке #

WBS — не единственная иерархия декомпозиции в арсенале проектного управления и разработки. Рядом стоят как минимум две структуры, которые регулярно путают с WBS или подменяют её.

PBS (Product Breakdown Structure, продуктовая структура) — иерархия продукта, а не работ: система → подсистемы → модули → детали. PBS отвечает на вопрос «из чего состоит результат», WBS — «какие работы нужны, чтобы этот результат получить». Разница тонкая, но принципиальная: один и тот же модуль (узел PBS) может требовать нескольких работ (узлов WBS) — проектирование, реализация, интеграция, — а некоторые работы WBS не имеют собственного узла в PBS (управление проектом, обучение пользователей, миграция данных). В крупных инженерных программах PBS и WBS строятся парой и взаимно ссылаются; deliverable-oriented WBS по форме близка к PBS, но остаётся деревом работ: её лист — работа по созданию результата, а не сам результат.

Декомпозиция в разработке ПО — практика разбиения задач разработки, разобранная в отдельной статье: эпики на фичи, фичи на истории и технические задачи, оценка в стори-поинтах. Это рабочий инструмент команды внутри итерации; WBS же — инструмент планирования проекта от scope до бюджета.

Когда что использовать:

• WBS — при планировании проекта: фиксация scope, основа расписания, бюджета и распределения ответственности. Обязательна в контрактной и масштабной разработке.
• PBS — при проектировании: согласование состава системы между архитектурой, заказчиком и подрядчиками до того, как работы запланированы. Естественный «предшественник» deliverable-oriented WBS.
• Декомпозиция разработки — внутри итераций: живой процесс команды, не требующий формального дерева и change control.

Границу удобно проводить по вопросу: «что делаем, чтобы получить результат» — WBS; «из чего состоит результат» — PBS; «как команду разбить работу недели» — декомпозиция разработки.

WBS в Agile #

Иерархия бэклога как WBS #

Формальная WBS с change control плохо совместима с ценностью адаптивности, но сама функция — декомпозиция объёма от общего к частному — в Agile сохранена: её выполняет иерархия бэклога продукта: Epic → Feature → Story → Task. Эпик — крупная инициатива (по масштабу близка к ветке WBS верхнего уровня), фича — осязаемая часть ценности, пользовательская история — элемент, помещающийся в итерацию, задача — технический шаг внутри истории. Нижние уровни иерархии — прямые функциональные аналоги work packages.

Отличия от классической WBS принципиальны в двух пунктах. Во-первых, иерархия бэклога подвижна: элементы дробятся, сливаются и переформулируются по мере обучения, и никто не согласовывает каждое изменение — отличие от WBS, защищённой процедурой управления изменениями. Во-вторых, бэклог приоритизирован: порядок и состав ближайших работ важнее полноты всего дерева, тогда как WBS требует полноты сразу. Глубина детализации также неравномерна: ближайшие эпики разобраны до историй, отдалённые остаются крупными («дальше — крупнее», similar to rolling wave planning).

Отдельный элемент — spike: короткое исследовательское задание для снижения неопределённости (технический спайк — про осуществимость, функциональный — про требования). В терминах WBS спайк — work package особого рода: его результат — знание, а не продукт; его deliverable — решение или уточнённая оценка.

Связь с roadmap #

Дорожная карта продукта связывает иерархию бэклога со временем: эпики и фички получают целевые окна (кварталы, релизы), образуя верхний уровень плана. Это аналог верхних уровней WBS + расписание верхнего уровня: roadmap отвечает «что и когда в больших кусках», не детализируя отдельные истории. Team- и program-уровни масштабных фреймворков (типа SAFe) достраивают ту же лестницу: программные инкременты собирают эпики команд в планируемое целое — по сути, кросс-командная WBS с фиксированным ритмом пересборки.

Когда формальная WBS применима в Agile #

Полноценная WBS не заменяется иерархией бэклога в трёх ситуациях:

• зависимости между командами: когда эпик требует согласованных работ нескольких команд, формальная структура работ с ответственными за каждый элемент выявляет стыки, которые самоорганизация отдельных команд не закрывает;
• бюджет и контракт: фиксированная цена, гранты, бюджетные процессы требуют декомпозиции scope до суммируемых элементов — заказчику и финансам нужна WBS с оценками, независимо от того, как внутри итераций команда перетасовывает истории;
• отчётность и соответствие: регулируемые среды требуют трассируемости «требование → работа → результат», которую даёт связка WBS + словарь.

Практический компромисс: WBS верхнего уровня (эпики и крупные пакеты) — формальная, со словарём и бюджетом; всё, что внутри эпика, — живая декомпозиция команды на Scrum-итерациях. Правило 100% при этом сохраняет силу на формальном уровне: сумма эпиков покрывает весь согласованный объём.

Плюсы и минусы #

Сильные стороны #

• Полнота scope. Правило 100% превращает вопрос «ничего не забыли?» из надежды на память в проверяемое свойство структуры: дыры видны при обзоре дерева.
• Единая система координат для команды. Нумерованное дерево даёт общий язык: «пакет 2.1.2 задерживается» понятно всем без расшифровки. Новые участники читают WBS как карту проекта.
• Базис оценки. Оценка снизу вверх по малым пакетам точнее и честнее оценки «проект целиком»; бюджет и сроки проекта собираются из сумм пакетов, а не берутся с потолка.
• Фундамент остальных артефактов. Расписание, RACI, базельный бюджет, реестр рисков, критический путь — все получают исходные данные из одной структуры, что снимает рассинхрон между планами.
• Точка для управления изменениями. Каждое изменение содержания получает адрес — элемент WBS, — и влияние изменения видно сразу: какие пакеты, суммы и сроки затронуты.

Слабые стороны #

• Устаревает в изменчивой среде. WBS фиксирует состав работ на момент планирования; в проектах с высокой скоростью обучения (продуктовая разработка, R&D) структура устаревает быстрее, чем её пересматривают, и превращается в фикцию, с которой все работают «по факту иначе». Отчасти лечится rolling wave — детализацией только ближайших ветвей.
• Ложная точность. Чем детальнее дерево, тем больше его сопровождение стоит: тысячи пакетов требуют словаря, владельцев и синхронизации с реальностью. Очень подробная WBS создаёт видимость контроля, которого нет: точность оценок не растёт от дробления бесконечно, а бюрократия — растёт.
• Не показывает время и зависимости. Дерево состава вводит в заблуждение тех, кто ждёт от него плана: последовательность, параллельность и загрузка ресурсов в WBS не видны. Инструмент отвечает «из чего состоит», а не «как идти».
• Требует понимания результата. Deliverable-oriented декомпозиция невозможна, пока состав результата неизвестен; на ранних стадиях приходится начинать с фазовой структуры и терпить её неполноту.

Типичные ошибки #

Последняя строка таблицы — самая коварная: как и любой плановый артефакт, WBS работает только пока ей пользуются; дерево, с которым не сверяются при планировании и изменениях, — не инструмент, а украшение репозитория.

Заключение #

WBS — простая по замыслу структура (дерево работ с двумя инвариантами), из которой вытекает большая часть плановой архитектуры проекта. Пять тезисов статьи:

• WBS декомпозирует результат (deliverable), а не процесс: элементы — то, что можно передать и принять; фазы и активности — не элементы дерева.
• Правило 100% — фундаментальный инвариант: сумма детей равна родителю на каждом уровне, всё дерево покрывает объём проекта; без этого инварианта scope неполон или избыточен.
• Work package — нижний уровень с гранулярностью 8–80 часов: меньше — микроменеджмент, больше — потеря контроля и точности оценок.
• WBS — базис остальных PM-артефактов: расписание (Гантт), RACI, бюджет и контрольные счета, реестр рисков и критический путь получают исходные данные из одного дерева.
• В Agile роль WBS выполняет иерархия бэклога Epic → Feature → Story; формальная структура остаётся необходимой для зависимостей между командами, бюджета и отчётности.

Осознанное построение WBS — один из самых дешёвых способов навести порядок в содержании проекта: часы работы над деревом экономят недели споров о том, «что вообще входит в проект».

См. также #

• Введение в управление проектом — место WBS среди базовых понятий проектного управления.
• Декомпозиция проекта — прикладная декомпозиция задач разработки ПО: методы и уровни.
• Диаграмма Ганта — куда work packages ложатся строками расписания.
• RACI-матрица — распределение ответственности по элементам WBS.
• Треугольник проекта — содержание (scope), структурируемое WBS, как одна из вершин баланса.
• Управление рисками — идентификация рисков обходом элементов WBS.
• Критический путь — сеть зависимостей между work packages и расчёт длительности проекта.
• Scrum — итеративная среда, где формальную WBS заменяет иерархия бэклога.