Тестовое собеседование на позицию middle аналитика

Коротко о видео

Это учебный вебинар в формате тестового собеседования на позицию middle системного аналитика: ведущая задаёт вопросы Ольге Гришиной, которая работает аналитиком 1С и планирует перейти в системный анализ. Разбираются сбор и формализация требований, диаграммы, базы данных и SQL, REST/API и границы микросервисов; после ответов ведущая даёт обратную связь. Практические задания построены на условном приложении доставки: нужно собрать требования к промоэкрану, выделить сущности модели данных и спроектировать API создания заказа.

Затронутые темы

Что взять на заметку

• Для сбора требований кандидат называет интервью, анализ документации и существующей системы, анкетирование и наблюдение за работой пользователей «в полях».
• При уточнении фичи промоакции стоит сначала спросить о бизнес-цели, затем о целевой аудитории, частоте показа, сроке действия промокода, навигации по кнопке, готовности дизайна и возможном масштабировании на другие магазины.
• User Story описывает потребность пользователя и её цель на верхнем уровне, а Use Case раскрывает сценарий взаимодействия с системой, включая основной и альтернативные потоки.
• Постановка для фронтенда должна содержать экран и его элементы, обязательность полей, переходы и действия по нажатию, источник данных и при необходимости стратегию кэширования; для бэкенда нужно предусмотреть изменения данных и интеграций.
• Функциональные требования полезно конкретизировать перечислением отображаемых полей, статусов и правил доступа, а нефункциональные — измеримыми ограничениями доступности, нагрузки и скорости обновления данных.
• В модели доставки разумно начать с сущностей пользователь, заказ, блюдо, ресторан, доставка и оплата; связь заказов и блюд является many-to-many и в физической модели потребует промежуточной таблицы.
• При моделировании оплаты ведущая отмечает, что способ оплаты лучше связывать с конкретным заказом и учитывать наличные и СБП; платёж обычно обрабатывается внешним сервисом, а чувствительные карточные данные нельзя хранить без необходимых мер защиты.
• Для API создания заказа обсуждаются POST /api/v1/orders, JSON-объект заказа с массивом items, коды ответа, версионирование для обратной совместимости и обработка прикладных ошибок, например отсутствия товара.