Work Breakdown Structure

Готовий WBS на одному екрані — вісім гілок, тридцять один робочий пакет, 100%

Більшість тих, хто шукає Work Breakdown Structure, хоче побачити приклад. Ось повний — для типового ІТ-проєкту: ритейлер замінює свій інтернет-магазин за фіксовану ціну, за дев’ять місяців. Кожен рядок — це результат, іменник, щось, що існуватиме наприкінці, — і в кожного є код. Відсоток біля кожної гілки — її частка бюджету, і вісім разом дають 100. Наступні розділи посилаються на рядки за кодами.

1. 1.Управління проєктом — 10%

   1. 1.1План управління проєктом і базовий план
   2. 1.2Статус-звіти й матеріали для керівного комітету
   3. 1.3Реєстр ризиків і журнал змін
   4. 1.4Реєстр договорів із постачальниками

2. 2.Облікові записи клієнтів — 11%

   1. 2.1Реєстрація та вхід
   2. 2.2Відновлення пароля
   3. 2.3Профіль і збережені адреси
   4. 2.4Видалення облікового запису й експорт даних (GDPRGDPRGeneral Data Protection Regulation — закон ЄС про персональні даніЄвропейська регуляція про персональні дані: що можна збирати, на якій правовій підставі, скільки зберігати і чого людина може від вас вимагати щодо своїх даних. Вона застосовується за місцем перебування людей, а не компанії, — тому дістає до софту, збудованого будь-де.Усі терміни)

3. 3.Каталог і пошук — 14%

   1. 3.1Сторінки товарів
   2. 3.2Навігація категоріями й фільтри
   3. 3.3Пошук
   4. 3.4Завантаження каталогу з ERP

4. 4.Оформлення замовлення й оплата — 18%

   1. 4.1Кошик
   2. 4.2Варіанти й вартість доставки
   3. 4.3Оплата карткою, один провайдер
   4. 4.4Листи-підтвердження замовлення

5. 5.Міграція даних — 12%

   1. 5.1Записи клієнтів
   2. 5.2Історія замовлень
   3. 5.3Звіт звірки

6. 6.Платформа й експлуатація — 12%

   1. 6.1Середовища: розробка, stagingstagingсередовище-репетиціяКопія продакшену, на якій зміни пробують до того, як їх зустрінуть справжні користувачі. Скільки вона доводить, повністю залежить від того, наскільки вона схожа на продакшен: staging із десятою частиною даних, без реального трафіку й з іншою конфігурацією показує, що код запускається, і майже нічого більше.Усі терміни, production
   2. 6.2Конвеєр збирання й розгортання
   3. 6.3Моніторинг і алерти
   4. 6.4Резервні копії та перевірене відновлення

7. 7.Якість і приймання — 13%

   1. 7.1Стратегія тестування
   2. 7.2Звіт про тестування продуктивності
   3. 7.3Звіт про тестування безпеки
   4. 7.4Підписаний акт приймання користувачами

8. 8.Запуск і передача — 10%

   1. 8.1План переходу та його репетиція
   2. 8.2Ранбуки й документація для підтримки
   3. 8.3Навчання служби підтримки клієнтів
   4. 8.4Посилений супровід (hypercare), чотири тижні після запуску

Правила, що роблять дерево WBS

Сама ідея старша за програмні проєкти. У червні 1962 року Міністерство оборони США й NASA видали посібник із системи PERT/COST, створеної для програм на кшталт ракети Polaris, і вся робота в ньому була впорядкована деревом, орієнтованим на продукт. 1968 року військові зробили це стандартом — MIL-STD-881, який досі чинний у шостій редакції. Причина тоді була та сама, що й тепер: коли тисячі людей витрачають гроші на одну програму, єдиний спосіб знати, чи купують ці гроші продукт, — прив’язати кожну годину й кожен рахунок до шматка цього продукту.

Правило 100% і його близнюк

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

У цього правила є близнюк, про якого зазвичай мовчать: вузли одного рівня не мають перетинатися. Та сама робота може з’явитися рівно в одному місці дерева. Поруште це — і правило 100% формально виглядатиме виконаним, тоді як оцінка, підсумована знизу, порахує ту саму роботу двічі. Найчастіша жертва — тестування: якщо робочий пакет кожної функції містить її тести, а в гілці 7 є ще й «системне тестування», частина тестування тепер у бюджеті двічі, і ніхто не може вказати рядок, де помилка.

Іменники, а не дієслова

