Eugene K - the BA🇺🇦

І ще одна думка — не забувайте про сам бізнес-аналіз. 🙂 AI стає все більш серйозною частиною нашої роботи.AI-навички зараз дуже швидко стають масовими. Всі щось промптять, вайбкодять, запускають агентів, пробують нові інструменти — і з часом базове вміння працювати з AI буде у більшості людей у професійному середовищі. Десь він залишається інструментом. Десь стає майже співгравцем. Десь забирає на себе окремі задачі або навіть цілі шматки роботи. І, думаю, одне з головних питань для нас зараз — як ми, як професіонали, будемо з ним взаємодіяти (про саму цю взаємодію я ще окремо якось скоро напишу). Але щоб нормально взаємодіяти з AI як бізнес-аналітик, треба в першу чергу бути хорошим бізнес-аналітиком. 😄 Розуміти, як працювати з зацікавленими сторонами. Як витягувати потребу з того, що говорить клієнт. Що і навіщо уточнювати. Як працювати з невизначеністю. Як перетворювати все це на вимоги і специфікації, з якими можна рухатися далі. Тобто мати нормальний професійний фундамент. Бо у світі, де AI сам стає повноцінним гравцем, важливо залишатися повноцінним гравцем у своїй професії.⭐️ Тоді вже можна шукати ті точки взаємодії з AI, де разом ви працюватимете ефективніше, швидше і з більшим результатом. Тому, вивчаючи весь цей новий AI-світ, не забувайте паралельно ставати кращими бізнес-аналітиками. Бо ця частина професії нікуди не поділася. 👀 #AIforBA #growth #career

#ПʼятничнийЧекін 👇 Як ви? Як пройшов тиждень? Що з нього залишилося з вами?

Ну і що з усім цим робити бізнес-аналітику? 🙂 1) Перебудуйте свій інформаційний раціон. Дивіться, що випускають Anthropic, OpenAI та інші AI-лабораторії. Дивіться, що відбувається в Claude Code, Codex та інших developer tools. Читайте engineering-блоги, дивіться GitHub, слідкуйте за новими підходами до agentic development. 🦄А якщо цей пост набере 50 єдинорогів, то я підготую предметний список джерел, які читаю сам. Це все — не тому, що бізнес-аналітик завтра має стати розробником. А тому, що значна частина того, що потім приходить до нашій роботі, особливо у сфері ІТ, зараз спочатку з’являється і обкатується саме там. 2) Практикуйте. Поставте собі Claude Code і спробуйте щось зробити руками. Візьміть якусь невелику ідею і спробуйте пройти шлях від задуму до working software. Спробуйте повайбкодити, якщо ви ще цього не робили. Спробуйте BMAD Method, Spec Kit або просто нативний flow Claude Code. Подивіться, як агент досліджує проєкт, як планує, який контекст йому потрібен, де він починає ставити питання, а де — навпаки — мовчки приймає рішення за вас. 😄 Особливо цікаво пройти цей процес саме бізнес-аналітику. Бо тоді всі ці розмови про спеки, інжиніринг контесту, харнесс, agentic workflows перестають бути абстрактними словами. Ви буквально бачите, що відбувається з вашою вимогою після того, як вона пішла в реалізацію. І починаєте значно краще розуміти, чому розробникам потрібен певний контекст, де специфікації не вистачає, які рішення агент уже може приймати самостійно і де все ще потрібна людина. 3) Дивіться вперед. Gartner ще у своїх прогнозах по agentic AI говорив про те, що агенти будуть забирати на себе дедалі більшу частину робочих рішень і задач. Тому я б точно не чекав моменту, коли все це остаточно оформиться в окремий «AI for Business Analysts» курс із сертифікатом.😄 Технологія вже тут. Можна просто піти і подивитися руками, як вона змінює розробку — і що з цього означає для нас. 🤖 #AIforBA #growth #career

