Окт. 08

Як сплануєш, так і проведеш. Оцінюємо проєкт з максимальною точністю

Мене звати Оля, я сертифікований РМР і PM у компанії SoftServe. На написання статті мене надихнуло спілкування з близькою людиною, яка починала проєкт from a scratch. Як виявилось, часто навіть технічним спеціалістам потрібна допомога в структуруванні процесу та розкладанні усього по поличках.

Думаю, багато з вас брали участь в оцінюванні проєкту і навіть мають певні tips&trics. Але завжди знайдуться нюанси, які можна випадково пропустити. У статті розглянемо проєкт під мікроскопом, зокрема його оцінювання. Отож ми:

довідаємось, як допомогти оцінювачам давати найкращі естімейти;
докладно обговоримо WBS, network diagram, методи оцінювання і те, як естімейт експерта перетворити на час роботи команди.
розглянемо різні типи оцінювачів і зрозуміємо, на що треба зважати під час оцінювання.

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

Ілюстрація Уляни Патоки

Етапи планування проєкту

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

Важливо не братися за все відразу, а виділити головні етапи в плануванні — від декомпозиції робіт і пошуку залежностей між їх видами до оцінювання тривалості та власне розробки детального графіка, який охоплює ресурси та показує залежність від календаря. Тобто отримуємо project schedule, project budget & project scope.

Планування проєктів — це поєднання чотирьох етапів:

WBS — вихід від декомпозиції проєкту.
Network diagram — вихід від пошуку залежностей між активностями проєкту.
Оцінювання тривалості та вартості проєкту.
Планування ресурсів (експерт найчастіше планує під себе, і далі ми вже масштабуємо це на команду).

Етап № 1. Work breakdown structure (WBS)

Це перший етап після того, як ми зібрали вимоги й визначили скоуп.

WBS — графічне зображення декомпозиції проєкту за правилом: якщо зберемо всі частинки декомпозиції в одне ціле, отримаємо готовий продукт.

Я буду використовувати два терміни. Декомпозиція — це метод, за допомогою якого розбивають project scope і project deliverables на дрібніші елементи, якими легше керувати. Work package — це елементи робіт, розташовані на найнижчому рівні WBS, для якого можлива оцінка cost and duration, а також управління ними.

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

Хто має декомпозувати? Найкраще зібрати команду, яка далі працюватиме над проєктом. Хоча часто це робить архітектор з BA чи техлід з BA. Знаю випадки, коли цим займався джуніор чи, ще гірше, PM.

Раніше майже кожен проєкт я самостійно розбивала на частинки на 70%. Це залежало від його складності. Якщо в роботу потрапив простий сайт чи інтернет-магазин — ви як PM зможете зробити основну декомпозицію проєкту.

Отже, потрібно взяти увесь скоуп робіт і розбити на маленькі поставки (deliverables). І записати їх. Де? Та хоч в Excel чи у Word. І далі, якщо маєте змогу, розмістити в ієрархічній структурі, використовуючи MS Project чи схожі тули.

Як декомпозувати? Саме це питання я чула найчастіше. Адже без суттєвого досвіду в оцінюванні проєктів складно зробити це вперше : )

Я підготувала маленьку шпаргалку. Треба:

Проаналізувати всі результати поставок щодо того, чи справді вони входять у скоуп і чи правильно ми їх розуміємо. Це надзвичайно важливий етап. Часто є кілька джерел скоупу, наприклад, SOW (Statement of Work), листи на пошті чи певні нотатки. Тому бажано зібрати цю інформацію воєдино і ще раз отримати підтвердження від клієнта.
Організувати рівні — що на що ми розбиваємо. Поміркуйте та уявіть, що буде на головному рівні, а що на дочірніх.
Розбити верхні рівні на нижні.
Перевірити, чи достатньо ми декомпозували. Для цього ставимо питання що? Якщо далі при розбитті йде питання як? — ви достатньо декомпозували.

Далі розглянемо приклади та правила, як це робити. Почнімо від простого і зрозумілого усім. Ми хочемо відкрити кафе. Як це завдання розбити? — Ремонт обладнання, меблі, документація, персонал тощо.

Розбиваємо завдання «ремонт»: стіни + стеля + підлога. Далі «стіни»: шпалери + дзеркала.

