Про що говорять БА у світі: огляд конференції European BA day 2026

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Привіт, спільното!

Останнім часом спостерігаю таку тенденцію, що в ІТ індустрії (зокрема в сфері бізнес-аналізу) почало багато чого змінюватись, трансформуватись. І звісно не без участі ШІ. Водночас є багато спеціалістів, котрі ще не до кінця розібрались, як з тим ШІ навчитись взаємовигідно співіснувати і продовжують все ще бути цінними «канонічними» спеціалістами. Хтось панікує, що нас всіх (БА) скоро замінить ШІ, а хтось впевнений, що це неможливо.

Я — Катерина Ліман, senior business analyst в Uklon, авторка благодійного блогу «БА — це безалкогольне?». Минулого року я здала 5 ІІВА сертифікацій, а цього року вирішила відвідати 5 конференцій.

Наразі хочу поділитися з вами суб’єктивним оглядом і ключовими трендами з однієї з найбільших подій — 7th European Business Analysis Day, яка відбулася 28 травня 2026 року в онлайн-форматі.

European Business Analysis Day - EU BA Day

European BA Day

Перше, що хочеться відзначити — це участь українських БА не тільки в якості спікерів, а й в якості організаторів та волонтерів конференції. Юрій Гомон та Олександр Москалюк — виходимо на потужний рівень! (а, може, й навпаки — підтягуємо Європу до нашого рівня 😉).

Друге, це те — що конференція об’єднала спеціалістів з усього світу, далеко за межами Європи. Було цілих 39 сесій з 10 країн! Тим і заманливо було доєднатися: виміряти середню температуру по палаті. Бо, як ви знаєте, бізнес аналіз дуууууже відрізняється від регіону до регіону: БА в Україні — це зовсім не те саме, що БА у західній Європі, на Близькому Сході чи у Америці.

Отож, для тих, хто пропустив таку подію — переходимо ближче до суті справи.

Overview & Trends: Про що говорять БА у світі

Хоча тематика і була доволі різноманітною, головний лейтмотив проступав чітко: штучний інтелект. Удівітєльно? Ніт 🙃. Але також прослідковувались ще два тренди у доповідях: стратегічний аналіз та розвиток кар’єри БА (те, що залишається у незмінному фокусі вже протягом багатьох років).

Давайте про кожний з них детальніше.

1. AI <> BA

Якщо рік тому на подібних конференціях ще ділились прогнозами і візіями про те, як АІ змінить професію БА, то тепер вже спікери ділились досвідом і настановами.

Щонайменше 8 доповідей були присвячені саме ШІ, і це не рахуючи тих, де він фігурував між рядків. Загальний настрій був доволі обнадійливим: ШІ не загрожує існуванню бізнес-аналітиків 🥳. Можна спати спокійно.

Саме BA мають унікальну позицію, щоб стати тими людьми, які змусять ШІ реально працювати в організаціях. Бо зрозуміти потребу стейкхолдерів «поміж рядків», закриваючи очі на те, що клієнт «знає чого хоче» (насправді, він хоче зовсім не те), ШІ поки (?) не здатен.

На конференції коротко розібрали анатомію ШІ-агентів від базових термінів до побудови АІ-based проєктів — щоб аналітики розуміли, з чим мають справу, коли потрапляють на такі проєкти.

Окремий фокус був на практичному застосуванні ШІ-інструментів у щоденній роботі: як за лічені години створювати change management plan, як генерувати вимоги і специфікації, діаграми і все те, за що зазвичай платять гроші бізнес-аналітикам.

Водночас доволі різко прозвучала тема якості ШІ-генерованих вимог. Індустрія кинулася генерувати вимоги за допомогою ШІ, але забула побудувати автоматичний контроль їхньої якості. Тому справжній профіт від адопшину мав би бути не в генерації, а у верифікації та валідації вимог через LLM: виявлення двозначностей, залежностей, прогалин і неточних формулювань до початку розробки.

Згадували також тему сторітелінгу для БА — old but true 🤌 Думаю, зараз у цієї навички має відкритись друге дихання, як раз щоб доволі швидко та ефективно залучити потрібних стейкхолдерів або, можливо, пояснити контекст ШІ (хто, що і для чого). Бо нам (БА) необхідно все-таки пришвидшуватись у прийнятті рішень, щоб встигати за темпами розробки та делівері.

Пролунали і провокаційні та протилежні тези щодо документування вимог:

  • Навчіть АІ писати хороші BRD/Specs, щоб інший АІ їх легко розумів і швидко кодив;
  • класичні PRD мертві, їм на зміну приходять легші формати product brief, що дозволяють рухатися швидко без втрати контролю.

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

АЛЕ

Я особисто очікувала вже якісь приклади АІ-first BA team чи якісь процеси повністю інтегровані з ШІ, так щоб з метриками успішності чи підвищення ефективності (бо про це є зараз доволі багато прикладів і інформації на просторах української БА спільноти). Проте, здається, закордоном ШІ використовується здебільшого в індивідуальному порядку для окремих задач, і ще поки не є системним підходом (або про це не розказали 🥲).

2. Стратегічна роль BA

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

