Eugene K - the BA🇺🇦

Коротко про підсумки року.🤔Загалом проводжаю рік на видиху 😮‍💨Зміна 3х проєктів, десятки пресейлів та ще більше інтерв’ю разом з колегами.Спільними командними зусиллями наш БА відділ суттєво виріс, а наш мега-менеджмент буквально висвітлював чудові цифри зростання загалом по компанії 📈Круто, коли все працює як треба у правильних місцях та в руках професійних та цілеспрямованих людей.💜 Тож приходьте і доєднуйтеся 😉Цей рік для мене видався більше перформансом, аніж розвитком.⚡️⚡️⚡️Хоча динаміка — це теж навчання і зростання, просто треба вчасно зупинятися і брати паузу.🔥По "позаробочим активностям": - Виступ на EU BA Day - Виступ на УБАК - Спільний вебінар з БА - це безалкогольне? - Спільний вебінар з Badass BA - Лекція в УКУ - Спільна стаття про сертифікацію ECBA з колегами Перепрошую, якщо щось чи когось забув.Також завдяки моїй ініціативі майже пів сотні БА мали можливість ефективніше підготуватися до сертифікацій IIBA.🤞На наступний рік теж роблю ставку на ШІ 🤖Загальне захоплення зникло, індустрія в цілому трохи скинула обороти і вже за нею легше спостерігати і щось пробувати.👀Залишилася прагматика і бажання ще більше бустанути БА та інші активності за допомогою LLMок, агентів та інших цікавих сервісів 🚀Також дякую вам як читачам цього каналу — нас вже 500+ 🙌Не соромтеся коментувати та спілкуватися і залишаймося на зв’язку у 2026. 🙌#mood

Отже, чому рекомендаційні механізми — це складно? 🤯1️⃣ Не існує “правильної” відповіді.Тут завжди є що обговорювати і погоджувати із зацікавленими сторонами.Можуть бути кілька конфліктуючих думок, і ці конфлікти потрібно якось розрулювати.А показати, яке рішення “краще”, буває не так просто.Наприклад: - бізнес хоче конверсію 💰 - дата саєнтисти — якість моделі 📊 - UX-дизайнер — щоб не дратувало користувача 🎨 - в кінці кінців користувач хоче побачити одне, а бізнес — показати йому інше 💥2️⃣ Потрібно домовитися, що саме рекомендувати.Ми зважаємо на критерії, про які писав вище(властивості транзакцій, контенту, користувачів і багато іншого),і це все може бути не швидкою, а доволі кропіткою роботою 🧩3️⃣ Результатом аналізу має бути чітке пояснення: - “Чому ця система цьому користувачу порекомендувала ось це?” - Тобто потрібна валідація рішення і можливість його пояснити.4️⃣ Складно (але реально) виміряти успіх.Потрібно зрозуміти, чи дійсно те, що ми рекомендуємо,користувач хотів, обрав, придбав, переглянув тощо 📈І відповідно хороший, сильний, сенйорний, енергічний та кмітливий БА 💪:• Зрозуміє початкову ціль такої фічі• Прорекомендує пріоритети складових рекомендаційного механізму(типу: «почнемо з цього, бо воно дає нам ось такий ефект»)• Побудує модель або whitepaper по механізму, де чітко зафіксує на підставі яких саме даних, за яким принципом, з якими пріоритетами та вагами рекомендаційна система працює• Провалідує наявність необхідних даних• Якісно це все скомунікує(до речі, в більшості випадків ексель-таблиця з критеріями та вагами може бути дуже ілюстративною — навіть як інпут для серйозних ML-рішень 📄)• І, звісно, погодить це все з усіма зацікавленими сторонами 🤝І наостанок: рекомендаційні системи виглядають як “фіча”, але насправді це постійна гіпотеза, яка живе, змінюється і ламається разом із поведінкою користувачів 🔄Успіхів! 🚀