І ще коротка думка вдогонку. Мені здається, що нинішнє розділення на Claude Chat/Claude Code/Claude Cowork, ChatGPT/ChatGPT Work/Codex і т.д. — це взагалі проміжний стан. Зараз воно виглядає трохи фрагментовано: тут ти просто говориш з AI, тут працюєш з файлами, тут агент виконує довгу задачу, тут працює з кодом і репозиторієм. Але я думаю, що поступово це все зведеться до одного інтерфейсу. Вже для більшості користувачів, можливо, взагалі не буде важливо, що там під капотом — чат, агент, coding agent чи ще щось. Більше того, саме програмування може стати настільки ж тривіальною задачею для AI (та й нас), як зараз зробити презентацію чи написати текст. Просто результатом буде не .pptx чи документ, а software. Тобто сьогодні ми ще вибираємо інтерфейс під задачу. А через якийсь час, думаю, просто будемо ставити задачу — а система сама вирішуватиме, який режим, агент, модель та інструменти для неї потрібні. А ви як думаєте? 🤔 #AI

І ще одна штука про Claude Code, яка, як на мене, важлива для бізнес-аналітиків. Code у "Claude Code" у назві трохи збиває з пантелику 😄 Бо якщо прибрати саме coding use case, залишається доволі цікава модель роботи з AI — агент працює не просто всередині чату, а у вашому робочому середовищі. І це вже суттєва різниця. У звичайному чаті ми переважно працюємо сесіями: дали контекст → щось обговорили → отримали результат → пішли далі. З agentic workspace контекстом стає сам проєкт. Файли, папки, документація, Git history, правила проєкту, підключені через MCP системи — все це може бути робочим середовищем агента. Тобто замість того, щоб кожного разу пояснювати: «Ось мій PRD, ось ще три документи, ось структура проєкту, а ось що ми вирішили минулого разу», ми можемо поступово будувати середовище, в якому цей контекст уже живе. І для BA тут особливо цікава робота з артефактами. Вимоги перестають бути просто текстом, який ми один раз згенерували в ChatGPT і перенесли в Confluence. Вони можуть лежати у файлах, змінюватися разом із продуктом, мати version history, diff, бути пов’язаними з іншими артефактами проєкту — і агент може працювати з усім цим як з єдиним контекстом. Плюс через MCP до цього середовища можна підключати Jira, Confluence та інші системи, з якими ми і так працюємо. Тому для мене Claude Code та подібні інструменти цікаві не через можливість бізнес-аналітику раптом почати писати код. Цікава сама зміна моделі роботи з AI: від окремого чату — до агента всередині робочого середовища. І от це вже, як на мене, значно ближче до того, як AI реально може вбудовуватися в щоденну роботу BA. 🤖 #AIforBA

Ще одна цікава зміна, яка відбувається разом з agentic development — це роль специфікації. Ми звикли, що вимоги та специфікація — це передусім спосіб передати домовленості між людьми. BA описав вимоги → команда їх прочитала → розробник інтерпретував → реалізував. З агентами цей ланцюжок починає змінюватися. У spec-driven development специфікація стає вже не просто документацією для людини. Вона стає input для агента, який безпосередньо виконує роботу. І тут з’являється цілий клас артефактів, які раніше в типовому BA-процесі могли взагалі не існувати: CLAUDE.md, AGENTS.md, constitution-файли, story files, ADR, різні project instructions. Вони описують не тільки те, що треба побудувати, але й правила, обмеження, архітектурні рішення, conventions, контекст проєкту — тобто те, в яких межах агент взагалі має працювати. І це трохи змінює ціну хорошої специфікації. Якщо раніше неоднозначність у вимозі міг побачити розробник, прийти до BA і сказати: «А що тут мається на увазі?» — то агент за замовчуванням просто візьме одну з інтерпретацій і піде її палити токени реалізовувати.😄 А швидкість тут тільки підсилює проблему. Чим швидше ми можемо перейти від ідеї чи наміру (зараз модно говорити "intent") до working software, тим дорожчою стає помилка в самому intent, контексті або обмеженнях. Тому специфікація поступово стає не просто артефактом комунікації між BA та командою. Вона стає частиною виконання: уявіть, що ви пишете ноти🎶, а агент як досвідчений піаніст їх відіграє, але від саме записаних нот музика залежить більше, ніж від того, хто за фортепіано.🎹 Тут, як на мене, для бізнес-аналітиків відкривається дуже цікава територія. Бо якщо агент безпосередньо працює з вимогами, правилами та контекстом, то якість нашої роботи може впливати на реалізацію значно пряміше, ніж раніше. #AIforBA

