одиниця 2 / 11

Структура розподілу робіт (WBS) і планування обсягу

Прибуток:

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

Коли ви починаєте проект із "що ми будемо робити?" Починати з цього — це як ходити в темряві. Проекти часто зазнають невдачі не тому, що ними погано керують, а тому, що вони були визначені неправильно з самого початку. Предметом цього розділу є два основні інструменти, які окреслюють межі проекту та поділяють роботу на керовані частини: заява про обсяг і структура розподілу робіт. Якщо ці два документи налаштовані правильно, графік, прогноз, ризик і бюджет міцно сидять на них; При неправильному налаштуванні все тремтить протягом всього проекту. ШІ є потужним партнером у написанні обох документів: він пропонує скелет обсягу та розбивку робочих пакетів за лічені хвилини. Але пам’ятайте: ШІ створює загальний шаблон; Лише ви та ваша команда знаєте фактичні результати, обмеження та критерії прийнятності вашої організації.

Що таке заява про обсяг?

Обсяг – це те, що проект включає, а що не включає. Заява про обсяг – це документ, який викладає його в письмовій формі та зазвичай містить: мету проекту, ключові результати, критерії прийнятності, елементи, що виходять за рамки, припущення та обмеження. Найважливішою і найбільш нехтуваною частиною тут є список поза межами: «Ми не будемо робити X у цьому проекті» запобігає аргументу «але я думав, що це включено» пізніше.

Коли обсяг виходить з-під контролю, це називається розповзанням обсягу: невелика, незатверджена робота, додана до проекту, з часом роздуває його. «Ще одна маленька добавка» при повторенні підриває бюджет і розклад. Хороша заява про обсяг і чіткі критерії прийняття є першою лінією захисту від розповзання обсягу. Критерії прийнятності — це вимірювана умова, якій має відповідати результат, щоб вважатися «завершеним» (наприклад, «форма завантажується менш ніж за 2 секунди»).

Порада. Під час написання заяви про обсяг докладіть стільки ж зусиль до списку «що ми не будемо робити», скільки до списку «що ми будемо робити». Виключені предмети – найдешевша страховка для проекту.

Що таке структура розподілу робіт (WBS)?

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

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

Крок за кроком: Створення чернетки WBS за допомогою ШІ

  1. Уточніть обсяг. Анонімно повідомте ШІ мету проекту, ключові результати та відомі обмеження. Хороший WBS не виникає через незрозумілу мету.
  2. Попросіть розбивку проекту. Попросіть ШІ створити ієрархію, розділену на фази та робочі пакети; Попросіть однорядковий опис обсягу та запропоновану доставку для кожного пакета.
  3. Перевірте правило 100%. Перевірте, чи загальна кількість виготовлених упаковок повністю відповідає обсягу; Позначте відсутні та непотрібні елементи.
  4. Додайте критерії прийняття. Вимагайте проект вимірюваних критеріїв прийнятності для кожного ключового результату, а потім уточніть їх відповідно до реальності.
  5. Уточнити поза межами. Попросіть штучного інтелекту надати список «предметів, які, ймовірно, повинні бути поза межами цього проекту», і обговоріть його з командою.
  6. Перевірка команди та зацікавлених сторін. Перегляньте чернетку разом із власниками пакету робіт. WBS ніколи не є «планом» без схвалення команди.
Застереження: WBS, згенерований штучним інтелектом, часто може пропускати критичний пакет (наприклад, «юридичне схвалення», «міграція даних», «навчання користувачів»), який здається логічним, але є специфічним для вашої організації. Відсутній пакет зробить ваш прогноз неправильним із самого початку. Обов’язково застосовуйте правило 100% з людської точки зору.

три міні-чохла

Випадок 1 — Економія часу. Замість того, щоб будувати WBS з нуля для нового інтранет-проекту, експерт PMO надав YZ анонімне резюме та попросив чернетку. YZ запропонував 6 фаз і 34 робочих пакети. Експерт видалив 5 пакетів і додав 3 відсутні пакети (інтеграція SSO, тестування доступності, міграція вмісту) під час 45-хвилинного семінару з командою. Робота, яка зайняла б один день з нуля, була виконана за півдня і стала більш повною.