Права колонка виглядає розумно й ламається одразу. «Написати код» неможливо перевірити правилом 100%, неможливо однозначно позначити завершеним, і воно повторюється однаково під кожною гілкою — тобто дерево не каже вам нічого нового. Результат можна оглянути; про дію можна лише відзвітувати. Саме тому дії з’являються пізніше: коли робочі пакети вже є, кожен розкладають на кроки, що його створюють, і ці кроки йдуть у графік, який змінюється щотижня, а не у WBS, який змінюється лише за згодою.

Три способи організувати другий рівень

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

• За великими результатами

  Облікові записи, каталог, оформлення, міграція. Варіант за замовчуванням і правильний вибір, коли продукт має чітко відокремлювані частини з різними власниками.

• За фазами

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

• За підпроєктами

  Поділ за постачальником, майданчиком чи системою, коли різні організації постачають різні частини. Кожен підпроєкт далі розкладається за власною логікою.

Десять перевірок, перш ніж хтось його підпише

Словник — де насправді живе обсяг

Рядок у дереві — це від двох до п’яти слів, чого категорично замало, щоб утримати межу обсягу. «Оплата карткою, один провайдер» може означати для клієнта й для команди з десяток різних речей. Словник WBS — це супровідний документ, що для кожного робочого пакета каже, що до нього входить і що ні, як його прийматимуть, хто ним володіє, скільки він за оцінкою коштує і від чого залежить. Саме цю частину пропускають — і саме вона за пів року розв’язує суперечку. Ось рядок 4.3, відкритий.

Найбільше роботи робить рядок «Не входить». Включення описують те, що команда й так збиралася будувати; виключення — найдешевші рядки, які хтось напише на проєкті, бо кожен із них — суперечка, якої не буде. Інший рядок, вартий двох прочитань, — «Припущення». Припущення з власником і датою — це ризик, яким керують. Припущення, про хибність якого обидві сторони знають у момент підписання, — зовсім не припущення: це відкладений запит на зміну, і другий кейс нижче показує, чого коштували 800 таких.

Коди, контрольні рахунки й де вимірюють гроші

Кожен вузол отримує код: 1, далі 1.1, 1.1.2 і так далі. Це виглядає оздобленням, але ним не є. Код — ідентифікатор, на який посилаються табелі, замовлення на закупівлю, записи ризиків і запити на зміни, тож фактично витрачене можна підсумувати вгору тим самим деревом, яким униз спускалася оцінка. Видані коди ніколи не перевикористовують: видалена гілка лишає дірку, а не перенумеровується, бо старий номер уже стоїть у рахунках за пів року.

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

На контрольному рахунку щомісяця порівнюють три числа. Planned value — що, за планом, мало бути завершено на сьогодні. Earned value — бюджет того, що справді завершено. Actual cost — скільки витрачено, щоб туди дійти. Earned value нижче за planned value означає відставання від графіка; actual cost вище за earned value — перевитрату бюджету. Увесь метод тримається на одному питанні: скільки робочого пакета вважається «завершеним», доки він не завершений?

Наскільки глибоко — правило 8/80, пакети планування і хвилі

Найнижчий рівень WBS — робочий пакет. Поширена евристика — правило 8/80: не менше 8 годин роботи й не більше 80. Менше 8 — ви керуєте дрібницями; більше 80 — ви не скажете, чи пакет іде за планом. Друге емпіричне правило часто корисніше: жоден робочий пакет не довший за один звітний період, щоб на кожній статус-зустрічі кожен був або завершений, або ні. Жодного з цих чисел немає в стандарті; обидва — домовленості, що працюють.

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

Пакети планування й хвильове планування

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

WBS поруч з agile-беклогом

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

Вони відповідають на різні питання. Беклог відповідає на «що робити далі?» і свідомо ніколи не завершений. WBS відповідає на «про що саме ми домовилися як про ціле?» і нічого не вартий, якщо неповний. Коли організації потрібні обидва для тієї самої роботи — звичний випадок: договір із фіксованою ціною, виконуваний спринтами, — робоча схема така: WBS до того рівня, якого потребує договір, зазвичай до результатів, іноді до робочих пакетів, а беклог живе під ним. Кожен епік тоді стоїть рівно під одним рядком WBS, і запис у словнику для цього рядка — те, що мають у сумі дати історії цього епіка.

Три кейси і рядок, якого бракувало кожному

Жодному з цих проєктів не бракувало плану. Кожен зафіксував ціну чи дату для обсягу, не визначеного до того рівня, якого вимагало зобов’язання, — і кожному про це казали вчасно.

