Eugene K - the BA🇺🇦

Сорі, я тут писав о 16:00 - як виявилося о 17:00 https://www.linkedin.com/events/7469785720262656000/ То ж, хто ще не встиг - приходьте ;) #events

CBAP, пора! 🔥😎🦄 #certification #iibaexamprep

Вдалого всім понеділка!✌️ Буквально на цих вихідних малював борду в Miro для воркшопу (є там у нас регулярний воркшоп, але цього разу в трошки оновленому форматі). 🎨 Так от: можливо, звучить трохи дивно, але цікаве відчуття, коли ти робиш щось сам, а не просто постійно щось генеруєш у Claude чи ChatGPT. Тобто не пропускаєш усе через них. У випадку з бордою ти, звісно, можеш щось погуглити, можеш щось спитати в ШІ, але саму борду все одно робити тобі (Miro AI я, до речі, не використовую- мені якось легше все одно зробити руками). І цікаво, що це вже відчувається як щось нестандартне. 🤔 Хоча, чесно кажучи, це, напевно, одна з останніх речей, які я ще роблю майже повністю сам. У вас не було такого відчуття, що речі, які ви робите самі, потроху закінчуються? Що в цілому від ідеї і до якоїсь фінальної реалізації ви на всіх кроках працюєте з ШІ-сервісами? Що штучний інтелект стає вашим таким екзоскелетом "на кожен день", екзоскелетом вашої робочої діяльності, чи не так? #mood #AIforBA

AI, стратегічний аналіз чи кар'єра - що хвилює європейських бізнес-аналітиків у 2026 році? Про це розповідає у своєму огляді старша бізнес-аналітикиня Uklon Катерина Ліман. Авторка розбирає доповіді з однієї з найбільших міжнародних конференцій BA та наводить три ключові тренди. 📌 https://dou.ua/goto/hlbA

Цікавий огляд по БА з конференції в т.ч. по ШІ

Колеги! 👋 Зараз трошки в запарі ("знову?"😅), але маю для вас цікавий івент. Запрошую вас у вівторок о 16:00 (за Києвом) на англомовний🇬🇧 вебінар про AI-автоматизацію 🤖 — про те, чим я останнім часом у тому числі займаюся. Поговоримо про те, як взагалі підійти до AI-автоматизації так, щоб значно знизити шанси на фейл проєкту 🚀 і не перетворити вашу AI-стратегію на гори AI-slop’у, нескінченних рахунків 💸 та постійної підтримки робочих процесів. ➕ Цей фреймворк буде особливо корисним бізнес-аналітикам, адже, по суті, я розповім, які інструменти та підходи використовує бізнес-аналітик у проєктах цифрової трансформації. Презентація вже практично готова і вийшло, як на мене, достатньо просто, доступно та з прикладами. 🙂 🎟️ Посилання на івент: https://www.linkedin.com/events/7469785720262656000/ Тож приходьте! Буду дуже радий вашій компанії, лайкам 👍, питанням 💬 та просто підтримці. До зустрічі! 👋 #events

#ПʼятничнийЧекін 👇 Як ваш тиждень? З чим його завершуєте? Чи відкрили щось нове, що берете на своє озброєння?

Що точно є плюсом — це те, що все-таки цей фреймворк і workflows, які він застосовує, структуровані, але ти можеш відхилятися від основної ідеї. От, наприклад, в одному з проєктів ми пробували розробляти гру 🎮 Ну, якщо вийде, звісно, поділюся, але отаке. І ми дуже сильно відхилилися від вимог як системи. В цілому ми більше вдарились в розробку самої гри, і це була доволі глибока історія, яка, по суті, теж була вимогою. Чесно кажучи, я ніколи цим не займався. Можливо, так бізнес-аналіз в іграх і відбувається, але в цілому ми займалися геймдизайном. По суті, дуже багато ми проєктували саму гру. Тобто там був такий великий шматок, в якому я ще, по суті, знаходжуся. Правда, ми вже маємо якийсь POC, який можна потестувати і вже з ним говорити. До речі, ми тут теж в це відхилилися. І ми, по суті, пішли в геймдизайн. Але потім ти можеш завжди повернутися до основного flow: складання вимог, проєктування, архітектура і так далі. #AINativeBA #SDLC

