Як проджект менеджеру працювати з проєктом за Fixed Price

Мінімізація ризиків – одне з головних завдань PM-а під час обговорення та взяття в роботу проєкту. Саме тому досвідчені менеджери багато разів подумають, перш ніж співпрацювати з клієнтом за Fixed Price. Цей формат по праву вважається однією з професійних вершин в умінні проджекта запропонувати оптимальне рішення, яке влаштує клієнта, керівництво і команду, і при цьому зведе будь-які ризики до мінімуму. Давайте разом розбиратися, що таке фіксований прайс і як з ним правильно працювати PM-у.

Що таке Fixed Price

Fixed Price – фіксований проєктний трикутник: конкретний скоуп, час виконання і бюджет. При цьому визначено чіткі критерії якості оцінки проєкту і всі ризики «лягають на плечі» підрядника. Наприклад, якщо команда щось не встигла, то доробляє безкоштовно і навіть можлива виплата штрафів за зриви термінів.

По суті, коли клієнт підписує договір на фіксований прайс, він купує передбачуваність на кшталт «проєкт коштуватиме 100.000$ незалежно від можливих ризиків». Якщо ж відбувається щось не за планом, це вже проблема підрядника. Тому в ціну проєкту від самого початку намагаються включити всі можливі ризики, і в завдання PM-а входить виявити їх і правильно розрахувати.

Коли PM-у варто брати проєкт із фіксованим прайсом

Під час аналізу Fixed Price Project необхідно врахувати комерційну і технічні складові. Обидві рівноцінно важливі, але з погляду проджекта розглядати для управління проєкт із фіксованим прайсом має сенс, якщо:

1. Можна детально описати і зафіксувати скоуп на рівні докладних User Srories. Оптимально, якщо перед підписанням договору присутнє передпроєктне дослідження (дискавері фаза) для виявлення максимальної кількості «підводних каменів».
2. PM і команда можуть точно оцінити скоуп проєкту: технологія знайома, присутні всі необхідні фахівці або їх легко підключити, немає ризикових інтеграцій з непередбачуваними наслідками.
3. Project Manager зможе повністю контролювати процес розробки і робити її силами власної команди без підключення сторонніх девелоперів, зокрема і з боку клієнта.

Якщо всі три пункти виконуються і з комерційною складовою все гаразд, такий Fixed Price Project є потенційно робочим, якщо враховано всі ризики. Саме тому досвідчені менеджери наполягають на проведенні обов’язкової Discovery-фази в життєвому циклі конкретного FP-проєкту.

Як працювати на кожному етапі Fixed Price Project

Головна відмінність FP-проєкту від інших моделей – сильний акцент на аналізі та плануванні, більш жорсткі рамки та підвищений контроль за процесом розробки з боку менеджера. В іншому Fixed Price Project схожий на інші формати.

Життєвий цикл FP-проєкту складається з 5 основних блоків:

1. Аналіз і планування.
2. Ітеративна розробка та тестування.
3. Регресія і стабілізація.
4. Приймальне тестування – UAT.
5. Реліз і пост-релізна підтримка.

Пункти «Регресія і стабілізація» і «Приймання (UAT)» можна виконувати паралельно з деяким зсувом. 

Аналіз і планування

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

Основні кроки, які має виконати Project Manager на етапі аналізу та планування:

1. Описати та зафіксувати скоуп з максимально можливою деталізацією.
2. Оцінити проєкт: технічна реалізація, вартість, терміни.
3. Розробити план виконання кожного етапу розробки, узгодити з командою.
4. Опрацювати ризики, припущення: що може піти не так і що робити, якщо це станеться.
5. Узгодити критерії якості за проєктом, методику і час на UAT.
6. Створити план із розгортання готової системи (Deployment Plan), узгодити його з клієнтом: скільки часу відводиться, хто і за що відповідає.
7. Зафіксувати всі домовленості документально.

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

Ітеративна розробка і тестування

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

Основні завдання проджекта під час створення і тестування IT-продукту:

• усунення проблем на шляху команди;
• моніторинг і коригування плану;
• контроль зміни скоупа;
• репортинг.

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

Моніторинг і коригування

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

Планове = (Загальна оцінка проєкту / Кількість робочий днів у проєкті) * Номер поточного дня * 100%

Фактичне = (Загальна оцінка закритих завдань за день / Загальна оцінка проєкту) * 100%

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

Контроль зміни скоупа

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

Алгоритм дій з контролю зміни скоупа:

