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