Якщо агентний кодинг так прискорює розробку, то чому до сих пір немає темної теми в стоці у Google Slides? 🤔 #mood

Привіт, колеги та друзі 👋 Зробіть приємну для мене і корисну для України справу 🇺🇦 Задонатьте на мою банку для подвійного Секретного Русорізу 3.0 разом з Geniusee. ⚔️ Стерненко запустив збір на Секретний Русоріз 3.0 — нове покоління FPV-дронів для ураження логістики ворога на великій відстані. Саме такі технологічні рішення сьогодні допомагають нашим військовим отримувати перевагу на полі бою. 🔥 Плюс Geniusee подвоює всю зібрану суму. ✖2️⃣ Тому схема проста: ➡️ ви донатите ➡️ ми збираємо 25 000 грн ➡️ Geniusee подвоює цю суму ➡️ і всі 50 000 грн йдуть саме на русоріз 3.0 (загальна ціль 250 000 тис.) Тому закликаю вас не зволікати та скинути свої 300–3000 гривень 💪 Кожен донат має значення. Разом наближаємо нашу перемогу 🇺🇦 Посилання на банку: https://send.monobank.ua/jar/5w6DtM5WCC #charity

Отже, BMAD Method і робота БА — як це виглядає, на мою думку 🤔 У моїх тестах BMAD Method за своєю ідеєю заміняв аналітика.🔥 Бо там є окремий агент-аналітик, який безпосередньо виконує роль БА: ставить питання, збирає контекст, шукає логічні дірки, структурує вимоги і готує артефакти для подальшої роботи. Тим не менш, якщо посадити замовника самого один-на-один з Claude Code + BMAD, замовник втомиться спілкуватися з ШІ по цьому фреймворку (для розуміння, скільки навалює тексту ШІ - до завершення MVP тестового продукту ці всі агенти накидали мені, наспілкувалися на 50 тис. рядків тексту🤯). Якщо ж говорити про участь реального бізнес-аналітика, то я бачу тут кілька важливих ролей. Перша — це такий собі адепт пропонованих воркфлоу. Тобто людина, яка розуміє, як виглядає процес/фреймворк, які артефакти потрібні, в якій послідовності їх створювати, де треба зупинитися, що уточнити, а де можна рухатися далі. І БА буде вирішувати на які питання скласти відповідь самому, які спитати/погодити у замовника тощо. Також він може згодовувати контекст після зустрічей з командою, замовниками. Друга роль — це ревізор контенту. Бо агент може дуже добре структурувати інформацію, але це не означає, що все, що він написав є автоматично правильним. Хтось має перевірити логіку, вимоги, припущення, критерії прийняття, розбіжності і загалом те, чи не поїхала система не туди. В моїх випадках, якби я був аналітиком на такому проєкті, я б, напевно, працював саме як посередник між BMAD і замовником. Тобто я б спілкувався з BMAD, відповідав на ті питання, на які знаю відповідь сам, а з тими, на які не знаю, йшов би до клієнта. По суті, я був би мостом між агентом, який пише специфікацію у потрібному форматі для agentic development, і стороною замовника, яка має бізнес-контекст, обмеження і реальні очікування. Такий собі трохи поглиблений промпт/контекст інжиніринг, але в цілому такий самий БА. Питання до вас: чи у вас вже є практичні кейси з такими методами? І який ваш досвід? Бо коли хтось називає BMAD або схожі підходи чимось необхідним, то, напевно, за цим уже має стояти якась практика. Тому нумо обмінюватися досвідом.👇💬 #AINativeBA #SDLC

