Как ставили задачи на проекте?

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

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

Как отвечать

Опирайтесь на свой реальный проект и пройдите по цепочке от запроса до готовой задачи:

• источник: откуда приходили запросы (заказчик, владелец продукта, поддержка, изменения в законодательстве) и кто решал, брать ли их в работу;
• артефакты: в каком виде задача доходила до разработки. Пользовательская история с критериями приёмки в формате Given/When/Then, use case, спецификация интеграции, в госпроектах ТЗ по ГОСТ 34;
• инструменты: трекер (Jira, YouTrack), база знаний в Confluence, схемы в BPMN или UML, контракты API в OpenAPI;
• ритуалы: груминг бэклога, Definition of Ready, оценка в story points или часах, планирование спринта. Если работали по канбану, так и скажите;
• приоритизация: MoSCoW, WSJF или решение владельца продукта по бизнес-ценности.

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

Если опыта постановки задач не было, скажите прямо: задачи ставил лид или другой аналитик, а вы видели, чего в них не хватало. И расскажите, как бы вы это исправили.

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

Отвечают «ставили в Jira». Инструмент без описания процесса и артефактов ничего не говорит о вашей квалификации.

Описывают процесс команды, но не свою роль. Интервьюер так и не понимает, что делали лично вы.

Ругают прошлый проект за хаос, не рассказав, что сами сделали, чтобы его стало меньше.