1. Прийняти від клієнта запит.
2. Внести його до реєстру змін за проєктом.
3. Разом із командою проаналізувати запит і зрозуміти, чи є він із формального погляду зміною до скоупу: порівняти з беклогом, із припущеннями.
4. Оцінити запит з технічного погляду: чи впливає на поточний або майбутній скоуп і як саме (терміни, бюджет).
5. Затвердити з клієнтом підсумкове рішення за його запитом: вносити чи ні зміни. Тут головне завдання PM-а – домогтися чіткої відповіді від клієнта і все задокументувати. Це допоможе відстояти вашу позицію в разі виникнення спірних питань, особливо якщо зміняться строки і бюджет проєкту.

Приклад реєстру змін:

Репортинг

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

Що має бути в проєктному звіті:

• прогрес (кількісні дані);
• ризики та блокери;
• допомога, яка потрібна від стейкхолдерів;
• динаміка змін скоупа;
• прогноз дати релізу з урахуванням поточного стану проєкту.

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

Регресія і стабілізація

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

Зазвичай ця фаза йде перед прийманням, мета – підійти до фази UAT зі стабільним реліз-кандидатом. Під час оцінки термінів і бюджету на цей етап обов’язково врахувати хоча б один цикл регресії та час на усунення дефектів із повторною перевіркою. Після цього можна переходити до наступної фази Fixed Price Project – приймального тестування або UAT.

Приймальне тестування – UAT

UAT проводить клієнт, при цьому сам процес – це не технічне тестування за аналогією з QA. Тут основний акцент не на функціональності, а на виконанні бізнес-логіки – клієнт має зрозуміти, чи закриває отриманий продукт його бізнес-потреби.

Загальна схема організації UAT:

1. Сформулювати критерії входу і виходу.
2. Розробити сценарії приймання.
3. Прохід по кожній окремій історії.
4. Реєстрація та пріоритизація запитів.
5. Усунення дефектів і внесення змін.

Після останнього кроку знову повернення до пункту 3 – прохід за сценаріями – і так по колу, поки клієнт не скаже переходити до релізу продукту. Критерії входу і виходу можуть бути різноманітними. Наприклад, фазу UAT може бути розпочато за умови, що після перевірки X% тест-кейсів у системі залишаються неусунутими 0 дефектів рівня blocker, до 3-х – critical і не більше 10 – high.

Реліз і пост-релізна підтримка

Основа проведення релізу – Deployment Plan, у якому описано технічні кроки та зони відповідальності організації процесу з розгортання системи. План має бути детально описаний і обов’язково узгоджений із клієнтом. Оптимально, якщо присутній ще й Rollback Plan, щоб була можливість повернути назад у разі виникнення помилок і проблем із розгортанням. Досвідчені менеджери також радять ще провести Dry Run – попередньо «прогнати» систему за Deployment Plan у тестовому оточенні, яке схоже на продакшн.

Якщо говорити про пост-релізну підтримку, то тут краще заздалегідь забюджетувати необхідну команду і чітко домовитися про severity-дефекти, які безкоштовно усуваються. Такий підхід дасть змогу простіше організувати техпідтримку і чітко визначити межі, що саме входить до стандартного пакету послуг, а що за додаткову плату. Щойно реліз пройшов успішно і забезпечено умови щодо пост-релізної підтримки, Fixed Price Project можна вважати закритим.

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

Fixed Price Project для компанії несе в собі більше ризиків, ніж інші види проєктів. Тому за всіх рівних, досвідчені менеджери намагатимуться взяти варіант без фіксованого прайсу. Але бувають ситуації, коли з фінансового погляду або якихось домовленостей для компанії конкретний FP-проєкт значно привабливіший за інші – це PM не може ігнорувати. У цьому разі в завдання проджекта входить оцінити кількісно ризики, дати начальству інформацію для рішення і в разі ухвалення проєкту – мінімізувати кількість потенційних проблем і негативних наслідків.

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

Інформацію керівництву щодо спірного FP-проєкту краще передавати в такому форматі:

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

Далі, якщо керівництво ухвалить рішення взяти в роботу Fixed Price Project, менеджер мінімізує ризики для компанії. Детально розділяє скоуп і зони відповідальності між клієнтом і командою, документує залежності на замовника, робить якомога більше припущень. Усе це дає змогу зменшити не лише кількість ризиків, а й можливість виникнення негативних наслідків у разі провалу FP-проєкту.

Висновки

Саме проджект-менеджер відповідає за те, чи візьмуть проєкт у роботу, та чи зможе команда Delivery працювати без стресу. Тому ви повинні міти швидко оцінювати, планувати та управляти очікуваннями клієнтів. Як далі працювати з проєктом за Fixed Price (і чи брати його взагалі), ви маєте визначитись на етапі пресейлу.

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

Ми з Ольгою Гром (Delivery Manager в Master Of Code Global) навчимо вас планувати проєкт так, щоб Delivery-команда змогла його здійснити межах встановленого плану, навіть в умовах Fixed Price.