Що таке оцінка проекту? Приходить до Вас менеджер з документом на 5 аркушів і питає за скільки часу це буде зроблено. Потрібно дуже терміново, на вчора. Погортавши 3 хвилини цей документ, почухавши потилицю, Ви видаєте фразу: “3 місяці”.
Чи була це оцінка затрат часу на проект? Звичайно! І тут Ви навіть використали один з найпопулярніших способів оцінки – пальцем в небо. Наскільки точною є ця оцінка – це уже інше питання. Вона може бути дуже точною, все залежить від досвіду.
Цей спосіб чудовий, і працює в більшості випадків, але ж ми професіонали і так не робимо. Розглянемо варіанти як можна правильно оцінювати проекти.
На цю тему уже є величезна кількість матеріалів зібраних більш ніж за 20 років історії індустрії, є величезна кількість експертів і побудовані процеси. Але все ще:
- Кожний десятий проект не може бути оцінений взагалі;
- Кожний шостий приречений на провал з самого початку;
- Кожний четвертий має великі шанси вийти за межі бюджету і часу.
Що таке оцінка проекту
Для початку дамо визначення що таке проект.
Проект – це унікальний набір зкоординованих дій з датами початку і закінчення, направлений на досягнення кінцевого результату в рамках обмежень по часу, витратах і ресурсам.
Існує 3 проектні обмеження: Schedule, Scope, Resource.
Якщо дядя Ваня за 1 день робить 1 стілець і ми платимо йому $100 за день, тоді виходить вартість стільця для нас – $100.
Що таке успішний проект? Щоб проект став успішним, він повинен відповідати наступним критеріям:
- Зробити кінцевий продукт який влаштовуватиме всі зацікавлені сторони;
- Закінчити його в термін (вчасно);
- При цьому залишитись на вимагаємому рівні якості і з дотриманням рівня виділених ресурсів;
- Виявитись прибутковим.
Щоб цього досягти нам потрібно оцінити:
- Scope – об’єм задач які нам потрібно буде зробити (трудозатрати);
- Schedule – час за який нам потрібно реалізувати ці роботи;
- Resources – ресурси за домогомою який ми реалізуємо ці роботи в межах встановленого часу.
Schedule = Scope/Resources
Ніколи, ні при яких обставинах, не давайте спонтанних оцінок. Попросіть хоча б 15 хвилин, підійдіть до свого робочого місця і подумайте.
Так як на проект впливає велика кількість факторів, оцінка – це ймовірнісне значення. Тут можна розглянути “Конус невизначенності МакКонела”
В залежності від етапу проекту, оцінка витрат може змінюватись від -50 до +100%.
Завжди давайте оцінку з адекватним рівнем точності, викорстовуйте вилку оцінювання – від-до. (Не можна казати замовнику: Ми оцінили проект в 1264 години, він займе 2 місяці і 19 днів і буде коштувати $46328.)
Хороша оцінка – хорошою вважається оцінка яка забезпечує достатньо ясне представлення реального стану проекту і дозволяє керівнику проекту приймати хороші рішення відностно того як управляти проектом для досягнення цілей.
Алгоритм оцінки
- Scope estimates – рахуємо загальний об’єм роботи;
- Effort estimates – знаючи що потрібно зробити, можна скласти список задач які потрібно реалізувати;
- Schedule estimates – графік, коли ці роботи можуть бути виконані;
- Risk estimates – оцінюємо ризики;
- Resource estimates – оцінюємо ресурси з урахуванням коли люди підуть у відпустки і є перерви в роботі, коли потрібно збільшувати команду
- 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
- Використовуйте контрольні списки стандартних робіт щоб нічого не забути
- Працює закон великих чисел (помилки як в плюс так і в мінус)
Експертні оцінки:
- Оцінку проекту виконує експерт на основі свого досвіду
- Експерт формує оцінку з врахуванням відмінностей поперднього проекту
- Експерт може врахувати відмінності пов’язані зі зміною технології розробки
- Експертні оцінки потрібно застосовувати разом з іншими методами
Переваги:
- Легко організувати і провести
- Можна застовувати в умовах повної або часткової невизначеності
- Може бути дуже точним
Недоліки:
- Якість експертної оцінки визначається досвідом і особливостю конкретного експерта
- Важко відтворити результат (оцінка дана двома різними експертами може сильно відрізнятися)
Методи проведення експертних оцінок
- Делфі – розсилаємо задачі експертам і вони їх окремо оцінюють не бачучи інших учасників. Не впливають один на одного
- Сесія оцінок – збираємо всіх експертів разом і вони оцінюють кожну задачу
Точні методи
Використовуються коли немає експертів або потрібно працювати з новою технологією. Також коли є готове Технічне завдання з усіма вимогами.
Переваги:
- Легко відтворити результат (використовуючи один алгоритм оцінка буде завжди така ж)
Недоліки:
- Дані алгоритми не враховують виняткові ситуації: дедлайни, пришвидшення роботи за рахунок овертаймів…
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:
- Класифікувати діючих персонажів (actors) на простих, середніх і складних, потім вирахувати Unadjusted Actor Weight (UAW), перемжноживши кількість actors в кожній категорії на ваговий коефіцієнт і додати результати;
- Класифікувати варіанти використання (use cases) на прості, середні і складні в залежності від кількості операцій, включаючи операції альтернативних сценаріїв. Вирахувати Unadjusted Use-Case Weight (UUCW) аналогічно до UAW;
- Додати 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/
