Собеседование на бизнес-аналитика: 40 вопросов с ответами 2026
Готовимся к собеседованию на бизнес-аналитика: реальные вопросы, разборы ответов, кейсы и советы от практиков.
Собеседование на бизнес-аналитика: 40 вопросов с разбором и советы по подготовке
Собеседование на позицию бизнес-аналитика — не экзамен по теории. Интервьюеры проверяют, как вы думаете, умеете ли работать с неопределённостью и можете ли объяснить сложное простым языком. Разбираем реальные вопросы и как на них отвечать.
---
Структура типичного собеседования
Большинство интервью на позицию БА состоит из трёх частей:
- Теоретические вопросы — проверка базовых знаний о требованиях, методологиях, инструментах
- Практические кейсы — задача, которую нужно решить в режиме реального времени
- Поведенческие вопросы (STAR) — как вы справлялись с реальными ситуациями
В крупных компаниях (Сбер, Яндекс, Ozon) собеседований несколько: скрининг с HR, техническое с командой, финальное с руководителем.
---
Теоретические вопросы (и как на них отвечать)
Требования
Q: Что такое функциональные и нефункциональные требования? Приведите пример.
Функциональные — что система должна делать. Например: «Пользователь должен иметь возможность восстановить пароль через email». Нефункциональные — как система должна это делать: производительность, безопасность, доступность. Например: «Страница восстановления пароля должна загружаться не дольше 2 секунд».
Q: Как вы собираете требования, если заказчик не знает, чего хочет?
Начинаю с проблемы, а не с решения. Задаю вопросы: «Что сейчас происходит?», «Что не устраивает?», «Как вы поймёте, что проблема решена?». Помогает техника «5 почему» — чтобы добраться до корневой причины. Показываю прототипы и примеры — у людей появляются мысли, когда они видят конкретное.
Q: Чем Use Case отличается от User Story?
Use Case — это сценарий взаимодействия пользователя с системой, описывает поведение подробно: акторы, предусловия, основной поток, альтернативные потоки. User Story — короткое описание потребности пользователя в формате «Как [роль], я хочу [действие], чтобы [цель]». User Story — это инструмент Agile, Use Case — более формальный, часто используется в Waterfall или при детальном описании интеграций.
Q: Как приоритизируете требования?
Зависит от контекста. MoSCoW (Must/Should/Could/Won't) — быстрый способ для первичной сортировки. Для Agile хорошо работает WSJF (Weighted Shortest Job First) — приоритизируем по соотношению ценности к размеру. Если нужно учитывать мнение нескольких стейкхолдеров — Kano или голосование точками. Главный принцип — приоритизация должна быть обоснована бизнес-ценностью, а не громкостью голоса.
Q: Что делаете, если требования противоречат друг другу?
Сначала убеждаюсь, что противоречие реальное, а не терминологическое — иногда разные люди называют одно разными словами. Если противоречие настоящее — собираю стейкхолдеров вместе и фасилитирую обсуждение: какая цель важнее? Никогда не выбираю сам между конкурирующими требованиями — это решение владельца продукта или бизнеса, моя роль — подсветить конфликт и помочь прийти к решению.
---
Методологии и процессы
Q: Опишите, как работает бизнес-аналитик в Scrum.
В Scrum BA работает в тесной связке с Product Owner. До спринта — помогает PO детализировать user stories в бэклоге, добавляет критерии приёмки, уточняет нюансы. Во время спринта — отвечает на вопросы разработки, участвует в уточнениях. В конце спринта — участвует в демо, собирает обратную связь. Плюс — refinement-сессии, где детализируем истории на несколько спринтов вперёд.
Q: Что такое критерии приёмки и зачем они нужны?
Критерии приёмки — конкретные условия, при которых user story считается реализованной. Нужны, чтобы и разработчики, и тестировщики, и бизнес понимали одинаково, что должно получиться. Формат Given/When/Then: «Дано: пользователь на странице входа. Когда: вводит неверный пароль 3 раза. Тогда: аккаунт блокируется на 15 минут».
Q: Как вы работаете с изменениями требований?
Изменения — норма, не проблема. Важно управлять ими: фиксировать изменение, оценивать его влияние на уже готовое и в разработке, информировать команду. В Agile это встроено в процесс — backlog refinement. В проектах с жёсткими сроками — через change request с оценкой стоимости изменения.
---
Инструменты
Q: Какие инструменты вы используете в работе?
Для документации — Confluence. Для задач — Jira. Для схем и прототипов — Miro, Figma, draw.io. Для BPMN — Camunda Modeler или Bizagi. Для анализа данных — SQL, Excel. Выбор инструментов вторичен — важнее понять, что команда уже использует, и работать в той же экосистеме.
Q: Умеете ли вы работать с SQL?
Да, на уровне аналитика: SELECT с JOIN, GROUP BY, WHERE, подзапросы. Не пишу хранимые процедуры, но могу самостоятельно проверить данные, подготовить выборку для анализа, проверить гипотезу без помощи разработчика.
---
Практические кейсы: что дают и как подходить
Типичный кейс 1: Опишите процесс сбора требований
«Вам нужно разработать систему записи клиентов к специалистам в салоне красоты. Как вы подойдёте к сбору требований?»
Хороший ответ:
Начну с определения стейкхолдеров: клиенты, мастера, администраторы, руководитель салона.
Проведу интервью с каждой группой:
- Клиентам важно: удобная запись онлайн, напоминания, выбор мастера
- Мастерам: видеть своё расписание, управлять окнами
- Администраторам: общая картина загрузки, возможность ручного редактирования
- Руководителю: отчёты по загрузке, выручке
Опишу текущий процесс AS-IS (сейчас, скорее всего, звонки/Telegram), найду боли.
Сформулирую TO-BE процесс в BPMN, согласую со всеми стейкхолдерами.
Напишу функциональные требования, приоритизирую с PO, детализирую в user stories для первого спринта.
Типичный кейс 2: Найдите противоречие
Дают два требования: «Система должна хранить историю всех действий пользователя» и «Пользователь должен иметь возможность полностью удалить свой аккаунт и все данные».
Хороший ответ: Требования противоречат: полное удаление данных несовместимо с хранением полной истории. Нужно уточнить у бизнеса, что важнее — соответствие GDPR/152-ФЗ (удаление) или аудит безопасности (история). Возможный компромисс: анонимизация данных вместо удаления.
---
Поведенческие вопросы (STAR-метод)
STAR: Situation (ситуация), Task (задача), Action (что сделали), Result (результат).
Q: Расскажите о случае, когда заказчик менял требования в последний момент.
Готовьте реальный пример. Структура: что была за ситуация, что изменилось и почему, как вы среагировали, что сделали, чем закончилось. Хорошие ответы показывают гибкость и умение управлять изменениями, плохие — жалобы на заказчика.
Q: Был ли конфликт между бизнесом и разработкой? Как разрешили?
Здесь проверяют навык медиации. Хороший ответ показывает, что вы выслушали обе стороны, нашли общую цель и помогли договориться без выбора «победителя».
Q: Расскажите о провальном проекте. Что пошло не так?
Умение признавать ошибки и извлекать уроки — признак зрелости. Не прячьтесь от вопроса, но заканчивайте на том, что вынесли из ситуации.
---
Что взять на собеседование
- Портфолио — 2–3 артефакта: схема процесса, фрагмент user stories с критериями приёмки, фрагмент ТЗ
- Вопросы к компании — покажите, что вы выбираете, а не ждёте оффер. Спросите про методологию, команду, типичные задачи
- Ноутбук — некоторые интервью предполагают онлайн-рисование схем в Miro
---
Готовитесь к собеседованию? Смотрите открытые вакансии бизнес-аналитика на РаботаМакс — там видно, что реально ищут работодатели.
По теме:
Готовы найти работу быстрее?
Регистрация бесплатна. Максимум — 499₽/нед, открывает безлимитный AI-матчинг с вакансиями и трекер откликов.