Middle Business Analyst — Питання на співбесіді бізнес аналітика

Як пріоритизувати, коли кожен каже, що його вимога критична?

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

Що робити з вимогою, яка змінилася посеред розробки?

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

Що таке матриця трасовності і коли її варто вести?

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

Як моделювати процес і що це насправді дає?

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

Чим валідація вимог відрізняється від верифікації?

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

Як писати вимоги до інтеграції із зовнішньою системою?

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