• Співбесіда на бізнес-аналітика рівня junior/middle: що потрібно знати

    Співбесіда на бізнес-аналітика рівня junior/middle: що потрібно знати

Співбесіда на бізнес-аналітика рівня junior/middle: що потрібно знати

Якщо ви хочете зайняти посаду junior ВА чи претендуєте на вищу позицію middle-спеціаліста — спершу на вас чекає співбесіда на бізнес-аналітика. Щоб успішно впоратися з цією задачею та отримати бажану роботу, вартує заздалегідь підготуватися до питань, які вам можуть поставити.

Співбесіда на бізнес-аналітика: типові запитання

1. Розкажіть про свій останній проект.

Щоб грамотно розповісти про свій останній проект, важливо зупинитися на наступних пунктах:

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

Розглянемо приблизні відповіді на ці запитання:

  • Додаток, над яким  я працював, був у мобільній сфері. Компанія була стартапом і розробляла додатки для завантаження та програвання музики.
  • Нашими користувачами були молоді люди віком від 18 до 35 років.
  • У стартап було залучено Х мільйонів інвестицій і він отримав Y мільйонів користувачів, а також таких великих партнерів, як MTV, Vodafone.
  • Розроблений додаток вирішував проблему доступу до контенту у фоновому режимі.
  • Він завантажував популярну музику, свіжі чарти та плейлисти, які користувачі могли слухати в офлайн-режимі. Також додаток вигідно відрізнявся від конкурентів своєю ціновою політикою та можливістю тижневої підписки.
  • Додаток працював на платформах iOS та Android, мав backend частину та мобільний frontend, веб-інтерфейс для здійснення оплат.

Від якості відповіді на перше запитання залежить те, в якому напрямку буде розвиватися співбесіда.

2. За якою методологією ви працювали? / Які методології знаєте? (за відсутності досвіду) 

Більшість організацій зараз працюють за гнучкою методологією (Agile). Також часто зустрічається каскадна методологія (Waterfall). Їх часто порівнюють.

Каскадна методологія передбачає, що розробка рухається етапами, і перехід на кожен етап виконується після завершення минулого. Наприклад, тільки після збору та аналізу всіх вимог починається розробка. Після розробки починається тестування.

Гнучка методологія (Scrum, Kanban, XP) передбачає, що для початку розробки не треба, щоб були сформовані всі вимоги, і не треба завершувати розробку для того, щоб почати тестування. Головне щоб у кінці ітерації (відрізка роботи, зазвичай 2 тижні) були виконані всі заплановані задачі. Але головна відмінність – акцент на цінності для користувача.

3. Які головні артефакти й основні ролі у вашій методології?

Розглянемо відповідь на це питання на прикладі Scrum.

Основні артефакти:

  • Product Backlog — це впорядкований та постійно оновлюваний список того, що необхідно для покращення продукту. Це єдине джерело роботи, яку виконує Scrum Team.
  • Sprint Backlog – це план, створений силами Developers для Developers. Це наочна та доступна в режимі реального часу картина роботи, яку Developers планують виконати в ході Sprint для досягнення Sprint Goal.
  • Increment – це конкретна сходинка до досягнення Product Goal. Кожен Increment є доповненням до всіх попередніх. Щоб надати цінність, Increment має бути придатним для використання.

Далі перейдемо до того, які ролі є в Scrum.

Основна одиниця Scrum – невелика команда людей, Scrum Team. Scrum Team складається з одного Scrum Master, одного Product Owner та Developers. Усередині Scrum Team немає підкоманд та ієрархій. Це згуртоване об’єднання професіоналів, сфокусованих на одній меті – Product Goal.

  1. Product Owner несе відповідальність за максимізацію цінності продукту, який отримується в результаті роботи Scrum Team.
  2. Scrum Master відповідає за ефективність Scrum Team. Він робить це, допомагаючи Scrum Team покращувати свої методи роботи у рамках фреймворку Scrum.
  3. Developers – це люди у Scrum Team, які мають необхідні навички для створення будь-якого аспекту готового до використання Increment у кожному Sprint.

Якщо вам потрібно поглибитися у Scrum, рекомендуємо до прочитання Scrum Guide.

4. Якими способами запису/ фіксації вимог ви користуєтеся?

Якщо досвіду роботи у вас немає, достатньо ці способи просто перерахувати.

4 найпоширеніших документи, які містять специфікацію вимог:

  • software requirements specification – специфікація вимог до ПЗ;
  • functional requirements specification – функціональна специфікація;
  • product requirements specification – специфікація вимог до продукту;
  • vision and scope document – документ про бачення продукту та об’єм робіт.

Фіксувати вимоги можна у вигляді UML-діаграм: activity, use case, sequence, state machine, class, component, object diagrams тощо.

