Work Breakdown Structure (WBS, иерархическая структура работ)

Любая WBS (Work Breakdown Structure, иерархическая структура работ, ИСР) отвечает на вопрос, который кажется банальным: на какие части разрезать большую работу. От ответа зависит, получится ли этой работой управлять. В 1980 году Окаяма и Чирилло в отчёте «Product Work Breakdown Structure» разобрали практику судостроителей. Традиционные верфи делили работу по функциональным системам судна. Для смет и ранних стадий проектирования такое деление естественно. В планировании и исполнении оно давало плохую координацию и слишком крупные пакеты работ: по ним нельзя было контролировать материалы, человеко-часы и сроки. На деле судно, как и большинство изделий, собирают из закупленных и изготовленных деталей, соединяют их в подсборки, подсборки — в блоки. Деление работ, которое повторяет этот реальный путь изделия, оказалось гораздо управляемее.

Тот же принцип закреплён в PMBOK — своде знаний Института управления проектами (PMI). Там иерархическая структура работ определена как ориентированная на результаты (deliverable-oriented) иерархическая декомпозиция работ, которые выполняет команда проекта. В более поздней формулировке, которую приводит Википедия, речь идёт о декомпозиции всего объёма работ, нужного для достижения целей проекта и создания требуемых результатов. Главное слово здесь — «результаты». Структура фиксирует, что должно появиться на выходе, а не какие действия совершат люди.

Ниже — история метода от ракетной программы Polaris до справочника NASA 2021 года, правила построения со ссылкой на первоисточники и расхождения между стандартами и популярными пересказами. Дальше — шесть типовых ошибок, план на три недели и разбор бесплатного фрейма OrgDevTools, который проверяет правило 100% на всех уровнях дерева.

Происхождение и исследовательская база WBS

У метода три линии происхождения: оборонно-космическая, линия PMI и британская школа Association for Project Management (APM). Параллельно идёт академическая работа, в основном инженерная и строительная.

Оборонно-космическая линия: Polaris, PERT/COST, MIL-STD-881

По данным Википедии, подход возник в ВМС США в 1957 году при разработке ракетной программы Polaris. К июню 1962 года Министерство обороны США, NASA и аэрокосмическая отрасль выпустили документ по системе PERT/COST, где был описан и подход к декомпозиции работ. Сама техника планирования PERT выросла в той же среде. В 1968 году Министерство обороны издало военный стандарт MIL-STD-881 «Work Breakdown Structures for Defense Materiel Items». Он обязал использовать иерархические структуры работ во всём ведомстве. Иногда метод называют system breakdown structure — декомпозицией системы.

Там же сформулирована его управленческая роль. Структура работ даёт общий каркас для планирования и контроля контракта. На её основе работу делят на определимые части, пишут техническое задание (statement of work) и выстраивают отчётность по технике, графику, стоимости и трудозатратам.

Самый подробный современный документ этой линии — «NASA Work Breakdown Structure (WBS) Handbook» (NASA/SP-20210023927, ноябрь 2021). Согласно справочнику, структура работ и её словарь (WBS Dictionary) — обязательные элементы управленческой базовой линии проекта. Это следует из директив NPR 7120.5, NPR 7120.7, NPR 7120.8 и раздела NFS Part 1834. Структура остаётся ядром базовой линии на всех фазах жизненного цикла. Руководитель проекта и команда отвечают не только за первичную разработку, но и за её поддержание и контроль изменений. Стандартные шаблоны NASA применяются к проектам, запущенным начиная с 1 июня 2005 года.

Линия PMI: PMBOK и практический стандарт

В PMBOK иерархическая структура работ — часть управления содержанием проекта. Подробную методологию PMI вынес в отдельный практический стандарт — Practice Standard for Work Breakdown Structures. Эрик Норман, Шелли Бразертон и Роберт Фрайд руководили разработкой второго издания этого стандарта. В 2008 году они выпустили книгу «Work Breakdown Structures: The Foundation for Project Management Excellence». Авторы описывают структуру работ как фундамент управления проектом. Она одновременно делает содержание проекта ясным для всех участников и служит инструментом мониторинга и контроля. Книга расширяет стандарт и показывает, как внедрять метод на протяжении жизненного цикла проекта.

