Співбесіда бізнес-аналітика перевіряє, як ви збираєте вимоги, працюєте з незгодними стейкхолдерами і перетворюєте невизначеність на те, що команда зможе побудувати. Нижче — найчастіші питання з еталонними відповідями. Junior: базова теорія, визначення та прості практичні кейси.
Функціональні вимоги описують, що система має робити — користувач може скинути пароль, рахунок можна вивантажити. Нефункціональні описують, наскільки добре вона це робить: час відгуку, кількість одночасних користувачів, доступність, безпеку, доступність для людей з обмеженнями. Саме нефункціональні вимоги команди забувають записати, і саме вони найчастіше змушують переписувати архітектуру, коли виявляються пізно.
User story будується за шаблоном «як роль, я хочу дію, щоб отримати вигоду» — остання частина найважливіша, бо фіксує «навіщо» і дозволяє команді запропонувати краще рішення. Критерії приймання визначають готовність у перевірюваних термінах, часто у форматі Given-When-Then, покриваючи основний сценарій, крайні випадки та помилки. Історія без критеріїв — це запрошення трьом людям зрозуміти її трьома різними способами.
Інтервʼю заглиблюються в позицію однієї людини, воркшопи рано виявляють конфлікти між стейкхолдерами, спостереження показує, що люди роблять насправді, а не що кажуть, аналіз документів фіксує наявні правила, а прототипи дають конкретний зворотний звʼязок, якого абстрактне обговорення ніколи не дасть. Вибір залежить від того, наскільки зрозуміла предметна область — чим менше ясності, тим більше опори на спостереження та прототипи.
Треба зробити конфлікт явним, а не тихо обрати одну сторону: зафіксувати обидві позиції, аргументи за кожною і компроміс. Потім звести стейкхолдерів разом з даними — цифрами використання, вартістю, ризиками — і отримати рішення від того, хто відповідає за результат. Помилка в тому, щоб розвʼязати конфлікт кулуарно: сторона, що програла, дізнається про це на прийманні, і робота йде у відмову.
MoSCoW розкладає вимоги на Must have, Should have, Could have і Won't have цього разу. Must — це те, без чого реліз не має цінності; Won't найкорисніша категорія, бо робить винятки явними і зупиняє тихе розповзання скоупу. Поширена дисципліна — тримати Must приблизно в шістдесяти відсотках від ємності команди, щоб лишилося місце під те, що неминуче спливе по ходу.
Діаграма use case показує, які актори взаємодіють з якими можливостями системи — вона добра для розмов про скоуп з бізнесом. Sequence-діаграма показує впорядковані повідомлення між компонентами в часі й адресована розробникам, які проєктують взаємодію. Activity і BPMN стоять між ними для опису процесу, а діаграма станів — правильний інструмент, коли у сутності є життєвий цикл, наприклад у замовлення чи заявки.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Junior Business Analyst →