Eugene K - the BA🇺🇦

Технічні скілли.Все менше і менше кандидатів кажуть, що не працювали з API, базами даних, не розуміють архітектуру веб чи мобільних застосунків і т.д. ⚙️І все більш важливим і помітним це стає в плані вимог до кандидатів БА.Чому бізнес-аналіз все більше і більше вимагає елементи аналізу систем? 🤔І чому важливо це вивчати, знати, вміти?Для більшості наших клієнтів продукт, система — це і є бізнес 💼Це те, що вони продають кінцевим споживачам, іншим бізнесам, вайтлейблять, інтегрують тощо.Тому сприймайте систему як критичну capability (слово, яке складно перекласти) бізнесу.І успіх застосування бізнес-аналізу, а саме:🔹 аналіз інтерфейсів (де користувацький посідає далеко не перше місце),🔹 моделювання даних і потоків даних,🔹 аналіз станів —є так само критичним заняттям.Що вже казати про швидку, вільну взаємодію та комунікацію з ІТ-командами 🚀Я до сих пір вірю, що ви не маєте (і у більшості випадків не зможете) знати все, чи бути здатним самим будувати, створювати рішення, але сприяти успішній розробці через ваше розуміння технічних аспектів рішення — це саме те, що дає зараз цінність у переважаючій кількості компаній та проєктів 💡Тому курси щодо тех скіллів (наприклад, Art of BA — з перевірених, не реклама), сертифікації клауд провайдерів, практика у створенні систем та тестування, дослідження чи розробка навіть простих технічних сценаріїв чи власних рішень — це міцні кубики 🧱 для майбутнього і теперішнього вашої кар’єри та успішного проходження інтерв'ю. 🎯#tips #interview

У якості подяки за ваші донати 💛 і відгуки на вакансії 💼 з мене — на додачу до вакансій — буде ще кілька цікавинок щодо співбесід 😏Бо зараз їх багато, а я ділюся саме поточним чи нещодавнім досвідом.То ж поїхали! 🚀Бізнес-вимоги!Це одне з перших питань на співбесіді, і доволі висока статистика того, що саме на ньому кандидати фейлять 😅І якось співбесіда після цього стартує вже не так позитивно.А давайте це виправимо разом! 💪📌 Бізнес-вимога — це вимога, яка в першу чергу відповідає певній потребі бізнесу, усієї організації.Тобто які саме потреби є у компанії, які визначають подальші потреби окремих зацікавлених сторін, функціональні вимоги тощо.⚠️ Частою помилкою є, коли кандидати кажуть “зробити якусь фічу/продукт” — але це вже рівень рішення, а не бізнес-вимога, або це рівень потреби без розуміння її першопричини.💡 Ключові елементи бізнес-вимоги:• Вона відповідає потребам бізнесу — наприклад: розширення долі ринку, збільшення кількості платних користувачів, скорочення витрат тощо. Тобто те, що приносить бізнесу гроші.➡️ Приклад бізнес-вимоги: “Локалізувати систему для країн Близького Сходу задля виходу продукту на ринки ОАЕ та Катару.”• Вона пов’язана з бізнес-цілями.Є чудовою практикою вказати бізнес-ціль у формулюванні бізнес-вимоги або її описі.Ціль має бути за SMART — особливо звертайте увагу на вимірюваність результату (у грошах, відсотках) і часові рамки.➡️ Приклад SMART-бізнес-вимоги:“Локалізувати всі інтерфейси кінцевих користувачів (покупців) для країн Близького Сходу задля виходу продукту на ринки ОАЕ та Катару протягом наступних 6 місяців.”🎯 Якщо ви Middle+, обов’язково наводьте приклад бізнес-вимоги з вашого реального досвіду.Це свідчить про усвідомленість, практичність і зрілість вашого підходу 💼#tips #interview

От ці всі "LLM-володарі світу" (Альтман, Маск...) будують гігаватні датацентри ⚡️, закупають тоннами чіпи 💾, будуть витрачати море електроенергії й ресурсів 🌍А я думаю: може б ви краще подумали, як вашому умовному ChatGPT влучніше давати відповіді?🤔За статистикою, користувачі отримують бажану відповідь на першій спробі лише у 70–75% випадків (і це ми говоримо про текст 📝).Для складних або професійних задач, щоб дійти до правильного результату, потрібно 2–4 уточнення чи переформулювання запиту, або ж використання тактики “iterate & revise” 🔁Уявляю, що буде, коли в гру вступлять агенти-оператори, які виконують багатокрокові завдання —де успішність, умовно, = 0.8 × 0.7 × 0.75… і що вийде в результаті? — сумно 😅Не забувати контекст у попередніх двох повідомленнях 💬, не придумувати велосипед 🚲, а краще шукати, розуміти, і давати звичні для конкретного користувача формати відповідей 🎯Звісно, я не експерт у побудові LLM — ці знання лежать у окремого кола людей (ми так... крихти збираємо, можемо юзати їх опенсорс-моделі) 🤓Але мені здається, що оптимізаційні та персоналізаційні покращення самих LLM були б економічно більш вигідними 💡Аніж те, що часто видаються незадовільні промпти, які змушують вентилятори на відеокартах крутитися ще і ще 🔁💨А ви як гадаєте? 😉#mood

