Есть ли аналитики на проекте и кто формирует требования к продукту?

Что проверяют

Как на вашем проекте рождались требования и какое место в этом занимали вы. По ответу видно, тестировали вы по документации или по догадкам, и умеете ли работать, когда требований нет. Следом обычно спрашивают, что вы делали с неполным или противоречивым требованием.

Как отвечать

Опишите реальную схему своего проекта, без идеализации:

• кто формирует: продакт-менеджер или product owner решает, что и зачем делать, бизнес-аналитик или системный аналитик превращает это в спецификацию, пользовательские истории, макеты и контракты API. На небольших проектах аналитиков нет, и требования пишет продакт или тимлид прямо в задаче;
• где живут требования: Confluence, задачи в Jira или YouTrack, макеты в Figma, спецификация OpenAPI для бэкенда;
• ваша роль: тестирование требований до разработки. Вы читаете спецификацию на груминге, ищете пропуски (пустое поле, ошибка сети, граничные значения), задаёте вопросы и добиваетесь критериев приёмки;
• без аналитика: собираете требования из разговоров с продактом и разработчиками, фиксируете договорённости в задаче, опираетесь на похожие функции продукта и поведение конкурентов, спорные места согласуете письменно.

Приведите один свой пример: какой пробел в требованиях вы нашли до разработки и что это сэкономило. Детали и цифры нужны ваши, а не придуманные. Если опыт только с одной схемой, скажите честно и объясните, как работали бы в другой.

Этот же вопрос полезно задать компании в конце собеседования: по ответу станет понятно, не придётся ли вам самому быть аналитиком.

Где спотыкаются

Отвечают «требования писал аналитик, я тестировал» и больше ничего. Интервьюер слышит пассивного исполнителя, который не участвует в проверке требований.

Жалуются на отсутствие документации как на причину пропущенных багов. Сильнее показать, что вы делали, чтобы это компенсировать.

Путают роли: называют аналитиком того, кто ставил задачи, и не могут объяснить, чем продакт отличается от бизнес-аналитика.