Структура декомпозиції робіт: відмінності між версіями

[перевірена версія][перевірена версія]
Вилучено вміст Додано вміст
Немає опису редагування
м оформлення
Рядок 1:
'''Структура декомпозиції робіт''' ({{lang-en|work breakdown structure, WBS}})'''  у [[Управління проектами|проектному менеджменті]] та [[Системотехніка|системотехніці]] є орієнтованою на доконане виконання проекту декомпозицією проекту на менші частки. Структура декомпозиції робіт є ключовою часткою робіт по проекту, яка організовує командну роботу по проекту у керовані частини. [[PMBOK]] визначає структуру декомпозиції робіт як "«ієрархічну декомпозицію робіт, що має бути виконаною командою проекту та орієнтована на успішне завершення проекту"».
 
Елементом структури декомпозиції робіт може бути [[Продукт (економіка)|продукт]], [[дані]], [[Послуги]] або будь-яка комбінація вищезгаданого. Крім того,  WBS надає необхідний каркас для детальної оцінки термінів та контролю, а також надає управління для розробки графіків робіт і контролю за їх виконанням.<ref name="BAH">Booz, Allen & Hamilton [http://science.energy.gov/~/media/opa/powerpoint/Final_Module_2.ppt Earned Value Management Tutorial Module 2: Work Breakdown Structure], [http://science.energy.gov/opa/project-management/tools-and-resources/ Office of Science, Tools & Resources for Project Management], science.energy.gov. </ref>
 
== Огляд ==
Рядок 8:
Система декомпозиції робіт надає загальний каркас для природнього розвитку загального планування та контролю договору і є базисом для розподілу роботи у такі інкременти, що можуть бути визначеними, та з яких може бути зроблене [[Технічне завдання|Технічне Завдання]] і установлені звіти по технічним даним, графікам, вартостям, робочим годинам .<ref name="NASA01">NASA (2001). </ref>
 
Структура декомпозиції робіт дозволяє зібрати докупи підлеглі витрати по задачах, матеріалах тощо на вищий рівень "«батьківських"» задач, матеріалів тощо. Для кожного елементу структури декомпозиції робіт генерується опис задачі, що має бути виконаною.<ref>Electronic Industries Alliance Standard ''Systems Engineering Capability Model'' EIA-731.1</ref> Ця техніка (іноді називається ''структурою декомпозиції системи'' <ref>Institute of Electrical and Electronics Engineers ''Standard for Application and Management of the Systems Engineering Process'' IEEE Std 1220-20051220—2005</ref>) використовується для визначення і налагодження сумарних [[Рамки (керування проектами)|рамок]] [[Проект (управління проектами)|проекту]].
 
WBS організовується навколо ключових продуктів проекту (чи запланованих результатів), а не необхідних робіт для випуску продукту (заплановані дії). Так як заплановані результати є бажаним завершенням проекту, вони формують відносно стабільний набір категорій, у яких ціни запланованих для їх досягнення необхідних дій можуть бути зібрані докупи. Добре розроблена WBS робить легко досяжним призначення кожної діяльності проекту до виключно однієї термінальної події у WBS. Додатково до її функцій у обліку витрат WBS також допомагає співвіднести вимоги одного рівня системних специфікацій до іншого, наприклад, відповідність матриці вимог перехресних посилань до функціональних вимог на вищий чи нижчий рівні документації.
Рядок 15:
 
== Історія ==
Концепт структури декомпозиції робіт був розроблений у рамках [[Техніка оцінювання та аналізу програм|Техніки Оцінювання та Аналізу Програм]] (PERT) [[Міністерство оборони США|Міністерством Оборони США]] (DoD). PERT був запропонований ВМС США у 1957 році для підтримки розробки ракетної програми [[Поларіс]].<ref>[http://www.crosstalkonline.org/storage/issue-archives/1998/199807/199807-0-Issue.pdf Fleming, Quentin W., Joel M. Koppelman "«Earned Value Project Management"» CROSSTALK: The Journal of Defense Software Engineering July 1998, p 20]</ref> В той час як термін "«структура декомпозиції робіт"» не був вживаний, найперша імплементація PERT організувала задачі у продукто-орієнтовані категорії.<ref>Haugan, Gregory T., Effective Work Breakdown Structures, pp7-8</ref>
 
У червні 1962 року, DoD, [[Національне управління з аеронавтики і дослідження космічного простору|NASA]] та аерокосмічна індустрія опублікували докумен для системи PERT/COST, що описував підходи WBS.<ref>DOD and NASA Guide, PERT/COST System Design, June 1962</ref> Цей путівник був представлений Міністром Оборонидля ухвалення всех послуг.<ref>Hamilton, R. L., ''[http://handle.dtic.mil/100.2/AD603425 Study of Methods for Evaluation of the PERT/Cost Management System]'', MITRE Corporation, June 1964</ref> У 1968 році, DoD видав "«Структура Декомпозиції Робіт Для Товарів Військової Техніки"» (MIL-STD-881), військовий стандарт, що потребував використання структур декомпозиції робіт у DoD.<ref>MIL-STD-881, 1 November 1968</ref>
 
Документ був переглянутий кілька разів, останній раз у 2011 році. Поточна версія цього документу може бути знайдена у "«Струкрути Декомпозиції Робіт для Товарів Військової Техніки"» (MIL-STD-881C).<ref>MIL-STD-881C, ''[http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=36026 Work Breakdown Structures for Defense Materiel Items]'', 3 October 2011</ref> Він включає визначення WBS для специфічних систем військових товарів, та стосується елементів WBS, що є спільними для всіх систем.
[[Файл:Work_Breakdown_Structure_of_Aircraft_System.jpg|right|thumb|300x300px|Приклад із MIL-HDBK-881, що відображає перші три рівні типової системи повітряного апарату.<ref name="SEF01">[http://www.dau.mil/pubs/pdf/SEFGuide%2001-01.pdf ''Systems Engineering Fundamentals.''] </ref>]]
Категорії товарів Військової техніки згідно MIL-STD-881C є:
Рядок 33:
* WBS систем запуску транспортних засобів
* WBS автоматизованих інформаційних систем
Спільними елементами, визначеними у MIL-STD-881C, Додаток L, є: Інтеграція, збір, тестування та перевірка; Інжинірингові системи; Програмний Менеджмент; Тест і Оцінка систем; Тренування; Дані; Обладнання Власної Підтримки; Обландання Загальної Підтримки; Оперитвна/Місцева активація; Промислові об’єктиоб'єкти; Початкові Запчастини та Частини для Ремонту. Стандарт також включає додаткові спільні елементи, що є унікальними для Космічних Систем, Систем Запуску транспортних засобів та Автоматизованих Інформаційних Систем.
 
у 1987 році,  [[PMI|Інститут Проектного Менеджменту]] (PMI) задокументував розширення цих технік на використання не лише в системах оборони. У книзі ''Звід Знань по Проектному Менеджменту'' (PMBOK) викладений концепт WBS, в той час як "«Практичний Стандарт для Структур Декомпозицій Робіт"» є порівняним дл книги DoD, проте призначений для більш загального використання.<ref>Haugan, Gregory T., The Work Breakdown Structure in Government Contracting, Management Concepts, 2003 ISBN 978-1567261202</ref>
 
== Принципи ==
 
=== 100&nbsp;% керування ===
Важливий принцип конструкції для роботи структур декомпозиції називається 100&nbsp;% керування..<ref>''Effective Work Breakdown Structures'' By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN 1567261353, p.17</ref> Він визначається наступним чином:
: 100&nbsp;% керування визначає, що WBS включає в собі 100&nbsp;% роботи, що виділена в межах проекту та охоплює всі [[Результат (проектний менеджмент)|результати]] –&nbsp;— внутрішні, зовнішні, проміжні&nbsp;— що мають бути завершені з точки зору виконуваної роботи, включаючи проектний менеджмент. 100&nbsp;% керування є одним з найважливіших принципів, що керують розробкою, декомпозицією та оцінкою WBS. Правило застосовується до усіх рівнів у наступній ієрархії: сума робіт на "«дочірньому"» рівні має бути рівною 100&nbsp;% роботи, що представлена "«батьківським"» рівнем, а також WBS не смає містити будь-якої роботи, яка не є частиною актуальних меж, визначених проектом, що в свою чергу визначає, що вміст не може бути більшим за 100&nbsp;% роботи… Важливо пам’ятатипам'ятати, що правило 100&nbsp;% керування також застосовується до рівня діяльностей. Робота, що відтворюється діяльностями у кожному робочому пакеті, має складати 100&nbsp;% роботи, необхідної для його завершення.<ref>''Practice Standard for Work Breakdown Structures (Second Edition)'', published by the [[PMI|Project Management Institute]], ISBN 1933890134, page 8</ref>
 
==== Взаємовиключні елементи ====
[[Несумісні події]]: Додатково до правила 100&nbsp;% керування, важливо пам’ятатипам'ятати про відсутність перекриттів між різними елементами у питанні визначенні меж в рамках структури декомпозиції робіт. Ця неоднозначність може призвести до подвійної роботи чи проблемах комунікації у питаннях відповідальності та авторитетності. Таке перекриття також може спричинити плутанину щодо обліку витрат проекту. У випадку, коли назви елементів WBS є неоднозначними, словник WBS може стати у нагоді задля прояснення відмінностей поміж елементами WBS. Словник WBS описує кожен компонент структури WBS разом з віхами, результатами, діяльностями, межами та інколи датами, ресурсами, витратами, якістю.
 
=== Заплановані висновки замість дій ===
У разі, якщо автор структури декомпозиції робіт спробує охопити будь-яку дієво-орієнтовану деталь у WBS, він/вона включить або забагато, або замало дій. Забагатість дій перевищать 100&nbsp;% бітьківських меж, в той час як замалість відставатиме від 100&nbsp;% батьківських меж. Найкращим шляхом є дотримання правила 100&nbsp;% керування для визначення елементів WBS у термінах результатів, а не дій. Це також гарантує, що WBS не буде занадто приписуючим, що збільшить винахідливість та креативне мислення у частини учасників проекту. Для нових проектів, що розробляють продукти, найбільш популярною технікою для гарантування результато-орієнтовної WBS є використання [[Структура декомпозиції продукту|структури декомпозиції продукту]]. [[Feature Driven Development|Розробка, керована функціональністю]] може використовувати схожу техніку, що має утворити структуру декомпозиції ознак. Коли проект надає професійні послуги, зазвичай використовується техніка охоплення всіх запланованих результатів для створення результато-орієнтовної WBS.<ref>Swiderski, Mark A., PMP [https://www.workbreakdownstructure.com/work-breakdown-structure-according-to-pmbok.php workbreakdownstructure.com], PMBOK-Work Breakdown Structures. </ref> Структури декомозиції робіт, що розділяють роботу на фази проекту (наприклад, попередній етап проектування, фаза критичного технологічного планування) мають гарантувати, що фази чітко розділені запланованими результатами та вони такох використовуютсья доя визначення [[критерій завершення|критерію завершення]] (наприклад, затверджений у минулому чи огляд критичної технічної частини).
 
=== Рівень деталізації ===
Має існувати кінцева точка завершення поділу роботи на менші частини. Це допоможе у визначенні тривалості діяльностей, що необхідні для вироблення результату, що визначений у WBS. Є кілька евристичних чи "«емпіричних правил"», що використовуються при визначенні відповідної тривалості для діяльності чи групи діяльностей, необхідних для вироблення специфічного результату, визначеного WBS.
* Першим є "«правило 80 годин"», яке визначає, що жодна одинична діяльність чи група діяльностей на найнижчому рівні деталізації у WBS  для отримання результату не може тривати більш ніж 80 робочих годин.
* Друге емпіричне правило визначає, що жодна діяльність чи група діяльностей на найнижчому рівні деталізації у WBS не боже бути довшою за одиничний звітний період. Таким чином, якщо команда проекту звітується по прогресу проекту щомісячно, жодна одинична діяльність чи їх група не може тривати більше місяця.
* Останнє евритичне правило є правилом "«чи є це доцільним"». Застосовуючи це емпіричне правило, можна застосувати "«здоровий глузд"» при створенні тривалостей діяльностей чи груп діяльностей, що необхідні для вироблення результату, визначеного у WBS.
Робочий пакет на рівні діяльностей є задачею, яка:
* може бути реалістично і впевнено оцінена;
Рядок 62:
 
=== Схема кодування ===
Для елементів структури декомпозиції робіт є частою практика послідовної нумерації при створенні ієрархічної структури. Метою нумерації є надання послідовного підходу до визначення та управління WBS у вигляді системи неалежно від вендору чи обслуговування.<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶4.3</ref> Наприклад, '''1.1.2 Просування''' (у прикладі нижче) визначає цей елемент як Елемен Рівня 3 структури WBS, так як існує три числа, розділених [[Десятковий розділювач|десятковим розділювачем]]. Схема кодування також допомагає елементам WBS бути визначеними у будь-якому письмовому контексті.
 
Практичний приклад схеми кодування WBS:<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011 Appendix A, ¶A.3</ref>
Рядок 86:
: ''1.8 Обладнання Загальної Підтримки''
: ''1.9 Оперативна/Місцева Активація''
: ''1.10 Промислові об’єктиоб'єкти''
: ''1.11 Початкові Запчастини та Частини для Ремонту''
Приклад у сфері програмного забезпечення буде виглядати наступним чином:<ref name="PMH">Taylor, Michael, [http://www.pmhut.com/wbs-examples WBS Examples], PM Hut. </ref>
Рядок 103:
 
=== Термінальний елемент ===
Найнижчим елементом у [[Дерево (структура даних)|деревній структурі]], термінальним елементом, є такий, що не може бути надалі поділений. У структурі декомпозиції робіт такі (діяльності чи результати) елементи є елементами, що оцінюються як вимоги до ресурсів, [[Бюджет|бюджету]] та тривалості; пов’язаніпов'язані залежностями; а також заплановані. На стику елементу WBS та організаційного блоку, встановлюються рахунки управління та робочі пакети, планується продуктивність, вимірюється, записується та контролюється.<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶3.1.4</ref> WBS може бути деталізована до будь-якого рівня зацікавленості. Мінімально рекомендованими є три рівні, в той час як додаткові рівні мають бути заданими лише для елементів з високою вартістю чи високим ризиком,<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶1.4.1</ref> і два рівня деталізації у випадках, таких як системний інжинірінг чи програмний менеджмент,<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶2.2.4.2</ref> зі стандартами прикладами того, що WBS з різною глибиною, такі як розробка програмного забезпечення, доходять до 5 рівнів<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-6</ref>, або системи керування вогнем, що доходят до 7 рівнів.<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-1</ref>
 
=== Відповідність до норм ===
Найвищий рівень структури WBS має відповідати нормам чи шаблонам компанії, що існують всередині організації чи домену. Наприклад, кораблебудування для ВМС США має брати до уваги, що морські умови та відповідна ієрархічна структура мають відповідати стандарту MIL-STD<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Appendix E</ref>, включеному у Військово-Морську Архітектуру <ref><cite class="citation book">Gilmer, Thomas (1982-08-04). </cite></ref>, а також що відповідні Воєнно-Морські офіси і процедури були побудовані у відповідності до цієї архітектури, тому будь-яка істотна зміна у нумерації елементів WBS чи неймінгу у ієрархії буде неприйнятною.
 
== Приклад ==
[[ImageФайл:WbsConstruction.png|thumb|left|260px|Техніка конструювання WBS, що використовує правило 100&nbsp;% керування під час побудови.]] Фігура зліва показує структуру декомпозиції робіт для техніки будування, що демонструє правило 100&nbsp;% керування, а також техніку "«прогресивної розробки"». На рівні WBS 1 показано 100 одиниць роботи як загальний обсяг проекту для конструювання та побудови користувацького велосипеду. На рівні WBS 2, 100 одиниць розподілені у сім елементів. Кількість одиниць, виділених на кожен елемент роботи, може бути базований на об’ємуоб'єму зусиль чи вартості; задачі оцінити тривалість не встановлено.
 
Три найбільших елементи WBS Рівня 2 надалі діляться на Рівні 3. Кожен з двох найбільших елементів на Рівні 3 визначає лише 17&nbsp;% загального об’ємуоб'єму проекту.  Ці більше елементи можуть бути надалі поділені за допомогою використання техніки ''прогресивної розробки,'' що описана вище.
 
Дизайн WBS може бути підтриманий програмним забезпеченням (таким як [[Електронний аркуш]]), що дозволить автоматичне встановлення контрольних точок. Оцінки зусиль чи вартостей можуть бути розробленими шляхом обговорень членами команди. Ця спільна техніка створює велику проникність у визначення меж проекту, припущень та консенсусів, стосовно необхідного рівня деталізації для управління проектами.
 
== Оманливі уявлення ==
* WBS не є вичерпним переліком необхідних до виконання робіт. Насправді вона є комплексною класифікацією рамок проекту.
* WBS не є ані [[план проекту|планом проекту]], ані графіком виконання, ані хронологічним списком. Вона лише визначає, "«що"» саме буде зроблено, а не "«як"» чи "«коли"».
* WBS не є ієрархією організації, хоча й може використовуватися при призначенні відповідальності. Дивіться також: [[Матриця відповідальності|Матриця Відповідальності]] (інша назва ''Кадрова Матриця'').
 
Рядок 132:
== Подальше  читання ==
* Carl L. Pritchard. <cite>Nuts and Bolts Series 1: How to Build a Work Breakdown Structure</cite> ISBN 1-890367-12-5
* Project Management Institute. <cite>Project Management Institute Practice Standard for Work Breakdown Structures, Second Edition (2006)</cite> ISBN 1-933890-13-4 (Note: The Second Edition is an extensive re-write of the Practice Standard.)
* Gregory T. Haugan. <cite>Effective Work Breakdown Structures (The Project Management Essential Library Series)</cite> ISBN 1-56726-135-3
* Dennis P. Miller, PMP, <cite>"«Building Your Project Work Breakdown Structure --&nbsp;— Visualizing Your Objectives, Deliverables, Activities and Schedule"». </cite><cite>ISBN 1-42006969-1 (Note: This new book is essentially a facilitator's guide for planning a project based on the WBS.)</cite>
 
== Посилання ==
== Зовнішні посилання ==
{{commonscat|Work breakdown structures}}