Однак цей формат містить критичні ризики, особливо якщо йдеться про складні довгострокові проєкти або AI-рішення. Найпоширеніша помилка, яка призводить до втрати ресурсів та лояльності клієнта — це відсутність чіткої межі між обов'язками Project Manager (PM) та Business Analyst (BA).

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

Чому суміщення ролей нівелює результативність Discovery?

1. Конфлікт цілей та фокусу

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

У ситуації суміщення фахівець опиняється в стані внутрішнього конфлікту.

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

2. Ерозія експертності

Сьогодні етап discovery в IT перестав бути просто збором вимог. Нішева експертність для BA стала обов'язковим стандартом у будь-якому домені. Без глибокого розуміння конкретної галузі аналітик не здатний поставити правильні питання та побачити приховані ризики.

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

Залучення фахівця з недостатнім рівнем компетенцій (наприклад, Junior-рівня) або спроба PM «підхопити» аналітику створює подвійну вразливість. Помилки, закладені на етапі архітектурного планування, масштабуються під час розробки, перетворюючись на фінансові втрати.

3. Професійна стагнація на складних проєктах

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

Як мінімізувати ризики Fixed Price Discovery: системний підхід

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

1. Наявність перевіреного фреймворку

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

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

2. Чіткий розподіл зон відповідальності

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

  • PM (Project Manager) фокусується на «зовнішньому контурі»: контролює бюджет і терміни, стежить за ресурсами та вчасно каже «ні» новим ідеям, що не вписуються в кошторис. Його завдання — не дати дискавері вийти за межі комерційної доцільності.
  • BA (Business Analyst) занурюється у «внутрішній зміст»: виявляє справжні потреби стейкхолдерів, деталізує вимоги та вибудовує архітектуру рішень.

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

3. Аудит компетенцій

Проведіть чесну оцінку навичок PM/BA (assessment). Ви повинні дуже добре розуміти знання й навички персоналу, який працює на проєктах. На Fixed Price Discovery категорично не можна ставити junior-фахівця, оскільки в умовах жорстко обмеженого бюджету немає права на помилку, яку зазвичай закладають у «навчання на практиці».

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

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

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

4. Фокус на обмеженнях: бюджет як жорсткий детермінант

На етапі Fixed Price Discovery основне завдання PM — не дати фіксованому бюджету перейти в розряд гумового, оскільки в дискавері легко захопитися нескінченним уточненням деталей. Саме тому потрібен фахівець, який вчасно зупинить процес.

  • Бюджет як KPI: Контроль витрат на дослідження є головним KPI менеджера. Кожна додаткова година роботи аналітика над фічами, які не були погоджені в межах дискавері контракту, це прямий збиток.
  • Управління очікуваннями: PM має балансувати між бажанням стейкхолдерів додати ще одну маленьку деталь і реальним обсягом оплачених годин. Якщо вимога виходить за межі, вона має бути відсічена або винесена в окремий Change Request.
  • Запобігання Scope Creep: Поки BA прагне до глибини опрацювання, PM стежить за шириною покриття. Його мета — отримати достатній для оцінки результат, не перетворивши коротку фазу дослідження на нескінченний процес.

Підсумовуючи все вищесказане, BA має добре розуміти нішу й бізнес клієнта, а також бути проактивним і надавати рекомендації щодо роботи проєкту.

Ризик ігнорування суміщення ролей PM та BA — високий!

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

Чи готовий ваш бізнес до фінансових ризиків, спричинених неефективною структурою команди?