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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
[неперевірена версія][неперевірена версія]
Вилучено вміст Додано вміст
Narkulome (обговорення | внесок)
Створено шляхом перекладу сторінки «Work breakdown structure»
Narkulome (обговорення | внесок)
Створено шляхом перекладу сторінки «Work breakdown structure»
Рядок 17: Рядок 17:
Концепт структури декомпозиції робіт був розроблений у рамках [[Техніка оцінювання та аналізу програм|Техніки Оцінювання та Аналізу Програм]] (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>
Концепт структури декомпозиції робіт був розроблений у рамках [[Техніка оцінювання та аналізу програм|Техніки Оцінювання та Аналізу Програм]] (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>
У червні 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, що є спільними для всіх систем.


== Принципи ==
== Принципи ==

Версія за 15:33, 20 січня 2016

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

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

Огляд

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

Приклад структури декомпозиції робіт, що була застосована у звітних структурах NASA.[2]

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

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

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

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

Історія

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

У червні 1962 року, DoD, NASA та аерокосмічна індустрія опублікували докумен для системи PERT/COST, що описував підходи WBS.[7] Цей путівник був представлений Міністром Оборонидля ухвалення всех послуг.[8] У 1968 році, DoD видав "Структура Декомпозиції Робіт Для Товарів Військової Техніки" (MIL-STD-881), військовий стандарт, що потребував використання структур декомпозиції робіт у DoD.[9]

Документ був переглянутий кілька разів, останній раз у 2011 році. Поточна версія цього документу може бути знайдена у "Струкрути Декомпозиції Робіт для Товарів Військової Техніки" (MIL-STD-881C).[10] Він включає визначення WBS для специфічних систем військових товарів, та стосується елементів WBS, що є спільними для всіх систем.

Принципи

100% керування

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

100% керування визначає, що WBS включає в собі 100% роботи, що виділена в межах проекту та охоплює всі результати – внутрішні, зовнішні, проміжні – що мають бути завершені з точки зору виконуваної роботи, включаючи проектний менеджмент. 100% керування є одним з найважливіших принципів, що керують розробкою, декомпозицією та оцінкою WBS. Правило застосовується до усіх рівнів у наступній ієрархії: сума робіт на "дочірньому" рівні має бути рівною 100% роботи, що представлена "батьківським" рівнем, а також WBS не смає містити будь-якої роботи, яка не є частиною актуальних меж, визначених проектом, що в свою чергу визначає, що вміст не може бути більшим за 100% роботи… Важливо пам’ятати, що правило 100% керування також застосовується до рівня діяльностей. Робота, що відтворюється діяльностями у кожному робочому пакеті, має складати 100% роботи, необхідної для його завершення.[12]

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

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

Заплановані висновки замість дій

У разі, якщо автор структури декомпозиції робіт спробує охопити будь-яку дієво-орієнтовану деталь у WBS, він/вона включить або забагато, або замало дій. Забагатість дій перевищать 100% бітьківських меж, в той час як замалість відставатиме від 100% батьківських меж. Найкращим шляхом є дотримання правила 100% керування для визначення елементів WBS у термінах результатів, а не дій. Це також гарантує, що WBS не буде занадто приписуючим, що збільшить винахідливість та креативне мислення у частини учасників проекту. Для нових проектів, що розробляють продукти, найбільш популярною технікою для гарантування результато-орієнтовної WBS є використання структури декомпозиції продукту. Розробка, керована функціональністю може використовувати схожу техніку, що має утворити структуру декомпозиції ознак. Коли проект надає професійні послуги, зазвичай використовується техніка охоплення всіх запланованих результатів для створення результато-орієнтовної WBS.[13] Структури декомозиції робіт, що розділяють роботу на фази проекту (наприклад, попередній етап проектування, фаза критичного технологічного планування) мають гарантувати, що фази чітко розділені запланованими результатами та вони такох використовуютсья доя визначення критерію завершення (наприклад, затверджений у минулому чи огляд критичної технічної частини).

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

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

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

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

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

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

Для елементів структури декомпозиції робіт є частою практика послідовної нумерації при створенні ієрархічної структури. Метою нумерації є надання послідовного підходу до визначення та управління WBS у вигляді системи неалежно від вендору чи обслуговування.[14] Наприклад, 1.1.2 Просування (у прикладі нижче) визначає цей елемент як Елемен Рівня 3 структури WBS, так як існує три числа, розділених десятковим розділювачем. Схема кодування також допомагає елементам WBS бути визначеними у будь-якому письмовому контексті.

Практичний приклад схеми кодування WBS:[15]

1.0 Система Літаків

1.1 Повітряний апарат
1.1.1 Корпус
1.1.1.1 Інтеграція корпусу, Збір, Тестування та Перевірка
1.1.1.2 Фюзеляж
1.1.1.3 Крило
1.1.1.4 Хвіст
1.1.1.5 Кабіна
1.1.1.6 Інші компоненти корпусу 1..n (Визначити)
1.1.2 Просування
1.1.3 Підсистеми апарату
1.1.4 Авіоніка
1.2 Системний Інжиніринг
1.3 Програмний Менеджмент
1.4 Перевірка і Оцінювання Системи
1.5 Тренування
1.6 Дані
1.7 Обладнання Власної Підтримки
1.8 Обладнання Загальної Підтримки
1.9 Оперативна/Місцева Активація
1.10 Промислові об’єкти
1.11 Початкові Запчастини та Частини для Ремонту

Приклад у сфері програмного забезпечення буде виглядати наступним чином:[16]

1267.1 Системна Інтеграція

1267.1.1 Визначення Вимог
1267.1.2 Регламент
1267.1.3 Планування
1267.1.4 Моніторинг та Контроль
1267.1.5 Менеджмент Закупівель
1267.1.6 Закриття

1267.2 Дизайн

1267.2.1 Концептуальний Дизайн
1267.2.2 Попередній Дизайн
1267.2.3 Фінальний Дизайн

Термінальний елемент

Найнижчим елементом у деревній структурі, термінальним елементом,є такий, що не може бути надалі поділений. У структурі декомпозиції робіт такі (діяльності чи результати) елементи є елементами, що оцінюються як вимоги до ресурсів, бюджету та тривалості; пов’язані залежностями; а також заплановані. На стику елементу WBS та організаційного блоку, встановлюються рахунки управління та робочі пакети, планується продуктивність, вимірюється, записуєтсья та контролюється.[17] WBS може бути деталізована до будь-якого рівня зацікавленості. Мінімально рекомендованими є три рівні, в той час як додаткові рівні мають бути заданими лише для елементів з високою вартістю чи високим ризиком,[18] і два рівня деталізації у випадках, таких як системний інжинірінг чи програмний менеджмент,[19] зі стандартами прикладами того, що WBS з різною глибиною, такі як розробка програмного забезпечення, доходять до 5 рівнів[20], або системи керування вогнем, що доходят до 7 рівнів.[21]

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

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

Приклад

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

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

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

Оманливі уявлення

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

Дивіться також

Посилання

  1. Booz, Allen & Hamilton Earned Value Management Tutorial Module 2: Work Breakdown Structure, Office of Science, Tools & Resources for Project Management, science.energy.gov.
  2. а б в NASA (2001).
  3. Electronic Industries Alliance Standard Systems Engineering Capability Model EIA-731.1
  4. Institute of Electrical and Electronics Engineers Standard for Application and Management of the Systems Engineering Process IEEE Std 1220-2005
  5. Fleming, Quentin W., Joel M. Koppelman "Earned Value Project Management" CROSSTALK: The Journal of Defense Software Engineering July 1998, p 20
  6. Haugan, Gregory T., Effective Work Breakdown Structures, pp7-8
  7. DOD and NASA Guide, PERT/COST System Design, June 1962
  8. Hamilton, R. L., Study of Methods for Evaluation of the PERT/Cost Management System, MITRE Corporation, June 1964
  9. MIL-STD-881, 1 November 1968
  10. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011
  11. Effective Work Breakdown Structures By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN 1567261353, p.17
  12. Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute, ISBN 1933890134, page 8
  13. Swiderski, Mark A., PMP workbreakdownstructure.com, PMBOK-Work Breakdown Structures.
  14. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶4.3
  15. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011 Appendix A, ¶A.3
  16. Taylor, Michael, WBS Examples, PM Hut.
  17. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶3.1.4
  18. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶1.4.1
  19. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶2.2.4.2
  20. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-6
  21. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-1
  22. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Appendix E
  23. Gilmer, Thomas (1982-08-04).

Подальше  читання

  • Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure ISBN 1-890367-12-5
  • Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures, Second Edition (2006) ISBN 1-933890-13-4 (Note: The Second Edition is an extensive re-write of the Practice Standard.)
  • Gregory T. Haugan. Effective Work Breakdown Structures (The Project Management Essential Library Series) ISBN 1-56726-135-3
  • Dennis P. Miller, PMP, "Building Your Project Work Breakdown Structure -- Visualizing Your Objectives, Deliverables, Activities and Schedule". ISBN 1-42006969-1 (Note: This new book is essentially a facilitator's guide for planning a project based on the WBS.)

Зовнішні посилання