Вопросы собеседования BA и SA

Собеседование аналитика — это не экзамен на заученные определения, а проверка того, умеет ли кандидат рассуждать о требованиях, процессах и коммуникации. Вопросы делятся на теоретические (проверяют понятийную базу) и практические (проверяют опыт и способ мышления). Ниже — карта типовых вопросов для уровней от начинающего до middle, сгруппированная по темам. Ответы здесь не пересказываются: каждый блок ведёт к соответствующей статье базы знаний.

1. Как устроен набор вопросов

Комплекты вопросов для BA и SA обычно строятся по одному принципу: примерно половина — теория, половина — практика. Теория проверяет, владеет ли кандидат терминологией и стандартами; практика — умеет ли он применять их к реальным ситуациям. Отдельно выделяются вопросы «на рассуждение»: они не имеют единственно верного ответа и нужны, чтобы увидеть ход мысли.

Тип вопроса	Что проверяет	Как отвечать
Теоретический	Понятийная база, знание нотаций и стандартов	Кратко, по существу, с примером
Практический	Опыт, применение методов	Через конкретную ситуацию: контекст → действие → результат
Ситуационный (кейс)	Мышление, работа с неопределённостью	Проговорить варианты и критерии выбора

2. Роль аналитика и жизненный цикл

Базовый блок — понимание, кто такой аналитик и где он находится в процессе разработки. Здесь спрашивают о различии ролей BA, SA и FA, о месте аналитика в SDLC и о разнице между бизнес- и системным анализом. Это отправная точка: без чёткого ответа на эти вопросы остальные темы «повисают».

• Опишите жизненный цикл разработки ПО (SDLC) и роль аналитика на каждом этапе.
• Чем отличается бизнес-анализ от системного анализа?
• Какие роли существуют в agile-командах и какова роль аналитика?
• В чём разница между waterfall и agile подходами?

Разграничение ролей разобрано в 00.01 Кто такой аналитик (роли BA, SA, FA), а специфика работы в гибких командах — в 05.02 Scrum и Kanban (аналитик в Agile).

3. Требования: классификация и модели

Самый объёмный блок. Проверяют, различает ли кандидат типы требований, знает ли модели их описания и умеет ли выбирать подходящую. Сюда же относятся вопросы о бизнес-правилах, критериях приёмки и трассируемости.

• Чем отличается функциональное требование от нефункционального?
• Какие типы требований выделяют по BABOK?
• В чём разница между бизнес-правилами и системными требованиями?
• Расскажите о моделях требований: use case, user story, BPMN.
• Что такое acceptance criteria и как вы их определяете?
• Что такое traceability matrix и зачем она нужна?
• Что такое MVP и зачем его используют?

Классификация требований — в 02.03.01 Классификация требований (БТ, ФТ, НФТ). Про истории и сценарии — 04.02 Пользовательские истории (User Stories) и Job Stories и 04.03 Use Case vs User Story — выбор подхода.

4. Выявление требований и работа со стейкхолдерами

Здесь проверяют коммуникационные навыки и владение техниками elicitation. Вопросы часто строятся как «как бы вы…» — важно показать не список методов, а логику выбора.

• Какие техники сбора требований вы знаете? В чём их преимущества и недостатки?
• Как бы вы провели интервью с пользователями для сбора требований?
• Как бы вы подготовили и провели воркшоп?
• Как вы работаете с заинтересованными сторонами?
• Как разрешаете конфликты между заказчиком и командой разработки?
• Какие методы анализа позволяют выявить скрытые потребности пользователей?
• В чём суть метода 5 Whys и когда его применять?

5. Моделирование процессов и нотации

Блок про инструменты: BPMN, UML, диаграммы. Спрашивают как о знании нотаций, так и о практическом опыте — в каком ПО работали, какие элементы использовали.

• Какие стандарты и нотации для описания требований и процессов вы знаете?
• Опишите основные элементы диаграммы классов UML.
• Какие типы диаграмм вы используете и в чём разница между ними?
• Приведите пример описания бизнес-процесса в нотации BPMN.
• Как выявляете и описываете «узкие места» в бизнес-процессах?
• С каким ПО для моделирования процессов вы работали?

Основы нотации — в 06.02.01 Потоки, шлюзы, события.

6. Приоритизация, изменения и управление бэклогом

Вопросы о том, как аналитик управляет потоком требований: расставляет приоритеты, обрабатывает изменения, ведёт бэклог.

• Какие методы приоритизации требований вы знаете? Приведите примеры.
• Что такое MoSCoW-приоритизация?
• Как вы определяете, какие требования реализовывать в первую очередь?
• Опишите процесс управления изменениями требований.
• Как вы фиксируете и отслеживаете изменения в проекте?
• Для чего нужен backlog и как он формируется?
• Объясните понятия «эпик», «фича» и «user story».

7. Документирование и артефакты

Проверяют, умеет ли кандидат оформлять результаты работы и адаптировать документы под аудиторию.

• Как бы вы оформили спецификацию требований для нового модуля?
• Опишите ваш подход к построению документов для технической и бизнес-аудитории.
• Что включает в себя документ Vision?
• Как вы документировали требования в гибкой команде?
• Как проверяете полноту и непротиворечивость требований?
• С какими метриками качества требований вы работали?

8. Технические знания

Для системного аналитика этот блок шире: базы данных, SQL, архитектура, форматы обмена. Вопросы проверяют, понимает ли аналитик техническую сторону решения.

• Что такое CRUD-операции и где они применяются?
• Какие базовые понятия о базах данных и SQL вы знаете?
• Какие форматы данных используются для обмена (XML, JSON)?
• Какие требования к безопасности данных существуют для интеграции?
• Какие системы и технологии используются в существующей ИТ-архитектуре?

Базы данных и SQL — в 07.01 Базы данных и SQL на уровне аналитика, протоколы обмена — в 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL).

9. Практические кейсы и ситуации

Финальный блок — вопросы «расскажите случай из практики». Здесь нет правильного ответа, оценивается структура рассказа и выводы.

• Приведите пример, когда требования изменились в середине проекта. Как вы действовали?
• Приведите пример, когда неверно сформулированные требования привели к ошибкам. Что вы сделали?
• Опишите случай, когда пришлось отказаться от части требований. Как вы это объясняли заказчику?
• Что делать, если разработчики неверно интерпретировали требования?
• Как вы взаимодействуете с разработчиками и тестировщиками на этапе реализации?
• Как вы определяете, что требование реализовано корректно?

10. Как готовиться

Подготовка строится по тем же блокам, что и вопросы: сначала понятийная база, затем практика на кейсах. Полезно проговорить вслух ответы на ситуационные вопросы — они показывают ход мысли лучше, чем заученные определения. Отдельно стоит потренироваться в формулировке требований и в описании процессов: это те навыки, которые проверяются в тестовых заданиях.

Ключевой принцип: на каждый вопрос отвечать через конкретику — контекст, действие, результат. Общие рассуждения без примеров на собеседовании middle звучат слабо.