І тут давайте наближено - як це працює у роботі бізнес-аналітика? 💼 Інжиніринг контексту — це саме те, що допомагає зробити ШІ-агентів справді корисними у нашій роботі.Коли аналітик взаємодіє з генеративними моделями, контекст — це все: історія проєкту, вимоги, артефакти, домовленості, корпоративні стандарти.Якщо ці дані автоматично підтягуються в потрібний момент — модель може генерувати точні, релевантні, контекстно узгоджені відповіді.🧩 Приклади застосування: - агент, який знає поточний опис епіка чи фічі та генерує релевантні сторьки; - ШІ, який підтягує релевантні вимоги або артефакти з Confluence перед створенням BRD; - асистент, що памʼятає минулі зустрічі, прийняті рішення та пропонує узгоджені зміни; - генерація acceptance criteria, враховуючи стиль і стандарти конкретної команди.Звучить як майбутнє?👨‍🚀 Але ви вже можете створювати інструкції для Gems чи GPTs, якщо у вас є доступ до ШІ на роботі (а він вам точно вже треба).👍І всі Rovo, Scope AI та інші продукти — вони все одно не стануть робити магію самі по собі.🤷‍♂️Їм треба буде підказувати куди дивитися і що брати, показувати їм взаємозв'язки і сенси, які знаєте тільки ВИ! 🧠#AIforBA

От по Comet трохи з потенційних сценаріїв розказав (і буду ділитися ще). Але давайте розкажу про недоліки як цього браузера, Асистента так і схожих рішень 👇1️⃣ Я кілька раз писав словосполучення “в теорії” — на практиці у Comet, як і у будь-якого іншого такого агента, повно проблем: баги, застрягання LLM або оператора і ще різні недоліки, які вірогідно можна виправити, але:🧩 По-перше, є поточні невирішені проблеми LLM (принаймні у публічних рішеннях) — контексне вікно, погана памʼять, галюцинації на відчутному рівні.🧠 Погодьтесь, для ШІ покрити всі можливі інтерфейсні рішення буде складною задачею.2️⃣ 🎤 Голосовий ввід жахливий — у Comet щось говорити голосом це погана ідея, у мене обривалися слова англійською, якісь незрозумілі символи. Коротше, у них якийсь неякісний Speech-to-text стоїть.3️⃣ 💻 Жахливий недолік цього браузера — з невідомих причин він час від часу скидає шерінг екрану на мітах.Ну, уявляєте, як це для БА, та й взагалі для людини, яка часто щось демонструє по екрану — це важко 😅Може, я щось не те наклацав — пишіть, якщо знаєте.4️⃣ ⚙️ Чого не вистачає Comet — це певні функції звичайного ChatGPT, а саме:покращена памʼять, утримання і розуміння контексту (я цього не помітив), можливо краща навігація у розмовах, проєкти, можливо якісь заготовлені флоу (хоча там щось час від часу пропонується).5️⃣ 🕐 Ну і звісно, щоб агент якісно виконав завдання, треба самому перше прописати правильний промпт з достатньою кількістю деталей — за часом це може бути не менше (а то й більше), ніж самостійно його виконати 😅А чи є у вас враження? 🤔Може вже встигли поклацати? Що скажете про свій досвід з цим та іншими агентивними браузерами? 🌐

🤖 Прочитав свіжу статтю Карла Вігерса — «Take Chatbot Responses with a Big Grain of Salt»Карл ділиться досвідом і робить простий, але болісно точний висновок:«Більшість із цього — правда. Проблема в тому, що ми не знаємо, яка саме частина — ні.» 🫠Карл перевірив чатботи (ChatGPT, Gemini, Copilot, Grok) на прикладах, де він точно знав правильну відповідь.Результат — цікава статистика помилок і вигадок:📚 приписані книги, яких він не писав🧩 техніки, які він ніколи не рекомендував🎬 сцени з серіалів, яких не існує👨‍🎤 актори, що ніколи не знімалися у зазначених роляхЙого спостереження боляче резонує з тим, що я сам бачу:AI-моделі часто звучать впевнено навіть тоді, коли помиляються.І якщо ми, як аналітики, не перевіряємо факти, — ці помилки потрапляють у документи, презентації, продукти.А потім знову потрапляють у тренувальні дані.🧨♻️ Garbage in — reinforced garbage out.Отже, висновок такий: в цілому можна довіряти «більшості» відповідей, але не варто забувати перевіряти критичні.Особливо коли на кону — рішення, гроші чи довіра клієнта. Але які вимог є критичними — варто знати нам.🧠 P.s.: закиньте отцю лайк на статтю 👍#mood #AIforBA

