Middle-уровень: сбор требований, моделирование платёжных процессов СБП, интеграции с корпоративными системами и работа на стыке бизнеса и IT в Agile-команде
Фишка: Продуктовая команда развития СБП в масштабе федерального банка: высокая регуляторная нагрузка (ЦБ, 732-П), плотная интеграция с ERP/CRM/POS и необходимость быть «мостом» между бизнесом, IT и смежными стримами
| Этап | Длительность | Что проверяют |
|---|---|---|
| HR-скрининг | 30–45 мин | Мотивация, опыт 3+ лет как БА, знание банков/финтеха, готовность к гибриду в Москве, зарплатные ожидания, сроки выхода |
| Интервью с руководителем / product owner | 60 мин | Разбор реального опыта: сбор БТ, работа со стейкхолдерами, документация, участие в тестировании и демо, понимание платёжных продуктов |
| Техническое / предметное интервью | 60–90 мин | BPMN и декомпозиция процессов, user stories и use cases, интеграционные схемы, СБП и C2B-сценарии, REST API, нормативка ЦБ, кейс на анализ требований |
| Финальное интервью / согласование | 30–60 мин | Культурный fit, работа в кросс-функциональной команде, вопросы кандидата о продукте и процессах ВТБ |
| Проверка службой безопасности | 3–10 рабочих дней | Стандартная для крупного банка с госучастием; не требует отдельной подготовки, но учитывай сроки |
Обязательный минимум
Плюсом будет
В чём разница между функциональными и нефункциональными требованиями?
Функциональные — что система делает (сценарии, правила). Нефункциональные — как: производительность, безопасность, доступность 24/7, соответствие 732-П. Оба типа фиксируй в БТ/ТЗ отдельными разделами.
Что такое FR (functional requirement)?
Формулировка наблюдаемого поведения системы: актор, действие, результат. Проверяемо на UAT. Пример для СБП: «ТСП получает статус платежа в течение N секунд».
Что такое INVEST в user stories?
Independent, Negotiable, Valuable, Estimable, Small, Testable. История должна нести ценность бизнесу и быть проверяемой на демо.
Как вы различаете user story, use case и БТ?
User story — ценность для пользователя в backlog. Use case — детальный сценарий с акторами и альтернативами. БТ — согласованный документ для стейкхолдеров и разработки, часто шире одной истории.
Какие артефакты вы готовите на этапе сбора требований для платёжного продукта?
БТ, CJM, BPMN-схемы процесса, интеграционные диаграммы, глоссарий терминов СБП, матрица трассировки требований → тест-кейсы.
Ловушка: Не смешивай бизнес-правила (комиссия, лимиты) с технической реализацией (формат API) в одном требовании — разделяй уровни.
Совет: На собесе ВТБ приводи пример полного цикла: интервью со стейкхолдером → БТ → user stories → приёмка на демо.
Какие основные элементы диаграммы BPMN?
События (start/intermediate/end), задачи (task), шлюзы (gateway), потоки (sequence flow), пулы и дорожки (pool/lane), артефакты и объекты данных.
Какие виды шлюзов есть в BPMN?
Exclusive (XOR) — один путь; Parallel (AND) — все пути; Inclusive (OR) — один или несколько; Event-based — по событию. Для платежа: XOR после проверки статуса, AND при параллельной нотификации банка и ТСП.
Что такое UML и когда вы его используете?
Язык моделирования: диаграммы последовательностей (интеграции СБП), компонентов (системы), use case. BPMN — для бизнес-процессов; UML — для технического уровня.
Как декомпозируете сложный платёжный процесс на подсистемы и этапы?
Сверху вниз: клиентский путь → банк-отправитель → НСПК/СБП → банк-получатель → учёт/касса. На каждом уровне — входы, выходы, исключения, SLA.
Фишка: В вакансии прямо указана декомпозиция процессов и схемы интеграций — готовь одну нарисованную схему C2B-платежа через СБП.
Ловушка: Не путай BPMN activity с системной операцией: на бизнес-диаграмме — «Провести платёж», на sequence diagram — вызовы API.
Что такое СБП и чем она отличается от карточных платежей?
Система быстрых платежей Банка России — мгновенные переводы по номеру телефона/QR, круглосуточно. Участники: банки, НСПК, ТСП. Комиссии и лимиты регулируются отдельно от Visa/MC.
Опишите сценарий C2B-платежа через QR-код СБП
Покупатель сканирует QR → выбор банка → подтверждение → списание → зачисление ТСП → статусы (pending/success/fail) → фискализация при необходимости.
Какие риски и edge cases важны для аналитика СБП?
Таймауты, дубли, отмена, возврат, несовпадение суммы, недоступность банка-участника, идемпотентность, PCI/ПДн, лимиты ЦБ.
Какие метрики продукта вы бы отслеживали для платёжного сервиса СБП?
Конверсия QR→оплата, success rate, среднее время проведения, доля возвратов, подключённые ТСП, объём C2B, NPS мерчантов.
Совет: Изучи официальные материалы НСПК и ЦБ: типы операций (C2C, C2B, B2B), роли участников, статусы.
Ловушка: C2B — не только QR: есть оплата по ссылке, NFC; не ограничивай ответ одним каналом.
Что такое REST API?
Архитектурный стиль: ресурсы по URL, HTTP-методы (GET/POST/PUT/DELETE), stateless, JSON/XML. Для СБП — контракты между банком, процессингом, ERP, кассой.
Что такое ESB?
Enterprise Service Bus — шина для маршрутизации, трансформации и оркестрации сообщений между системами. В банке снижает point-to-point хаос.
Как вы описываете интеграцию СБП с ERP (1С, SAP)?
Диаграмма последовательности: триггер оплаты → статус в шлюзе → проводка в ERP → сверка → отчёт. Укажи формат, частоту, обработку ошибок и идемпотентность.
Что такое EML в контексте интеграций?
Enterprise Messaging / специфичный для проекта формат обмена сообщениями — уточни на собесе контекст; покажи, что различаешь транспорт (ESB/Kafka) и контракт (схема сообщения).
Фишка: Вакансия требует опыт интеграции с CRM, онлайн-кассами и POS — подготовь пример цепочки «оплата → чек → учёт».
На агрегированных или на детальных данных строите дашборд?
Операционный мониторинг — детальные данные с фильтрами; стратегические KPI — агрегаты (день/неделя). Укажи trade-off: точность vs скорость vs нагрузка.
Какой у вас опыт работы с данными / Excel?
Сводные таблицы, ВПР, базовая статистика, визуализация трендов продаж. Для БА важнее интерпретация, чем ML.
Работали ли с большим объёмом данных?
Опиши источники, ETL/выгрузки, как валидировал качество и как выводы превращал в требования к продукту.
Совет: Связывай метрики с решениями: «рост отказов на шаге X → требование на retry и понятный UX ошибки».
Работали ли в Jira?
Backlog, epics/stories, спринты, доски Kanban/Scrum, связь с Confluence для БТ.
Как вы взаимодействуете со смежными стримами и стейкхолдерами?
Регулярные синки, RACI, протоколы решений, эскалация конфликтов требований, единый backlog приоритетов.
Какие требования из BABOK и V-Model вы знаете?
BABOK — области знаний BA (планирование, elicitation, анализ, дизайн, оценка). V-Model — трассировка требований к тестам слева направо, верификация справа налево.
Какие у вас есть вопросы к нам?
Спроси про roadmap СБП, состав команды, Definition of Done для БТ, частоту релизов, взаимодействие с compliance.
Совет: ВТБ ценит самоорганизацию и доведение задач до результата — покажи пример, где ты закрыл требования без напоминаний.
Декомпозиция C2B-платежа через СБП
ТСП хочет принимать оплату по QR СБП в интернет-магазине. Опишите бизнес-процесс от генерации QR до подтверждения оплаты и уведомления учётной системы. Выделите акторов, основной и альтернативные потоки (отказ, таймаут, частичный возврат).
Акторы: покупатель, интернет-магазин (ТСП), банк покупателя, НСПК/СБП, банк ТСП, ERP/касса. Happy path: 1) ТСП создаёт заказ и запрашивает QR (сумма, merchantId, orderId). 2) Покупатель сканирует QR в приложении банка. 3) Подтверждение и аутентификация. 4) Списание → клиринг через СБП → зачисление. 5) Callback/webhook статуса SUCCESS в ТСП. 6) Фискализация и проводка в ERP. Альтернативы: FAIL — показать причину, не менять статус заказа на «оплачен»; TIMEOUT — polling статуса, SLA эскалации; REFUND — отдельный процесс с связкой по originalTransactionId. Артефакты: BPMN основного потока, таблица статусов, матрица интеграционных сообщений.
Сложность: O(actors × states)
User stories для подключения мерчанта к СБП
Команда развивает онбординг ТСП в сервис СБП ВТБ. Напишите 5 user stories для MVP: заявка, проверка, договор, техническое подключение, первый тестовый платёж. Примените INVEST.
1) Как менеджер по продажам, я хочу создать заявку ТСП с реквизитами и MCC, чтобы передать её на комплаенс-проверку (ценность: скорость подключения). 2) Как комплаенс-офицер, я хочу видеть чек-лист 732-П и статус проверки, чтобы принять решение (ценность: снижение рисков). 3) Как ТСП, я хочу подписать оферту и тариф онлайн, чтобы начать приём платежей без визита в офис. 4) Как интегратор, я хочу получить тестовые credentials и sandbox QR, чтобы провести тестовый платёж до prod. 5) Как ТСП, я хочу видеть статус первого платежа в личном кабинете, чтобы убедиться, что всё работает. Критерии приёмки: чёткий актор, измеримый результат, тест на демо.
Сложность: O(stories)
Матрица трассировки требований
Бизнес просит «ускорить прохождение C2B-платежей». Как вы переведёте запрос в измеримые требования и свяжете их с тест-кейсами?
1) Elicitation: текущий p95 времени, целевой SLA, каналы (QR/ссылка). 2) НФТ: p95 < 3 сек на шаг подтверждения; доступность 99.9%. 3) ФТ: асинхронный polling вместо блокирующего UI; кэш статусов; retry с backoff. 4) Матрица: Req-ID → Story → Test case (нагрузочный, негативный таймаут). 5) Метрика успеха после релиза: сравнение p95 до/после на проде.
Сложность: O(requirements)
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| Бизнес-требования | можешь за 2 минуты объяснить разницу FR/NFR и показать пример БТ для платежа |
| BPMN | можешь нарисовать C2B-процесс с XOR-шлюзом при отказе платежа |
| СБП | можешь описать участников и статусы C2B-платежа без подсказок |
| Интеграции | можешь набросать sequence diagram СБП → ERP → касса |
| Agile | можешь написать INVEST-совместимую user story с критериями приёмки |
| Поведенческие | есть 2 готовых STAR-кейса про стейкхолдеров и тестирование |
В день собеседования