Спікери озвучили концепт «архітектора цінності», який бере участь у формуванні стратегії організації. Як раз core skill зрілих БА — виявляти справжню бізнес потребу, враховуючи контекст і всі ті концепти з BACCM.

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

В цілому, доволі логічний тренд переходу від requirements engineers до БІЗНЕС аналізу.

АЛЕ

Тут теж варто зазначити, що всі ці заклики про стратегічний аналіз базуються на відповідних галузях знань з всіма нами улюбленого BABOK (Strategy analysis, Solution Evaluation), а також на вище згаданій BACCM. Тобто, як на мене, це базові теоретичні речі, які не є новаторськими. Тут шифту чи трансформацій ніяких помічено не було 🤷‍♀️. Корисно, здебільшого, було БА-початківцям.

3. Кар’єра та розвиток

Always on time, як то кажуть. Обговорювали, як ефективно проходити інтерв’ю на BA-позиції, за якими критеріями оцінювати аналітиків при промоушені (якщо коротко — показуйте метрики успіху), як знаходити «своїх людей» у команду.

Ми всі бачимо, як зараз ринок просідає і як челенджово може бути отримати офер. І тут мене зацікавив спільний погляд спікерів: під час процесу хайрінгу варто більше звертати увагу на софт-скіли (комунікаційні навички, лідерство, аналітичне мислення — все по списку Underlying Competencies у BABOK), метч особистостей кандидата та команди, щоб створити атмосферу, в якій буде комфортно і драйвово працювати. Буде більше толкового спілкування, поки «штучка інтєлєкт» буде записувати вимоги та писати код.

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

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

Ключові інсайти

Тут виділю основні ідеї, які мені особисто відгукнулись і запам’ятались:

  • ШІ не замінить БА. ШІ замінить requirements engineers.
  • ШІ для рутинних задач вже став звичкою, проте ШІ-first процеси та ШІ-first команди ще знаходяться в діскавері фазі.
  • Не піддаватись на ШІ-провокації: деякі рутинні і повторювані процеси можна просто автоматизувати (і не витрачати зайві токени). Не обов’язково всюди тулити ШІ і намагатись делегувати йому все. AI adoption is not the same as AI value ©
  • Just a friendly reminder: основна задача БА (була і завжди буде) — це вияв бізнес потреби та формування цінності, а не документування вимог.
  • БА мають виходити на стратегічний рівень і демонструвати свій вплив і значимість через вимірювані метрики (процесні або продуктові).
  • В гонитві за трендами, щоб виявляти справжні потреби і можливості для розвитку бізнесу варто звертати увагу не тільки на те, що роблять всі «і нам треба», а радше на слабкості (складнощі у користуванні продуктом чи у процесі; коли юзери використовують систему чи додаток не так, як ми дизайнили; коли падає конверсія у якомусь процесі тощо).
  • Soft skills актуальні як ніколи. В поєднанні з ШІ-грамотністю можна стати супер-затребуваним спеціалістом. Головне — викликати довіру і знайти метч з командою.

Висновки

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

BA-спільнота вже не питає «чи замінить нас AI?» — вона обговорює, як саме використовувати ШІ як інструмент, зберігаючи критичне мислення, етику та фокус на цінності (business value). Конференція показала: найбільш затребувані BA 2026 року це ті, хто поєднує аналітичний склад розуму із ШІ-грамотністю, стратегічне мислення зі здатністю працювати hands-on, і технічне розуміння з soft skills.

Тож читайте ВАВОК, практикуйте ШІ, та не забувайте донатити за військо, бо наша країна має бути сильною не тільки розумом, а й на полі бою.
👍ПодобаєтьсяСподобалось12
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Водночас доволі різко прозвучала тема якості ШІ-генерованих вимог. Індустрія кинулася генерувати вимоги за допомогою ШІ, але забула побудувати автоматичний контроль їхньої якості. Тому справжній профіт від адопшину мав би бути не в генерації, а у верифікації та валідації вимог через LLM: виявлення двозначностей, залежностей, прогалин і неточних формулювань до початку розробки.

То, з точки зору BA, цього зараз не вистачає в контексті впровадження методик Spec-Driven Development?
В існуючих тулкітах/фреймворках типу GitHub Spec Kit чи OpenSpec є кроки валідації специфікації. Основне питання — відносно чого валідувати — ми можемо провалідувати що існуюча специфікація ок, або що нові зміни відповідають чи коректно доповнюють специфікацію. Щодо прогалин — тут складніше, але в принципі ллмка може задати додаткові запитання/уточнення, якщо її це попросити і у нас домен, про який вона знає.

p.s.
Ну і в контексті девелопменту специфікації як такі можуть грати різну роль.
Скажімо, Фаулер описує три різні підходи:

Spec-first: A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand.
Spec-anchored: The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature.
Spec-as-source: The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.

martinfowler.com/...​g-gen-ai/sdd-3-tools.html

Катерино, дякую за статтю. Дуже актуальна тема і підсумки дуже корисні для розуміння куди рухається світ бізнес аналізу в еру AI. Keep going!

Дуже класна стаття, прям на одному диханні зайшла)
Дякую!

Дякую, дуже цікаво!

Оптимізм — це гарно. Реальність може бути іншою, але will see

Підписатись на коментарі