50 питань з співбесіди для бізнес-аналітиків (Частина 1)

Вступ

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

Як правило, на співбесіді часу на роздуми вкрай мало, тому важливо заздалегідь підготуватися за всіма можливими напрямками діяльності бізнес-аналітика, щоб не впасти обличчям у бруд!

Рівень та складність питань на співбесіді з бізнес-аналітиком варіюється в залежності від посади, на яку ви претендуєте, а також від посади конкретної компанії. Прочитайте питання та відповіді з різних рівнів складності. Якщо у вас виникнуть питання щодо матеріалів — залиште коментар до статті.

Ми зібрали «50 питань з інтерв’ю для бізнес-аналітиків» – це найбільш популярні питання та відповіді для проходження співбесіди на позицію бізнес-аналітика.

Питання на співбесіді з провідними бізнес-аналітиками підпадають під загальну категорію і можуть бути поставлені як частина питань на співбесіді з бізнес-аналітиками для будь-якого рівня кар’єри.

Питання 1: Хто такий бізнес-аналітик?

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

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

Основне завдання бізнес-аналітика у широкому сенсі: вивчити поточний контекст бізнесу (зовнішнє бізнес-середовище, внутрішні бізнес-процеси), зібрати потреби від зацікавлених сторін, описати на основі потреб вимоги та обґрунтувати можливі рішення/зміни, які необхідні для бізнесу.

Питання 2 — Назвіть типи документів, які використовує бізнес-аналітик у своїй роботі?

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

Project vision document (Документ «Бачення та межі проекту»)
Use cases (Сценарії використання, Варіанти використання або у народі Юзкейси)
Requirement Management Plan (План управління вимогами)
User stories (Історії користувача)
Requirement Traceability Matrix (RTM) — Матриця відстеження вимог
Business Requirement Document (Бізнес-вимоги)
System Requirement Specification (SRS) – Специфікація вимог програмного забезпечення / System Requirement Document (SRD) – Системні вимоги
Test case (Тестування або Тест-кейс)
Functional Requirement Specification (FRS) – Специфікація функціональних вимог / Functional Specification Document (FSD) – Документ з функціональними вимогами

Запитання 3 — Що таке SRS та які ключові елементи SRS ви знаєте?

Відповідь: Специфікація системних вимог (SRS) або Специфікація вимог до програмного забезпечення – це документ або набір документів, які описують функції системи або програмної програми. Документ включає безліч елементів, які визначають передбачувану функціональність, необхідну для зацікавлених сторін і замовника для задоволення кінцевих користувачів.

На додаток до цього, SRS надає загальне уявлення про Систему/Рішення та її поведінку, основні підтримувані бізнес-процеси, припущення та ключові параметри продуктивності системи.

Ключові елементи SRS:

• Обсяг робіт
• Функціональні вимоги
• Нефункціональні вимоги
• Залежності
• Модель даних
• Припущення
• Обмеження
• Критерії приймання

Питання 4 – Що таке вимога?

Відповідь. Вимога – описує, що потрібно зробити для досягнення певних бізнес-цілей. Це вхідні дані для різних етапів SDLC (життєвий цикл програмного забезпечення). Вимоги – це основа проекту, які перед реалізацією мають бути затверджені зацікавленими сторонами та бізнес-користувачами. Крім того, кожна вимога має бути належним чином задокументована для використання у майбутньому.

Вимога є придатним для використання описом потреби бізнес-користувача/заінтересованої сторони. У центрі уваги є питання: яку користь отримає бізнес-користувач у результаті виконання/реалізації вимоги. По суті, вимогою може бути як одна пропозиція, так і цілий документ (або набір документів) — все залежить від обставин і масштабності проекту.

Також вимоги поділяються на різні типи, про них добре написано у книзі Аналіз вимог щодо Вігерсу (2004).

• Бізнес-вимога: Подання цілей, завдань та результатів, що пояснюють навіщо було ініційовано зміну та як оцінюватиметься успіх. Бізнес-вимога – це не те, що має виконувати система. Це те, що бізнесу потрібно робити чи мати, щоб продовжувати зростати чи зберегти компанію.
• Функціональні вимоги – це особливості продукту або функції, які розробники повинні реалізувати, щоб користувачі могли виконувати свої завдання. Тому важливо прояснити їх як команди розробників, так зацікавлених сторін. Як правило, функціональні вимоги описують поведінку системи у певних умовах.
  – Система надсилає запит схвалення після того, як користувач вводить особисту інформацію.
  – Система надсилає електронного листа з підтвердженням створення нового облікового запису.
