Как читать и объяснять формат задания
Что проверяют
Умеете ли вы превратить входящую задачу, будь то пользовательская история, ТЗ или письмо заказчика, в понятную команде постановку, не потеряв смысл и не додумав лишнего. Следом обычно дают пример задачи и просят сказать, что в ней не так и какие вопросы вы зададите автору.
Как отвечать
Покажите порядок работы, а не «читаю внимательно несколько раз»:
- определите формат: пользовательская история, юзкейс, ТЗ по ГОСТ 34.602-2020, BRD или просто тикет. От формата зависит, что в нём обязано быть и где искать пробелы;
- найдите цель: какую проблему бизнеса решаем и как поймём, что решили. Если цели в тексте нет, это первый вопрос заказчику;
- разложите по частям: роль, действие, данные, ограничения, критерии приёмки. У истории проверьте, что есть кто, что хочет сделать и зачем, а критерии записаны проверяемо, например в виде Given/When/Then;
- выпишите неясности: размытые слова вроде «быстро», «удобно», «все пользователи», не описанные ошибки и граничные случаи, противоречия между разделами;
- сверьте с системой: какие процессы, интеграции и сущности задача затрагивает, нет ли конфликта с тем, что уже сделано.
Объясняйте задачу под аудиторию. Разработчику нужны данные, API, статусы и ошибки, тестировщику критерии приёмки и граничные случаи, заказчику результат и сроки. Удобный приём: перескажите задачу своими словами и попросите автора подтвердить, а после обсуждения зафиксируйте договорённости в тикете или базе знаний, а не в чате.
Хорошо звучит пример из практики: какую задачу вы разбирали, какие вопросы нашли и что это сэкономило команде. Если опыта мало, разберите вслух задачу, которую дали на собеседовании: это и есть проверка навыка.
Где спотыкаются
Пересказывают задачу близко к тексту вместо анализа. Интервьюеру важно услышать, какие вопросы вы зададите, а не то, что вы умеете читать.
Молча додумывают пробелы. Предположение, которое не проверили у автора, всплывает на приёмке и оборачивается переделкой.
Объясняют всем одинаково: заказчику рассказывают про схемы таблиц, а разработчику про ценность для бизнеса без единого поля и статуса.