Наступний варіант фіксації вимог:

  • Use Cases (прецедент використання) – це послідовність дій користувача і відповідних реакцій системи на них.
  • UX Mockups (функціональні нариси інтерфейсу) – високорівневе зображення того, як буде виглядати користувацький інтерфейс. Цього зображення має бути достатньо для того, щоб розробники могли зробити оцінку необхідних трудозатрат, а замовник міг зрозуміти, як буде розташована інформація на екрані.

5. Намалюйте sequence diagram.

Часто БА просять намалювати діаграму (більше про це можна прочитати тут). Розглянемо це завдання на прикладі sequence diagram. Нижче наведено зображення процесу двофакторної аутентифікації користувачів.

6. Складіть use case.

На тому самому прикладі двофакторної аутентифікації можна скласти наступний сценарій:

  1. Користувач відкриває додаток.
  2. Додаток пропонує ввести логін та пароль.
  3. Користувач вводить дані.
  4. Система ідентифікує користувача, ініціює надсилання ОТАС (one-time authorization code) і відображає поле вводу ОТАС.
  5. Користувач отримує ОТАС і вводить його в поле.
  6. Система валідує ОТАС і аутентифікує користувача.

Також популярним практичним завданням на співбесідах є створення use case.

7. Що таке вимоги? Які є типи вимог?

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

Класифікація вимог (за рівнями):

  • Бізнес вимоги (business requirements): опис мети, очікуваних результатів та цілей бізнесу, що дають обґрунтування ініціації змін.
  • Вимоги стейкхолдерів (stakeholders requirements): опис потреб зацікавлених сторін, що дозволять досягати бізнес-вимог.
  • Вимоги до рішення (solution requirements): якості та властивості продукту, якими він повинен володіти, щоб відповідати вимогам зацікавлених сторін.
  • Транзитні вимоги (transition requirements): дії, які необхідно виконати для переходу з поточного стану в майбутній. Ці вимоги виконуються один раз.

8. Назвіть характеристики вимог. Що таке Definition of Ready, навіщо потрібен DoR?

Хороші вимоги повинні мати наступні характеристики:

  • повнота
  • послідовність / несуперечність
  • атомарність
  • простежуваність
  • актуальність
  • недвозначність
  • обов’язковість
  • можуть бути перевірені.

До першого пункту також поставити питання щодо атрибутів повноти вимог, оскільки це найважливіший та найважчий у виконанні критерій. 

А прочитати про DoR ви можете у нашій іншій статті «DoD, DoR та AC».

9. Які ви знаєте методи збору вимог?

Це питання ставлять на співбесідах на обидві посади: і junior, і middle BA. Методів збору вимог існує багато, але зазвичай досить знати основні:

  • інтерв’ю – особисте спілкування з користувачем (Interview users)
  • опитування, анкетування (Questionnaires or Surveys)
  • мозговий штурм (Brainstorming)
  • спостереження (User Observation)
  • аналіз нормативної документації (Document Analysis)
  • порівняльний аналіз і аналіз ринку (Benchmarking and Market Analysis)
  • аналіз статистики використання (Usage Analysis)
  • reverse engineering – використовується за необхідності переписати, за відсутності документації або за умови її застарілості. Тобто можливі випадки коли зрозуміти, як це працює, можливо лише за допомогою даної техніки.

10. Як ви будете управляти змінами?

Це питання може звучати по-різному. Наприклад: “Що ви будете робити, якщо в середині спринту прийде замовник і скаже, що хоче замінити/змінити якісь історії?”, “Що якщо під час демо замовник каже, що фіча виглядає/працює не так, як він очікував, і просить переробити її?”

І таких варіантів можливо десятки. А варіантів відповідей і того більше – десятки тисяч. Тому у своїй відповіді головне розкрити такі моменти:

  • Поясніть своє бачення роботи в команді.
  • Продемонструйте послідовність підходів.

Приблизний варіант відповіді може бути таким:

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

Час перейти до питань, які дають уявлення про те, чи дійсно у вас є деякий заявлений досвід.

11. Як організований ваш проект в Jira? 

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

12. Як ви управляєте залежностями між різними проектами та різними компонентами системи? 

Наприклад, у вас є розподілені backend-, mobile- та web-команди. Над певними завданнями вони повинні працювати спільно — має бути спільне напрацювання рішення. В процесі розробки ці команди мають вчасно інформувати один одного про прогрес, зміни та проблеми. Але досить часто це погано координується і тому БА змушений проявляти ініціативу і брати на себе додаткові організаційні обов’язки.

Обов’язково наведіть кілька прикладів, як ви допомогли розробникам знайти спільну мову або допомогли організувати продуктивну співпрацю між командами.

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

Прокачати свої навички бізнес-аналітика та підготуватися до співбесід ви зможете на нашому курсі Business Analysis Intensive Online.

Узнайте, что нового!
Рекомендуем не пропускать наш ежемесячный дайджест )