Що точно є плюсом — це те, що все-таки цей фреймворк і workflows, які він застосовує, структуровані, але ти можеш відхилятися від основної ідеї. От, наприклад, в одному з проєктів ми пробували розробляти гру 🎮 (ну, якщо вийде, звісно, поділюся з часом - у мене взагалі багато всякого слопу)) І ми дуже сильно відхилилися від вимог як системи. В цілому ми більше вдарились в розробку самої гри, і це була доволі глибока історія, яка, по суті, теж була вимогою. Чесно кажучи, я ніколи цим не займався. Можливо, так бізнес-аналіз в іграх і відбувається, але в цілому ми займалися геймдизайном. Дуже багато ми проєктували саму гру. Тобто там був такий великий шматок, в якому я ще, по суті, знаходжуся. Правда, ми вже маємо якийсь POC, який можна потестувати і вже про нього поговорити. До речі, ми теж в це відхилилися - у розробку PoC як ранню стадію до початку розробки по самому фреймворку. Але потім ти можеш завжди повернутися до основного flow: складання вимог, проєктування, архітектура і так далі. Гадаю, що БА, який би користувався таким фреймворком ця гнучкість дуже потрібна. #AINativeBA #SDLC

Отже стосовно практики використання "BMAD Method" 🤖 У мене було кілька прогонів (які ще тривають 🤷‍♂️), і їх можна умовно розділити на два сценарії. Перший сценарій — коли у вас вже є готовий документ вимог 📄 У такому випадку ви можете просто згодувати його Claude Code з встановленим BMAD Method. І тут буде обраний шлях не створення PRD з нуля, а скоріше рев’ю та реструктуризації вашого документа у форму, з якою BMAD зможе працювати далі. Тобто система бере ваш готовий PRD, дивиться, що там є, шукає логічні дірки, непослідовності, неясні місця — і намагається привести це все до більш структурованого формату 🧩 Тут вже запускається агент-аналітик 🕵️‍♂️ Він перевіряє документ, ставить уточнюючі питання, шукає проблемні місця, а далі вже на основі цього BMAD може рухатися до архітектури, планування і наступних етапів. Другий сценарій — коли у вас немає готового документа. Є просто ідея продукту одним рядком 😅 І от тут теж включається агент-аналітик, але робота вже виглядає інакше. Він починає проводити з вами так звані workshops - на практиці це більше схоже не на воркшоп, а на письмові інтерв’ю ✍️ Наприклад на старті він питає: * як вас звати і хто ви у цьому проєкті, ваше біо; * що ви хочете зробити з цим продуктом; * яка у вас візія; для кого цей продукт; які проблеми вирішуємо; * хто користувачі; які є обмеження; який очікуваний результат. і так далі. З плюсів — це реально прикольно 👍 Бо воно змушує більш вдумливо описати продукт. Типу не просто “хочу зробити застосунок”, а подумати: навіщо він, для кого, яку проблему вирішує, що має бути в першій версії, а що можна відкласти. Тобто як інструмент для структурування думок — це працює 🧠 Але є і мінус. Питань багато. Дуже багато. 🤪 І частина з них, чесно кажучи, здається зайвою або надто детальною для старту. Тобто якби такий discovery проводив аналітик-людина і просто закидав клієнта такою кількістю питань підряд, клієнт би його вже десь там прибив))) Та й воркшопи або хоча б інтерактивні взаємодії діскавері є більш залучаючим інструментом збору вимог. Хоча в цілому для роботи з ШІ це має сенс 🤖 Бо агенту треба зібрати контекст. І якщо він не отримає цей контекст на старті, то потім сам почне його вигадувати. А ми вже знаємо, що коли ШІ починає “ну я так зрозумів”, то десь поруч уже тихо плаче архітектура та й в цілому доля продукту. 🥲 #AINativeBA #SDLC

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

Привіт, колеги 👋 Три дні був у відпустці. Побували в Києві. Заодно вкотре побачили й згадали, якими ж покидьками (дякую ChatGPT за культурне перефразування😇) є росіяни після всього, що вони роблять з нашою країною. Про BMAD продовжу писати вже найближчим часом — це поки залишається моєю основною темою 🤖 А поки запрошую глянути свіжий подкаст Олександра Крючкова про роботу в продуктовій компанії vs аутсорс, на якому я приймав активну участь і ділився своїм досвідом і там і там. 🎙️ Запис: https://www.youtube.com/watch?v=xW1r3Y4zeAQ 📼 #mood #webinar

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

