Що таке оцінка проекту? Приходить до Вас менеджер з документом на 5 аркушів і питає за скільки часу це буде зроблено. Потрібно дуже терміново, на вчора. Погортавши 3 хвилини цей документ, почухавши потилицю, Ви видаєте фразу: “3 місяці”.

Чи була це оцінка затрат часу на проект? Звичайно! І тут Ви навіть використали один з найпопулярніших способів оцінки – пальцем в небо. Наскільки точною є ця оцінка – це уже інше питання. Вона може бути дуже точною, все залежить від досвіду.

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

На цю тему уже є величезна кількість матеріалів зібраних більш ніж за 20 років історії індустрії, є величезна кількість експертів і побудовані процеси. Але все ще:

  • Кожний десятий проект не може бути оцінений взагалі;
  • Кожний шостий приречений на провал з самого початку;
  • Кожний четвертий має великі шанси вийти за межі бюджету і часу.

 

Що таке оцінка проекту

Для початку дамо визначення що таке проект.

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

Існує 3 проектні обмеження: Schedule, Scope, Resource.

Якщо дядя Ваня за 1 день робить 1 стілець і ми платимо йому $100 за день, тоді виходить вартість стільця для нас – $100.

Що таке успішний проект? Щоб проект став успішним, він повинен відповідати наступним критеріям:

  1. Зробити кінцевий продукт який влаштовуватиме всі зацікавлені сторони;
  2. Закінчити його в термін (вчасно);
  3. При цьому залишитись на вимагаємому рівні якості і з дотриманням рівня виділених ресурсів;
  4. Виявитись прибутковим.

Щоб цього досягти нам потрібно оцінити:

  • Scope – об’єм задач які нам потрібно буде зробити (трудозатрати);
  • Schedule – час за який нам потрібно реалізувати ці роботи;
  • Resources – ресурси за домогомою який ми реалізуємо ці роботи в межах встановленого часу.

Schedule = Scope/Resources

Ніколи, ні при яких обставинах, не давайте спонтанних оцінок. Попросіть хоча б 15 хвилин, підійдіть до свого робочого місця і подумайте.

Так як на проект впливає велика кількість факторів, оцінка – це ймовірнісне значення. Тут можна розглянути “Конус невизначенності МакКонела”

В залежності від етапу проекту, оцінка витрат може змінюватись від -50 до +100%.

Завжди давайте оцінку з адекватним рівнем точності, викорстовуйте вилку оцінювання – від-до.  (Не можна казати замовнику: Ми оцінили проект в 1264 години, він займе 2 місяці і 19 днів і буде коштувати $46328.)

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

Алгоритм оцінки

  1. Scope estimates – рахуємо загальний об’єм роботи;
  2. Effort estimates – знаючи що потрібно зробити, можна скласти список задач які потрібно реалізувати;
  3. Schedule estimates – графік, коли ці роботи можуть бути виконані;
  4. Risk estimates – оцінюємо ризики;
  5. Resource estimates – оцінюємо ресурси з урахуванням  коли люди підуть у відпустки і є перерви в роботі, коли потрібно збільшувати команду
  6. Budget estimates – отримавши попередні оцінки, можна порахувати бюджет.

Методи оцінювання

Оцінювання об’єму роботи можна розділити на 2 методи: грубі і точні.

До грубих методів можна віднести:

  • Метод аналогії – якщо уже є подібний проект. Якщо такого нема – цей метод не підходить;
  • Метод декомпозиції – розбиваємо до WBS (work background structure);
  • Експертні оцінки – експерти на основі свого досвіду оцінюють об’єм роботи після декомпозиції

До точних методів (алгоритмічних) відносимо:

  • Story points – оцінюємо задачі в об’ємі а не в годинах;
  • Functional points – підрахунок кількості функцій з точки зору користувача;
  • Use-Сase points – підрахунок кількості use cases;

 

Грубі методи

Метод аналогії:

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