По агентивному браузеру 🌐 — зараз очікується їх бум і фінальна боротьба (а потім Chrome всіх винесе, ІМХО 😅) за цей ринок. А ринок — максимальний: браузер + пошук + ШІ-чат = і весь інтернет належить вам 🚀.Я користуюся вже тиждень браузером Comet від Perplexity на безкоштовному Pro-tier, інформацією про який ділився з вами пару тижнів тому.І скажу чесно: він мене більше порадував, ніж розчарував 🙌. Дав надію і бачення, як круто це може бути — і вже фактично є.🔥✨ Суть Comet — асистент, який може робити все з будь-якою відкритою табою браузера: - Хочете інтегруватися у Jira? Ок. ✅ - Працювати з офісними рішеннями без Gemini чи Copilot? Легко. ✅ - Slack? Просто залогіньтеся, і він вже агентизується 🤖. - і т.д.Що таке «агентизується»?🔹 ШІ-асистент бере повний контроль на рівні CUA (computer-using agent, він же оператор). Тобто він може: - читати (текст, HTML), - бачити (зображення), - вводити текст, - клікати, скролити, навіть зумити.🔹 Він вирішує задачі комплексно: можна поставити завдання («створи задачу у Jira», «напиши повідомлення у Slack»), і він буде мислити, декомпозувати, логінитися, переходити, клікати — крок за кроком 🪄.💡 Перевага Comet — він базується на Perplexity, а це і пошук, і LLM одночасно. І мені подобається, як він шукає.Для порівняння: коли вийшов Operator у ChatGPT, це було сиро — маленький екран, авторизація на віртуалці, багато помилок, дуже стрьомно. А от Perplexity зробили одразу правильно 👌.Далі розпишу кейси, але в цілому — це варто спробувати кожному 🚀.#AIforBA

Трошки надихнуло вчорашнім ще одним нашим внутрішнім стрімом по ШІ 💡:💡 AI-проєкти (продукти/фічі) все ж таки відрізняються від звичайних проєктів для BA.Коли ви працюєте над ШІ-фічами, бізнес-аналіз змінює правила гри. Ось ключові відмінності, які варто тримати в полі зору: - 📊 Аналіз, що базується на даних (data-driven analysis). Вимоги значною мірою залежать від доступності, якості та маркування даних. - 🎯 Ймовірнісні результати (probabilistic outputs). AI рідко дає 100% детермінований результат — плануйте прийнятні пороги якості, % впевненості (confidence) моделі. Також у більшості випадків потрібно обов’язково на старті (а насправді і не тільки) мати в процесі генерування перевірку людьми на якість, можливі коригування. - ⏳ Еволюція рішення (Evolving Solutions). AI-рішення можуть «деградувати» (model decay, data drift) з часом. І варто піднімати питання впровадження SFT, періодичного донавчання моделі (retraining) тощо. - 📏 Розширені метрики. Окрім бізнес-метрик, додаються AI-метрики: точність (accuracy), рівень галюцинацій (hallucination rate), затримка (latency) тощо. - 🤝 Зацікавлені сторони з різних фахів/дисциплін (Cross-Disciplinary Stakeholders). Більше взаємодії з ШІ-інженерами, фахівцями з compliance/юристами та ML Ops командами.Бізнес-аналіз у ШІ — це інший темп, інші виклики й інший набір інструментів. Результат навряд чи буде ідеальним одразу, тому готуйтеся до довгої, але цікавої подорожі 🚀#AIforBA #mood

