Технічні навички бізнес-аналітика: навіщо потрібні і де їх вивчати

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

Привіт! Мене звати Юрій Гончарук, я бізнес-аналітик в компанії ITOMYCH STUDIO. У цій статті я хочу поділитись своїми думками та досвідом того, які технічні скіли потрібні БА, щоб ефективно виконувати свою роль та додавати собі цінності як спеціалісту.

Я починав як Manual QA, також є досвід в Automation QA (Java+Selenium), після чого перейшов в бізнес-аналіз. Перехід з QA в BA — досить поширена практика. Технічна освіта і досвід в автоматизації дають гарний бонус в роботі БА, а також розуміння підвалин розробки.

Та перш ніж зрозуміти, які скіли потрібні бізнес-аналітику, нагадаю, навіщо він взагалі потрібен у команді.

Чим займається бізнес-аналітик

БА бере участь на всіх етапах розробки ПЗ.

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

Основний для БА етап — виявлення, збір та аналіз вимог. Сюди входить:

  • документація бізнес та функціональних вимог;
  • валідація вимог;
  • створення плану дій для розробки;
  • визначення скоупу та пріоритезація;
  • комунікація вимог команді.

На етапі дизайну БА створює прототипи для UX/UI дизайнерів, визначає варіанти дизайну і знаходить можливості для покращення.

Під час розробки продукту БА проводить демо за результатами спринтів, збирає фідбеки від стейкхолдерів, доносить їх до команди.

На етапі тестування БА наглядає за юзер аксептенс тестуванням, аналізує аутпути ПО, поведінку та функціональність, дефекти.

Під час деплойменту та підтримки ПО задачі БА — перевіряти готовність, готувати мануали та гайди і вести пост-релізну комунікацію.

Важливо розуміти, яка відповідальність за яку частину роботи і на якому етапі лежить на бізнес-аналітикові, і як ви можете допомогти команді та клієнту досягнути цілей.

Чи потрібні БА технічні скіли

Коротка відповідь — так.

У вакансіях для БА на DOU у грудні 2022 року найчастіше зустрічаються ці 10 технічних скілів:

  1. SQL
  2. Excel
  3. Tableau
  4. Python
  5. Web
  6. Design
  7. API
  8. REST
  9. Presentation
  10. Testing

Навіщо БА потрібні технавички

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

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

Найважливіші технічні навички для БА

Software Development Methods

Бізнес-аналітику важливо знати різні методології розробки програмного забезпечення. Це дасть розуміння того де, коли та за що відповідає БА на кожному етапі розробки, як максимально ефективно допомогти команді та досягти цілей проєкту. Знання SDLC також допомагає краще планувати свою діяльність.

Найпоширеніші методології:

  • Agile — гнучка методологія розробки, яка проходить ітеративно.
  • Waterfall — модель, яка досить пряма та лінійна, використовує підхід зверху вниз.
  • DevOps — поєднання розробки та операцій. DevOps — це практика, яка дозволяє одній команді керувати всім життєвим циклом розробки програми: розробкою, тестуванням, розгортанням і моніторингом.

Де вивчати:

  1. Раджу почитати книгу Dean Leffingwell «Agile Software Requirements», а також «Scrum Guide».

Web/Mobile/Desktop Applications

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

Де вивчати:

  1. Web, Mobile or Desktop App — Which is Right for Your Project?

Research Skills

Ресерч — ключова навичка, оскільки допомагає БА ставити правильні питання, знаходити та збирати релевантну інформацію з різних джерел, розробляти різні гіпотези та створювати вичерпні репорти на основі зібраної інформації.

Statistics and Probability

Розуміння базових понять статистики та теорії ймовірності дає з’єднувати точки та знаходити рішення. Ти краще розумієш дані, щоб скласти ефективні прогнози, аналізувати минулі результати та прогнозувати майбутні; приймати рішення на основі закономірностей, присутніх у зібраних даних.

Основні моменти, на які варто звернути увагу:

  • Перестановки і комбінації;
  • Розподіл ймовірностей;
  • Теорема Байєса;
  • Регресійний аналіз;
  • Відбір вибірки;
  • Перевірка гіпотези;
  • Тестування Т-розподілу;
  • Дисперсійний аналіз (ANOVA).

Documentation and Presentation

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

Основні типи документації:

  • BRD
  • SRS
  • Use Case
  • User Story
  • User Guide / Manual
  • Reports

Презентація важлива з точки зору демонстрації стейкхолдерам нових ідей, презентації рішень, проведення демо клієнту та ін.

Зручні інструменти:

  • Confluence, Notion.
  • Google Sheets/Docs.
  • Google Slides, PowerPoint, Canvas.