Переваги:

  • Легко зібрати дані для оцінки
  • По потребує знань предметної сфери
  • Не дає грубих помилок
  • Може застосовуватись на ранніх етапах розробки

Недоліки:

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

Метод декомпозиції:

  • Складаємо Feature List (feature, scope estimates, priority, milestone, comments)
  • Допомагає не упустити якусь функціональність
  • Проводьте декомпозицію до рівня work package
  • Використовуйте контрольні списки стандартних робіт щоб нічого не забути
  • Працює закон великих чисел (помилки як в плюс так і в мінус)

Експертні оцінки:

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

Переваги:

  • Легко організувати і провести
  • Можна застовувати в умовах повної або часткової невизначеності
  • Може бути дуже точним

Недоліки:

  • Якість експертної оцінки визначається досвідом і особливостю конкретного експерта
  • Важко відтворити результат (оцінка дана двома різними експертами може сильно відрізнятися)

Методи проведення експертних оцінок

  1. Делфі – розсилаємо задачі експертам і вони їх окремо оцінюють не бачучи інших учасників. Не впливають один на одного
  2. Сесія оцінок – збираємо всіх експертів разом і вони оцінюють кожну задачу

 

Точні методи

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

Переваги:

  1. Легко відтворити результат (використовуючи один алгоритм оцінка буде завжди така ж)

Недоліки:

  1. Дані алгоритми не враховують виняткові ситуації: дедлайни, пришвидшення роботи за рахунок овертаймів…

 

Story points

В нас є список задач, знаходимо серед них найпростішу і присвоюємо їй значення в 1 story point – визначаємо її еталоном. Знаходимо наступну функціональність яка така ж або, приблизно, в 2 рози більша, порівнюємо з еталоном. Ставимо оцінки відносно одна одної. В результаті виходимо на оцінку всього проекту.

В результаті маємо якусь кількість story points. Наприклад, це 800 story points. Зараз це число нічого не говорить, але якщо визначити скільки часу коштує 1 story point то можна перемножити і дізнатись час.

Для оцінок можна застововувати метод Planning pocker. Колода з фібоначі-лайк послідовності: 0.5, 1, 2, 3, 5, 8, 20… Кожен викидає карту зі своєю оцінкою рубошкою вгору і по команді скрам-майстра всі відкривають свої карти. Метод допомагає вберегтись від впливу інших. Кожен ставить свою оцінку. Далі дебати і ставиться фінальна оцінка.

Functional points

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

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

У Functional points НЕ вимірються вартість, тривалість і трудовитрати. Винятковго розмір.

Use-Case model

Застосовується якщо процес іде по Unified процесу. Даний процес опирається на графічні моделі, варіанти використання.

Кроки методу Use-Case:

  1. Класифікувати діючих персонажів (actors) на простих, середніх і складних, потім вирахувати Unadjusted Actor Weight (UAW), перемжноживши кількість actors в кожній категорії на ваговий коефіцієнт і додати результати;
  2. Класифікувати варіанти використання (use cases) на прості, середні і складні в залежності від кількості операцій, включаючи операції альтернативних сценаріїв. Вирахувати Unadjusted Use-Case Weight (UUCW) аналогічно до UAW;
  3. Додати UUCW і UAW для отримання Unadjusted Use-Case Points (UUCP).

Правила оцінки. Висновок

  • Оцінюйте не об’єм документації, а реальну функціональність. Зведість документацію до Feature list;
  • Фільтруйте інформацію, не допускайте до оцінки занадто багато інформації;
  • Не повідомляйте експертам Ваші міркування щодо розміру і тривалості оцінюваного проекту. Не впливайте на хід їхніх думок

Можна почитати:

https://en.wikipedia.org/wiki/Function_point

https://en.wikipedia.org/wiki/Use_Case_Points

https://www.liquidplanner.com/blog/5-methods-of-project-estimation/

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Схожі статті

Leave a Reply

Your email address will not be published. Required fields are marked *