Продовження теми запитань, що можуть траплятися на співбесідах на позицію бізнес-аналітика різних рівнів.
Найпопулярніші питання на співбесіді з молодшим бізнес-аналітиком
Запитання 21 — Яким найкращим практикам варто слідувати при написанні варіанта використання (use case)?
Відповідь. Деякі з найкращих практик для написання сценарію використання полягають у наступному:
- Щоб стати допустимим варіантом використання, він має повернути певну цінність суб’єкту чи зацікавленій особі.
- Функціональні та нефункціональні вимоги мають бути відповідним чином відображені у сценарії використання.
- Варіант використання повинен мати один або кілька альтернативних потоків поряд з основним потоком.
- Варіант використання повинен описувати лише те, що робить система, а не те, як це робиться, що означає, що він не описуватиме дизайн. З погляду актора, це буде чорна скринька.
Запитання 22 – У чому різниця між exception flow (потоком винятків) та alternate flow (альтернативним потоком)?
Відповідь: Альтернативний потік – це альтернативні дії, які можуть виконуватися окремо для основного потоку та можуть розглядатися як додатковий потік.
Потік винятків — це шлях, пройдений у разі виключення чи помилки.
Запитання 23 — Як ви вважаєте, бізнес-аналітик повинен брати участь у тестуванні рішення?
Відповідь: Так. Тому, що бізнес-аналітик дуже добре розуміє загальні системні вимоги та проблеми, пов’язані з ними. Отже, він може відіграти важливу роль на етапі тестування, щоб запустити його належним чином та дозволити будь-який системний запит.
Запитання 24 – Що означає INVEST?
Відповідь: INVEST — це абревіатура, за допомогою якої менеджер по продукту або розробник може створювати якісні історії користувача. INVEST розшифровується як “Незалежний, Договірний, Цінний, Підлягає оцінці, Відповідний розмір, Що Піддається перевірці”.
- Independent (Незалежний)
- Negotiable (Договірний)
- Valuable (Цінний)
- Estimable (Зразковий)
- Sized Appropriately (Відповідний розмір)
- Testable (Перевірений)
I — Незалежність: користувацька історія (user story) повинна бути автономною, якщо це взагалі можливо, щоб уникнути залежності від інших історій користувача. Оскільки однією з характеристик гнучких методологій є здатність виявляти гнучкість і змінювати пріоритети в тому, що важливо, незалежні користувацькі історії забезпечують гнучкість при плануванні ітерацій. Якщо ви виявите, що ваші історії користувача залежать одна від одної, ви можете об’єднати разом невеликі користувацькі історії, які залежать одна від одної. Так само ви можете розділити більші залежні користувацькі історії на дрібніші історії, так що одна з нових дрібніших історій буде містити і ізолювати частину більших історій, що перекриваються.
N — договірна: історії користувачів можна змінити або переписати до моменту кодування. Це додатково підтримує гнучкість, пов’язану із гнучкими методологіями. Оскільки вимоги часто розвиваються або підвищуються і втрачають пріоритет, користувацькі історії повинні мати можливість адаптуватися до вимог, що змінюються.
V – Цінний: історія користувача є метою кінцевого користувача або покупця і повинна надавати функціональні можливості, які вважаються цінними. Це означає, що особливості технічного дизайну – це не те, що ви документували б у вигляді історій користувача. Однак у деяких технічних вимогах є компонент, який є цінністю для користувача. Користувач може очікувати, що сторінки завантажаться протягом 2 секунд. У історії користувача буде зазначено, що час завантаження сторінки становить 2 секунди, в той час як специфіка фізичної реалізації цього буде опущена.
E – Оцінка: ви завжди повинні мати можливість оцінити розмір користувацької історії. Іноді розробники не мають досвіду, необхідного для визначення конкретної ситуації або необхідного для користувацької історії. У цьому випадку користувацьку історію можна розділити на дві окремі історії користувача. Перша – це «спайк», при якому розробники проводять швидке дослідження, щоб визначити здійсненність чогось або отримати краще уявлення про те, скільки часу може знадобитися для реалізації конкретної функції. Спайк завжди обмежений часовими рамками, тобто обмежений наперед визначеним проміжком часу. Користувацька історія «спайку» може бути названа «Дослідження (щось) для визначення…», тоді як друга користувацька історія — це те, де фактично буде реалізована функціональність. Ці дві користувацькі історії слід запланувати на дві окремі ітерації, щоб можна було завершити спайк і оцінити здійсненність другої історії користувача до початку кодування. Це дає команді відреагувати час, якщо в результаті спайку виникнуть проблеми.
S – Відповідний розмір: історії користувачів не повинні бути надто великими або надто маленькими. То як вирішити, який розмір правильний? По-перше, будь-яка історія користувача, яку розробник не може завершити за одну ітерацію (або пару розробників, якщо використовується парне програмування), занадто велика. Користувацька історія має бути поділена на дві або кілька дрібніших історій. Так само немає необхідності робити користувацькі історії занадто деталізованими тільки заради декомпозиції функцій. Якщо функції добре групуються і доповнюють одна одну, тоді має сенс створити єдину користувацьку історію. Наприклад: «Як шукач роботи я хочу мати можливість додавати, видаляти та редагувати професійні навички в моєму електронному резюме, щоб я міг вести точний список моїх навичок». Немає причин розділяти “додати, видалити, редагувати”.
T — Тестований: користувацькі історії повинні бути тестованими, щоб гарантувати, що розробка завершена і була зроблена правильно. Отже, коли користувацькі історії не можна тестувати? Часто, якщо аналітик є неуважним, нефункціональні вимоги написані в неперевіреній манері. Розглянемо приклад “сторінки завжди повинні завантажуватися швидко”. У цьому твердженні є два компоненти, що не перевіряються: «Завжди» і «швидко». Можна перевірити твердження, що «сторінки повинні завантажуватись протягом 1,5 секунд у 97% випадків».
Буде корисно також прочитати: User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги
Запитання 24 – Що таке аналіз Парето?
Відповідь: Аналіз Парето використовує принцип Парето, що відомий також як “Правило 80/20”, який був введений італійським екномістом Вільфредо Парето, у його книзі 1896 року “Політична економіка”
Принцип Парето стверджує, що 80 відсотків вигоди припадає на 20 відсотків роботи. Чи, навпаки, 80 відсотків проблем можна віднести до 20% причин. Аналіз Парето визначає проблемні області чи задачі, що принесуть найбільшу віддачу. Інструмент має кілька переваг, в тому числі:
- Виявлення і приорітизація проблем та задач
- Допомога людям більш ефективно організовувати власні робочі навантаження
- Підвищення продуктивності
- Підвищення рентабельності.
Запитання 24 – Що таке BPMN? Назвіть основні елементи BPMN?
Відповідь: BPMN – це модель і нотація бізнес-процесу. Це графічне представлення бізнес-процесів.
Business Process Modeling Notation (BPMN) – Нотація моделювання бізнес-процесів – це метод, який використовується для ілюстрації бізнес-процесів. Інформація міститься в діаграмі, яка нагадує блок-схему, тому її легше зрозуміти та використовувати.
BPMN це метод блок-схеми, який моделює кроки запланованого бізнес-процесу від початку до кінця. Метод наочно відображає докладну послідовність бізнес-операцій та інформаційних потоків, необхідних для завершення процесу.
BPMN містить чотири типи елементів для діаграм бізнес-процесів:
- Flow objects: events, activity, gateways
- Connecting objects: sequence flow, message flow, association
- Swimlanes: pool or lane
- Artifacts: data object, group, annotation
BPMN — один із найпоширеніших методів моделювання бізнес-процесів, у якому використовуються стандартизовані символи, щоб зробити карти процесів більш зрозумілими для всіх зацікавлених сторін: керівництва, співробітників та консультантів. Він пропонує стандартні позначення, зрозумілі кожному.
Рекомендуємо також: Вебінар “Артефакти бізнес аналітика: темплейти та приклади”
Запитання 27 – Що таке Kano analysis (Кано-аналіз)?
Відповідь: Kano Analysis — це підхід до пріоритету функцій у дорожній карті продукту на основі ступеня, в якому вони можуть задовольнити клієнтів. Продуктові групи можуть зважити функціональність, що приносить високий рівень задоволеності, з витратами на її реалізацію, щоб визначити, чи додавання її до дорожньої карти є стратегічно правильним рішенням.
Модель Кано є однією з багатьох систем пріоритету, розроблених, щоб допомогти продуктовим командам визначати пріоритети ініціатив.
Як працює модель Кано?
За допомогою моделі функції та атрибути продукту або послуги поділяються на п’ять категорій:
- Порогові атрибути (основні відомості) (обов’язкові функції) — це функції, які клієнти очікують від послуги або продукту, це не функції, які обов’язково вражають клієнтів, але можуть викликати невдоволення, якщо вони відсутні.
- Атрибути продуктивності (задовольняючі) (одномірні функції) — ці функції не входять до угоди, та заодно підвищують рівень задоволення.
- Атрибути збудження (захоплення) (привабливі риси) – це найважливіші характеристики, які збільшують перевагу продукту/послуги перед конкурентами. Це атрибут, на якому варто зосередитись, оскільки він поставить вас на п’єдестал серед ваших конкурентів.
- Байдужі атрибути – це особливості, які клієнти не можуть вирішити, хороші вони чи погані.
- Зворотні атрибути – ці функції можуть бути високої якості або продуктивності, але не підвищувати рівень задоволеності.
Щоб оцінити функцію, споживачам ставлять два питання:
- Як ви почуваєтеся, якщо у вас є ця функція? (Функціональне питання)
- Як ви почуваєтеся, якщо у вас немає цієї функції? (Дисфункціональне питання)
На обидва питання подано відповіді за п’ятибальною шкалою з єдиним кодом
Якщо цікаво, то перегляньте: Питання на іспит CBAP/CCBA. Розбір прикладу
Запитання 28 – Які типи actors ви знаєте для діаграми use case?
Відповідь: у сценарії використання можуть бути зображені переважно актори двох типів:
- Головні дійові особи – починається процес
- Вторинні актори – допомагають першому актору
Більш того, ми можемо розділити акторів на чотири типи:
- Людина
- система
- апаратні засоби
- таймер
Запитання 29 — З якими типами розривів може зіткнутися бізнес-аналітик під час GAP-аналізу?
Відповідь: в основному є чотири типи розривів.
- Розрив у продуктивності — різниця між очікуваною та фактичною продуктивністю
- Продукт/Ринок Gap – розрив між бюджетом продажів та фактичними продажами називають як продукт/ніша на ринку
- Profit Gap — Різниця між цільовим та фактичним прибутком компанії.
- Розрив у робочій силі — розрив між необхідною кількістю та якістю робочої сили та фактичною силою в організації
Питання 30 – Що таке Benchmarking (Бенчмаркінг)?
Відповідь: Бенчмаркінг – це вимір ефективності організації, яка конкурує у галузі. У цьому процесі компанія може вимірювати свою політику, результати діяльності, правила та інші заходи.
Наступна частина – 50 питань з співбесіди для бізнес-аналітиків (Частина 4)