Мок-собеседование на позицию Middle бизнес-аналитика

Ключевые тезисы

Разбор реальных вопросов и кейсов с собеседований на позицию бизнес-аналитика.
Обсуждение границ ответственности бизнес- и системного аналитика.
Практика сбора требований, работы с документацией и коммуникации с командой.
Разбор типов требований, нотаций (BPMN) и методологий (Agile).
Проработка кейса по проекту онлайн-продажи билетов.

Опыт кандидата (Ралина)

Текущая роль: Fullstack-аналитик с 3-летним опытом.
Путь: Стартап (BA/PM) → Медтех-компания (fullstack) → Финтех (банк, fullstack).
Команда: Fullstack-аналитик, продакт-менеджер (он же проджект), 3 C#-разработчика, 1 Python-разработчик, 1 тестировщик, фронтенд-разработчики.

Бизнес- vs Системный аналитик

Бизнес-аналитик (BA): Сбор и анализ требований от бизнеса. Выявление бизнес-цели, ценности, проработка гипотез, сбор метрик. Коммуникация с бизнесом и дизайнерами. Верхнеуровневые и частично функциональные требования.
Системный аналитик (SA): Техническая и архитектурная проработка решений на основе требований BA. Выбор интеграций, языков программирования, проектирование API, работа с БД.

Документация и требования

Типовой шаблон артефактов: Бизнес-цель/требования → User Story → Ролевой доступ → Функциональные требования (ФТ) → Нефункциональные требования (НФТ) → BPMN-схема/Use Case → Критерии приёмки.
Разница ФТ и НФТ: ФТ отвечают на вопрос "Что система должна делать?", НФТ — "Как система должна это делать?" (производительность, масштабируемость, бизнес-правила, ограничения).
Use Case: Описание сценариев взаимодействия.
- Основной поток: Идеальный сценарий (Happy Path).
- Альтернативный поток: Ошибочные или отклоняющиеся сценарии.
Критерии приёмки: Могут быть в формате списка или Given/When/Then. Не равны тест-кейсам, но служат для них основой.
Работа при отсутствии документации: Самостоятельное исследование системы (тыкание на тестовом стенде), анализ запросов, составление вопросов, встречи с командой разработки и пользователями, фиксация информации в собственный "скелет" документации.

Процесс работы с задачей

Поступление идеи от бизнеса (через продакта/проджекта).
Анализ и дополнение требований: Изучение входящих данных, подготовка вопросов, интервью со стейкхолдерами.
Подготовка артефактов: Создание макетов, документации.
Бизнес-груминг: Встреча с командой разработки для презентации и обсуждения артефактов, сбор вопросов.
Согласование в команде: Валидация требований разработчиком и тестировщиком.
Передача на техническую проработку системному аналитику.

Коммуникация и работа в команде

Разрешение конфликтов: Мягкое информирование о приоритетах или технических ограничениях. Консультация с SA/разработчиками для поиска альтернатив (костыль, MVP). Чёткое обоснование отказа.
Зрелость гипотез: В идеале — зона ответственности бизнеса или продакта. BA может помочь, но не должен подменять их.
Обратная связь в команде:
- В Agile — через ретроспективу (доски "старт/стоп/продолжить").
- Вне зависимости от методологии — аккуратный личный разговор с целью понять корень проблемы (проблемы в артефактах, личные обстоятельства).
- Использование Performance Review или опросов 360°.
Проведение демо: Опыт есть. В случае негативной обратной связи — снять напряжение, собрать детальные комментарии, определить, проблема единичная или массовая, предложить обучение или поставить задачу на доработку.

Техники и инструменты

Сбор требований: Интервью, опросы/анкетирование (для массовых проблем), мозговые штурмы.
Бизнес-процессы: Основная нотация — BPMN. Также знакома с UML (диаграмма активностей) и IDEF0. Инструменты: draw.io, BPMN.io, встроенные средства Confluence.
Уровни декомпозиции процессов: На практике используются 2-й и 3-й уровни, где шаги детализированы максимально подробно для выявления узких мест.
Интеграции: Понимание разницы между синхронным (REST API, JSON RPC) и асинхронным (брокеры сообщений, Kafka) взаимодействием. Для BA — базовое понимание методов API (GET, POST, PUT, DELETE), структуры запроса/ответа.

Кейс: Онлайн-продажа билетов (выявление требований)

В ходе кейса были заданы уточняющие вопросы по ключевым аспектам:

Контекст и интеграция: Наличие внутренней системы бронирования (AS-IS), необходимость интеграции с ней.
Целевая аудитория: Молодёжь (18-40), агрегатор мероприятий по РФ.
Функционал покупки: Один заказ — одно мероприятие, но несколько билетов в нём. Ограничение времени на оплату (20-30 мин).
Пользовательский путь: Минимум шагов до оплаты. Авторизация через номер телефона (для программы лояльности) опциональна, но желательна.
Данные: Обязательные поля — имя, номер телефона. Дата рождения и почта — опционально. Не требуется указывать данные гостей (билеты не именные).
Доставка билетов: Личный кабинет, email, мессенджер (для экономии на SMS).
Метрики успеха: Увеличение количества проданных билетов на 30%, конверсия, время от добавления в корзину до оплаты.
Дополнительные возможности: Подарок (отправка на чужой email), проверка возраста 18+, интеграция с программой лояльности (приветственные бонусы, списание баллов).

Самооценка и развитие

Сильные стороны: Опыт fullstack-аналитики, работа с документацией, коммуникация.
Зоны роста: Проведение пользовательских исследований (формулировка гипотез, подготовка вопросов), углубление в продуктовые метрики (Completion Rate, анализ воронок), изучение новых технологий.
Работа с метриками: Участие в пост-анализе внедрённых фич, анализ веб-метрик, определение точек оттока пользователей.

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