Расскажите о релевантном опыте бизнес и системного аналитика
Что проверяют
Где проходит ваша граница между бизнес и системным анализом и на какой стороне вы сильнее. Вопрос открытый намеренно: по тому, что вы начнёте рассказывать первым, интервью с заказчиком или схему интеграции, становится видно, подходите ли вы под роль, которую закрывают. Заодно смотрят, сумеете ли описать домен так, чтобы человек со стороны понял.
Как отвечать
Дайте рамку за минуту: домены, размер команд, тип систем (внутренний продукт, интеграция с внешними сервисами, миграция), ваша роль. Потом один проект целиком, от потребности до внедрения.
Что стоит назвать явно:
- источники требований: интервью, наблюдение за работой, разбор обращений поддержки, выгрузки из базы;
- артефакты, которые делали руками: карта процесса as-is и to-be, пользовательские истории с критериями приёмки, схема потоков данных, описание API, модель данных;
- нотации: BPMN для процессов, UML для системной части, ER для данных. Говорите то, что рисовали сами;
- как проверяли требование: прототип, демонстрация заказчику, приёмочные сценарии, сверка с реальными данными через SQL.
Сильный кандидат показывает противоречие в требованиях и то, как его снял: два отдела хотели разного статуса у одной заявки, вы развели их ролями и правами. Это ровно та работа, за которую платят аналитику.
Где спотыкаются
Пересказывают шаблон с результатом «сократили время обработки заявок на тридцать процентов». Аналитика спросят, откуда цифра, что входило в замер и кто его делал, и разговор пойдёт не в вашу пользу.
Второе: перечисляют инструменты вместо задач. Список нотаций и таск-трекеров ничего не говорит о том, умеете ли вы вытащить из заказчика настоящую потребность за словами «сделайте кнопку».
Третье: рассказывают только про постановки и не могут объяснить, что было дальше. Как принимали работу, какие дефекты вернулись, что меняли на опытной эксплуатации: без этого опыт выглядит бумажным.