Собеседование бизнес-аналитика проверяет, как вы собираете требования, работаете с несогласными стейкхолдерами и превращаете неопределённость в то, что команда сможет построить. Ниже — самые частые вопросы с эталонными ответами. Senior: архитектуру, трейд-оффы, менторство и принятие решений.
Интервью углубляются в позицию одного человека, воркшопы рано выявляют конфликты между стейкхолдерами, наблюдение показывает, что люди делают на самом деле, а не что говорят, анализ документов фиксирует существующие правила, а прототипы дают конкретную обратную связь, которой абстрактное обсуждение никогда не даст. Выбор зависит от того, насколько понятна предметная область — чем меньше ясности, тем больше опоры на наблюдение и прототипы.
Нужно сделать конфликт явным, а не тихо выбрать одну сторону: зафиксировать обе позиции, аргументы за каждой и компромисс. Затем свести стейкхолдеров вместе с данными — цифрами использования, стоимостью, рисками — и получить решение от того, кто отвечает за результат. Ошибка в том, чтобы разрешить конфликт кулуарно: проигравшая сторона узнаёт об этом на приёмке, и работа уходит в отказ.
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 или показать прототип, чтобы вытащить скрытые допущения. Всё найденное на этом этапе несравнимо дешевле, чем после реализации.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Senior Business Analyst →