І далі по темі, розглянемо тренд agentic development — самий сильний зараз.🤖 Загалом, про момент, який мені як бізнес-аналітику особливо подобається. Коли розробники почали активно використовувати coding agents, достатньо швидко стало зрозуміло: просто дати агенту задачу і сказати «реалізуй» — не найкраща стратегія (і я як Chief AI Slop Engineer підтверджую це😅). Агенту треба пояснити, що саме ми будуємо, навіщо, які є вимоги, обмеження, правила, контекст і як взагалі зрозуміти, що результат правильний. І в результаті навколо agentic development почали з’являтися фреймворки та підходи, які виглядають для бізнес-аналітика підозріло знайомо.😄 Наприклад: 1) BMAD Method взагалі будує workflow з окремими ролями Analyst, PM, Architect, Developer, QA. 2) Spec Kit пропонує flow: Specify → Clarify → Plan → Tasks → Implement. Тобто по 1 і 2 спочатку ми описуємо, що і навіщо будуємо, уточнюємо неоднозначності, формуємо технічний план, декомпозуємо його — і лише після цього йдемо в реалізацію. Насправді Claude Code з коробки є Plan Mode: спочатку агент досліджує кодову базу, контекст і задачу, формує план реалізації — і лише після цього переходить до змін. Але згадаємо ще парочку прикладів. 3) Kiro використовує EARS для структурованого опису вимог. 4) OpenSpec — сценарії у форматі GIVEN / WHEN / THEN. 5) PRP (Product Requirement Prompt) поєднує вимоги, контекст, документацію, приклади та інструкції для реалізації в одному артефакті. І все це виникає з достатньо практичної проблеми: AI-агент може дуже швидко щось реалізувати, але спочатку треба достатньо добре визначити, що саме він має реалізувати. Тобто ми автоматизуємо implementation — і раптом ще сильніше впираємося у якість того, що стоїть перед implementation. Тобто, розробники будують нові AI-native процеси розробки — і поступово перевинаходять частину того, чим бізнес-аналіз займається вже багато років. Тільки тепер якісні вимоги, специфікації, контекст і acceptance criteria потрібні не лише для того, щоб люди однаково зрозуміли задачу. Їх безпосередньо споживає агент, який після цього може піти і щось реалізувати. І от тут, як на мене, починається значно цікавіша розмова про майбутню роль бізнес-аналітика. Бо потреба в аналізі нікуди не зникає. Питання лише в тому, хто буде цей аналіз робити — бізнес-аналітик чи агент, якого для цього налаштував розробник і наскільки і коли друге буде достатньо якісним. 👀 #AIforBA

Продовжуючи тему фокусу БА на те, що відбувається у світі розробки 👀 І один із найяскравіших прикладів тут — Claude Code. Якщо подивитися на те, як він розвивався протягом 2025–2026 років, можна побачити доволі цікавий напрямок. Спочатку Claude Code був саме інструментом для розробників. Але поступово навколо нього почала будуватися ціла модель роботи з AI-агентами. З’являється Plan Mode — агент може спочатку дослідити задачу і скласти план, не змінюючи код. Потім Hooks — можливість задавати автоматичні дії на певні події. Далі Subagents — окремі спеціалізовані агенти зі своїм контекстом і задачами. Потім Claude Agent SDK, Plugins, Skills — тобто вже інструменти для того, щоб не просто поговорити з AI в чаті, а будувати навколо нього повторювані процеси, давати агентам спеціалізацію, інструкції, доступ до інструментів і контексту. У січні 2026 Anthropic випускає Cowork — фактично той самий агентний підхід, але вже не для роботи з кодом, а для knowledge work. Тобто агент отримує доступ до ваших файлів, може самостійно планувати роботу, виконувати послідовність дій, створювати та редагувати документи. А побудований Cowork на тому самому Claude Agent SDK, який виріс із Claude Code. І скажу на своєму досвіді, Cowork є навіть дещо урізаною версією Claude Code з точки зору потенціалу тулів. Цікава сама траєкторія: спочатку нову модель роботи з AI активно обкатують на software development, де є код, Git, тести, чіткі артефакти і можливість перевірити результат. А потім ті самі принципи починають переносити на іншу інтелектуальну роботу. Тому те, що сьогодні виглядає як developer tooling, завтра цілком може стати звичайним tooling для knowledge workers. І, схоже, частина цього «завтра» вже настала 🤖 #AIforBA