Формулировку PMBOK используют и государственные методологии. Так, руководство Enterprise Performance Life Cycle Министерства здравоохранения США (HHS) опирается на определение PMI. Оно добавляет важное разграничение: структура работ определяет «что» проекта, а график — «когда» и «кто».

Британская линия: PBS в паре с WBS

APM рассматривает две структуры вместе: структуру продукта (Product Breakdown Structure, PBS) и структуру работ. Для каждой предусмотрены свои тесты корректности и свои способы применения — при планировании и при ведении проекта. Логика пары простая. Сначала фиксируют, какие продукты должны появиться. Затем — какая работа нужна, чтобы их создать. Это перекликается с выводом Окаямы и Чирилло: работу удобнее делить по тому, как реально собирается продукт.

Академические исследования

Боаз Голани и Авраам Штуб в главе «Work Breakdown Structure» (2001) выводят метод из разделения труда и организационных структур. Они разбирают связь организации проекта с декомпозицией работ, типы структур, пакеты работ, контроль изменений и роль структуры в обучающейся организации. К главе приложено оглавление типового технического задания.

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

Хосе Гарсия-Форньелес, Ип-Шинг Фан и Перес (2003) изучали проекты модернизации самолётов. Их исходный тезис: то, как строится структура работ, зависит от человека и его точки зрения. Ключевые навыки в таких проектах похожи, но точных повторов почти нет, и без хорошей структуры информацию прошлых проектов трудно использовать заново. По итогам глубокого изучения работы одной промышленной компании авторы предложили интегрированную структуру, которая учитывает информационные потребности и взгляды разных участников.

Амира Шарон и Дов Дори (2014) на упрощённом примере беспилотного летательного аппарата показали проблему традиционного подхода. Компоненты изделия и обеспечивающие продукты в структуре работ часто не выражены явно. Авторы предлагают выводить её из единой модели жизненного цикла «проект — продукт».

Альберто Серезо-Нарваэс, Андрес Пастор-Фернандес и Мануэль Отеро-Матео (2020) анализировали интеграцию структуры затрат (Cost Breakdown Structure, CBS) со структурой работ в строительстве. Их отправная точка: управление содержанием помогает реагировать на отставание по срокам, бюджету и качеству, сокращает изменения и пропуски в бюджете, повышает точность смет и ответов на риски. Но работает оно только поверх надёжной структуры работ, которая полно и иерархически отражает все задачи и пакеты.

Прикладных работ несколько.

• Сержиу Секейра и Эурику Лопеш (2015) предложили простой метод ранней оценки стоимости по структуре работ. Метод использует матрицу распределения ответственности (responsibility assignment matrix, RAM) и электронную таблицу. По заявлению авторов, смоделированные оценки показали более высокую точность.

• Вания Элсие, Юсуф Латиф и Лени Сагита (2018) разработали стандарт структуры работ с учётом рисков для плана безопасности конструктивных работ. Идея в том, чтобы выявлять опасности по каждому виду работ, заложенному в структуру.

• Монти Сутрисна, Чамил Эрик Раманаяка и Джек Стивен Гулдинг (2018) построили матрицу структуры работ для модульного строительства (offsite). Они обнаружили расхождения между площадочными и заводскими процессами, а также повторы и дублирование работ.

• Дуаньшунь Ли и Мин Лу (2016) предложили автоматическую генерацию структуры работ и сетевой модели «работа в узле» для земляных работ на основе оптимизации потоков.

• Маха Аль-Касасбе, Осама Абудайе и Хэсю Лю (2020) использовали структуру работ как единый каркас для управления активами зданий. Их аргумент: стандартные классификаторы вроде UniFormat или MasterFormat создавались для других целей и напрямую под эту задачу не подходят.

• С. Гейзен (2010) организовывал 3D-модели BIM по структуре работ, чтобы улучшить поиск коллизий между системами здания.

Структура работ — не таблица задач, а договорённость о том, из каких результатов состоит проект. Всё остальное — график, бюджет, риски, ответственность — прикрепляется к её узлам.

Ключевые идеи и принципы WBS