Чи можемо розбити ще шпалери? Ні, далі будуть лише активності: купити шпалери, наклеїти тощо.

Головне правило — пам’ятати, що всі рівні WBS відповідають на питання що? Якщо починається питання як, то це вже шлях досягнення результату поставки.

До речі, після цього мало виникнути питання: а як це відбувається в Agile і Scrum? Усе просто: ми розбиваємо продукт на епіки, їх на Features, ті на User Stories.

Пам’ятаємо, що результатом Story Point є deliverables. Тобто результат поставки, який відповідає на питання що? Наприклад, поглянемо на work package, наша User Story: я як користувач хочу отримати те для того-то. Відповідь на питання «Що я хочу отримати?» — те.

Як споживачеві мені зручно шукати книги за жанрами, щоб швидко знайти ті, які я люблю читати.

Що? Книги будуть посортовані за жанрами.

Як споживач я, відбираючи книги для купівлі, хочу кожну класти відразу в кошик.

Що? Книга в кошику.

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

Що? Відстеження покупок.

Те, що я розповідаю, здається логічним, але свого часу почула питання: «Не розумію, як мені це розбити і за якою ознакою?». Відповідь проста: це можна робити так, як забажаєте. Наприклад, за фазами проєкту.

Або за результатами поставки:

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

Далі можемо ділити кожен модуль. Зокрема, «модуль пацієнтів» — «контактна інформація» (яку, своєю чергою, дробимо на «адреси», «телефони», «фотокартки», «вік» тощо), «страховки», «історія». І так з кожним модулем. Зверніть увагу на те, що у прикладі я ділю цілком поверхово.

А що робити, якщо не всі deliverables відомі? Та все просто. Розставляємо ті, які знаємо, а далі кожного спринту передивляємось та оновлюємо. Це називається Rolling wave planning.

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

Вигляд в Agile:

Але це ще не всі правила: нижчі рівні WBS повинні згортатися на вищі рівні, щоб нічого не було пропущено і щоб не виконувалася зайва робота. Іноді це називають «правилом 100%».

Варто пам’ятати:

Cost. Елементи WBS не містять costs. Ми ще не дійшли до оцінювання проєкту в грошовому еквіваленті.
Importance. Елементи WBS не вказують на важливість (пріоритетність). Як ви вже побачили на прикладах, ми не вказували, які результати поставок є для бізнесу більш важливими, а які менш.
Levels of decomposition. WBS не має обмежень за кількістю рівнів декомпозиції. Це може бути і два рівні, і шість, і більше. Це залежить від проєкту, його складності.
Relationships. WBS не містить взаємозв’язків елементів. Ми не згадували, які результати поставок мають бути першими, які другими, а які покривають своїм виконанням інші.
Resources. Елементи WBS не показують призначені ресурси. Це просто елементи. Ми потім будемо думати, а хто ж стане виконавцем.
Time. WBS не містить тривалості та послідовності елементів. Знов-таки це дія, яку ми виконуватимемо пізніше.

WBS checklist

Перед здачею WBS я рекомендую пройтись по таких пунктах. Якщо якийсь із них не виконується, треба обов’язково це вирішити:

Чи визначає WBS 100% роботи, яка має бути виконана на проєкті? Тобто це мають бути не лише продукти після імплементації, а й інші активності, наприклад, важлива документація (PM Plans).
Чи кожний елемент є результатом (deliverables)? Чи не потрапили туди активності?
Чи зможуть стейкхолдери зрозуміти сферу проєкту із WBS? Тобто кожна людина, яка залучена до проєкту, зрозуміє кожен пункт WBS?
Чи охоплює WBS всі зовнішні та внутрішні результати, включаючи результати управління проєктами?
Чи кожен рівень становить 100% роботи, необхідної для доставки батьківського рівня?
Чи достатньо декомпозиції, щоб прописати активності до кожного work package?
Чи використовується ієрархічна структура?
Чи WBS створили ті, хто буде виконувати роботу? Якщо відповідь ні, хоча б ознайомте з результатом команду.
Чи регулярно оновлюється WBS після затвердження проєкту?
Чи можете ви чітко визначити критерії прийняття кожного work package? Definition of Done, або Acceptance Criteria.
Чи дає змогу WBS точно оцінити витрати?
Чи не є WBS занадто громіздкою або навпаки?

Етап № 2. Network diagram