У моїй практиці рекомендаційних механізмів було кілька — і вони були різного рівня складності.І це нормально: не обовʼязково це завжди має бути складна математична чи ML-модель.Але навіть найпростіші з них змушували замислюватися і мене і технічну, і продуктову команди 🤔Самий простий варіант був — підкидати опції фільтра користувачу для вибору(або це був продукт, або користувач для адміна — вже не пригадаю точно 😄).За основу бралися останні використані опції + найчастіше використовувані опції.У результаті користувачу це суттєво пришвидшувало вибір —не потрібно було вводити текст у пошук,а в більшості випадків — клац-клац і готово ✅А от була і модель рекомендацій контенту — уявімо аналог YouTube 🎥Там уже була ML-історія і кілька груп критеріїв:• Метадані контенту (категорія, теги)• Текстова інформація (заголовок, опис, транскрипт аудіо/відео)• Користувачі контенту (хто дивився, їхні персональні дані, як довго дивилися)• Свіжість (свіжі відео потрібно просовувати, бо на старті по них складно зібрати поведінкові дані)• Популярність (перегляди умовно на 70% тривалості відео, лайки, коментарі)• Featured-відео (користувачі могли «бустанути» свої відео за гроші, щоб отримати більше стартового охоплення і вищу ймовірність «завіруситися» у соцмережі 💸)Мені все одно не дуже подобалася сама наявність нейронки,але ми виписували основні правила і могли їх перевіряти, наприклад:«Якщо користувач протягом останніх 14 днів переглядав відео з категорії X більше ніж 3 разиі сумарний час перегляду таких відео перевищує 60% їх тривалості,то в рекомендаціях збільшується вага категорії X».Насправді правил там виникає дуже багато,і перевірити їх усі — довго і дорого 💰⏳Тому зазвичай робиться брейнстормінг топ-сценаріїв,вони тестуються,а все інше — ми свідомо «довіряємо» системі.Так, по суті, працюють усі великі компанії.Вони фізично не в змозі перевірити все —це вже не просто набір бізнес-правил,а комплексне рішення у надрах нейронки,яка може обробити мільярди сценаріїв для формування рекомендацій —і це, в цілому, має сенс 🤖(хоча так, іноді вони теж галюцинують 😅).

Нещодавно питався у вас, які функції, користувацькі історії або фічі є найскладнішими для аналізу — і наведу свій особистий топ-5.Першою категорією таких фічей будуть зміни у комплексних міждоменних процесах.Уявімо достатньо складний процес, який покриває кілька доменів, команд і систем. Наприклад 👇🔹 Міжнародна платіжна системаТут є: - підключення клієнтів - обмін валют - здійснення міжнародних переказів (зі своїми стандартами, типу ISO 20022)І тут зʼявляється, наприклад, система бонусів:окремо — на обмін, окремо — на платежі.Звучить як дві різні фічі?Але під капотом це дуже тісно повʼязана логіка 💥🔹 Компанія, що поєднує іпотеку, страхування, управління та продаж нерухомостіНічого собі, так?І сюди приходить фіча моніторингу клієнтів — за діями у всіх цих системах і сервісах одночасно.Складно?👉 Так!Чому це може бути складно в цілому 🤯 - Кожен домен і так має власні правила, юридичні обмеження та терміни(а якщо ви не знаєте домен — буде ще складніше). -У процесі може брати участь велика кількість ролей(наприклад: позичальник, брокер, оператор оформлення, ріелтор, юрист, клієнт — і ще вагон таких зацікавлених сторін). -Дані розпорошені між зовнішніми системами.І інтеграції з ними треба не просто враховувати —їх доводиться вивчати і перечитувати при кожній зміні. - Різні рівні послуг і часові затримки між кроками ⏱ - десь потрібна миттєва відповідь, - десь — чекати конкретної дати або часу, - десь — ручне введення. - Високий ризик розривів у процесі через велику кількість точок передачі інформації або через рішення, які приймають різні актори.🤷‍♂️Що вимагається від BA чи PO 🧠 - Побудова (або перепланування) детального процесу чи споживацької подорожі у разі змін. І так — деталей там буде вже багато. - Виявлення та активна комунікація з багатьма зацікавленими сторонами. - Формування єдиної моделі сутностей (типу ERD або хоча б concept map). - Аналіз розривів між системами, залежностей і точок потенційних збоїв.Побудова діаграм робочих процесів і станів (що спочатку захоплює 😄,а через місяці три ти починаєш відчувати себе рабом тієї BPMN-ки).❓ Чи зіштовхувалися ви з чимось подібним?Пишіть у коментарях 👇

