Собеседование бизнес-аналитика проверяет, как вы собираете требования, работаете с несогласными стейкхолдерами и превращаете неопределённость в то, что команда сможет построить. Ниже — самые частые вопросы с эталонными ответами. 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 →