1. Принцип: результаты, а не действия

   Википедия формулирует этот принцип как «планируй итоги, а не действия» (plan outcomes, not actions). Руководство HHS выражается ещё жёстче. Структура описывает работу существительными и прилагательными, а не глаголами. В ней нет зависимостей, длительностей, действий и назначений ресурсов. Глаголы, связи и исполнители появляются позже — в графике.

   На практике это значит, что элемент называют результатом: «Фундамент», «Отчёт по пилоту», «Модуль оплаты». Формулировки вроде «Заливать бетон» или «Тестировать» не подходят. Результат либо есть, либо его нет — его можно принять. Процесс «заливать» может длиться бесконечно.

2. Принцип: правило 100%

   Правило 100% (100% rule) — центральное в методе, его называют все источники брифа. Структура охватывает 100% работ, входящих в содержание проекта. Каждый уровень дочерних элементов в сумме составляет ровно 100% родителя — без пропусков и без лишнего. Элементы первого уровня, по формулировке workbreakdownstructure.com, должны охватывать всё содержание проекта целиком. Руководство HHS говорит то же: структура организует и определяет 100% работ.

   У правила есть и обратная сторона, на которую указывает Institute of Project Management. Раз за пределы 100% выйти нельзя, правило помогает явно отслеживать, что в проект не входит. Всё, что не помещается ни в один элемент, — либо пропуск, либо работа вне согласованного содержания. Её нужно убрать или оформить изменением.

3. Принцип: элементы одного уровня не пересекаются

   Соседние элементы не должны делить между собой одну и ту же работу. Это иногда называют принципом MECE: взаимоисключающие и вместе исчерпывающие элементы. Если на одном уровне стоят «Стены» и «Кирпичная кладка», одна и та же работа попадает в два узла. Тогда трудозатраты считаются дважды, а за результат отвечают сразу двое — то есть никто. Правило 100% без этого условия теряет смысл: сумма может сойтись формально, но за счёт двойного учёта.

4. Принцип: уровни и кодирование

   Число уровней — отдельная тема у конкурентов (levels). Пример из учебных материалов CUNY показывает стандартную логику нумерации. Уровень 1 — код 1.0, весь проект. Уровень 2 — коды 1.1, 1.2, 1.3. Это сводный уровень, на котором часто ведут отчётность. Уровень 3 — коды 1.1.1, 1.1.2 и далее. Нумерация служит уникальным идентификатором каждого элемента.

   Материалы университета LSU добавляют требования к документу. Корневому узлу дают название и номер проекта. Дочерние узлы нумеруют через точку. Термины поясняют, указывают автора и дату. В учебном примере DePaul (проект установки по переработке топлива) верхний элемент «1.1 Fuel Processing Facility» раскладывается на концептуальное проектирование, проектирование, оборудование, строительство, администрирование проекта, разработку систем, пусконаладку и безопасность. Каждый из этих элементов детализирован до четвёртого уровня. Параллельно ведётся шестизначный код для учёта.

5. Принцип: уровень детализации и терминальный элемент

   Википедия выделяет уровень детализации (level of detail) и терминальный элемент (terminal element) — нижний узел ветви, дальше которого декомпозиция не идёт. Обычно это пакет работ (work package). Самый практичный критерий остановки даёт LSU. Дробить достаточно, когда по каждой единице работы можно:

   • оценить все ресурсы, нужные для её выполнения;

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

   Популярные гайды, например Institute of Project Management, предлагают эвристику «8/80». Пакет нижнего уровня занимает не меньше 8 и не больше 80 часов трудозатрат. Мельче — растут накладные расходы на учёт. Крупнее — падает точность оценки и контроля.

   Здесь есть расхождение, о котором стоит знать. В материалах LSU под похожим названием «правило 80%» описана другая вещь: ни одна единица работы не должна составлять 80% и более всего объёма. Это ограничение доли, а не часов. Обе эвристики — ориентиры, а не нормы стандарта. Первичен критерий «можно оценить и связать». Окаяма и Чирилло показали, к чему приводит его нарушение: пакеты, слишком крупные для контроля материалов и человеко-часов.

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