Колеги, поки не було часу писати, але знайшлася годинка-друга безсонної ночі послухати ювілейний подкаст Badass BA з самим Карлом Вігерсом ⭐️Я вітаю Кирила та Антона з такою крутою коллабою 🎉 + Вігерса як завжди приємно почути, прислухатися. ☺️І тримайте від мене підбірку з того, що сподобалося мені у цьому подкасті, корисні думки з моїми коментарями: - Визначення меж рішення (scoping) — це завжди правильна стратегія у підході до вимог у проєктах (Карл навіть книжки з цим підходом пише). Спочатку скласти загальний пул вимог, фіч, проєкту — що робимо, що не робимо, велика картина, але чіткі обмеження — і тільки потім рвемося в деталі, сторьки і задачки. 📘🧩 - Згадали чудовий документ для Discovery-фази, який використовується у більшості ІТ-компаній — Solution Vision and Scope; до речі, темплейт на цей та інші прикольні артефакти можна знайти тут: https://softwarereqs.com/. 📝✨ - Співпраця двох чи більше людей не гарантує швидше завершення роботи, але покращить її результат — це релевантно не тільки для написання книг, але й для роботи БА-команд і усвідомлення їхньої цінності, цінності їхньої співпраці 🤝💡 - Працюючи в команді, обовʼязково обговоріть, як вам разом працювати та взаємодіяти; в ідеалі має бути БА-план, де ця взаємодія прописана та погоджена — між БА та іншими зацікавленими сторонами проєкту 🧭🗂️ - Склад розуму БА: ми — про проблеми і потреби, коли інші — про рішення (знаменита книжкова цитата "now build me a system!"). Але в цьому наша перевага, адже гарні рішення базуються на глибокому розумінні саме потреб. Також згадували про мислення на різних рівнях абстракції: хороший БА вміє майстерно думати одночасно і про тактичні рішення, і стратегічні, переключатися від контексту поведінки окремої кнопки до стратегічних напрямків розвитку корпорації. 🚀🔍 - Згадали чудову техніку — business objective modeling для discovery 🎯 - На прикладі DFD (діаграма потоків даних) Карл розказав про можливість застосування технік у різних контекстах; на перший погляд достатньо технічна діаграмка може іноді пояснити концепції бізнесу.Я в свій час теж прийшов до того, що вивчення технік — це не просто заучування нотацій і слідування їм, це — напрацювання загального арсеналу підходів у бізнес-аналізі. І в якийсь момент накопиченого досвіду і знань ти починаєш не просто адаптувати, а модифікувати існуючі типи діаграм, створювати нові — під кожен конкретний контекст, проєкт, людей. 🧠📊✨ - Звісно, поговорили про ШІ — я вже якось писав про його статтю «Take Chatbot Responses with a Big Grain of Salt». Основні думки на подкасті схожі: - ШІ галюцинує, його треба перевіряти; - ШІ пише те, що вам подобається, його легко переконати — а значить з ним легше втратити звʼязок з реальністю.Від себе ще додам, що ускладнюється все тим, що у БА часто не буває чітких вхідних даних. Наприклад, інші члени ІТ-команди мають вимоги від БА і з ними працюють, а от БА… працює з величезним неструктурованим контекстом, розкинутим у різних формах між різними людьми, і з якими це треба комунікувати — причому по-різному. ШІ це ще не скоро буде під силу. 🤖⚠️ - Багато у кого є синдром самозванця, хоча (хороша новина) — у справжніх самозванців цього синдрому немає. - Будьте справжніми, знайте реальні можливості своєї компетенції і валідуйте свої знання через оцінку їх результативності на практиці. 💛💪Лінк на сам подкаст: https://www.youtube.com/watch?v=N7Pfcpzxr5Q 📼#mood