Де вивчати:

  1. Алістер Кокберн — Writing Effective Use Cases.
  2. Майк Кон — User Stories Applied: For Agile Software Development.
  3. Джефф Паттон — User story Mapping.
  4. Ненсі Дуарте — «Slide:ology. Навички створення видатних презентацій».
  5. Галло Кармін — «iПрезентація. Уроки переконання від лідера Apple Стіва Джобса».

Advanced Process Modelling

Необхідно вміти моделювати складні існуючі процеси та аналізувати їх, вносити зміни для оптимізації процесів, а також візуалізовувати майбутні системи та процеси.

Основні типи діаграм, які варто знати та застосовувати, в залежності від задачі:

  • SIPOC (suppliers, inputs, process that is being improved, outputs, and the customers that receive the outputs) — допомагає зацікавленим сторонам визначити ключові елементи процесу.
  • BPMN — для моделювання бізнес-процесів.
  • UML — мова моделювання для візуалізації систем; діаграми включають учасників, дії, ролі, класи та допомагають краще зрозуміти або задокументувати систему.
  • Value Stream Mapping — інструмент моделювання бізнес-процесів, який використовується для аналізу існуючих і майбутніх станів процесу. Ці карти показують усі важливі кроки, а також потік цінності та інформації через процес.
  • IPO (input-process-output model) — це функціональний графік, який визначає входи, виходи та необхідні процеси.
  • Gantt — спрощені діаграми, які забезпечують візуалізацію загального часу, необхідного для виконання завдання або процесу. Діаграми Ганта можуть показувати час/дату початку та завершення процесу, необхідні завдання та час виконання кожного з них.
  • Program Evaluation and Review Technique (PERT) diagrams — прагнуть розбити потоки бізнес-процесів на часові шкали шляхом оцінки найкоротшого, найдовшого та найімовірнішого часу для завершення кожного кроку в бізнес-процесі.

Зручні інструменти:

  • Draw.io
  • Lucidchart
  • Visual Paradigm
  • Vision
  • Bizagi
  • Enterprise Architect

Де вивчати:

  1. What is Unified Modeling Language | Lucidchart.
  2. Застосування UML 2.0 і шаблонів проєктування (Крег Ларман).
  3. Essential Business Process Modeling 1st Edition by Michael Havey.
  4. Process Modelling and Model Analysis by Ian Cameron.

Prototyping

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

Що потрібно вміти і знати:

  • створювати wireframes та mockups;
  • знання основ дизайну;
  • створення простих дизайнів;
  • покращувати UX;
  • вносити дрібні зміни в існуючий дизайн (щоб не відволікати дизайнера).

Зручні інструменти:

  • Figma
  • Balsamiq
  • Axure

Де вивчати:

  1. Figma UI Design Tutorial: Get Started in Just 24 Minutes! (2022).
  2. Bootstrap 4+ UI Kit | Figma Community.
  3. Selection controls — UI component series | by Taras Bakusevych | UX Collective.

Non-functional Requirements Classification

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

З основних НФВ виділяють такі:

  • Performance — продуктивність стосовно кількості ресурсів, що використовуються у зазначених умовах.
  • Scalability — ступінь розширення системи.
  • Portability — ступінь ефективності, з якою систему, продукт або компонент можна перенести з одного апаратного забезпечення, програмного забезпечення чи іншого робочого середовища, чи середовища використання в інше.
  • Compatibility — ступінь, до якого продукт, система або компонент може обмінюватися інформацією з іншими продуктами, системами або компонентами та/або виконувати свої необхідні функції, спільне використання того самого апаратного та програмного середовища.
  • Reliability — ступінь, до якого система, продукт або компонент виконує визначені функції за певних умов протягом визначеного періоду часу.
  • Availability — ступінь, до якого система, продукт або компонент є робочими та доступними, коли це необхідно для використання.
  • Maintainability — ступінь ефективності та ефективності, з якою продукт або система можуть бути модифіковані призначеними супроводжувачами.
  • Security — ступінь, до якого продукт або система захищає інформацію та дані, щоб особи або інші продукти або системи мали ступінь доступу до даних, який відповідає їх типам і рівням авторизації.
  • Usability — ступінь, до якого продукт або система можуть використовуватися певними користувачами для досягнення визначених цілей з ефективністю, ефективністю та задоволенням у визначеному контексті використання.

Testing

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

Що потрібно розуміти:

  • Функціональне тестування — тестування окремої частини функціональності системи.
  • Смоук-тестування — швидка перевірка того, що система в цілому працездатна після останніх змін.
  • Регресійне тестування — повний процес перевірки всієї системи, як правило, застосовується перед релізом продукту.
  • Test cases.
  • Manual testing.
  • Test scripts/Automated tests.
  • Acceptance testing.
  • Age cases.

