Хто такий бізнес-аналітик в IT: ролі, обов'язки та взаємодія з PM
Initiation (Ініціація)
На старті на проєкті нема нікого, окрім менеджера з продажу, ПМ та БА. Здавалося б, роботи небагато. Ніхто не пише код або не створює дизайн. Є лише технічне завдання від клієнта та вхідні документи, які потрібно обробити. Проте залученість аналітика на цьому етапі чи не найвища. Головне завдання зараз — зрозуміти справжню проблему замовника.
БА не починає з написання детальних вимог — він збирає контекст. Цей процес включає аналіз документів, виданих клієнтом, інтерв’ю з клієнтом або внутрішнім замовником, фіксацію бізнес‑цілей, аналіз уже існуючого рішення (якщо таке є) та пошук альтернатив. Також варто додати, що є Discovery* — підфаза у рамках ініціації проєкту, на якій БА працює ще більш інтенсивно над дослідженням проблеми та виявленням вимог.
Якщо коротко, на цьому етапі формуються короткий опис проблеми та перші гіпотези: хто користувачі, які ключові процеси зачіпаємо та які метрики маємо покращити. БА робить короткий BRD (business requirements document) та список відкритих питань до клієнта. Також може працювати над першими прототипами системи, щоб візуалізувати текстові вимоги та припущення у реальний інтерфейс, який виконує реальні задачі. Хоч це і є однією з ключових та найбільш дієвих технік виявлення вимог, використовуватися вона може не завжди.
- Комунікація з ПМ: БА передає ПМ первинні результати і список ризиків/невизначеностей. Разом вони вирішують, чи потрібна фаза Discovery* і орієнтовний масштаб робіт. ПМ фіксує бізнес-цілі і визначає next steps (реальні дати для Discovery).
Discovery — опціональна підфаза у рамках ініціації, серед задач якої є поглиблення у контекст замовника, більш детальне вивчення його бізнесу, цільової аудиторії. Це необхідно, щоб отримати більш детальні очікування зацікавлених сторін від продукту.
BRD — документ, який є основним відображенням бізнес-ідеї проєкту.
Planning (Планування)
Тепер, коли ми маємо всі необхідні дані про проєкт, розуміємо проблему клієнта та яке рішення потрібно розробляти, можна переходити до планування.
БА на цьому етапі переводить гіпотези у формальні артефакти: карти процесів, user stories, acceptance criteria, користувацький шлях у системі та прості прототипи. Вони потрібні, щоб зробити більш точну та реалістичну оцінку часу розробки. І найголовніше — правильно побудувати календарний план. Робота за рахунок цього розбивається на логічні частини і допомагає оцінити залежності (технічні інтеграції, дані, компетенції). БА готує WBS‑подібну розбивку* на основний скоуп робіт задля проведення більш детальної оцінки.
- Комунікація з ПМ: тут пари працюють щільно — БА надає «готові до оцінки» User Stories*, ПМ використовує їх для розподілу ресурсів, календарного планування і формування спринтів*/віх*. ПМ питає у БА про пріоритети (що критично для MVP*), а БА підсвічує бізнес‑наслідки відтермінування або скорочення об’єму робіт. Артефакти для обміну: backlog*, роадмапа*, список залежностей.
WBS розбивка — декомпозиція задач більшого масштабу на менші, легші для оцінювання об’єму робіт.
User stories — короткий опис функціоналу з точки зору користувача.
Спринт — заданий відрізок часу, протягом якого потрібно виконати запланований обсяг роботи.
Віха — точка у проєкті, яка відзначає завершення важливого етапу або випуск великого функціоналу.
MVP — Minimum Viable Product, версія продукту/системи, яка виконує мінімально необхідний для розвʼязання задачі функціонал.
Backlog — список задач, які треба виконати для випуску певної версії продукту.
Роадмапа — візуальний стратегічний документ, що відображає основні етапи розвитку продукту чи системи.
Execution (Виконання / Розробка)
Тепер, коли БА визначив, що потрібно робити, а ПМ — хто та за який час це буде здійснювати, можна переходити до виконання.
Під час цієї фази залученість БА залежить від того, яка обрана методологія розробки програмного забезпечення. Якщо це одна з Agile-методологій*, задіяність БА буде стабільно високою, особливо, якщо виникнуть додаткові запити від замовника або різноманітні Change Requests*. Це означатиме, що знову треба робити виявлення, аналіз, документацію та затвердження вимог. При методології Waterfall* залученість БА буде нижчою.
Проте незалежно від методології основна задача — це бути «живим довідником» або консультантом з вимог. А саме: відповідати на питання розробників, уточнювати acceptance criteria*, доповнювати приклади даних і моделювати бізнес‑логіку. БА також фіксує тимчасові рішення і коригує вимоги, якщо під час розробки виявляються нові факти. Інструменти: Confluence/Docs для описів, Miro/Figma для уточнень, Jira/Trello для тасків*.
- Комунікація з ПМ: БА повідомляє ПМ про зміни в об’ємі робіт або нові ризики, аргументує потребу в додатковому часі або ресурсах. ПМ приймає рішення про перепланування, узгоджує з клієнтом і відслідковує вплив на дедлайни*. У великих командах ПМ не приймає технічних рішень. Він координує, а БА забезпечує змістовну сторону.
Agile методології — підхід до управління проєктом із фокусом на ітеративну розробку з постійною співпрацею, гнучкість та швидкість адаптації до змін.
Change Request — формальна пропозиція на зміну у проєкті/системі.
Waterfall методологія — класична методологія з фокусом на покрокову розробку від А до Я.
Acceptance Criteria — набір попередньо описаних вимог до поведінки та відгуку системи на конкретні дії.
Таска — англіцизм, задача.
Дедлайн — кінцевий строк завершення задачі.
Monitor & Control (Моніторинг і контроль)
Залученість БА тут уже нижча, проте задачі все ще є. На цьому етапі БА контролює, що реалізоване відповідає бізнес‑цілям. За необхідності проводить перевірку функціоналу за acceptance criteria, бере участь у тестуванні бізнес‑кейсів та іноді — просто у тестуванні системи. Буває, на пару з ПМ.
- Комунікація з ПМ: БА передає список критичних дефектів та пріоритетні доопрацювання; ПМ вирішує, чи входять вони у поточний випуск функціоналу, чи відкладаються. ПМ також інформує стейкхолдерів про статус і координує прийняття управлінських рішень на основі аналітичних висновків БА.
Стейкхолдер — зацікавлена сторона.
Closure / Handover (Закриття)
На етапі закриття у залученості абсолютно домінує ПМ, бо в кінці відбуваються в основному адміністративні процеси. До цього часу БА уже зробив основну масу артефактів.
Перед релізом і після нього аналітик може готувати документацію з вимогами, бізнес‑правила, інструкції для користувачів. Після релізу БА опціонально проводить аналіз результатів проти початкових KPI і готує короткий звіт (що вдалося, що ні). Артефактом може бути фінальний звіт щодо змін у КРІ.
- Комунікація з ПМ: разом вони проводять ретроспективу, формують списки покращень для процесу. ПМ забезпечує формальний розпуск/перерозподіл ресурсів і закриття контрактних зобов’язань. БА — передає знання і відповідає за бізнес‑контекст.
Бонусна секція! Кілька практичних порад для ефективної БA – ПM взаємодії
- Узгодьте, що вважається готовим (Definition of Ready) для історій і артефактів.
- Пояснення: зафіксуйте мінімальний набір полів для user story/задачі (опис, acceptance criteria, приклади даних, залежності). Це зменшить питання від розробників і прискорить планування.
- Приклад: «Історія не йде у спринт, поки у ній немає acceptance criteria та дизайну».
- Узгодьте формат артефактів і місце зберігання (наприклад, усі user stories у Jira, рішення — у Confluence).
- Використовуйте одні інструменти: Miro для воркшопів, Figma/Balsamiq для прототипів, Jira/Trello для тасків, Sheets для швидкої аналітики.
- Ведіть спільний Decision Log (Журнал рішень) і правила ескалації
- Пояснення: фіксуйте ключові рішення (хто, що, чому, коли діяти), щоб уникнути суперечок і пам’ятати контекст. Визначте, які питання вирішує БА, які — ПМ, і коли звертатися до стейкхолдерів.
Підсумок
У цьому гайді ми розглянули лише один із прикладів роботи БА. На практиці обов'язки аналітика можуть змінюватися залежно від специфіки проєкту, команди та методології. Проте незмінним залишається одне: чітке розуміння ролей у команді — це запорука успіху. Взаємодія БА та ПМ є тим фундаментом, на якому будується якість майбутнього продукту.
Отже, БА веде проєкт від виявлення потреб бізнесу до перевірки результату, а ПМ керує процесом доставки. Їхня співпраця — це безперервний діалог. БА відповідає на запитання «Що ми будуємо і чому?», ПМ — «Коли і якими ресурсами?».