Привіт колеги, безпеки і гарного тижня!✌️ Останнім часом я доволі багато копаюся у тому, що зараз відбувається з AI-технологіями у розробці: агентами, новими підходами, інструментами, фреймворками, context engineering і оце все. 🤖 І ловлю себе на думці, якою і буду ділитися цього тижня у постах: щоб бути на хвилі 🏄‍♂️ (а не під нею😅) бізнес-аналітикам варто дуже уважно слідкувати за розробниками. І у 2026 це стало значно помітніше. Люди вже використовують агентів для роботи з вимогами, PRD, Jira, дослідження систем, роботи з репозиторіями, побудови прототипів і автоматизації цілих шматків knowledge work. І багато практик, які через якийсь час стають актуальними для BA, PM та інших скажімо, knowledge workers, спочатку народжуються і обкатуються в engineering-середовищі. Інжиніринг контексту, MCP, агентні патерни, Skills, AGENTS.md, agentic loops — ці підходи зараз народжуються і розвиваються навколо software engineering у ШІ-лабах (OpenAI, Anthropic...) та командах, які будують AI-агентів. Спочатку цими проблемами займались розробники, команди, які будували агентів, та компанії, що створювали developer tooling. І частина очікуваних проблем, які вони намагаються вирішити, нам, бізнес-аналітикам, дуже знайома — як передати контекст, як чітко описати очікувану поведінку, як зафіксувати правила та обмеження, як не втратити intent між постановкою задачі та реалізацією. А вже потім ці підходи починають поступово їхати в сторону бізнес-користувачів. Тому я трохи змінив для себе інформаційний раціон. Тому, думаю, зараз варто слідкувати не тільки за BA-контентом, але й за, так би мовити, першоджерелами цих змін — блоги інженерів, GitHub, новими інструментами розробки і тим, як із AI працюють самі розробники. Особливо якщо хочеться зрозуміти не тільки те, що вже прийшло в нашу професію, а й що може змінити нашу роботу через пів року-рік. 👀 #AIforBA

#ПʼятничнийЧекін 👇 Як справи? Як тиждень? Що нового, цікавого або несподіваного для себе відкрили?

Насичений був попередній тиждень - цей буде не менш насиченим... #mood

#ПʼятничнийЧекін 👇 Як пройшов ваш тиждень? Що найбільше запам’яталося? І чи було щось нове в бізнес-аналізі або ШІ для вас?

І нагадую не проходити повз і задонатити на мою банку для подвійного «Секретного Русорізу 3.0» разом із Geniusee 🫙🇺🇦 Ви донатите на банку, ціль — жалюгідні 2,5 пачки грошей. Geniusee подвоює цю суму до 50 тисяч, і ці гроші потім ідуть на «Русоріз». Дуже ціную і поважаю нашу компанію за те, що вона таким займається.💜 У нас це вже багаторічна історія: багато різних внутрішніх ініціатив і постійна підтримка зборів 🤝 Тож, знову ж таки, запрошую задонатити. Посилання на банку: https://send.monobank.ua/jar/5w6DtM5WCC Зробіть подвійну приємність ЗСУ і подвійну неприємність росіянам 🫶🔥 #charity

А поки чекаю вас у коментарях до попереднього поста — цікаво почитати ваші враження за цей тиждень 👇 Паралельно ще трошки нагадаю про УБАК і благодійність 💙💛 Як бачите, найбільша українська онлайн-конференція для бізнес-аналітиків передає 1 000 гривень з кожного квитка фонду «Повернись живим». І це достатньо правильна й крута позиція для будь-якого зрілого бізнесу, який зараз насправді переживає непрості часи, але продовжує наближати нашу перемогу 🇺🇦 Реєструйтеся за посиланням: https://uabaconf.info/ А промокод eugenektheba дає знижку 15% від поточної ціни квитка 🎟 #events

#ПʼятничнийЧекін 👇 Як ви після цього тижня? Яким він був для вас? І що нового або цікавого з’явилося у вашому досвіді?

