Как строился процесс работы с системной аналитикой
Что проверяют
Владеет ли аналитик полным циклом, от выявления потребности до сопровождения изменений, и говорит ли конкретными артефактами, а не общими словами про «сбор требований».
Как отвечать
Разложить процесс по этапам и на каждом назвать, что получается на выходе.
- Выявление. Интервью со стейкхолдерами, наблюдение за работой пользователей, разбор обращений в поддержку, анализ текущей системы и её данных. Выход: список потребностей с указанием источника и владельца.
- Анализ и моделирование. BPMN процессов as-is и to-be, use case, ER-модель, диаграммы последовательности для интеграций, схема состояний ключевой сущности. Модель нужна затем, чтобы противоречия стали видны до кода, а не на демо.
- Спецификация. User story с критериями приёмки, контракты API (OpenAPI для REST, схемы сообщений для очередей), правила валидации, коды и тексты ошибок, нефункциональные требования числом: нагрузка, p95 ответа, объём данных, требования к хранению.
- Согласование и валидация. Ревью с бизнесом, разработкой и QA. Прототип в Figma там, где спор про интерфейс дешевле закрыть картинкой, чем текстом.
- Сопровождение изменений. Версионирование документа, трассируемость от бизнес-цели до задачи и теста, живой реестр открытых вопросов с ответственными и сроками.
Отдельно стоит проговорить конфликты стейкхолдеров: они решаются не голосованием, а возвратом к цели и метрике, приоритизацией (MoSCoW, RICE) и письменной фиксацией решения, чтобы через месяц не начинать заново.
Инструменты: Confluence, Jira, Miro, draw.io, Swagger, Postman, SQL для проверки гипотез по реальным данным.
Хорошо закончить мыслью, что аналитик отвечает не за объём документации, а за то, что бизнес, разработка и тестирование одинаково понимают задачу.
Где спотыкаются
Пересказывают учебник (BABOK, этапы, техники) без единого примера со своего проекта. Второй частый вариант: описывают себя как передатчика задач от бизнеса к разработке, не показывая работы с данными, интеграциями и ограничениями системы.