Ми вже згадували, що WBS не містить взаємозалежностей чи зв’язків, але ж їх треба врахувати, тому що певна частина робіт має вищий пріоритет. А ще без результатів певних робіт ми не можемо почати виконання наступних.

Інколи буває, що запускаєш фічу й цим закриваєш частини іншого функціоналу. Чи це потрібно вказувати власне на WBS? WBS не містить dependencies. Їх містить мережева діаграма.

У Network diagram показано управління проєктами, що потрібно зробити і в якому порядку.
У термінології управління проєктами мережева діаграма — це «логічне подання завдань, що визначають послідовність роботи над проєктом».
Діаграма може містити дати початку та кінця, назви завдань, ім’я людини, відповідальної за виконання кожного завдання.
Діаграма повинна з першого погляду показати, що має відбутися і в якому порядку.

Діаграми мережі корисні, оскільки вони:

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

Погляньмо на схему. Який елемент на ній головний? Щоб працювати над D, ми повинні завершити роботу над A&B. Те саме щодо елемента G — спочатку закінчуємо з D&E і лише потім беремося за G. Також на діаграмі варто вказувати (якщо є потреба) часові рамки початку кожного виду робіт.

Етап № 3. Естімейт тривалості та вартості

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

Аналогічне оцінювання.
Параметричне оцінювання.
Оцінювання знизу вверх.
Оцінювання за трьома точками, або PERT.

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

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

Оцінювання за аналогією

Є завдання — розробити десять нових лендинг-сторінок. Ваша команда вже виконувала схожі задачі, і створення п’яти сторінок займало один тиждень. Отже, ви берете цю кількість часу як приклад. І якщо треба розробити 10 лендингів, то припустите, що на це піде два тижні.

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

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

Оцінювання за параметрами

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

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

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

Повернемось до прикладу і спробуємо оцінити той самий лендинг: ми знаємо, що header займалися дві години, вартість роботи фронтендера коштує 20 баксів за годину, futter — одна година тощо. Підсумуємо й отримаємо вартість лендингу.

А тепер — до плюсів і мінусів. Якщо немає параметра, за який можна зачепитися, ми не зможемо використати такий метод оцінювання.

Розгляньмо на прикладі будівництва. Проєкт будинку оцінюють у 120 доларів за квадратний метр. Підрядник має зробити ставку не менше як 5000 доларів на день. Інженер вимагає плату в розмірі 10 000 доларів за креслення. Ви можете розпізнати параметричне оцінювання за його параметричним значенням (одиничною ставкою).

Для цього методу відповідальна за оцінювання людина змоделює (або описує) проєкт, використовуючи набір алгоритмів. Наприклад, проєкт охоплює проведення опитування 300 осіб. Кожне інтерв’ю містить 20 запитань із кількома варіантами, а минулий досвід показав, що на адміністрування потрібно 10 хвилин. Згідно з параметричною оцінкою, загальні зусилля для цього завдання становитимуть: E = кількість інтерв’ю × 10 хвилин = 3000 хвилин = 5 годин.

Оцінювання за трьома числами, або Project Evaluation and Review Technique (PERT)

Для визначення приблизного діапазону тривалості Activity метод PERT використовує три оцінки:

• Most likely/Most Probable (найімовірніша) — tM;

• Optimistic (оптимістична) — tO;

• Pessimistic (песимістична) — tP.

Expected duration (очікувана тривалість) — tE — розраховується за формулою: tE = (tP + tO + 4* tM) : 6

Standard deviation, стандартне відхилення — σ — розраховується за формулою: σ = (tP — tO) : 2

Повернімося ще раз до прикладу. Отже, для розробки лендингу ми оцінюємо tO як 40 годин, tM як 45 годин, а tP — 55 годин. Відповідно до формули, маємо (40 + 4 * 45 + 55) / 6 = 46 годин. І також обрахуємо стандартне відхилення (55 — 40) : 2 = 7.5

Отже, клієнту подаємо дані у вигляді 46 год +/- 7.5 год

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

Оцінювання знизу вверх

Це і є наша декомпозиція, про яку ми вже стільки говоримо. Робота розбивається на більш дрібні завдання. Готуємося до оцінювання того, що потрібно для виконання вимог кожної з частин роботи, і ці оцінки сумуються для певного елемента робіт. Точність оцінювання «знизу вверх» визначається розміром і складністю робіт, виділених на нижніх рівнях. Зазвичай менша кількість процесів збільшує точність оцінювання. Це — найточніший метод.

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

