Структура розбиття робіт (Work Breakdown Structure - WBS)

Zosym Maxym

May 30, 2023 • 7 min read

Структура розбиття робіт (Work Breakdown Structure - WBS) в управлінні проектами та системній інженерії - це орієнтована на результат розбивка проекту на менші компоненти. Структура розбиття робіт є ключовим результатом проекту, який організовує роботу команди на керовані частини.

Звід знань з управління проектами (PMBOK® 7) визначає структуру розбиття робіт як "Ієрархічна декомпозиція загального обсягу робіт, які має виконати команда проекту для досягнення цілей проекту та створення необхідних результатів".

Елементом структури може бути продукт, дані, послуга або будь-яка їхня комбінація. WBS також забезпечує необхідну основу для детальної оцінки та контролю витрат, а також надає вказівки щодо розробки та контролю графіку.

Структура розбиття робіт (Work Breakdown Structure - WBS) є одним з етапів для Методу критичного шляху (Critical path method)

Загальний огляд Структури розбиття робіт (Work Breakdown Structure - WBS)

WBS - це ієрархічна та інкрементна декомпозиція проекту на фази, результати та пакети робіт. Це деревоподібна структура, яка показує розподіл зусиль, необхідних для досягнення мети, наприклад, програми, проекту або контракту.

У проекті або контракті WBS розробляється, починаючи з кінцевої мети і послідовно розбиваючи її на керовані компоненти за розміром, тривалістю і відповідальністю (наприклад, системи, підсистеми, компоненти, завдання, підзадачі і робочі пакети), які включають всі кроки, необхідні для досягнення мети.

Структура розбиття робіт (Work Breakdown Structure - WBS) забезпечує загальну основу для природного розвитку загального планування та контролю за контрактом і є основою для поділу робіт на чітко визначені етапи, на основі яких можна розробити технічне завдання та скласти технічну, календарну, вартісну та робочу звітність.

Структура розбиття робіт (Work Breakdown Structure - WBS) дозволяє підсумовувати підпорядковані витрати на завдання, матеріали і т.д. до їх послідовно вищого рівня "батьківських" завдань, матеріалів і т.д. Для кожного елемента структури розбиття робіт створюється опис завдання, яке потрібно виконати. Цей метод (іноді його називають структурою розбиття системи) використовується для визначення та організації загального обсягу проекту.

WBS організована навколо основних продуктів проекту (або запланованих результатів), а не робіт, необхідних для виробництва продуктів (запланованих дій). Оскільки заплановані результати - це бажані цілі проекту, вони утворюють відносно стабільний набір категорій, в яких можна зібрати витрати на заплановані дії, необхідні для їх досягнення.

Добре розроблена WBS дозволяє легко віднести кожну діяльність проекту до одного і тільки одного кінцевого елемента WBS. На додаток до своєї функції обліку витрат, WBS також допомагає відображати вимоги з одного рівня специфікації системи на інший, наприклад, матриця перехресних посилань відображає функціональні вимоги до проектної документації високого або низького рівня.

WBS може відображатися горизонтально у вигляді схеми або вертикально у вигляді деревовидної структури (як організаційна діаграма).

Розробка WBS зазвичай відбувається на початку проекту і передує детальному плануванню проекту і завдань.

Історія Структури розбиття робіт (Work Breakdown Structure - WBS)

Концепція структури розбиття робіт була розроблена в рамках Методу оцінки та аналізу програм (PERT) Міністерством оборони США. PERT був запроваджений ВМС США у 1957 році для підтримки розвитку ракетної програми "Поларіс". Хоча термін "структура розбиття робіт" не використовувався, ця перша реалізація PERT організувала завдання за категоріями, орієнтованими на продукт.

У червні 1962 року Міністерство оборони, НАСА та аерокосмічна промисловість опублікували документ для системи PERT/COST, який описував підхід WBS. Цей посібник був схвалений міністром оборони для прийняття всіма службами. У 1968 році Міністерство оборони випустило "Структури розбиття робіт для оборонних матеріальних засобів" (MIL-STD-881), військовий стандарт, що вимагає використання структур розбиття робіт в усьому Міністерстві оборони.

Документ неодноразово переглядався. Станом на травень 2023 року остання редакція - F, випущена 13 травня 2022 року. Історія версій і поточна редакція стенду розміщена на веб-сайті ASSIST Агентства логістики Міністерства оборони США (DLA). Він містить визначення WBS для конкретних систем товарів оборонного призначення і розглядає елементи WBS, які є спільними для всіх систем.

Категорії товарів оборонного призначення за стандартом MIL-STD-881F такі:

Авіаційні системи
Електронні/загальні системи
Ракетні системи/системи озброєння
Стратегічні ракетні системи
Морські системи
Космічні системи
Наземні транспортні системи
Безпілотні морські системи
Системи ракет-носіїв
Інформаційні системи/оборонні бізнес-системи

