Бізнес аналітик у комерційному IT більше не зводиться до людини, яка «пише технічне завдання і зникає». Після квітня 2015 року базовим описом професії лишається третя редакція A Guide to the Business Analysis Body of Knowledge (BABOK Guide v3) Міжнародного інституту бізнес-аналізу (IIBA): шість галузей знань і 30 завдань. У 2022 році той самий інститут видав The Business Analysis Standard — коротший каркас тієї ж практики. У 2026-му до цього додався робочий шар штучного інтелекту: IIBA уже описує, як моделі допомагають готувати сесії збору вимог, але не замінюють перевірку зі стейкхолдером — особою, яка впливає на рішення або залежить від нього.
На ринку праці це видно в цифрах. За літнім опитуванням 2026 року медіанна зарплата Senior Business Analyst в українському IT сягнула 3400 доларів США на місяць — на 300 доларів вище, ніж пів року тому. Поруч Senior Product Manager отримує близько 4300 доларів, Senior-розробник — близько 4500. Розрив показує місце ролі: аналітик коштує менше за того, хто пише код або вирішує, що потрапить у реліз, і саме тому його часто плутають і з тим, і з іншим.
Нижче — не перелік «навичок для резюме», а механізм: хто замовляє роботу бізнес-аналітика, що він робить день за днем, які документи віддає команді і за чим вимірюють, чи робота взагалі вдалася.
Зміст 6 розділів
Хто це — бізнес-аналітик і чим він відрізняється від IT-фахівців
Бізнес-аналітик — це фахівець, який з’ясовує, яку зміну має отримати організація, і перекладає її мовою, придатною для реалізації: правилами, сценаріями, обмеженнями, даними й критеріями приймання. Замовником його роботи буває спонсор проєкту, власник продукту, керівник підрозділу або зовнішній клієнт аутсорсингової компанії. Результат оцінюють не «гарним звітом», а тим, чи команда будує саме потрібну зміну, а не озвучене бажання.
У структурі компанії аналітик стоїть між бізнесом і реалізацією. Він не затверджує бюджет і рідко сам розставляє пріоритети беклогу — упорядкованого списку робіт продукту. Він також не пише прод-код і не ставить фінальний вердикт «баг чи фіча». Його зона — повнота й узгодженість потреб до того, як їх закріплять у коді або в пріоритеті спринту.
| Роль | За що відповідає | Чого не вирішує самотужки |
|---|---|---|
| Бізнес-аналітик | Потреба, правила, сценарії, трасування вимог | Пріоритет релізу, архітектуру коду, факт проходження тестів |
| Розробник | Реалізація рішення в коді й технічні обмеження | Бізнес-ціль зміни та склад стейкхолдерів |
| Тестувальник (QA) | Перевірка відповідності заявленим критеріям | Формулювання самої потреби бізнесу |
| Продакт-менеджер / Product Owner | Цінність, пріоритет, рішення «робимо / не робимо» | Повну специфікацію правил і даних для всіх сценаріїв |
Плутанина виникає там, де одну людину називають і аналітиком, і власником продукту. Тоді рішення про пріоритет і деталізація вимог злипаються. Для маленької команди це терпимо. Для продукту з регуляцією, кількома системами й суперечливими підрозділами це вже ризик: ніхто окремо не фіксує, чию потребу відхилили і чому.
Які завдання вирішує аналітик на початку проєкту
Перша фаза — не «зібрати побажання в таблицю». За BABOK Guide v3 збір вимог (elicitation) і співпраця зі стейкхолдерами не є окремим етапом, який можна закрити протоколом і більше не повертатися. Це повторювана робота, поки зміна живе. На старті аналітик з’ясовує проблему, а не список екранів.
Практично це виглядає так. Керівник складу каже: «Зробіть кнопку, щоб комірник бачив залишки в реальному часі». Аналітик перевіряє, з якої системи беруться залишки, хто має право їх бачити, що вважається «реальним часом» — хвилина, каса чи нічна інвентаризація — і що станеться, якщо два склади відвантажать той самий рядок. Без цих відповідей розробник намалює кнопку, а бізнес отримає іншу правду, ніж у бухгалтерській системі.
На початку проєкту типовий набір дій такий:
- карта стейкхолдерів: хто замовляє, хто користується, хто блокує, хто підписує;
- інтерв’ю, воркшопи, розбір чинних інструкцій, логів і сусідніх систем;
- формулювання проблеми й межі рішення — scope, тобто що свідомо не входить у поставку;
- чорнові користувацькі історії або сценарії використання з критеріями приймання;
- відкриті питання й припущення, без яких оцінка розробки є фікцією.
Технічне завдання в класичному сенсі — один із можливих пакетів, а не обов’язкова форма. У сервісних контрактах його все ще вимагають як додаток. У продуктових командах частіше живуть епіки, історії, правила й макети в спільному просторі. Суть та сама: зафіксувати потребу так, щоб її можна було реалізувати й перевірити, а не «зрозуміти на словах».
Як аналітик будує модель даних і готує документацію
Модель тут — не «красива схема для презентації», а стислий опис того, як устрій справи виглядає для системи. Аналітик показує об’єкти (замовлення, клієнт, залишок), їхні зв’язки, статуси й правила переходу. Розробник з цього збирає сутності, API й обмеження бази. Тестувальник — перевірки на заборонені переходи. Без моделі команда тримає правила в голові кількох людей, і вони розходяться вже на другому спринті.
Це схоже на крій одягу за мірками: поки знято обхват і довжину, кравець не кроїть тканину. Аналогія ламається в моменті, коли вимоги ще змінюються під час «пошиття»: програмний продукт рідко шиють за раз, тож модель мають оновлювати разом зі зміною правила, а не залишати в файлі «версія 1.0» на диску.
Набір робочих артефактів залежить від команди, але рідко обходиться без кількох шарів.
- опис процесу в нотації BPMN 2.0 (стандарт Object Management Group, формальна версія грудня 2010 року) — хто що робить і де система втручається;
- сценарії використання або користувацькі історії з критеріями приймання;
- словник даних і бізнес-правила: що є «активним клієнтом», коли замовлення можна скасувати;
- прототипи екранів — часто в Figma — із прив’язкою полів до правил, а не лише до вигляду;
- матриця трасування: вимога → історія → тест → зміна в коді.
Інструменти — службові. Jira або аналог тримає історії й статуси. Confluence, Notion чи внутрішнє сховище тримає специфікації. SQL потрібен не щоб «бути розробником», а щоб перевірити, чи заявлене правило взагалі існує в даних. Draw.io, Miro, спеціалізовані BPMN-редактори фіксують процес. Документ цінний тим, що з нього можна зібрати тест і оцінку, а не тим, що в ньому сто сторінок.
Для контрактів і регульованих систем орієнтиром якості формулювань лишається ISO/IEC/IEEE 29148:2018 — міжнародний стандарт інженерії вимог. Він задає, якими мають бути окремі вимоги: необхідними, однозначними, перевірюваними, узгодженими. Аналітик, який пише «система має бути зручною», цьому стандарту не відповідає: зручність неможливо ні прийняти, ні спростувати.
Якими метриками вимірюється результат аналітика
Якість аналітика не вимірюють кількістю сторінок і не кількістю зустрічей. Дивляться на те, скільки разів команду змусили переробляти вже зроблене через діру у вимогах, і наскільки швидко після уточнення можна оцінити й реалізувати зміну.
Робочі показники, які команди справді можуть порахувати без окремої «науки»:
- частка історій, повернутих із розробки чи тесту через неясність критеріїв приймання;
- час від «є потреба» до «історія готова до оцінки» — cycle time підготовки вимог;
- кількість змін scope після старту реалізації, розкладених на «нова потреба» і «раніше не запитали»;
- покриття критичних правил тестами, виведеними з тієї ж специфікації;
- кількість дефектів класу «зробили не те», а не «зламався алгоритм».
Найсильніше заперечення проти окремої ставки аналітика звучить так: продакт і розробники і так пишуть тікети, зайва ланка лише сповільнює поставку. У вузькому продукті з одним замовником і стабільним доменом це інколи справді так. Там, де схрещуються склад, фінанси, кабінет клієнта й зовнішня інтеграція, ціна пропущеного правила вища за зарплату аналітика: переробка вже написаного коду й повторне тестування з’їдають ті самі 3400 доларів сеньйора за кілька тижнів простою команди. BABOK прямо фіксує, що виявлення потреб часто означає перевірку озвученого бажання, а не його стенограму.
Контроль якості — це рев’ю вимог до взяття в спринт, спільний розбір критеріїв із тестувальником і коротка перевірка після релізу: чи закрито сформульовану потребу, чи лише намалювали екран. Якщо після запуску бізнес каже «ми мали на увазі інше», це дефект аналізу, навіть коли код бездоганний.
Які навички потрібні, щоб працювати в цій професії
Кар’єра тримається на двох шарах. Перший — мислення: розкласти суперечливі пояснення на факти, правила й припущення; помітити, де стейкхолдер пропонує рішення замість потреби. Другий — мова спільної роботи: фасилітація зустрічі, письмова точність, англійська для більшості українських IT-контрактів.
З технічного мінімуму на 2026 рік роботодавці в вакансіях очікують не «знання всіх фреймворків», а здатність читати дані й інтерфейси. Практичний набір: SQL на рівні вибірки й перевірки гіпотези; розуміння, що таке API й статус об’єкта; BPMN або UML на рівні читабельної схеми; Figma як місце узгодження екрана, а не як професія дизайнера; Jira як облік історій. Математика потрібна в обсязі логіки й базових метрик — відсоток, когорта, поріг — а не в обсязі академічного аналізу.
Сертифікати IIBA — ECBA (з 2016 року, вхідний рівень), CCBA (з 2011-го) і CBAP (програма з 2006-го, для досвідчених) — не є допуском до роботи в Україні. Вони корисні, коли треба довести спільну мову з міжнародним замовником. Кар’єра частіше залежить від домену: логістика, банки, медичні реєстри, білінг. Фахівець, який уже розуміє, як у цій галузі виникає проводка або накладна, закриває проєкт швидше за універсала з ідеальним шаблоном історії.
Часті запитання
Нижче — питання, які ставлять до вакансії й до першого місяця на посаді, а не переказ розділів вище.
Чи пише бізнес-аналітик код
Ні, це не обов’язок ролі. Окремі аналітики вміють зробити SQL-запит, зібрати макет або налаштувати простий звіт — це інструмент перевірки, не поставка програмного продукту. Якщо основний результат людини — pull request, це вже інша спеціальність, навіть якщо в штатному розписі стоїть «BA».
Чим бізнес-аналітик відрізняється від системного аналітика
У вакансіях межі розмиті. На практиці бізнес-аналітик сильніше тримає процес, правила й потребу підрозділу; системний — інтерфейси між системами, формати повідомлень, обмеження платформи. В одній команді це буває одна людина. Різницю видно по артефакту: «коли можна скасувати замовлення» проти «яке поле в якому повідомленні піде в SAP».
Чи можна зайти в професію без технічної освіти
Так, якщо є досвід предметної галузі й готовність освоїти документацію та дані. Типовий вхід — фахівець підтримки, операційного відділу або тестування, який уже розбирає чужі формулювання. Без навички фіксувати правило так, щоб його можна було перевірити, галузевий досвід сам по собі не робить аналітика.
Скільки зараз платять і від чого це залежить
Орієнтир українського IT на літо 2026 року: сеньйор бізнес-аналітики — медіана 3400 доларів США на місяць. На Work.ua в вересні 2026-го середня пропозиція в гривневих вакансіях (ширший ринок, не лише IT) — 65 000 гривень за вибіркою з 79 оголошень. Розрив пояснюється типом роботодавця: продуктові й сервісні IT-контракти платять у валютному еквіваленті, локальний бізнес поза IT — у гривні й ближче до загальноринкової медіани.
Джерела: DOU, зарплатне опитування аналітиків, літо 2026; Work.ua, статистика вакансій «Business analyst», вересень 2026.
Невирішеним лишається межі ролі в конкретній компанії. Десь аналітик лише уточнює історії продакта. Десь він веде процес від проблеми до приймання релізу й відповідає за словник даних. Перед тим як брати вакансію або заводити ставку, варто прочитати, які артефакти людина має віддавати щотижня і хто підписує пріоритет. Якщо в описі змішані «власник беклогу», «архітектор» і «той, хто малює макети», роль ще не визначена — і тоді метрики якості з розділу вище не спрацюють.
Критерій розвилки простий: вам потрібен перекладач між потребою й реалізацією, чи людина, яка сама вирішує, що ввійде в реліз. Перше — робота бізнес-аналітика. Друге — продакт. Поки це не розведено в обов’язках, команда платить двічі: спочатку за розмиту ставку, потім за переробки.