Випадок 2 — Уловлювання ковзання прицілу. Керівник проекту надає AI 12 невеликих запитів від замовника та запитує: «Вони входять до сфери чи поза межами згідно з поточною заявою про обсяги?» Він класифікував це як: YZ 7 позначив запит як «можливо поза межами». Прем'єр-міністр перетворив це на офіційні запити на зміни; інакше додаткові 3 тижні роботи мовчки просочилися б у проект.

Випадок 3 — Перехоплення відсутніх пакетів. Група схвалила 28 упаковок WBS, вироблених YZ, без перевірки. У середині проекту було помічено відсутність пакетів «міграція даних» і «репетиційна репетиція»; ці два промахи додали до розкладу 4 тижні. Урок: чернетки штучного інтелекту не можна затверджувати без тестування людьми за правилом 100%.

Слабка підказка / Сильна підказка

Слабка підказка:

Напишіть WBS для проекту мобільного додатку.

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

Потужна підказка:

Ваша роль: старший фахівець з планування проекту. Контекст: Мобільна програма для відстеження запасів для роздрібного клієнта (ім’я замасковано). Обмеження: 4 місяці, обов’язкова інтеграція з існуючим ERP, iOS+Android, доступна міграція даних. Завдання: створити чернетку WBS, розділену на фази та робочі пакети. Правила: - Дотримуйтеся правила 100%; пакети під кожною фазою повинні повністю охоплювати фазу.- Для кожного робочого пакета: один рядок обсягу + основний результат + вимірні критерії прийняття.- Надайте окремий список «можливо поза межами» в кінці.- Позначте пакети для конкретної установи, щодо яких ви не впевнені, за допомогою «[підтвердити з командою]», підходить. Результат: таблиця уцінки (Фаза | Пакет | Обсяг | Доставка | Критерії прийняття).

Цей запит є сильним, оскільки контекст, обмеження, правило 100%, критерії прийнятності та запит поза областю чіткі; також посилює невизначеність за допомогою "[підтвердження з командою]".

Додаткові шаблони:

# Пошук за межами області дії. Прочитайте заяву про область дії нижче. Перелічіть як «кандидатів поза сферою дії» завдання, які поширені, але ПРЯМО не згадуються тут (наприклад, навчання, документація, підтримка, міграція, тестування безпеки). Для кожного запитайте, чому його слід включити/виключити.

# Виробник критеріїв прийнятності Запропонуйте 3-5 вимірних критеріїв прийнятності для наступної поставки (у форматі SMART): [поставка]. Не пишіть критерії, які неможливо виміряти (наприклад, «це має добре працювати»).

# 100% засіб перевірки правил. Перегляньте WBS нижче. Який результат із заяви про обсяг НЕ має відповідника в жодному робочому пакеті? Які пакети ПЕРЕВИЩУЮТЬ заяву про область дії? Перелічіть прогалини.

Поширені помилки

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

Підсумовуючи

Заява про обсяг визначає межі проекту, тоді як WBS визначає керовані частини роботи. Хороша заява про обсяг включає чіткі критерії прийняття та чіткий список «поза межами»; Хороший WBS відповідає правилу 100% і взаємній винятковості. AI створює швидкі та повні креслення для обох, але може пропускати спеціальні пакети установ. Керівник проекту повинен застосувати правило 100% з людської точки зору, уточнити, що виходить за рамки, і отримати перевірку команди.

Аплікаційне завдання

Для вашого поточного проекту створіть проект WBS за допомогою ШІ, розділеного на фази та робочі пакети (анонімізуйте дані). Потім разом із членом вашої команди застосуйте правило 100%: яких пакетів бракує, які непотрібні, яка доставка не має критеріїв прийняття? Виправте принаймні 3 відсутні/неправильні точки та збережіть виправлену WBS.

контрольний список

  • [ ] Моя заява про обсяг містить мету, результати, критерії прийняття, поза межами, припущення та обмеження.
  • [ ] Я навмисне заповнив список «поза межами».
  • [ ] WBS дотримується правила 100% (без відсутніх/надлишкових пакетів).
  • [ ] Кожен робочий пакет є передбачуваним і відстежуваним.
  • [ ] Кожен важливий результат має вимірювані критерії прийнятності.
  • [ ] Я перевірив проект AI з командою; Я додав пакети для окремих установ.