Изменение требований по ходу разработки: править постановку или заводить новую задачу

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

У аналитика в этот момент два очевидных хода, и оба по-своему плохие.

Два неправильных ответа

Всегда править постановку

Быстро и вежливо: документ открыт, три строки заменены, все в курсе. Только «все» — это участники переписки. Постановка при этом перестаёт быть тем, что оценивали, и тем, по чему тестировщик уже начал писать проверки. Текст выглядит так, будто он всегда был таким.

Результат узнаваем: разработчик сделал по первой версии, тестировщик проверяет по второй, на приёмке спорят, и спор нельзя разрешить — первой версии больше нет.

Всегда заводить новую задачу

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

Вопрос не в процедуре, а в ценности. Правило «всегда так» удобно тем, что снимает необходимость думать. Но выбор между правкой и новой задачей — это выбор, что именно выйдет в релиз, и делать его должен тот, кто понимает зачем.

Как выбрать

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

Остальные признаки уточняют ответ:

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

Если признаки тянут в разные стороны, решает главный вопрос. А если ответа на него нет у аналитика — это вопрос к владельцу продукта, заданный прямо: «выпускаем как было или ждём исправления».

Если правим постановку

Правка допустима, незаметная правка — нет. Разница в одной записи, которая остаётся рядом с требованием:

REQ-114   доступ закрывается по истечении подписки
  ред. 2    2026-09-18
  было      в течение часа
  стало     в течение пяти минут
  причина   жалобы поддержки, BUG-402
  решил     владелец продукта
  затронуто TASK-2071 (в работе)
            test_REQ_114_access_closes_within_hour

Обратите внимание на последнюю строку. Название теста содержит старое значение, и без этой записи тест продолжил бы подтверждать час. Ровно этот разрыв описан в разборе трассировки: изменение доезжает до кода и не доезжает до проверки.

Минимум, без которого правка считается незаписанной:

• Старое значение сохранено. Не зачёркнуто в голове, а видно в тексте. Иначе спор на приёмке нечем разрешить.
• Изменённый критерий приёмки назван явно. Не «уточнили логику», а какое условие стало каким.
• Тестировщик узнал из задачи, а не из чата. Сообщение в переписке прочитают те, кто в ней был. Задачу прочитает тот, кто будет проверять.
• Оценка пересмотрена, даже если не изменилась. Строка «оценка прежняя» — тоже решение, и его кто-то принял.

Если заводим новую задачу

Новая задача опасна не сама по себе, а тем, что исходная делает вид, будто её не было. Две связи это исправляют:

1. В исходной задаче — строка о выносе. «Изменение такое-то не входит, вынесено в TASK-2094, решение от 18.09». Это продолжение списка отказов, о котором шла речь в разборе границ.
2. Исходная принимается по исходным критериям. Не по новым и не по смеси. Иначе приёмка превращается в спор о том, какая из задач сейчас проверяется.

И ещё одно: у новой задачи должен быть срок или хотя бы место в очереди, названное вслух. Задача-хвост без приоритета — это отказ, оформленный как согласие.

Изменение, которое прошло мимо аналитика

Самый частый случай — не тот, где аналитик выбирает. Самый частый — когда разработчику написали напрямую, он сделал, а постановка об этом не знает.

Признак простой: код ушёл дальше текста. На демонстрации система делает то, чего нет ни в одном критерии, и все считают это нормальным, потому что «так договорились».

Лечится не запретом на разговоры, а правилом: изменение не существует, пока оно не записано в задаче. Разработчик может принять просьбу, но реализует её после того, как появилась строка в постановке. Это не бюрократия, а защита самого разработчика: иначе на приёмке его работа будет выглядеть как самодеятельность.

Если на вопрос «почему система так делает» отвечают «так попросили», а не «так написано», постановка перестала быть источником истины.

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

Возьмите последнюю закрытую задачу, в которой что-то менялось по ходу. Сравните критерии приёмки в постановке с тем, что реально ушло в релиз. Каждое расхождение, которое нельзя объяснить записью в задаче, — изменение, прошедшее мимо.

Что дальше

Незаписанное изменение доживает до тестирования, и там тестировщик находит расхождение между системой и постановкой. Дальше спор: это дефект или постановка просто не договорила? Об этом — в следующем разделе.