Співбесіда бізнес-аналітика перевіряє, як ви збираєте вимоги, працюєте з незгодними стейкхолдерами і перетворюєте невизначеність на те, що команда зможе побудувати. Нижче — найчастіші питання з еталонними відповідями.
До кожного питання — еталонна відповідь, з якою можна порівняти свою.
Функціональні вимоги описують, що система має робити — користувач може скинути пароль, рахунок можна вивантажити. Нефункціональні описують, наскільки добре вона це робить: час відгуку, кількість одночасних користувачів, доступність, безпеку, доступність для людей з обмеженнями. Саме нефункціональні вимоги команди забувають записати, і саме вони найчастіше змушують переписувати архітектуру, коли виявляються пізно.
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-команд замінюють усі три продуктовим беклогом і легкими допоміжними документами, лишаючи формальні специфікації лише там, де цього вимагає комплаєнс.
Найнадійніший сигнал — питання на рефайнменті: мовчання частіше означає, що команда не вникла, а не що все зрозуміло. Практичні прийоми — попросити розробника переказати історію своїми словами, розібрати критерії приймання з QA до початку розробки і провести сесію example mapping або показати прототип, щоб витягнути приховані припущення. Усе знайдене на цьому етапі незрівнянно дешевше, ніж після реалізації.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Business Analyst →