Міжнародний аеропорт Денвера — кейс гілки, доданої після того, як стовбур уже збудували. Будівництво почалося в листопаді 1989 року. United Airlines 1991 року найняла BAE Automated Systems збудувати автоматизовану систему багажу для свого терміналу, а у квітні 1992-го аеропорт законтрактував BAE розширити її до єдиної системи на весь аеропорт — договір на 193 мільйони доларів, умови якого виробили за три інтенсивні робочі сесії. Будівлі, тунелі й графік, у які вона мала вписатися, уже були зафіксовані; дату відкриття — жовтень 1993-го — не посунули, щоб звільнити місце. Система стала причиною пізнього відкриття: чотири перенесення і 16 місяців пізніше, 28 лютого 1995 року, поруч установили звичайну систему приблизно за 51 мільйон, за даними Головного контрольного управління США. United відмовилася від автоматизованої системи 2005 року. Мовою WBS: одну гілку додали пізно, її залежності від кожної іншої гілки припустили, а не переспланували, і ті 100% проєкту, про які домовилися 1989 року, вже не були тими 100%, які будували.

Трамвай Единбурга — кейс для рядка «Припущення». 14 травня 2008 року проєктна компанія міста підписала договір на інфраструктуру з фіксованою ціною. Ціна трималася на Schedule Part 4 — переліку з 43 цінових припущень, — і сам цей додаток казав, що частина з них не відповідає фактам: проєктування не завершене, перенесення комунікацій не закінчене, — тож «застосовуватиметься механізм Notified Departure»: кожне відхилення від припущення ставало вважаною зміною, яку треба оплатити. Розслідування лорда Гарді, що оприлюднило звіт 19 вересня 2023 року, встановило: вище керівництво чекало від 60 до 100 таких відхилень, не намагалося оцінити їхню вартість — і отримало близько 800. Роботи зупинилися через суперечки; медіація в березні 2011 року їх урегулювала. Лінію відкрили 31 травня 2014 року, майже на три роки пізніше, від аеропорту до York Place замість Newhaven, за заявлені 776,7 мільйона фунтів проти бюджету 545 мільйонів на всю лінію. Самі інфраструктурні роботи зросли з 238,6 мільйона за повний маршрут до 427,2 мільйона за скорочений. Фіксована ціна рівно настільки фіксована, наскільки визначений обсяг під нею.

Де він вироджується

WBS рідко підводить у день, коли його малюють. Він підводить першого ж разу, коли хтось питає «чи це входить в обсяг?», а дерево не може відповісти. Майже кожен такий збій — одне з цього:

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

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

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

Коли це застосовувати

Пов’язані сторінки

• МенеджментUser StoriesUser story — це короткий опис потреби з погляду користувача, написаний, щоб почати розмову, а не замінити її. Шаблон — найменш важлива частина; справжня навичка — нарізати роботу так, щоб кожна історія давала користувачеві щось справді придатне, і ще до початку роботи домовитися, як усі зрозуміють, що її зроблено. Сторінка починається з шістнадцяти історій у тому вигляді, як їх справді пишуть команди, — що не так із кожною і як її переписати; далі — картка, розмова й підтвердження, критерії приймання та example mapping, дев’ять способів розділити історію, story mapping, INVEST, спайки й поінти, п’ять епізодів з історії формату і де все це вироджується.
• МенеджментЕпіки, фічі, задачіЕпіки, фічі й задачі — це рівні ієрархії роботи: від ставки, яку керівник робить на квартал, до кроку, який інженер робить сьогодні. Жоден стандарт їх не визначає: у Scrum Guide немає жодного з цих трьох слів, а Jira, Azure DevOps і SAFe ставлять епік на різний розмір. Сторінка починається з усіх рівнів на одному екрані й одного епіка, розкладеного до задач; далі — звідки ці слова, для чого кожен рівень, епік як ставка з виходом, фічі, enabler-и й задачі, чому підсумовані оцінки вводять в оману, п’ять епізодів з історії ієрархії і де все це вироджується.
• МенеджментWaterfallWaterfall — це спосіб вести проєкт у фіксованому порядку, коли кожну фазу завершують і затверджують до початку наступної. Його зазвичай викладають як застаріле, що його замінив Agile, і це водночас несправедливо й некорисно: це правильний вибір щоразу, коли змінити рішення пізно коштує дорожче, ніж ретельно все описати зараз. Сторінка починається з усіх фаз на одному екрані — що кожна створює, який гейт її закриває і скільки коштує зміна на ній; далі — що насправді написав Ройс 1970 року, кожна фаза по черзі, V-модель, шість питань, що вирішують між предиктивним та ітеративним планом, гібриди, якими живуть реальні проєкти, пʼять задокументованих випадків і де все це вироджується.