На тижні робив цікаву штуку: експортнув ВСІ готові реквайрменти по поточному проєкту з Jira (зі сторей) у Excel, потім у Word 😎Попросив GPT та Gemini знайти всі вимоги по доступу й зробити матрицю доступу (Use case vs. Roles).По контенту вийшло 75 сторей, 114 тис. символів, 28 тис. токенів — в принципі ізі для GPT 5.1 чи Gemini 3 💁‍♀️І давай-но клепати артефакти для Конфлюєнса!Перший — матриця доступів. У нас зараз всього дві ролі, неявно згадувався неавторизований доступ ◐Gemini vs. ChatGPT — результат приблизно однаковий, формулювання відрізнялися• (наприклад, Gemini напроти кожної ролі писав Allowed / Denied, а ChatGPT використовував смайли ✔️🚫 — останній трохи більше сподобався)• ChatGPT розбив певні функції на різні, причому зробив це не дуже гарно(задублював умовно функцію зміну статусу бану і потім дописав окремо Unban action — результат був правильний, просто некрасиво) 🤷‍♀️• Gemini додав колонку "Engineering Team" — була пара сторей для розробників. Мені сподобалося, що він звернув на це увагу. GPT цього не зробив 👀• Очікував (задача із зірочкою), що обидва помітять функціонал для неавторизованих юзерів — не помітили 🤷‍♂️• Gemini — схопив за руку. Це чудо техніки збрехало про приналежність одного функціоналу мобільної апки до адміністратора, хоча цього ніде не було вказано (та й це невідповідає дійсності) ❌📱• ChatGPT (при всіх його галюцинаціях) — такої лажі не знайшов 👍Я думаю, тут виграв ChatGPT 🏆, бо йому програв Gemini з галюцинацією про доступ. Це — груба помилка 🔴Варто зазначити, що я у ChatGPT створював кастомний GPT.P.S.: потім я зробив Gem для Gemini (аналог кастомного GPT з базою даних у вигляді файлу з вимогами) — він зробив щось непогане, але я не став рев’ювати, бо його попередній формат у просто чаті був кращий (там були пояснення, якщо доступ обмежений) 🤓P.S.: у цій гонці також приймав участь Notebook LM, але він щось дивне зробив: продублював рядки ролей 🫤P.S.: ще Rovo — по цій задачі він знайшов 7 сторей з доступами (хоча їх там мінімум 20). Просити робити щось далі не було сенсу 💩#AIforBA #experience

У computer vision, як і в принципі у будь-якому іншому ШІ, треба враховувати % успішності роботи моделі 🤖📊 (чи як краще це назвати).І приклад того, які дані ми враховуємо у метриках — а саме: - % загального визначення крадіжок у порівнянні з реальним, - реальні виявлення (true positives), - хибні виявлення (false positives).З будь-якими метриками я вважаю важливими три ключові речі 👇1. Доцільність. Чи дозволить нам метрика отримувати інформацію для реального прийняття рішень? Ми ж не хочемо просто мати цифри, на які будемо кліпати очима🙃Треба розуміти, які наші потенційні дії з метриками, коли ми побачимо на них ті чи інші значення. 🎯2. Вимірюваність і джерела інформації. Потрібно забезпечити процес вимірювання так, щоб значення метрик були об’єктивними й незалежними від зовнішніх факторів. Деякі метрики здобуваються з даних поза нашою системою, інколи офлайн. З ШІ взагалі, як згадувалося, має бути людина чи група експертів, що оцінюватимуть її роботу. Буває так, що потрібно розробити не один епік, щоб добитися отримання однієї, але дуже важливої цифри 🔍📈3. Правила звітності. А саме, формат звітності, частота оновлення/інформування тощо 🗂⏱#BAforAI #experienceI #tips

