Какие роли были в команде?
Что проверяют
Понимаете ли вы границы роли аналитика: где заканчивается работа продакта или владельца продукта и начинается ваша, кому вы передаёте требования и в каком виде. Следом почти всегда спрашивают: «Кто принимал финальное решение, когда требования противоречили друг другу?»
Как отвечать
Начните с контекста: какой продукт, сколько человек, одна команда или несколько. Затем опишите роли через то, чем вы с ними обменивались:
- владелец продукта или продакт: приоритеты и цель, от него вы получали проблему, а не готовое решение;
- заказчики и стейкхолдеры: источники требований, с ними интервью и согласование;
- бизнес- и системный аналитик: если были оба, скажите, как делили работу, например процессы в BPMN против спецификаций API и моделей данных;
- архитектор или техлид: интеграции и ограничения, с ним сверяли решения до передачи в разработку;
- разработчики: получали user story с критериями приёмки, OpenAPI-спецификацию или диаграммы последовательностей;
- тестировщики: строили проверки по вашим критериям приёмки и первыми находили дыры в требованиях;
- дизайнер: прототипы, которые вы сверяли с требованиями.
Главное в ответе: ваша роль и ваш вклад. Какие артефакты вели вы, в каком инструменте (Confluence, Jira, Miro), как проходило согласование. Если совмещали аналитику с управлением проектом или тестированием, скажите прямо и приведите пример. Подкрепляйте рассказ своими случаями и цифрами, а не шаблонным «проект сдали в срок».
Где спотыкаются
Путают роли аналитика и продакта: говорят, что сами решали, какие фичи делать. Интервьюер услышит либо преувеличение, либо размытую ответственность в команде.
Перечисляют роли без связей. Ценность ответа в том, что и кому вы передавали и где при этом возникали потери.
Не упоминают тестировщиков и разработчиков как потребителей требований. Хороший аналитик знает, что его спецификацию читают именно они, и может рассказать, как собирал с них обратную связь.