Загальні елементи, визначені в MIL-STD-881F, Додаток K, є наступними: Інтеграція, складання, випробування і перевірка; Системна інженерія; Управління програмами; Випробування і оцінка системи; Дані; Спеціальне допоміжне обладнання; Загальне допоміжне обладнання; Оперативна/майданчикова активація; Логістична підтримка підрядника; Промислові об'єкти; Початкові запасні частини і ремонтні деталі. Стандарт також включає додаткові спільні елементи, унікальні для космічних систем, систем ракет-носіїв і стратегічних ракетних систем.

У 1987 році Інститут управління проектами (PMI) задокументував розповсюдження цих методів на не оборонні організації. Посібник "Звід знань з управління проектами" (PMBOK) надає огляд концепції WBS, в той час як "Практичний стандарт для структур розбиття робіт" можна порівняти зі стандартом Міністерства оборони, але він призначений для більш загального застосування.

Якщо у вас в компанії потрібно розпланувати проект напишіть мені на пошту mzosim@gmail.com або в телеграмм @mzosim, я вам допоможу.

Принципи проектування

100% правило

Важливим принципом проектування структур розбиття робіт є правило 100%. Воно визначається наступним чином:

Правило 100% стверджує, що WBS включає 100% робіт, визначених обсягом проекту, і фіксує всі результати - внутрішні, зовнішні, проміжні - з точки зору робіт, які повинні бути виконані, включаючи управління проектом. Правило 100% - це один з найважливіших принципів, яким керуються при розробці, декомпозиції та оцінці WBS.

Правило діє на всіх рівнях ієрархії: сума робіт на "дочірньому" рівні повинна дорівнювати 100% робіт, представлених "батьківським", і WBS не повинна включати роботи, які виходять за межі фактичного обсягу проекту, тобто вона не може включати більше 100% робіт... Важливо пам'ятати, що правило 100% також застосовується до рівня робіт. Роботи, представлені роботами в кожному робочому пакеті, повинні складати 100% робіт, необхідних для завершення робочого пакету.

Взаємовиключні елементи

Взаємовиключні: На додаток до правила 100%, не повинно бути ніякого перетину у визначенні обсягу робіт між різними елементами структури розбиття робіт. Така невизначеність може призвести до дублювання робіт або непорозумінь щодо відповідальності та повноважень. Таке дублювання також може заплутати облік витрат проекту.

Якщо назви елементів WBS неоднозначні, словник WBS може допомогти прояснити відмінності між елементами WBS. Словник WBS описує кожен компонент WBS із зазначенням етапів, результатів, видів діяльності, обсягу, а іноді і дат, ресурсів, витрат, якості.

Плануйте результати, а не дії

Якщо розробник структури розбиття робіт спробує відобразити в WBS будь-які деталі, орієнтовані на дії, він, швидше за все, включить або занадто багато дій, або занадто мало дій. Занадто багато дій буде перевищувати 100% обсягу батьківської роботи, а занадто мало - не дотягувати до 100% обсягу батьківської роботи.

Найкращий спосіб дотримуватися правила 100% - це визначати елементи WBS в термінах результатів, а не дій. Це також гарантує, що WBS не буде надмірно директивним щодо методів, дозволяючи учасникам проекту проявляти більшу винахідливість і творче мислення.

Для проектів з розробки нових продуктів найпоширенішим методом забезпечення орієнтованої на результат WBS є використання структури розбиття продукту. Проекти програмного забезпечення, орієнтовані на функціональність, можуть використовувати аналогічну техніку, яка полягає у використанні структури розбиття на функції.

Коли проект надає професійні послуги, поширеною технікою є фіксація всіх запланованих результатів для створення WBS, орієнтованої на результат. Структури розбиття робіт, які поділяють роботи за фазами проекту (наприклад, фаза попереднього проектування, фаза критичного проектування), повинні гарантувати, що фази чітко розділені за результатом, який також використовується для визначення критеріїв входу і виходу (наприклад, затверджений попередній або критичний огляд проекту).

Рівень деталізації

Потрібно вирішити, коли припинити ділити роботу на менші елементи. Для більшості проектів буде достатньо ієрархії від двох до чотирьох рівнів. Це допоможе визначити тривалість робіт, необхідних для отримання результату, визначеного у WBS. Існує кілька евристик або "емпіричних правил", які використовуються при визначенні відповідної тривалості роботи або групи робіт, необхідних для отримання конкретного результату, визначеного у WBS.

Перше - це "правило 80 годин", яке означає, що жодна окрема робота або група робіт на найнижчому рівні деталізації WBS для отримання одного результату не повинна займати більше 80 годин зусиль.
Друге емпіричне правило полягає в тому, що жодна робота або група робіт на найнижчому рівні деталізації WBS не повинна тривати довше, ніж один звітний період. Таким чином, якщо команда проекту звітує про прогрес щомісяця, то жодна окрема робота або серія робіт не повинна бути довшою за один місяць.
Остання евристика - це правило "якщо це має сенс". Застосовуючи це емпіричне правило, можна керуватися "здоровим глуздом" при визначенні тривалості окремої роботи або групи робіт, необхідних для отримання результату, визначеного у WBS.

Робочий пакет на рівні діяльності - це завдання, яке

