Структура декомпозиції робіт: відмінності між версіями
[перевірена версія] | [перевірена версія] |
Вилучено вміст Додано вміст
Bunyk (обговорення | внесок) Немає опису редагування |
ReAl (обговорення | внесок) м оформлення |
||
Рядок 1:
'''Структура декомпозиції робіт''' ({{lang-en|work breakdown structure, WBS}})
Елементом структури декомпозиції робіт може бути [[Продукт (економіка)|продукт]], [[дані]], [[Послуги]] або будь-яка комбінація вищезгаданого. Крім того,
== Огляд ==
Рядок 8:
Система декомпозиції робіт надає загальний каркас для природнього розвитку загального планування та контролю договору і є базисом для розподілу роботи у такі інкременти, що можуть бути визначеними, та з яких може бути зроблене [[Технічне завдання|Технічне Завдання]] і установлені звіти по технічним даним, графікам, вартостям, робочим годинам .<ref name="NASA01">NASA (2001). </ref>
Структура декомпозиції робіт дозволяє зібрати докупи підлеглі витрати по задачах, матеріалах тощо на вищий рівень
WBS організовується навколо ключових продуктів проекту (чи запланованих результатів), а не необхідних робіт для випуску продукту (заплановані дії). Так як заплановані результати є бажаним завершенням проекту, вони формують відносно стабільний набір категорій, у яких ціни запланованих для їх досягнення необхідних дій можуть бути зібрані докупи. Добре розроблена WBS робить легко досяжним призначення кожної діяльності проекту до виключно однієї термінальної події у WBS. Додатково до її функцій у обліку витрат WBS також допомагає співвіднести вимоги одного рівня системних специфікацій до іншого, наприклад, відповідність матриці вимог перехресних посилань до функціональних вимог на вищий чи нижчий рівні документації.
Рядок 15:
== Історія ==
Концепт структури декомпозиції робіт був розроблений у рамках [[Техніка оцінювання та аналізу програм|Техніки Оцінювання та Аналізу Програм]] (PERT) [[Міністерство оборони США|Міністерством Оборони США]] (DoD).
У червні 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 видав
Документ був переглянутий кілька разів, останній раз у 2011 році. Поточна версія цього документу може бути знайдена у
[[Файл: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, в той час як
== Принципи ==
===
Важливий принцип конструкції для роботи структур декомпозиції називається 100 % керування..<ref>''Effective Work Breakdown Structures'' By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN 1567261353, p.17</ref> Він визначається наступним чином:
: 100 % керування визначає, що WBS включає в собі 100 % роботи, що виділена в межах проекту та охоплює всі [[Результат (проектний менеджмент)|результати]]
==== Взаємовиключні елементи ====
[[Несумісні події]]: Додатково до правила 100 % керування, важливо
=== Заплановані висновки замість дій ===
У разі, якщо автор структури декомпозиції робіт спробує охопити будь-яку дієво-орієнтовану деталь у WBS, він/вона включить або забагато, або замало дій. Забагатість дій перевищать 100 % бітьківських меж, в той час як замалість відставатиме від 100 % батьківських меж. Найкращим шляхом є дотримання правила 100 % керування для визначення елементів 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 не боже бути довшою за одиничний звітний період. Таким чином, якщо команда проекту звітується по прогресу проекту щомісячно, жодна одинична діяльність чи їх група не може тривати більше місяця.
* Останнє евритичне правило є правилом
Робочий пакет на рівні діяльностей є задачею, яка:
* може бути реалістично і впевнено оцінена;
Рядок 62:
=== Схема кодування ===
Для елементів структури декомпозиції робіт є частою практика послідовної нумерації при створенні ієрархічної структури. Метою нумерації є надання послідовного підходу до визначення та управління WBS у вигляді системи неалежно від вендору чи обслуговування.<ref>MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶4.3</ref>
Практичний приклад схеми кодування 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 має відповідати нормам чи шаблонам компанії, що існують всередині організації чи домену.
== Приклад ==
[[
Три найбільших елементи WBS Рівня 2 надалі діляться на Рівні 3. Кожен з двох найбільших елементів на Рівні 3 визначає лише 17 % загального
Дизайн 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
* 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>
== Посилання ==
{{commonscat|Work breakdown structures}}
|