Вопросы разработчика по постановке: журнал вопросов и куда попадают ответы

«Быстрый вопрос по задаче» в личных сообщениях. Аналитик отвечает за минуту, разработчик делает, и через месяц тестировщик заводит дефект на поведение, которого нет в постановке. Ответ был — но жил в переписке двух людей.

Вопрос разработчика по постановке — не помеха и не признак плохой работы аналитика. Это место, где текст не ответил, а человеку нужно продолжать. Каждый такой вопрос показывает дыру в постановке, а каждый ответ — требование, которого в ней не было.

Разрыв возникает не тогда, когда вопрос задан, а когда ответ остаётся там, где его дали: в личной переписке, на созвоне, в комментарии к коду.

Где теряются ответы

Где ответили	Кто узнает об ответе	Что случится потом
Личные сообщения	Двое	Тестировщик проверит по постановке и заведёт дефект на правильное поведение
Созвон	Участники, по-разному	Через месяц двое вспомнят ответ иначе
Комментарий в коде	Следующий разработчик этого файла	Правило живёт в коде, и его найдут, только читая код
Общий чат команды	Те, кто читал в тот день	Ответ утонет под сотней сообщений
Задача	Все, кто её откроет	Ответ проверят, учтут в тестах и найдут при разборе дефекта

Правило отсюда одно: отвечать можно где угодно, но ответ существует, только когда он записан в задаче. Устный вопрос получает устный ответ и одну строку в задаче — этого достаточно.

Журнал вопросов

Удобнее всего держать вопросы и ответы прямо в задаче отдельным списком. Не в комментариях вперемешку с обсуждением, а в одном месте, которое читается за минуту.

ВОПРОСЫ ПО ЗАДАЧЕ TASK-2071
В-1  12.09  разработчик
     Закрывать доступ сразу или в конце оплаченных суток?
     ответ   в момент истечения, с точностью до часа
     решил   владелец продукта
     учтено  критерий приёмки 2

В-2  13.09  разработчик
     Что видит пользователь, у которого доступ закрыли посреди сеанса?
     ответ   открыто — ждём макет от дизайна до 16.09;
             если не придёт — стандартная страница «доступ истёк»

В-3  14.09  тестировщик
     Продление в последний час — доступ не должен мигнуть?
     ответ   не должен; добавлен сценарий 3а
     учтено  сценарий, критерий приёмки 4

Строка «учтено» — главная. Она показывает, что ответ не остался в журнале, а переехал в постановку: в критерий, в сценарий, в правило. Журнал — входящий ящик, а не второе место хранения требований.

Куда попадает ответ

Не каждый ответ меняет постановку. Полезно различать типы вопросов — от типа зависит, кто отвечает и куда идёт ответ.

Тип вопроса	Пример	Кто отвечает и куда ответ
Смысл формулировки	«Активный пользователь» — это кто?	Аналитик → определение в постановке или словаре данных
Пропущенное исключение	А если внешний сервис не ответил?	Владелец процесса → сценарий и критерий приёмки
Противоречие требований	Пункт 3 и пункт 7 не выполняются вместе	Владелец продукта → правка постановки с пометкой «было/стало»
Нет данных или доступа	Где взять справочник тарифов?	Аналитик выясняет → до ответа это блокер на доске
Технический выбор	Хранить историю в той же таблице или отдельно?	Разработчик сам → в постановку не идёт, если не меняет поведение

Последняя строка важна в обе стороны. Аналитик не должен решать технические вопросы — и не должен пропускать технический ответ, который меняет поведение. «Храним только последнее значение» звучит как деталь реализации, но означает, что истории изменений не будет.

Ответ, меняющий требование, — это изменение по ходу. Если ответ на вопрос меняет критерий приёмки или оценку, к нему применяется всё, что сказано в разборе изменений по ходу разработки: старое значение сохраняется, тестировщик узнаёт из задачи.

Вопрос без ответа

Самые опасные вопросы — открытые. Разработчик не может ждать неделю и в какой-то момент делает «как логичнее». Чтобы это не происходило молча, у открытого вопроса должны быть две вещи: срок, до которого ждём ответ, и решение по умолчанию, если ответа не будет. Записанное решение по умолчанию — допущение, которое видно и которое можно оспорить. Молчаливое «как логичнее» — нет.

Вопросы как сигнал

Журнал полезен не только внутри задачи. Если посмотреть на несколько задач подряд, видно две вещи:

Много вопросов к одной задаче — её взяли неготовой. Это повод вернуться к тому, как проверяется готовность на рефайнменте, а не упрекать автора.
Одинаковые вопросы к разным задачам — в продукте нет общего определения или правила. Вопрос «что считается активным пользователем» в третий раз — сигнал записать это один раз в словарь.

Признак, что ответы теряются: тестировщик задаёт разработчику тот же вопрос, что разработчик две недели назад задал аналитику.

Проверка за десять минут

Возьмите задачу, которая сейчас в работе, и спросите разработчика: что ты уточнял по ней на словах? Сравните ответ с текстом задачи. Всё, чего в тексте нет, — требования, которые тестировщик не увидит.

Что дальше

Журнал вопросов ловит то, что разработчик заметил сам. Не заметил — расхождение доживёт до приёмки. Поймать его раньше можно, показав промежуточный результат тем, кто будет им пользоваться.