Як проводиться така сесія? 🤔 В цілому це — звичайний брейнсторм. Активності відбуваються на час, у нас йдуть стікери — віртуальні або реальні. І ми йдемо по кожній таблиці. В SWOT-аналізі в цілому рекомендований порядок — це сили, слабкості, можливості, загрози. Хоча насправді він не критичний. Можна з будь-чого починати. В SOAR-аналізі є чітка послідовність: сили (Strengths, S), можливості (Opportunities, O), прагнення (Aspirations, A), результати (Results, R). Тому що результати мають бути зав’язані на прагненнях, а прагнення — на можливостях і силах. По часу — дивлячись, що вам комфортніше. Ну, я думаю, це від 5 хвилин до 10–15 хвилин на блок ⏱️ Тут залежить від готовності ваших стейкхолдерів. Бо якщо ви попередньо готували стейкхолдерів, просили їх зробити якийсь самоаналіз, то вони достатньо швидко заповнять стікери. Ну, принаймні якась частина з них точно. Інші вже будуть наздоганяти. Але якщо люди не дуже готові, то, напевно, краще виділити більше часу і дати подумати. Якщо ми говоримо про аналіз компанії, то для співробітників або менеджменту це може бути певний челендж. Тому що, як і будь-яке стратегічне планування, це певна зупинка. Крок назад. І аналіз того, що реально відбувається — у відриві від поточних задач, цілей, проблем тощо 🧭 Іноді ті проблеми, які є, не завжди є проблемами саме на рівні компанії. Вони можуть бути на рівні стейкхолдерів чи департаментів, але не на рівні компанії. І на це треба фокусуватись. І так само по інших пунктах цього аналізу. Тому успіхів тим, хто в цьому приймає участь, і можливості сконцентруватися 🙌 Я думаю, перші етапи таких сесій варто проробляти в тиші. Тобто без особливих обговорень. Адже це брейнсторм, по-перше. Чим більше ідей, тим краще. А по-друге, це, власне, необхідність подумати, щось для себе проаналізувати. І зробити оцей крок назад. #techniques #strategy

Поговоримо по визначенню кожної букви трохи детальніше 🧩 SOAR зазвичай структурують у вигляді матриці 2х2. Прикольно, що SOAR як слово означає “злітати” або “підніматися вгору” — і це дуже добре лягає на саму ідею аналізу: не застрягати в проблемах, а дивитися, куди ми можемо вирости 🚀 З одного боку, ми дивимось на поточну ситуацію та майбутнє. З іншого — на внутрішні фактори та зовнішнє середовище. І виходить чотири квадранти: Strengths — сильні сторони 💪 Це про те, що в нас вже є. Унікальні ресурси, ключові компетенції, сильні сторони команди, найбільші досягнення. Тобто питання тут дуже просте: У чому ми реально сильні? Що є нашою унікальною перевагою? Наприклад, уявімо продуктову компанію Acme CRM, яка розробляє CRM-систему для enterprise-клієнтів. Їхньою сильною стороною може бути не просто “ми робимо CRM”, а глибока експертиза в конкретному домені — наприклад, у фармацевтичних продажах. Тобто команда добре розуміє, як працюють medical representatives, як будуються візити до лікарів, як виглядає робота з аптеками, дистриб’юторами, регуляторними обмеженнями, звітністю, compliance і так далі. І це вже стає реальною сильною стороною. Бо CRM сама по собі — це просто інструмент. А от CRM, яка добре розуміє конкретний enterprise-домен і його процеси, — це вже значно сильніша позиція. Opportunities — можливості 🚪 Це вже про зовнішній світ. Ринкові тренди, нові технології, незакриті ніші, партнерства, зміни в очікуваннях клієнтів. Особливість SOAR у тому, що ми не ігноруємо проблеми чи загрози, але намагаємось переосмислити їх як можливості. Наприклад, для Acme CRM можливістю може бути зростання попиту на AI-функціональність саме у pharma sales. Enterprise-клієнти хочуть не просто вести клієнтів і візити, а отримувати AI-підказки: до кого варто запланувати наступний візит, які лікарі чи аптеки потребують більше уваги, де падає активність, які next steps запропонувати medical representative, як краще прогнозувати результати по територіях. Тобто можливість тут не просто “додати AI”. А використати свою доменну експертизу і зробити AI-функціональність не загальною, а реально корисною для конкретного процесу. Aspirations — прагнення 🚀 Це те, ким ми хочемо стати. Яке в нас бачення майбутнього? Які масштабні цілі нас драйвлять? Яку корисну зміну ми хочемо принести клієнтам, компанії, команді? Тобто це вже не просто “що є”, а “куди ми хочемо рухатись”. Наприклад, для Acme CRM це могло б звучати як прагнення стати не просто CRM-системою для pharma sales, а інтелектуальною платформою для фармацевтичних sales-команд. Платформою, яка допомагає не тільки фіксувати активності, а реально підвищувати якість планування, комунікації з клієнтами, роботи medical representatives і прийняття рішень менеджментом. Results — результати 📊 А ось тут ми заземлюємо наші прагнення. Бо прагнення — це красиво, але важливо зрозуміти: а як ми побачимо, що це спрацювало? Які будуть метрики? OKRs, KPIs, конкретні показники, терміни, відповідальні. Наприклад, якщо прагнення Acme CRM — стати інтелектуальною платформою для pharma sales-команд, то результатами можуть бути: збільшення adoption AI-функцій серед medical representatives, скорочення часу на підготовку звітів, краща якість планування візитів, підвищення точності forecast по територіях, зменшення ручної роботи, краща видимість для менеджменту, зростання customer retention. Результати можуть бути (і в результаті мають стати) цілями і виставлятися по SMART. Отже SOAR — це наступна логіка: що в нас вже є сильного → які можливості ми бачимо → ким ми хочемо стати → як ми зрозуміємо, що ми туди реально прийшли. #techniques #strategy