6. Принцип: пакеты работ, пакеты планирования и контрольные счета

   На workbreakdownstructure.com описаны три типа узлов.

   • Контрольный счёт (control account) — узел, на котором руководство реально отслеживает бюджет, сроки и объём. Он объединяет несколько пакетов.

   • Пакет планирования (planning package) — часть содержания, которая уже точно входит в проект, но ещё не детализирована. Такие пакеты создают, чтобы соблюсти правило 100% и охватить всё содержание, даже когда подробностей пока нет.

   • Пакет работ (work package) — нижний уровень, по которому оценивают работу, назначают ответственного и измеряют выполнение.

   На этой иерархии строится метод освоенного объёма. Плановую и фактическую стоимость и освоение считают по пакетам и сворачивают до контрольных счетов.

7. Принцип: словарь WBS

   Дерево содержит только названия и вложенность. Содержание каждого элемента описывает словарь (WBS Dictionary). По руководству CUNY, словарь перечисляет и определяет элементы структуры. У NASA он обязателен наравне с самой структурой. Workbreakdownstructure.com советует писать описания на уровне пакетов работ так подробно, чтобы было видно: всё содержание проекта покрыто.

   Практичный состав полей:

   • код;

   • название;

   • описание того, что входит в пакет;

   • явные исключения;

   • критерии приёмки;

   • владелец результата.

   Поле исключений особенно полезно: оно проводит границы между соседними пакетами. Это и есть рабочая проверка непересечения элементов.

8. Принцип: типы декомпозиции

   Workbreakdownstructure.com выделяет два основных типа и показывает оба на примере строительства дома.

   • Ориентированная на результаты (deliverable-based). Первый уровень — компоненты продукта: фундамент, каркас, инженерные системы, отделка.

   • Фазовая (phase-based). Первый уровень — фазы жизненного цикла, внутри них — результаты.

   Coursera добавляет процессную (process-oriented) декомпозицию. Она также перечисляет родственные структуры, которые часто путают с ИСР:

   • структуру ресурсов (resource breakdown structure);

   • структуру рисков (risk breakdown structure);

   • структуру затрат (cost breakdown structure);

   • организационную структуру (organizational breakdown structure).

   Обратите внимание: аббревиатура RBS обозначает и ресурсы, и риски. В документах проекта её лучше расшифровывать. У конкурентов встречаются и «ресурсная», и «по ответственности» структуры. Строго говоря, это не альтернативы декомпозиции содержания, а другие разрезы, которые накладываются на ту же иерархию кодов. Пример — исследование Серезо-Нарваэса с соавторами об интеграции CBS. В реальных проектах часто используют гибрид: верхние уровни по фазам, нижние по результатам. Опрос Ибрагима, Каки и Ауада как раз изучал, в какой последовательности британские строители применяют критерии деления по уровням иерархии.

9. Принцип: «что», а не «когда» и «кто»

   По руководству HHS, структура работ — не график проекта. Руководство CUNY формулирует то же иначе: структура и словарь — не график, а строительные блоки для него. Порядок работ, длительности и связи задаёт следующий слой. Это диаграмма Ганта, сетевая модель и метод критического пути. Workbreakdownstructure.com прямо ставит составление графика по Ганту последним шагом после словаря.

10. Принцип: соответствие нормам и шаблоны

    Википедия упоминает принцип соответствия нормам (consistent to norms). Структура должна совпадать с отраслевыми и корпоративными шаблонами, где они есть. У NASA это стандартные структуры для новых проектов. Ибрагим с соавторами предлагают стандартизировать структуру для строительства. Белая книга Conest описывает структуру работ как шаблон повторяемого процесса: единый стандарт для сметчиков, руководителей проектов и прорабов. До строительства по ней готовят более точную смету, на стройке — сверяют фактические затраты и полноту выполнения. В примере Conest с установкой генератора новые работы отделены от переделки существующей системы. Это хорошая иллюстрация границ между пакетами.

    Готовые шаблоны есть и в инструментах. У Atlassian шаблон для Jira собран из дорожной карты, бэклога, настраиваемых рабочих процессов и канбан-доски. По сути, верхние уровни структуры здесь превращаются в крупные элементы бэклога, а пакеты — в задачи.

