Створення WBS

Кожен ролевий кластер визначає об'єм своєї роботи, необхідної для створення рішення, і описує його у формі планів, чек-лістів і тому подібне

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

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

Один з результатів процесу управління ризиками MSF – поява додаткових завдань, що є реакцією на наявні ризики. Ця робота може бути включена в WBS, оцінена, спланована і внесена до календарного графіка точно так, як і інші завдання. Розглянете можливість поєднання процесу складання WBS з мозковим штурмом по виявленню рисок.

Перший рівень структури WBS може відповідати фазам життєвого циклу проекту. Фази моделі процесів MSF дуже добре підходять для цього. Пропоновані в MSF проміжні віхи фаз проекту відповідають створенню базових або робочих версій певних складових рішення, тому їх природно використовувати як другий рівень структури WBS. Нижче за цей рівень робота структурується за допомогою процесу декомпозиції робота/задача (work/task decomposition).

Рекомендації по декомпозиції роботи

При створенні WBS корисно враховувати наступні рекомендації:

•Витрати на кожне завдання повинні бути реалістично оцінені.

•Час виконання окремого завдання не повинна бути менш 1 і більше 40 днів (для ITпроектів).

•Кожне завдання повинно мати однозначний опис як задачі, так і очікуваного результату.

•Завдання виділені правильно, якщо їх виконання може відбуватися без істотних пауз.

•Відповідальність за кожне завдання повинно бути доручене тільки 1-му працівнику.

•Кожне завдання може припускати подальше розбиття на елементарні під-задачі.

•Діяльність, зв'язана з великими ризиками, повинна деталізуватися більше, ніж діяльність, зв'язана з меншими ризиками.

•За винятком двох верхніх рівнів, завдання повинні формулюватися в наказовій формі (наприклад, "Спроектувати структуру бази даних").

•У WBS повинно бути від трьох до п'яти рівнів визначення завдань.

•По ходу роботи над проектом WBS послідовно допрацьовується, але зазвичай її формування відбувається на фазі планування.

Оцінка знизу вгору

У IT-проектах попередні оцінки тривалості завдань, їх вартості і тому подібне слід отримувати від тих, хто потім виконуватиме оцінювану роботу. Оцінка від низу вгору (bottom-up estimating) – це процес вироблення і інтеграції оцінок багатьма членами команди. Такий підхід має наступні переваги:

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

•Відповідальність. Ті, хто використовує в роботі власні оцінки, відчувають велику відповідальність, як за свою роботу, так і за адекватність зроблених оцінок.

•Уповноваженість (empowerment) проектної групи. Календарний графік, складений самою проектною групою, а не продиктований зверху керівництвом, надихає

131

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

Інтеграція представлених проектною групою оцінок

Кожен лідер ролевого кластера відповідальний за оцінку часу, необхідного своєму відділу. Наприклад, лідер команди розробників готує оцінки часу розробки.

Ролевий кластер "Управління програмою" координує підготовку оцінок трудовитрат і їх в зведений календарний графік і бюджет проекту.

Значний внесок у вартість IT-проектів вносить вартість робочої сили, тому оцінки трудовитрат – це істотна частина інформації, необхідної для оцінювання вартості і календарного графіка проекту.

Формування реалістичних очікувань

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

•Оцінки залежать від специфікації. Створення IT-рішень багато в чому нагадує побудову будинку під замовлення. Поки не відомі всі деталі замовлення, неможливо назвати ціну будинку. Проте не одні лише специфікації визначають вартість проекту. Інші складові проектної роботи, такі як переговори із замовником, наради, підготовка звітності і ін. займають певний час і, отже, повинні бути враховані в оцінках витрат.

•Будьте готові до компромісів. Робота з трикутником компромісів і встановлення базових пріоритетів з використанням матриці компромісів допомагають проектній групі і замовникові сформувати очікування.

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

•На кожній вісі відбувається переоцінка. У міру просування роботи над проектом необхідно проводити уточнення оцінок трудовитрат.

Невизначеність і точність оцінок

Оцінки при розробці ПЗ передбачають постійне уточнення. Рис. 7 ілюструє так званий "конус невизначеності" ("cone of uncertainty"), що демонструє процес збіжності оцінок програмного забезпечення. На ранніх етапах роботи над проектом оцінки витрат можуть сильно відхилятися від реальних величин. Проте у міру прогресу роботи над проектом це відхилення сходить нанівець.

Відмітимо, що на вісі "Концепція проекту затверджена" оцінки можуть відрізнятися від реальних величин у велику або меншу сторону в 2 рази. Показані на малюнку значення, узяті із статистичних даних за середину 1990-х років, не повинні сприйматися буквально. Дійсно важливим є розуміння порядків відхилення оцінок від реальних величин на кожній з фаз.

З представленої інформації можна побачити, що під час фази вироблення концепції проектна група отримує лише певні межі (іноді звані діапазонами оцінок - "ballpark estimates") для тимчасових і матеріальних витрат. Ніколи не можна стверджувати, що отримані на цій фазі оцінки остаточні – усвідомлюйте той, що після проходження віхи "Концепція проекту затверджена" вони можуть варіюватися у декілька разів.

132

Рисунок 30. Конус невизначеності

Джерело: "Cost Models for Future Lifecycle Processes: COCOMO 2.0" Boehm, et. al., 1995.

Оцінюйте завдання нижнього рівня декомпозиції

Існує декілька способів отримання оцінок трудовитрат для проектних завдань. Всі вони починаються з розбиття кожного із завдань, вказаних в WBS, на прості під-задачі. Цей процес здійснюється на рівні під-команд під безпосереднім керівництвом лідерів команд.

Потім для кожної простої під-задачі необхідно отримати всі необхідні оцінки. Їх підсумовування дає загальні оцінки для відповідних елементів WBS.

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

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

Таким чином, після об'єднання елементарних під-задач в завдання WBS для кожної з них існують три значення оцінок. Лідери команд представляють цю інформацію на розгляд кластеру "Управління програмою" для проведення аналізу вартості, а потім використовують оцінки при складанні календарного графіка.

Аналіз PERT

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

133