Ну, по-перше, яка задача цих аналізів (SOAR/SWOT - схоже)? 🤔 Це проаналізувати якийсь поточний стан, побрейнстормити в групі людей, які можуть впливати на компанію. В цілому, от в Geniusee ми вважаємо, що всі можуть впливати на компанію. І в нас в усіх офісах проводиться навіть SWOT-аналіз, тому по стейкхолдерах тут, я вважаю, нема обмежень. І це правильно. Якщо ви знаєте SWOT-аналіз, він використовується, щоб спочатку подумати, побрейнстормити про сили, потім про слабкі сторони, про можливості і про загрози. В SOAR є трохи відмінності. В SOAR-аналізі ми не концентруємося на негативних речах, а концентруємося більше на позитивних ✨ Тобто сили тут у нас залишаються — strengths. Opportunities теж залишаються. І у нас є ще aspirations — прагнення. Тобто це те, до чого ми прагнемо. По суті, це вже таке пропонування ідей: що ми пропонуємо в цілому, що б ми хотіли 🚀 І results, остання літера, — це про наші результати. Тобто наше прагнення — це круто, але в чому результативність того, до чого ми прагнемо? Що може бути об’єктом аналізу — що одного, що іншого? Це може бути як організація в цілому, компанія, так і, наприклад, ми проводимо SWOT-аналіз для BAO. І в цілому BAO може бути організацією, яка має певні функції, людей, результати, KPI, ресурси і так далі. І так само вона може мати якісь з вищеназваних аспектів для аналізу. Тобто департамент теж може під це підходити ✅ #techniques #strategy

Привіт, колеги 👋 Буремні дні, чесно кажучи. Мало часу на пости, дуже мало. Сьогодні взяв відпустку, але вона в мене в режимі “хата на тата” 🏠👶, тож часу теж малувато. Тим не менш, тим не менш, маючи трохи часу і гарну сигару😮‍💨, хотів вам розказати про таку штуку, як SOAR analysis. 🔍 Насправді, це варіант SWOT-аналізу, тому трошки розкажу вам про нього, а ви скажіть, чи проводили SWOT-аналіз, SOAR-аналіз чи якийсь інший схожий аналіз для стратегічного планування 🧭 І, можливо, поділіться своїми враженнями стосовно цього. А з мене — партія постів про SOAR-аналіз 🚀 #techniques #mood

#ПʼятничнийЧекін 👇 Як пройшов тиждень? Що по відчуттях? Чим зацікавите в коментах?)