• Нефункціональні вимоги — це вимоги, які пов’язані з функціональністю системи, вони визначають, як має працювати. Ось кілька прикладів:
  – Сторінки сайту повинні завантажуватись за 3 секунди за загальної кількості одночасних користувачів < 5 тисяч.
  – Система повинна підтримувати 20 мільйонів користувачів без зниження продуктивності.

 

До теми: Як проходить день бізнес-аналітика

Питання 5 – Що таке Use Case (Варіант використання)

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

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

Питання 6 – Які кроки потрібно виконати, щоб розробити Use Case (варіант використання)

Відповідь: Етапи розробки сценаріїв використання:

• Визначте користувачів системи
• Створіть окремий профіль користувача на кожну категорію користувача. Це включає всі ролі, які можуть грати користувачі і які мають відношення до системи.
• Визначте основні цілі, пов’язані з кожною роллю. Також опишіть ролі.
• Далі потрібно створити варіант використання для кожної мети, пов’язаної із шаблоном варіанта використання. Це також включає підтримання одного й того ж рівня абстракції для всього варіанта використання. Кроки варіанти використання вищого рівня вважаються цілями для нижчого рівня.
• Структурування варіантів використання
• Перегляд та перевірка користувачів

Питання 7 — Що таке Scope creep (розростання чи «розповзання» меж проекту) та як його уникнути?

Відповідь. У найпростішій формі Scope creep – це коли вимоги, цілі чи бачення проекту змінюються понад те, що було спочатку узгоджено. Коли це відбувається, проект перестає бути чітко визначеним, а межі відповідальності – і, зрештою, дати завершення проекту – стають нечіткими.

Розростання меж проекту або розростання вимог — це термін, який відноситься до неконтрольованих змін або відхилень в обсязі проекту в межах одного діапазону ресурсів, наприклад, в рамках одного і того ж графіка робіт і бюджету проекту. Це показник поганого управління проектом та серйозного ризику для проекту. Деякі з можливих причин scope creep:

• Погана комунікація між зацікавленими сторонами проекту
• Неправильна документація вимог проекту

Scope creep можна уникнути за рахунок:

• Вивчіть цілі свого проекту із самого початку
• Чітка та «прозора» документація про межі проекту
• Правильно збудований процес управління змінами, яким слідують усі учасники проекту та зацікавлені сторони
• Використовуйте програмне забезпечення для управління проектами, щоб тримати всіх у курсі
• Попереднє повідомлення про наслідки змін для пов’язаних сторін
• Належна документація за новими вимогами у project log
• Захистіть свою команду від “позолоти”: утримайтеся від додавання extra features до існуючих функцій
• Налаштуйте правильний канал комунікації між зацікавленими сторонами та вашою командою

Це цікаво: Інтерв’ю бізнес-аналітика – погляд з обох сторін

Питання 8 Що таке BRD? Чим він відрізняється від SRS?

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

Відповідно до BABOK 3: Business requirements (Бізнес-вимоги) — Опис цілей, завдань та результатів, які розкривають інформацію про те, навіщо була ініційована зміна та як оцінюватимуться результати проекту.

Різниця між BRD та SRS полягає в наступному:

BRD	SRS
BRD – це скорочення від Business Requirement Document.	SRS — це скорочення, яке використовується для визначення вимог до програмного забезпечення.
BRD широко відомий як документ специфікації бізнес-вимог.	SRS також називається Специфікацією вимог до продукту та Специфікацією системних вимог.
Він підтримується Business Analyst.	Він підтримується бізнес-аналітиком чи системним аналітиком.
Зосереджений на бізнес-вимогах та вимогах зацікавлених сторін.	Зосереджений на функціональних та нефункціональних вимогах.
Використовується на етапі ініціації.	Використовується на етапі планування.
BRD використовується управлінськими командами вищої та середньої ланки.	SRS використовується менеджерами проектів, технічними керівниками та експертами в предметній галузі.