Де вивчати:

  1. Rapid Testing by Robert Culbertso.
  2. The Art of Software Testing by Glenford J. Myers.

Read Technical Documentation

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

Види технічної документації та їх нюанси:

  1. API — спосіб спілкування між серверами (сервісами) у форматі запит-відповідь. Такі інтеграції можуть бути внутрішніми та зовнішніми. Доступ до інформації здійснюється через HTTP або JSON / XML, REST. Також бувають відкриті та закриті API, платні та безкоштовні API.
  2. 3rd party документація — різного роду інтеграції, модулі, плагіни, сервіси, SDK, бібліотеки, які необхідні для повноцінної роботи продукту. Рекомендація: стежити за release notes та versions своїх 3rd party сервісів, щоб бути в курсі оновлень.
  3. Документація щодо архітектури.

Де вивчати:

  1. Scripting in Postman.
  2. Опис вимог до інтеграції (частина 1). Файловий обмін.
  3. Опис вимог до інтеграції (частина 2). API.
  4. APIs For Dummies, 3rd IBM Limited Edition.
  5. RapidAPI Learn: API Development using fun challenges (with solutions!) and interactive examples.

Database and SQL

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

Потрібно розуміти, які є бази даних та як вони влаштовані, як писати туди запити, розуміти структури та принципи зберігання даних у БД, вміти самостійно отримати необхідні дані для перевірки гіпотези чи підготовки звіту.

З основного, що потрібно знати про різні БД:

  1. Реляційні (SQL) БД — всі дані зберігаються в строго описаних таблицях (назва колонок, тип даних, обсяг) і містять зв’язок між колонками за ключами та значеннями (індекси). Вони мають низький поріг входу. Такі бази даних схожі на Excel-таблиці. Використовують єдину мову запитів — SQL.
  2. Не реляційні (nonSQL) БД — такі БД не мають зв’язків (таблиць, відносин, id), дані зберігаються в іншому вигляді (без суворої структури), не мають єдиної мови запитів, мають велику швидкість обробки даних, легко масштабуються, немає транзакцій (запити потокові, якщо хоча б один із запитів не пройшов, запит скасовується).

Де вивчати:

  1. Fundamentals of Database Systems by Ramez Elmasri, Shamkant B. Navathe.
  2. SQL for Business Analysts.
  3. SQL Tutorial.
  4. SQLBolt — Learn SQL with simple, interactive exercises.

Data Visualization

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

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

В аутсорс-компаніях потрібно надавати чіткі звіти менеджменту всередині їхніх корпоративних структур, проджект- та акаунт-менеджерам.

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

Які типи візуалізації даних буде корисно знати:

  • точкові діаграми;
  • послідовності часових рядів;
  • діаграми полярних площ;
  • часові рамки;
  • лінійні графіки;
  • і більше.

Також потрібно вміти:

  • перетворювати необроблені дані у цифрові представлення;
  • розуміти, маніпулювати та витягувати інформацію з наборів даних;
  • використовувати інтелектуальні інструменти для створення звітів і дашбордів (Power BI, Qlik Sense, Tableau).

Де вивчати:

  1. Чому важливо наочно доносити інформацію. Візуалізація даних для бізнес-аналітика.

Microsoft Excel

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

Необов’язкові, але корисні техскіли

Мови програмування

Зазвичай, програмування не зустрічається часто у вимогах до вакансій БА. Проте для БА буде дуже корисно мати фундаментальне розуміння основних мов програмування, таких як Java, C++, Visual Basic, PHP, Python, та ООП.

Мови програмування, такі як R та Python, допомагають БА в роботі з великими об’ємами даних. R і Python містять кілька бібліотек і пакетів для обробки даних, маніпулювання даними, візуалізації даних і аналітики.

Знання бази програмування допоможе робити швидкий та якісний аналіз даних. Також складні проблеми можна вирішити шляхом написання ефективних кодів, а масивні дані можна аналізувати та візуалізувати з їх допомогою.

Де вивчати:

  1. CS50 Course.

Архітектура

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

Варто звернути увагу на наступне:

  • схема додатків: із чого складається проєкт, які елементи (сервіси) включає;
  • складові елементи (які сервіси, API, 3rd party);
  • детальний опис взаємозв’язків;
  • як читати схему додатка.

Де вивчати:

  1. 10 Common Software Architectural Patterns in a nutshell.
  2. IT Architecture For Dummies by Kalani Kirk Hausman, Susan L. Cook.
  3. Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series).
  4. Overview of Amazon Web Services — AWS Whitepaper.

Data Analytics

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

Аналітика може будуватись на основі вебтрафіку та на основі мобільного трафіку, на основі сторінок або подій (івентів).

