Насколько хорошо описана задача
Что проверяют
Этот вопрос задаёте вы, и по нему оценивают зрелость: понимаете ли, что фронтендер теряет на неясной постановке больше времени, чем на самом коде. Ответ работодателя покажет, во что вы упрётесь: в вечное «сделай как на макете» или в нормальный тикет с критериями приёмки.
Как отвечать
Спрашивать конкретно, общая формулировка даст общий ответ. Что стоит уточнить:
- кто пишет задачу: продакт, аналитик, дизайнер или разработчик сам себе;
- есть ли макеты на все состояния экрана (загрузка, пустой список, ошибка, длинный текст, узкий экран) или только счастливый путь;
- зафиксирован ли контракт с бэкендом до начала работы, кто его описывает и что делать, если сервер ещё не готов;
- есть ли критерии приёмки и кто принимает результат: тестировщик, продакт, дизайнер;
- как оцениваются задачи и что происходит, когда требования меняются в середине спринта;
- считается ли доработка после приёмки новой задачей или «мы же договаривались».
Сильный ход: попросить показать пару реальных тикетов из бэклога, лучше свежих и не самых образцовых. Это честнее любых слов про процессы: сразу видно, есть ли ссылка на макет, описан ли ожидаемый результат и кто задавал уточняющие вопросы в комментариях.
Где спотыкаются
Задают вопрос как претензию: «у вас задачи нормально описаны или как обычно?». Разговор превращается в оборону, деталей вы не узнаете, а впечатление остаётся.
Второе: слышат только название инструмента. Ответ «у нас всё в трекере» не значит ничего: качество постановки живёт в шаблоне задачи и дисциплине команды, а не в самом трекере.
Третье: не спрашивают про дизайн-систему и состояния компонентов. Именно там прячется разница между задачей на день и неделей на крайние случаи, которых не было в макете: адаптив, темизация, поведение при ошибке сети.