Питання 9 – Що таке Gap Analysis (аналіз розривів)?

Відповідь: Gap Analysis може застосовуватись для різних цілей.

Розглянемо два найбільш релевантні визначення для бізнес-аналітика. Один належить до розробки програмного забезпечення, інший до розробки стратегії/плану розвитку компанії.

Gap Analysis (аналіз розривів) – це метод аналізу прогалин між функціями існуючої системи та цільовї системи. Розрив (або пробіл) означає обсяг завдання або зміну, яка може знадобитися для отримання бажаного результату. Це порівняння рівня продуктивності між існуючими та пропонованими функціями.

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

Запитання 10 – Що таке приоритизація вимог? Які методи використовуються для встановлення пріоритетів у вимог?

Відповідь: Пріоритизація вимог – це процес розподілу вимог на основі терміновості для бізнесу в залежності від різних параметрів: фази проекту, графік робіт, вартість тощо.

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

• MoSCoW Technique — метод пріоритезації, який допомагає зрозуміти та керувати пріоритетами. Літери означають:
  • Must Have
  • Should Have
  • Could Have
  • Won’t Have this time
• 100-dollar method — Один із способів зробити розстановку пріоритетів більш відчутною — уявити її в термінах реального ресурсу: грошей. Дайте команді з розміщення пріоритетів 100 уявних доларів для роботи. Члени команди виділяють ці долари на купівлю елементів, які вони хотіли б реалізувати, з набору вимог кандидатів. Виділення більшої кількості доларів призводить до більшого значення пріоритетніших вимог.
• Kano Analysis — це підхід до пріоритету функцій у списку вимог на основі ступеня, в якому вони можуть задовольнити клієнтів.
• Матриця рішень Ейзенхауера — Що менше число, то вище пріоритет розділу.

• Timeboxing / Budgeting – використовується, коли є фіксовані терміни / бюджети для досягнення віх проекту. Timeboxing використовується в проектах, обмежених крайніми термінами, де реалізація проекту так само важлива, як і проект, який виконується вчасно або розробляється в рамках бюджету. Цей метод заснований на передумові, що важливіше мати хоча б основні функції продукту та випускати продукт вчасно, ніж мати всі функції та запускати продукт пізніше. Є дві точки оцінки — нормальні зусилля із завершення та зусилля щодо безпечного завершення. Нормальні зусилля по завершенню – це щасливий сценарій розробки вимог, тоді як зусилля щодо безпечного завершення – це оцінка, що ґрунтується на найгіршому сценарії.

BABOK 3.0 пропонує 8 факторів, що впливають на пріоритизацію вимог:

• Вигода – це перевага, яку бізнес отримує в результаті виконання вимог. Отримана вигода може відноситися до функціональності, якості або стратегічних/бізнес-цілей.
• Штраф – це наслідок невиконання вимоги. Це може стосуватися отримання штрафу, втрати частки ринку, неотримання додаткового прибутку, незадоволеності споживача чи зниження зручності використання товару.
• Вартість – це зусилля та ресурси, необхідні для реалізації вимоги. Ресурс може відноситися до фінансів, людських ресурсів або навіть технологій.
• Ризик — це можливість того, що вимога може не принести очікуваної цінності. Це може бути пов’язано з різними причинами, починаючи від складності розуміння вимоги і закінчуючи його реалізацією.
• Залежності – це відносини між вимогами. Таким чином, вимога вимагатиме виконання іншої вимоги для її реалізації.
• Чутливість до часу — усе йде з терміном придатності. Необхідно вказати, коли закінчується термін дії вимоги, або також, якщо вимога має сезонний характер.
• Стабільність це відноситься до ймовірності того, що вимога залишиться статичним.
• Відповідність нормативним вимогам / політикам – ті вимоги, які потрібно виконати, щоб відповідати нормативним вимогам.

Продовження:

50 питань з співбесіди для бізнес-аналітиків (Частина 2)

50 питань з співбесіди для бізнес-аналітиків (Частина 3)

50 питань з співбесіди для бізнес-аналітиків (Частина 4)

Переклад оригіналу здійснено 1 червня 2022 року