Потрібно базово розуміти, як працюють різні тули для аналітики (Google Analytics, Mixpanel, Amplitude, Heap, Hotjar) та вміти з ними працювати, налаштовувати дашборди та репорти на основі івентів.

Висновок

Тож як покращити свої техзнання та навички:

  1. Вивчайте додаткові IT-скіли, в яких у вас недостатньо знань та досвіду. Є безліч курсів та матеріалів для цього — деякими з них я ділився вище.
  2. Практикуйте свої комунікаційні скіли — це дасть вам змогу обговорювати, запитувати та дізнаватись необхідну інформацію від технічних стейкхолдерів.
  3. Застосовуйте свої навички для пошуку та дослідження нових матеріалів та інформації.
  4. Переглядайте різноманітні матеріали щодо документації.
  5. Удосконалюйте та поглиблюйте свої знання в розробці ПО.

Підбиваючи підсумки, знання техскілів дасть вам, як БА наступні переваги:

  • додасть цінності як експерту в цілому;
  • підвищить ціну на ринку;
  • допоможе краще комунікувати з усіма стейкхолдерами;
  • дозволить пропонувати деякі рішення на льоту.

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

👍ПодобаєтьсяСподобалось25
До обраногоВ обраному17
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

Гарна стаття. Дякую. Я б ще трошки додав навичок:
— методи пріорітизації вимог (типа MoSCoW, Кано та інш.)
— критерії якості вимог (по BABOK, по IREB, по Вігерсу, INVEST)
— трасування вимог
— життевий цикл вимог
— інструменти керування відносинами зі стейкхолдерами (типу RACI матриці)
В інтеграції ще непогано було трошки розумітися на брокерах повідомлень (відрізняти Кафку від Реббіта))
Ну і окрім Конфлюєнс треба ще й Джиру знати (маст-хев майже скрізь)

Класне доповнення! Дякую!

Дякую за допис! Мені цікаво, як поєднуються обов’язки BA та Product Manager, коли є дві такі людини на проекті? Бо у вашій статті ви прямо описалі все так, що з менеджерів потрібно тільки BA працювати, бо він покриває майже все. Дякую

Це про те, коли з BA роблять UI/UX designer, QA або Dev TL... Відповідна і якість фази BA ;)
Дуже гарна стаття!

Вітаю Юрій. Добра стаття!
Багато з чим згоден, з чимось не згоден, ну а на дещо... просто маю іншу точку зору і мабуть хотів би просто розширено прокоментувати, можливо додати інший погляд.
Мабуть на один, навіть великий комментар — тут не вистачить. Можливо спробую якось окремо щось написати, якщо ви не проти легкої критики статті та розширення ваших поглядів через погляди інших:)
Не проти?
p.s.
Я дуже поважаю тих хто витрачає свій час та створює професійний контент, тоже дякую за статтю на БА тематику, мені здається вона буде корисна.
p.s.2.
Також пропоную законектитись в LI.

Great job! Thanks for detalizing steps and directions of BA skills improvements.

Thank you! Happy to help!

An excellent summary, thanks a lot for putting it together!

Great to hear it! Thanks for your feedback!

Чудовий допис, ба більше дуже об’ємний !
Але це в одночас і плюс і мінус
Такі статті повинні бути сепаровані на частини

Що було прям дуже добре — це посилання на джерела для вивчення, в одночас через величезний об’єм втрачені розділення на бізнес аналітика,продуктового аналітика і системного аналітика (хоч його часто і називают бізнес ) - юні голови можуть і свідомість втратити, бо ввіжатимуть це все за одну роль :)

Далі «Program Evaluation and Review Technique (PERT)» — це більше метод для роботи з випадковими величина, які як раз базуються на трьох опорних (коротший, середній/оптимальний, довший)

Щодо NFR, це все ж по-перше : Бізнес правила, атрибути якості, зовнішні інтерфейси та обмеження, а вже після інше

Залучення БА описані тільки з однієї сторони — я б іі назвав в загальному плані Agile залученням, та і там не все так прозоро, бо є іще PO та й APO (якщо це LeSS), а у класичному вигляді проєкту де замість Бєклогу є WBS — залучення БА трохи інше, а ще ж є залучення не проєктне а організаційне і.т.д

Висновок:
Стяття супер корисна і це не мала робота і гарна робота, в той же час стаття не для джуніорів та трейні, а для Middle+ та вище

Дякую за коментар!

Спочатку була думка розбити статтю на декілька частин, та в результаві все ж вирішив залишити все в одній.

Основна ідея — це показати різноманіття напрямків, які варто та корисно прокачувати для БА з технічної точки зору.

Це такий собі гайд, який можна використовувати для планування свого професійного розвитку

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