Отже, маючи команду і SDLC, ви вже думаєте: а як мені цим всім керувати? 🤔 Якийсь такий менеджмент, мікроменеджмент одразу напрошується, нарізка купи завдань, чи не так? 🙉 І що, тепер треба вручну писати складні промпти кожному агенту?😱 Але якраз у BMAD Method, як і в інших схожих фреймворках, для цього використовуються workflows або skills.🧩 По суті, це заготовлені сценарії або інструкції, які зберігаються як код. Причому у форматах типу Markdown або YAML. Тобто ви умовно пишете коротку команду у вашому IDE. Наприклад, перша команда може бути наприклад /bmad-create-prd І після цього відповідний агент бере ініціативу в свої руки та починає ставити вам уточнюючі запитання, щоб крок за кроком скласти нормальний документ з вимогами до продукту.🤖Наприклад, той самий PRD 📋 Ви не пишете йому один величезний промпт на 10 екранів. Ви запускаєте робочий процес, а далі агент веде вас по ньому. Ставить питання. Уточнює деталі. Допомагає не забути важливі частини. І поступово формує артефакт, який потім стане контекстом для наступних кроків чи агентів. Якщо ж ви губитесь — а це можливо, бо питань і відповідей від цих агентів може бути достатньо багато — є корисна команда /bmad-help Це такий ваш розумний гід по поточному стану проєкту 🧭 Він може допомогти проаналізувати, де ви зараз, які документи вже створені, що вже пройдено і що логічно робити далі. Хоча, ця команда не завжди прямо обов’язкова. Бо підказка з наступними кроками зазвичай уже продумана всередині самих workflows.👍 Після завершення кожного робочого процесу агент, як правило, сам підказує, що можна робити далі. Тобто вам не треба постійно гадати наступний крок. У більшості випадків ви просто обираєте з варіантів, які пропонує ШІ. Тобто такі фреймворки, "AI-native SDLC" — це не магія. 🪄Це теж певний код, MD-файли та й все.🤷‍♂️ Точніше, це інструкції, сценарії, правила і шматки логіки, за якими працюють ці агенти поверх LLM. Умовно кажучи, це не просто “розумний чат”, який сам собі щось придумав. Це агенти, яким дали ролі, процес, інструкції і послідовність дій.🤓 І що я помітив: реальні команди працюють дуже схоже. - Є SDLC. - Є фреймворки. - Є гайди. - Є ролі. - Є питання, які треба поставити. - Є рішення, які треба прийняти. - Є артефакти, які треба підготувати. Просто у BMAD ця логіка перекладена на агентів і зафіксована у workflows та skills. Ну і ідея така: не змушувати ШІ кожного разу імпровізувати з нуля, а дати йому зрозумілий процес, за яким він має працювати. #AINativeBA #SDLC

Такс, команду зібрали 🤖🫡 Тепер їм треба дати підхід до роботи і скоординувати їх так, щоб не перетворити проєкт на слоп і хаос. І тут якраз з’являється одна з ключових ідей BMAD Method — дотримання 4 фаз Agile-розробки. Головне правило: жодна наступна дія не починається без затвердженого документа з попередньої фази. (привіт, waterfall🌊) Але в контексті роботи з ШІ це має сенс, бо ці документи — це не просто “документи заради документів”. Це спосіб зберігати контекст і не давати агентам вигадувати все з голови. Ось як виглядає цей шлях 👇 1️⃣ Фаза 1: Аналіз (Analysis) 🔬 На цьому етапі ви працюєте з Аналітиком, щоб провести мозковий штурм, дослідити ринок або технічні деталі майбутнього проєкту. Результат фази — базовий бриф проєкту (Project Brief) або документ PRFAQ. 2️⃣ Фаза 2: Планування (Planning) 📋 Підключається Продакт-менеджер, який перетворює короткий бриф на чіткий PRD (Product Requirements Document) — повноцінний документ із вимогами до продукту. Якщо у продукту є візуальний інтерфейс, на цьому етапі також проєктується UX-дизайн. 3️⃣ Фаза 3: Проєктування (Solutioning) 🏗 Час для Архітектора. Він розробляє детальну технічну архітектуру системи. Важливий нюанс методології: тільки після затвердження архітектури загальні вимоги розбиваються на великі модулі (Епіки) та дрібні задачі для розробника (User Stories). Це потрібно для того, щоб кожна задача була не просто “зроби мені фічу”, а вже враховувала обрану архітектуру, технології та технічні обмеження. 4️⃣ Фаза 4: Імплементація (Implementation) 💻 І лише тепер ШІ-Розробник береться за написання коду. Робота йде ітеративно та сфокусовано — крок за кроком, окремо по кожній User Story. Після імплементації фічі інший агент обов’язково проводить code review. Що маємо на виході і чому це круто? Власне, самі артефакти📚 Після кожної фази маємо окумент, який стає прямою інструкцією і збереженим контекстом для наступного етапу. Завдяки цьому наступний ШІ-агент не починає роботу з чистого аркуша і не вигадує функціонал з голови. Він діє в межах затвердженого контракту. І от саме це, на мою думку, дуже важливо в AI-driven development. Бо коли немає контракту, немає контексту і немає чіткої послідовності, ШІ дуже швидко починає робити “ну я так зрозумів”. #AINativeBA #SDLC