Ви знаєте, я часто стикаюся з проблемами ШІ при написанні вимог 🤖 і стаю все більш і більш переконаним, що умовного requirements engineer чи BA не було у списку експертів для SFT/RLHF-тренування моделі 😅Він має якісь приклади вимог, але, якщо взяти там опис сторі, то у більшості випадків його вимоги не витримають жодних критеріїв якості вимог — ні згідно BABOK, ні згідно INVEST 📘Я тільки за минулий тиждень (чому і надихнувся на пост) помітив, що згенеровані вимоги:• двозначні, не специфічні ⚖️• нерелевантні — я просто 20 хвилин переписувався з чатом, щоб переконати його викинути частину по логуванню акту виконання функції видалення у сторі, бо це в реалі не потрібно для того, щоб нашому продукту бути GDPR-compliant 🙈• їх неможливо протестувати — бо вони дуже абстрактні, використовуються конструкції etc., e.g., <A> or <B> 🧩• у формулюванні юзер сторі згадує деталі імплементації (які могли б бути у AC) 🔧• у формулюванні юзер сторі систему вказує як користувача 🖥• часто ШІ пропонує логування, що в цілому крута вимога (загалом це навіть best practice), але мені це наразі не потрібно 🪵• Mermaid діаграми — буває так, що я в принципі не можу щось згенерувати - просто 5 ітерацій підряд з помилкою і я здаюся (допомагає або просто повна перегенарція за першим промптом, або лагодження діаграми у Mermaid AI) 🫠При чому це відбувається не просто по рандомним промптам “згенеруй сторю таку-то”, — це працює в межах проєкту (тобто він може згрібати весь контекст під один дах для завдання). 🧠Також ШІ знає всі мої виправлення (зазвичай так і пишу “ось моя фінальна версія”) у сусідніх розмовах і вже мав би вчитися з того у контексті проєкту 🗂Тим не менш, генерація вимог — це хороший брейнстормінг на старті 💡 + полірування ваших вимог в кінці специфікації ✍️Але й б круто, якби хтось саме LLMку нормально натренував під вимоги (звісно це десь вже робиться) 🚀#AIforBA

Кілька порад для комфортного і ефективного проведення часу на інтерв’ю 💬🎯 Відповідайте по суті. Вслухайтесь у запитання і давайте відповідь прямо в ціль — коротко, структуровано: 1️⃣, 2️⃣, 3️⃣. Якщо чогось бракуватиме — інтерв’юер уточнить. 😉🧩 Не плутайте кейс із розповіддю про досвід. Часто питають не “розкажіть про ситуацію”, а “як би ви вчинили, якби…”. Тож не витрачайте час на бекграунд, а сфокусуйтесь на логіці рішення.🤝 Не бійтеся сказати “не знаю”. Це краще, ніж довга невпевнена відповідь, яка не веде до суті. Чесність завжди створює краще враження і дозволяє зосередитись на тому, де ви дійсно сильні 💪📁 Майте під рукою артефакти для демонстрації про всяк випадок. Якщо у вас є релевантне портфоліо чи домашнє завдання — підготуйте його наперед. Це чудова нагода показати свої сильні сторони на прикладі реальних артефактів.✨ Це допоможе оптимізувати ваш час, зробить спілкування зрозумілішим і дозволить інтерв’юеру краще побачити ваш досвід та підхід.Приємних вам інтерв’ю! 💜#tips #interview

Продовжую писати рекомендації по співбесідам зі свого досвіду 💬До недавнього часу ми просили кандидатів мінімізувати використання ШІ🤖 прямо у тексті завдання. Зараз ця вимога знята, але глобально ШІ-згенерований контент кидається в очі одразу не тільки своїм форматуванням (з яким все таки є сенс миритися, бо його можна і варто використовувати для того, щоб контент виглядав краще і без граматичних помилок), а ще й непрактичністю, нерелевантністю та іншими проблемами.🧐Взагалі не проти того, щоб домашки люди робили з умовним chatGPT, просто його використання має бути допоміжним, а суть, зміст — продуманими 💡Те, що генерує ШІ з першого промпта, у більшості випадків матиме купу проблем🥴 — я напишу про це окремий пост 🧩Плюс воно б'є по іміджу того, як ви відноситеся до потенційного роботодавця — якщо ви робите для "галочки", то це видно і навряд чи приверне увагу роботодавця, яку б ви від нього хотіли.👀✨ Що відрізняє круту конкурентну домашку від чергової, посередньої:🎯 релевантність — ви вичитуєте завдання і вирішуєте його самим ефективним способом по суті, орієнтуючись на цілі виконання домашки;🧠 ви використовуєте диверсифікований підхід, можливо кілька способів специфікації та моделювання, які доповнюють один одного і дозволяють кінцевому користувачу ваших вимог вас зрозуміти краще та відкинути потенційні питання;🔬 і звісно дбайте про деталі.У всіх трьох випадках варто вичитувати згенерований ШІ контент та проходити з ним кілька ітерацій, щоб ваше завдання не просто було прийнятним, а перевершувало очікування роботодавця 💎#tips #interview