11. Принцип: наглядность, иерархия, ясность

    Конкуренты перечисляют достоинства метода: наглядность (visuality), умение справляться со сложностью (complexity), иерархию (hierarchy) и ясность (clarity). За ними стоит один механизм. Большой проект перестаёт быть списком из сотен строк и становится деревом, где каждый узел — понятный результат. Форм представления три:

    • графическое дерево — для обсуждения с командой и заказчиком;

    • нумерованный список с отступами — для документа;

    • таблица с кодами — для связи со сметой и графиком.

Ограничения, слепые зоны и критика WBS

Типовые ошибки при работе с WBS

1. Ошибка 1: декомпозиция по действиям вместо результатов.

   Элементы называют глаголами: «Согласовать», «Разработать», «Протестировать». Дерево становится плоским списком дел, у которых нет точки завершения. Нельзя сказать, выполнен ли элемент, нельзя принять его по критериям, нельзя посчитать освоенный объём. Кроме того, в такую структуру неизбежно проникают зависимости и сроки, которым там не место.

   Как избежать

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

2. Ошибка 2: сумма дочерних элементов не равна 100%.

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

   Как избежать

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

3. Ошибка 3: пересекающиеся элементы.

   «Стены» и «Кирпичная кладка» на одном уровне, «Интеграция» и «API» рядом. Одна работа учтена дважды, у одного результата два владельца. При оценке трудозатрат сумма раздувается, а при сбоях каждый владелец ссылается на соседа.

   Как избежать

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

4. Ошибка 4: неправильная глубина декомпозиции.

   Пакеты по полгода работы для пятерых нельзя ни оценить, ни проконтролировать. Именно это Окаяма и Чирилло нашли у судостроителей. Обратная крайность — пакеты по два часа: учёт съедает больше времени, чем сама работа, и структура разрастается до сотен строк, которые никто не читает.

   Как избежать

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

5. Ошибка 5: дерево без словаря.

   Структура построена, а словаря нет — его считают бюрократией. Каждый участник понимает «Отчёт по пилоту» по-своему, а границы пакетов выясняются в спорах на приёмке. NASA не зря делает словарь обязательным наравне с самой структурой.

   Как избежать

   заводите словарь сразу на уровне пакетов работ с полями «код — название — что входит — что не входит — критерии приёмки — владелец». Описания должны быть настолько полными, чтобы по ним было видно покрытие всего содержания.

6. Ошибка 6: структура превращается в график.

   В узлы дописывают даты, длительности, связи «после того как» и фамилии исполнителей. Документ теряет главную функцию — показывать состав проекта. При каждом сдвиге сроков его приходится переделывать целиком, и структура замораживается в первом варианте.

   Как избежать

   держите слои раздельно. В структуре — «что». В словаре — границы и владелец результата. В графике — «когда» и «кто именно делает», с теми же кодами пакетов. Изменения содержания проводите через контроль изменений, изменения сроков — только через график.

План внедрения WBS

1. Неделя 1: подготовка и верхний уровень.

   • Соберите ключевые документы: устав проекта, описание содержания, требования, договор. Структура должна отражать утверждённое содержание проекта, а не пожелания.

   • Определите ключевых участников. Структуру строят руководитель проекта вместе с командой и экспертами по направлениям, а не в одиночку.

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

   • Сформулируйте элементы первого уровня и проверьте, что вместе они покрывают 100% содержания проекта.

2. Неделя 2: декомпозиция до пакетов работ.

   • Раскладывайте каждый элемент на подрезультаты, на каждом уровне проверяя правило 100% и отсутствие пересечений.

   • Останавливайтесь на пакетах, которые можно оценить по ресурсам и связать с другими. Сверяйтесь с эвристикой 8/80 часов.

   • Неясные части оформите пакетами планирования, чтобы не нарушать правило 100%.

   • Присвойте коды по схеме 1.0 — 1.1 — 1.1.1. В корне укажите название и номер проекта.

3. Неделя 3: словарь, владельцы и связь с графиком.

   • Заполните словарь по каждому пакету: что входит, что не входит, критерии приёмки, владелец результата.

   • Определите контрольные счета — уровень, на котором будете отслеживать бюджет и прогресс.

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

   • Привяжите к кодам смету и, если нужно, реестр рисков и структуру затрат.

   Далее: поддержание и обновление.

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

   Хорошая структура работ видна по тому, что на приёмке не спорят о границах. Каждый пакет закрывается по своим критериям, и ни одна работа не всплывает «из ниоткуда».