Якщо ви зі сторіс подумали, що я super-excited від нової моделі Claude, то ні: 1. Я в принципі боюся його використовувати після прочитання "Fable...draws down usage 2× faster than Opus"😅 2. Для моїх кейсів, як я вже і писав, Sonnet для БА-роботи у більшості випадків вже буде достатньо як самої моделі, Opus - це вже космос, це вже і серйозні прототипи, то й же BMAD. Fable...все ж таки Anthropic заглиблюється у кодинг більше, ніж усе інше, що в принципі має сенс у їх позиціонуванні як гравця ШІ-ринку. Ну, часу пройшло мало, побачимо...можливо ви маєте якісь відгуки щодо нової моделі? #mood

Отже, у BMAD Method ви отримуєте не просто чат-бота, а свою персональну команду ШІ-експертів 🤖 І це, насправді, одна з ключових ідей методу. Бо спілкування з одним універсальним чат-ботом під час написання коду, наприклад у Claude Code чи Codex, часто заходить у глухий кут. Бо коли один чат намагається бути майстром на всі руки одночасно, він дуже швидко втрачає контекст і починає робити все трохи посередньо 😅 Він ніби одночасно має бути бізнес-аналітиком, продактом, архітектором, розробником, QA, скрам-майстром і ще трошки психологом для вас, коли все зламалося. Ну, і воно не завжди працює. У BMAD Method логіка інша. Замість спілкування з одним ботом, ви працюєте з командою вузькопрофільних ШІ-експертів, де кожен має свою роль, персону і зону відповідальності. Отже, хто у нас тут може бути 👇Отже, хто у нас тут є 👇 1)🔬 Аналітик (Alex) — ваш дослідник. Він проводить дослідження ринку, вивчає цільову аудиторію та генерує ідеї на старті проєкту. 2) 📋 Продакт-менеджер (John) — головний планувальник. Він бере ідеї Аналітика і пише детальні вимоги до продукту — PRD, створюючи конкретні задачі (User Stories). 3) 🏗 Архітектор (Sarah) — проєктувальник. Він (вона?) продумує технічний дизайн системи, обирає стек технологій та архітектуру бази даних. 4) 💻 Розробник (James) — безпосередній виконавець. Він не вигадує нічого від себе, а просто пише код за вже готовими, чіткими інструкціями від Продакт-менеджера та Архітектора. Отже маємо 4 ролі, розподіл який вже дає кращий порядок, структуру роботи. Розробник не буде вигадувати бізнес-вимоги на ходу, а аналітик не лізтиме в архітектуру бази даних. Кожен ШІ-агент робить лише те, в чому він експерт, і це робить результат більш передбачуваним. Цікавий факт: імена умовні — ви можете створювати своїх агентів. Оскільки кожен ШІ-експерт — це звичайний Markdown-файл з інструкціями у вашому проєкті, ви можете легко кастомізувати систему: створити нового агента, назвати його “Валєра”, прописати йому інструкції для роботи з вашою специфічною базою даних — і він стане новим унікальним членом вашої ШІ-команди.😄 #AINativeBA #SDLC