Ми вже майже все врахували, але є ситуації, коли все іде не за планом і починають виникати ризики. Що ж тоді робити? Як це врахувати в оцінці?

Duration estimates можуть містити резерви. Це такі собі буфери, які використовують при появі ризиків. Є два типи резервів:

Резерв на випадок непередбачуваних ситуацій — це гроші, додані керівником проєкту до оцінки вартості проєкту за невизначені події/ризики, які можуть трапитися (також відомі як «відомі невідомі»). Цей буфер вводиться для управління виявленими ризиками. Суму розраховують на основі методів управління ризиками (якісний ризик-аналіз). Керівник проєкту має повноваження скористатися резервом у разі непередбачуваних ситуацій, коли ризик матеріалізується. Якщо ризик не буде реалізований, резерв, передбачений для нього, буде звільнений. Contingency reserves можуть бути виражені в %, фіксованій кількості робочих періодів або розраховані (PERT) — стандартне відхилення.
Управлінський резерв — це гроші, що додає вище керівництво до загального бюджету проєкту за невизначені події, про які навіть не замислюються (також відомі як «невідомі невідомі», тобто ризики, не вказані в реєстрі). Його використовують для управління невідомими ризиками, тобто тими, що неможливо ідентифікувати за допомогою процесів управління ризиками. Сама сума заснована на організаційній політиці та/або складності проєкту, зазвичай «вгадується» у розмірі 5-15% від загального бюджету. Резерв управління контролює представник вищого керівництва (не керівник проєкту), перед його використанням потрібно отримати схвалення. Резерв управління буде зберігатися до кінця проєкту.

Етап № 4. Ресурси

Estimate Activity Resources — це процес оцінювання ресурсів команди. Що робити, якщо експерт естімував на себе? А команда у вас, скажімо, складається з 10 людей.

У такому разі потрібно ввести коригувальний коефіцієнт:

Наприклад:

Senior — 1
Middle — 0.5-0.7
Junior — 0.2-0.3

Тобто:

Senior зробить роботу за 60 год
Middle зробить ту саму роботу за 78-90 год
Junior — за 102-108 год
Якщо у вас команда Senior, Middle & Junior, ви можете свої естімейти поділити на два (1 + 0.7 + 0.3)

Психотипи експертів

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

Спершу розглянемо психотипи експертів.

Експерт. Це людина, яка володіє спеціальними знаннями, навичками, досвідом. Проте запитайте себе, чи кожен Senior може адекватно оцінити проєкт? Відповідь має бути: ні! Для оцінювання важливими є:

Володіння техніками оцінювання.
Вміння враховувати невизначеності (ризики).
Аналіз власного (і не тільки) досвіду.
Психотип характеру (педант/авантюрист/оптиміст тощо).
Ретельне оцінювання.

То чому ж ми надіємось отримати хорошу, виважену оцінку від хорошого і сеньйорного розробника? Є поняття гало-ефекту (ефект ореолу) — результат дії загального враження про що-небудь (явище, людину, речі) на сприйняття його деяких особливостей.

Пам’ятайте: не кожен, хто добре виконує свою роботу, здатен її оцінити.

Практик. Що важливіше: теорія чи практика? Який спосіб є кращим: зосереджений на теорії чи на здобутті практичних навичок?

Ваш експерт з Node.js оцінив на цій технології вже безліч проєктів. І ви до нього звертаєтесь оцінити проєкт на TypeScript. Ну так, є якісь схожі моменти, але чи буде точною оцінка, якщо про TypeScript він знає лише теоретично?

Той, що любить деталі. Жоден талант не може подолати пристрасті до деталей. У мене є знайомий дизайнер, що по дві години вимальовує «суперважливу закарлючку». Врахуйте, що, не знаючи все до останньої деталі, така людина не візьметься за оцінювання проєкту. А часом дуже складно, до того ж в Agile, знати та передбачити все до останньої дрібниці.

Досвідчений. Якщо спеціаліст оцінив 10 однакових проєктів, в 11-му він точно щось не дочитає.

Песиміст. Песиміст бачить труднощі за будь-якої нагоди. Що це означає для вас? Найголовніше — те, що його оцінки будуть сильно завищені, і вам потрібно вирахувати оце «наскільки».