можна реалістично і впевнено оцінити;
не має сенсу практично розбивати на частини;
може бути виконане відповідно до однієї з евристик, визначених вище;
дає результат, який можна виміряти; та
формує унікальний пакет робіт, який можна передати на аутсорсинг або укласти контракт.

Схема кодування

Зазвичай елементи структури розбиття робіт послідовно нумеруються, щоб показати ієрархічну структуру. Мета нумерації - забезпечити послідовний підхід до ідентифікації та управління WBS в подібних системах, незалежно від постачальника або послуги.

Наприклад, 1.1.2 "Двигун" (у прикладі нижче) ідентифікує цей елемент як елемент 3-го рівня WBS, оскільки він має три цифри, розділені двома десятковими крапками. Схема кодування також допомагає розпізнавати елементи WBS в будь-якому письмовому контексті і дозволяє зіставляти їх зі словником WBS.

Якщо у вас в компанії потрібно розпланувати проект напишіть мені на пошту mzosim@gmail.com або в телеграмм @mzosim, я вам допоможу.

Практичним прикладом схеми кодування WBS є

1.0 Aircraft System
- 1.1 Air Vehicle
- - 1.1.1 Airframe
- - - 1.1.1.1 Airframe Integration, Assembly, Test, and Checkout
- - - 1.1.1.2 Fuselage
- - - 1.1.1.3 Wing
- - - 1.1.1.4 Empennage
- - - 1.1.1.5 Nacelle
- - - 1.1.1.6 Other Airframe Components 1..n (Specify)
- - 1.1.2 Propulsion
- - 1.1.3 Vehicle Subsystems
- - 1.1.4 Avionics
- 1.2 System Engineering
- 1.3 Program Management
- 1.4 System Test and Evaluation
- 1.5 Training
- 1.6 Data
- 1.7 Peculiar Support Equipment
- 1.8 Common Support Equipment
- 1.9 Operational/Site Activation
- 1.10 Industrial Facilities
- 1.11 Initial Spares and Repair Parts

Кінцевий елемент

Найнижчий елемент у деревоподібній структурі, кінцевий елемент, - це елемент, який не підлягає подальшому поділу. У структурі розподілу робіт такі елементи (роботи або результати), також відомі як робочі пакети, є елементами, які оцінюються з точки зору потреб у ресурсах, бюджету та тривалості; пов'язані між собою залежностями та графіком.

На стику елементів WBS та організаційного підрозділу створюються контрольні рахунки та робочі пакети, а також планується, вимірюється, реєструється та контролюється виконання робіт. WBS може бути виражена до будь-якого рівня зацікавленості.

Мінімально рекомендовано три рівні, з додатковими рівнями тільки для об'єктів з високою вартістю або високим ризиком, і двома рівнями деталізації в таких випадках, як системна інженерія або управління програмами, причому в стандарті наведені приклади WBS з різною глибиною, наприклад, розробка програмного забезпечення до 5 рівнів або системи протипожежного контролю до 7 рівнів.

Відповідність нормам

Вища структура WBS повинна відповідати будь-яким нормам або шаблонним мандатам, що існують в організації або галузі. Наприклад, суднобудування для ВМС США повинно враховувати, що морські терміни та їх ієрархічна структура, викладені в MIL-STD, вбудовані в морську архітектуру, і що відповідні офіси і процедури ВМС були створені відповідно до цієї структури морської архітектури, тому будь-яка значна зміна нумерації елементів WBS або імен в ієрархії буде неприйнятною.

Приклад WBS

На наступному рисунку показано техніку побудови структури розбиття робіт, яка демонструє правило 100% і техніку "прогресивної розробки". На 1-му рівні WBS показано 100 одиниць робіт як загальний обсяг проекту з проектування та виробництва велосипеда на замовлення. На 2-му рівні WBS ці 100 одиниць поділяються на сім елементів. Кількість одиниць, виділених для кожного елемента роботи, може базуватися на трудомісткості або вартості; це не є оцінкою тривалості завдання.

Три найбільші елементи рівня 2 WBS поділяються на рівні 3. Два найбільші елементи на рівні 3 представляють лише 17% від загального обсягу проекту. Ці більші елементи можна розбити на частини, використовуючи описану вище техніку прогресивної деталізації.

Це приклад підходу, заснованого на продукті (який може бути кінцевим продуктом, результатом або роботою), порівняно з поетапним підходом (який може бути обмеженим етапами формального життєвого циклу розробки систем, або вимушеними подіями (наприклад, щоквартальними оновленнями або перерозподілом бюджету на фінансовий рік), або підходом, заснованим на навичках/рольових функціях.

Дизайн WBS може бути підтриманий програмним забезпеченням (наприклад, електронною таблицею), щоб дозволити автоматичне згортання значень точок. Оцінки зусиль або вартості можуть бути розроблені шляхом обговорення між членами проектної команди. Цей метод спільної роботи дозволяє краще зрозуміти визначення обсягу робіт, основні припущення і досягти консенсусу щодо рівня деталізації, необхідного для управління проектами.

Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.