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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
[неперевірена версія][неперевірена версія]
Вилучено вміст Додано вміст
Narkulome (обговорення | внесок)
Створено шляхом перекладу сторінки «Work breakdown structure»
Narkulome (обговорення | внесок)
Створено шляхом перекладу сторінки «Work breakdown structure»
Рядок 29: Рядок 29:


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


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

Версія за 14:06, 20 січня 2016

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

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

Огляд

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

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

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

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

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

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

Історія

Принципи

100% керування

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

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

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

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

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

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

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

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

  • Першим є "правило 80 годин", яке визначає, що жодна одинична діяльність чи група діяльностей на найнижчому рівні деталізації у WBS  для отримання результату не може тривати більш ніж 80 робочих годин.
  • Друге емпіричне правило визначає, що жодна діяльність чи група діяльностей на найнижчому рівні деталізації у WBS не боже бути довшою за одиничний звітний період. Таким чином, якщо команда проекту звітується по прогресу проекту щомісячно, жодна одинична діяльність чи їх група не може тривати більше місяця.
  • Останнє евритичне правило є правилом "чи є це доцільним". Застосовуючи це емпіричне правило, можна застосувати "здоровий глузд" при створенні тривалостей діяльностей чи груп діяльностей, що необхідні для вироблення результату, визначеного у 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. Effective Work Breakdown Structures By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN 1567261353, p.17
  6. Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute, ISBN 1933890134, page 8
  7. Swiderski, Mark A., PMP workbreakdownstructure.com, PMBOK-Work Breakdown Structures.

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

  • 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.)

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