В мене був випадок, коли песиміст оцінив проєкт на 6 років замість фактичного року. Тобто не лише всі ризики мали збутися, мав настати майже апокаліпсис. «Усе грає на руку песимістам, однак песимісти завжди програють», — писав Жак Шардон, французький письменник.

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

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

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

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

Впевнений. Звертайте увагу на інтонацію. Якщо говорити щось впевнено — люди в це повірять.

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

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

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

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

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

Щоб не базуватися лише на психотипах, завжди перевіряйте:

Кваліфікацію експерта:
- досвід у предметній галузі (чи є оцінювач експертом саме в потрібній сфері. У маленьких компаніях часто буває, що PHP оцінює проєкт на Pyton. І на жаль, це не жарт);
- досвід в оцінюванні (якщо це перший досвід експерта, то ймовірність правильної оцінки зменшується).
Як проведена оцінка:
- які методи використовували (це оцінювання за аналогією чи декомпозиція? А може, збірна солянка?)
- чи була надана експерту необхідна інформація (можливо, не всі вимоги до проєкту були уточнені. Наприклад, як часто не враховуються нефункціональні вимоги? Оцінювання, зроблене без врахування NFR, спричинить овертайми на проєкті, відтак постраждає якість виконання);
- чи був проаналізований власний досвід (можливо, за плечима є схожі проєкти і варто скористатися історичними та статистичними даними);
- чи був проаналізований досвід організації (те саме в розрізі всієї компанії);
- наскільки ретельною була оцінка (чи це була зважена оцінка чи зроблена в поспіху? Чи дали ви достатньо часу експерту розібратися з усіма вимогами?).
Психотип експерта:
- чи міг психотип експерта вплинути на оцінку;
- якщо так, то в який бік варто зробити поправку.
Реалістичність минулих оцінок цього експерта (з минулих фаз/проєктів).
На яких припущеннях базується оцінка:
- кваліфікація виконавців (ви хочете сеньйора, а отримуєте трьох джунів);
- потреба в навчанні (чи ваші виконавці — знавці технології, на якій ведеться розробка проєкту? Чи необхідний певний час, щоб вони вийшли на стадію перформансу? До прикладу, ми переводили дотнетчиків на TypeScript і для хорошого перформансу це зайняло чотири місяці);
- доступність виконавців (можливо, хтось залучений на 50% на проєкті. Повірте, ці 50% у реальному світі навіть не можна прирівняти до 30%. На моїх проєктах був класний AQA, залучений на 50%. На жаль, з часом він настільки виснажився від перемикання між проєктами, що попросив один проєкт на 100% залученості).
Чи були враховані невизначеності та ризики:
- наявність резервів. Згадуємо про резерв на ризики та управлінський резерв;
- проєктні обмеження. Ви можете дати найдосконалішу оцінку, але в замовника лише 250 тис. доларів чи тільки 6 місяців. Тому орієнтуйтесь на це під час вибору технологій. Можливо, альтернативна технологія допоможе зекономити і час, і гроші;
- час виходу команди на максимальну продуктивність. Ви ж усі пам’ятаєте про стадії розвитку команд. Перед перформінгом в нас іде формінг, штормінг, нормінг. Так от, увесь цей час команда не зможе показувати найвищі результати;
- «непродуктивний» час — наради, зустрічі із замовником, звітність. Якщо думаєте, що ваші виконавці перформлять 8 годин на добу — це зовсім не так. Якщо працюєте за Scrum з усіма церемоніями, це буде приблизно 6 годин на добу на виконання безпосередніх завдань.
- затрати на забезпечення якості проєкту. Я завжди закладаю певний % часу на unit test, code review тощо. Плюс саме тестування: ви можете рахувати певний % часу від розробки загалом чи прораховувати час до кожної сторі. Не забувайте й про інтеграційне тестування.

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

Висновок

Отже, підіб’ємо підсумки. Крім хардскілової частини, PM має володіти психологічними техніками, щоб підкоригувати отримані оцінки. Також варто зважати на дуже багато факторів перед тим, як можна буде показати оцінку клієнтові.

Тож декомпозуємо, встановлюємо залежності, оцінюємо, коригуємо щодо кількості людей і сміливо йдемо до замовника!