Пропустити навігацію EPAM

Оцінювання проєкту: власний досвід та висновки

Ігор Швидкой

Senior Business Analyst, EPAM
Новини
  • Business Analysis

Оцінювання проєкту — важливий інструменту процесі ухвалення рішень та є невід’ємним компонентом в управлінні проєктами. Детально методи оцінювання описано у всім відомому довіднику PMBOK (Довідник із управління проєктами). 

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

1. Оцінювання «згори донизу»

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

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

2. Оцінювання «знизу догори»

Коли застосовувати: використовується, коли окремі завдання можуть бути чітко визначені. Це дозволяє одержувати точніші оцінки, на відміну від методу оцінювання «згори донизу», але водночас вимагає більшого рівня деталізації завдань. Прикладом цієї техніки можна назвати «Структуру декомпозиції робіт» (СДР).

Як застосовувати: ви працюєте з оцінюванням окремих завдань, результати потім складаються в загальну оцінку проєкту.

3. Параметричне оцінювання

Коли застосовувати: цей метод доцільно застосовувати лише в тому випадку, якщо ви маєте «історичні дані» для ваших розрахунків. Якщо ж вони у вас є — отже, вам пощастило і ви можете виконати оцінювання з високою точністю.

Як застосовувати: це кількісний підхід, що використовує історичні дані. Знаючи те, що на написання сценарію виконання витрачається близько 30 хвилин, ви можете підрахувати, що для написання 10 таких сценаріїв вам знадобиться приблизно 5 годин.

4. Приблизний порядок величини (ППВ) (також відомий як «приблизне», або «експертне судження»)

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

Як застосовувати: оцінювання ґрунтується на експертній думці чи минулому досвіді роботи з аналогічним проєктом. Згідно з даними PMBOK, точність цього методу становить від -25% до + 75%. Це означає, що фактична вартість проєкту може варіюватися від 75% до 175% від кошторисної вартості.

5. Метод Дельфі (також відомий як «метод експертних оцінок»)

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

Як застосовувати: метод Дельфі зазвичай ґрунтується на думці кількох експертів та проводиться в декілька «раундів». Кожен експерт дає свою оцінку. Потім ці оцінки обговорюються в групі. Після цього проводиться переоцінка на основі відгуків, одержаних у процесі обговорення. Далі проводиться ще один етап обговорення нових оцінок. Зазвичай потрібно 3 раунди оцінювання і обговорень.

6. Метод «набігаючої хвилі»

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

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

7. PERT (техніка оцінювання й аналізу програм, також відома як «триточкова оцінка»)

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

Як застосовувати: ви даєте три значення кожному оцінюваному компоненту, історії чи функції: 1) оптимістичне значення, або найкращий сценарій, 2) реалістичне значення, або найімовірніший сценарій і 3) песимістичне значення, або найгірший сценарій. Після цього середнє значення розраховується за такою формулою:

( Оптимістичний + Песимістичний + (4 * (Найімовірніший) ) ) / 6.

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

Принаймні з початковим вибором методу оцінювання може допомогти ця діаграма:

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

Ось чого я навчився з власного оцінювання докладених зусиль:

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

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

Завжди ретельно документуйте й звертайте увагу на всі обмеження та допущення. Переконайте клієнта, повторивши цю тезу декілька разів, що оцінювання (estimates) — це рекомендації, а не зобов'язання.

Підписатися на новини

Чудово! Ми вже готуємо добірку актуальних новин для вас :)

Вибачте, щось пішло не так. Будь ласка, спробуйте ще раз.

* Обов'язкові поля

*Будь ласка, заповніть обов’язкові поля

Вакансії EPAM Ukraine у Київ | Львів | Харків | Дніпро | Вінниця | Івано-Франківськ | Одеса | Чернівці | Хмельницький | Рівне | Ужгород | Тернопіль | Луцьк за напрямком Java | JavaScript | .NET | DevOps | Experience Design | Software Testing | Business Analysis | Python| Big Data | Mobile | Solution Architect | Ruby on Rails у містах за напрямком Java вакансії Київ | Java вакансії Харків | Java вакансії Львів | Java вакансії Вінниця | Java вакансії Одеса | Java вакансії Івано-Франківськ | Java вакансії Чернівці | Java вакансії Хмельницький | Java вакансії Рівне | Java вакансії Ужгород | Java вакансії Тернопіль | Java вакансії Луцьк | JavaScript вакансії Київ | JavaScript вакансії Харків | JavaScript вакансії Львів | JavaScript вакансії Вінниця | JavaScript вакансії Одеса | JavaScript вакансії Івано-Франківськ | JavaScript вакансії Чернівці | JavaScript вакансії Хмельницький | JavaScript вакансії Рівне | JavaScript вакансії Ужгород | JavaScript вакансії Тернопіль | JavaScript вакансії Луцьк | DevOps вакансії Київ | DevOps вакансії Харків | DevOps вакансії Львів | DevOps вакансії Вінниця | DevOps вакансії Одеса | DevOps вакансії Івано-Франківськ | DevOps вакансії Чернівці | DevOps вакансії Хмельницький | DevOps вакансії Рівне | DevOps вакансії Ужгород | DevOps вакансії Тернопіль | DevOps вакансії Луцьк