Група елементів 5. Функціональна логіка ⚙️Добралися до цікавенького 🙂Коли ми говоримо про опис інтерфейсу, то маємо на увазі не лише списки, поля чи групи, а й те, як усе це взаємодіє між собою та й поза UI. Тобто — функціональна логіка.Почнемо з навігації 🚦Що що тут можна подумати?1) Перехід на сторінку (transfer to page) — що відбувається після дії користувача (наприклад: «створити користувача» → відкривається сторінка з формою). Коли ми говорили про групи (і сторінки), ми вже зачіпали переходи на сторінки. Але часто потрібно продумати і переходи зі сторінки: вказати шлях, можливо навіть дати посилання на вимоги до тієї сторінки.2) Показ/приховування груп чи елементів (show/hide groups/elements) — динаміка інтерфейсу: певні блоки з’являються або зникають залежно від умов.3) Передавання даних на сторінку чи групу — іноді при навігації важливо передати дані. - «переходимо (зі сторінки редагування) на сторінку списку з оновленими/зміненими даними користувача»; - «передаємо знижку на сторінку замовлення з результатом промокоду в інтернет-магазині».4) Повернення назад (back navigation) — що стається при натисканні «Назад»: чи відтворюємо попередній стан, чи відкриваємо сторінку заново.5) Глибина навігації / breadcrumbs — чи потрібні «крихти» для орієнтації користувача, і яка логіка їх формування.6) Модальні переходи — перехід може бути не на повну сторінку, а в попап чи вкладку. Варто описати, чи це «повноцінна навігація», чи лише тимчасовий стан.7) Параметри URL / routing — якщо це веб-застосунок, описати які параметри передаються в URL (наприклад: ?userId=123&tab=profile).8) Архітектура навігації: MPA чи SPA - MPA (Multi-Page Application) — класичний варіант: кожна дія веде на нову сторінку, яка повністю перезавантажується (сервер формує сторінку). Простий підхід, але може бути повільніший для користувача. - SPA (Single-Page Application) — оновлюється тільки частина інтерфейсу без повного reload. - Тут варто подумати: - чи дійсно потрібні переходи без перезавантаження сторінки; - як зберігати стан між переходами; - чи виправдана складність SPA саме для цього проєкту (оцінити разом з командою).👉 А які особливості навігації найчастіше стають «підводними каменями» у ваших проєктах?І обовʼязково пишіть, якщо є що додати! 💡🙌

Єдинороги - сила 🦄Обіцяв вам поста про старт своєї карʼєри БА — пишу ✍️Так от, 27 серпня 2013 року 🎂 12 років тому мені подзвонила одна українська компанія і дала оффер на роботу аналітиком продажу 📊Я був дуже радий, адже на той момент я добре знав Excel та 1C (це такий собі SAP придуманий русскіми, і зараз його використовувати — це стрьом😅). Також на попередній роботі у одному з великих супермаркетів я працював менеджером відділу і це була крінжова компанія 😬: всіх гнобили, овертайми без оплати, багато чорної роботи, огляди на вході і виході - я після неї місяць відходив🏖. І я на тих гнобленнях («чого так мало продажів?») найкраще всіх відбивався аналітикою 📈 — аналіз даних: сезонності, по категоріях, співставлення з іншими магазинами🤓. Це теж мене надихнуло шукати подібну посаду і хотілося нормального офісу 🖥Приходжу я, працюю кілька днів — мене класно онбордять, все супер ✅.Робота нескладна, Excel люблю — супер 💚.І от десь через кілька днів до мене звертаються власники бізнесу і кажуть:«Ти ж знаєш 1С — нам треба поставити нову версію» (з 7.7 на 8.1 ⚙️).Це була велика зміна: у компанії вже була оптова торгівля, роздрібні магазини в Києві, франчайзі по Україні… Ну, власне я ходив до бізнесу, збирав вимоги, писав ТЗ 📝 (без якого «хз»))) описував процеси, задачки, комунікував з розробниками. Як казала наш директор: «Він виїдає їм мозок ложечкою» 😂 — це більше через те, що розробники працювали окремою компанією і, думаю, ми для них були в заплутаному пріоритеті, але мене це не зупиняло.Найскладніше, напевно, було виробництво 🏭 — адже цього процесу взагалі не існувало.А, до речі, слово «бізнес-аналітик» я почув вперше від одної української консалтингової компанії — вони перші показали мені (та й компанії)) довжелезні BPMNки з процесами (прям вся стіна в довжину метрів на 5 була ними обклеєна 🔄).До цього я називав себе системним аналітиком (правда, зараз більш логічною здається назва «аналітик систем»).У трудовій книжці писали навіть якось «начальник інформаційно-обчислювального центру»))) (просто інших посад на той момент здається і не було).😄2,5 років десь я там працював і набув класних навичок без менторства, часто з помилками, без розуміння як це можна і має бути. Здається, тоді читав Вігерса 📖, не все розумів (може і не все потрібно було). Але в принципі цього вистачило, щоб вже наступну роботу знайти з позицією БА.А з чого починали ви? 🙂#memoir