Как реализовать этот план с помощью фрейма «Work Breakdown Structure (WBS)» в OrgDevTools

Фрейм — бесплатный тренажёр. Он отрабатывает главное в методе: иерархическую декомпозицию и правило 100%. Фрейм устроен как три вкладки: «Дерево», «Визуализация» и «Итоги».

Вкладка «Дерево» (недели 1–2 плана).

• Корень. Это узел «Проект», доля у него не задаётся.

• Пример по умолчанию. В новом фрейме уже есть два дочерних элемента: «Разработка» (60%) и «Внедрение» (40%). Переименуйте их под свой проект.

• Название узла. Вводится текстом прямо в строке, подсказка — «Элемент работы».

• Доля. У каждого некорневого узла есть числовое поле процентной доли от родителя. Значения ограничены диапазоном 0–100.

• Добавление и удаление. Кнопка «+ подэлемент» добавляет дочерний узел с пустым названием и долей 0%. Кнопка «×» удаляет узел вместе со всеми его потомками.

• Проверка суммы. Под каждым узлом с детьми фрейм автоматически показывает строку «Сумма: N%». Если сумма не равна ровно 100, строка красная с пометкой «должно быть ровно 100%». Если равна — зелёная с пометкой «правило 100% выполнено».

• Счётчик ошибок. Число уровней с нарушением выводится красным прямо в заголовке вкладки — «N ошибка(и)».

На неделе 1 здесь фиксируют первый уровень. На неделе 2 по ним доводят декомпозицию до пакетов. Проверка требует точного равенства, поэтому три равные части задавайте как 33/33/34, а не дробями.

Вкладка «Визуализация» (неделя 2, проверка пропорций). Здесь показаны только листья дерева — рабочие пакеты — в виде горизонтальных полос. Для каждого фрейм считает абсолютную долю от всего проекта: перемножает проценты по цепочке родителей. Пакет с долей 50% внутри элемента с долей 40% даст 20% проекта. Вкладка помогает увидеть пакет, который занимает непропорционально большую часть проекта, и решить, не раздробить ли его дальше.

Вкладка «Итоги» (конец недели 2). Вердикт проверяет все уровни дерева сразу и выбирает один из трёх ответов по порядку:

• если в дереве только корень — подсказка начать декомпозицию;

• если правило 100% нарушено хоть где-то — предупреждение с числом таких уровней и именами родительских узлов, где сумма не сходится;

• если ошибок нет — подтверждение корректности и число рабочих пакетов (листьев).

Давайте узлам названия: если узел без имени, в вердикте вместо имени выводится его внутренний идентификатор.

Кнопка «Создать задачу →». Создаёт задачу с заголовком «Исправить нарушение правила 100% в WBS». В описание подставляется список узлов с нарушением, а если ошибок нет — число корректно декомпозированных пакетов.

В модуле проектов и задач OrgDevTools есть и отдельный рабочий инструмент «Иерархическая структура работ» с видом дерева. Это не тот же фрейм, а самостоятельный инструмент для реальных проектов. Тренажёр удобен, чтобы отработать структуру и проверить правило 100% до переноса в рабочую систему.

Книги по теме WBS

• Эрик Норман, Шелли Бразертон, Роберт Фрайд — «Work Breakdown Structures: The Foundation for Project Management Excellence» (2008). Авторы руководили разработкой второго издания практического стандарта PMI. Из книги взят взгляд на структуру как на основу ясного содержания и инструмент контроля на всём жизненном цикле проекта.

• NASA — «NASA Work Breakdown Structure (WBS) Handbook» (2021). Отсюда обязательность словаря наравне с деревом, роль структуры в базовой линии и требование поддерживать её и контролировать изменения на всех фазах.

• Боаз Голани, Авраам Штуб — глава «Work Breakdown Structure» (2001). Источник для связи структуры работ с организацией проекта, типов структур, пакетов работ и контроля изменений.