«Статья не появилась в ленте» ещё не означает «исправь FeedController». У записи может быть будущая дата, неподходящий статус или устаревший кеш. Если сразу выбрать исполнителя по слову «лента», он начнёт менять код до установления причины.
Маршрут задачи лучше определять по тому, что уже известно и какого результата не хватает. Это отличается от выбора конкретного помощника: сначала решаем, нужно ли исследование, реализация или проверка, затем назначаем исполнителя и процедуру.
Зафиксируйте состояние задачи
Для начала достаточно четырёх полей: наблюдаемое поведение, ожидаемое поведение, подтверждённые факты и следующий недостающий результат. В примере с лентой наблюдение звучит так: «по прямому URL статья открывается, в RSS её нет». Из этого ещё не следует, что ошибка находится в генераторе RSS.
Проверьте, одна ли среда используется в обоих запросах, когда опубликована запись и какую политику ленты выбрал автор. Архивная статья может быть намеренно исключена из свежих публикаций. В таком случае изменять код, чтобы она появилась в RSS, будет ошибкой относительно требований.
Маршрутизация начинается с определения вопроса, а не имени агента. Если цель неясна, требуется продуктовое уточнение. Если цель ясна, но причина неизвестна, требуется диагностика. Если причина подтверждена и границы согласованы, можно переходить к исправлению.
Добавьте к таблице вход и выход
Таблица «бэкенд → разработчик» слишком широкая. В одной зоне бывают исследование, изменение, ревью и эксплуатация, а права для них различаются. Полезная строка описывает узнаваемую ситуацию и результат, который разрешает перейти дальше.
| Состояние | Следующий результат | Кому поручить |
|---|---|---|
| Поведение расходится с ожиданием, причина неизвестна | Воспроизведение и подтверждённая причина | Исполнителю диагностики |
| Причина найдена, изменение затрагивает несколько потребителей | Карта влияния и ограниченный план | Исследователю участка и владельцу задачи |
| План согласован, контракт известен | Изменение и доказательства проверки | Владельцу соответствующих файлов |
| Изменение готово | Независимые замечания по требованиям и diff | Проверяющему с нужной предметной областью |
| Проверки приняты, требуется выкладка | Проверенный результат применения и способ восстановления | Уполномоченному на публикацию или деплой |
Названия в последней колонке — функции в процессе, а не обязательный набор отдельных агентов. Один человек может выполнять несколько шагов. Отдельного помощника стоит подключать, когда его результат действительно можно отделить и проверить.
Пройдите один случай до конца
Для условной неисправности RSS первый исполнитель читает состояние записи и путь формирования ленты. Он обнаруживает, например, что нужная категория исключена условием запроса. Это ещё не доказательство дефекта: нужно сравнить условие с выбранной политикой публикации.
Владелец задачи подтверждает, что материал должен входить в ленту. Теперь есть основание для ограниченного исправления. Если условие общее для нескольких выдач, сначала выясняется влияние на главную и поиск. Если оно локальное, отдельное большое исследование не требуется.
Исполнитель меняет нужный участок и проверяет присутствие статьи, отсутствие черновика и будущей публикации. Проверяющий получает исходное требование и diff, а не только обещание «лента исправлена». После принятия остаётся применение в нужной среде: локальная правка не означает, что продовая лента уже обновилась.
Передавайте состояние вместе с решением
Задача: опубликованный материал отсутствует в RSS.
Ожидание: материал этой категории должен входить в ленту.
Подтверждено: указать состояние записи и условие запроса со ссылкой.
Решение: изменить только локальный фильтр ленты.
Сохранить: исключение черновиков и будущих публикаций.
Следующий результат: diff и фактический результат согласованной проверки.
Не входит: применение на удалённом сервере.Эту карточку заполняют найденными фактами. Если подтверждение ещё не получено, поле не должно выглядеть завершённым. Особенно опасно переносить предположение из первого сообщения в раздел «причина» только потому, что оно много раз повторялось.
Переход между этапами не обязан требовать нового подтверждения человека для каждого обратимого действия. Достаточно действующего поручения и ясных границ. Новое продуктовое решение, расширение доступа или необратимое действие требуют оценки в рамках правил проекта, а не автоматического продолжения по таблице.
При неудаче выбирайте маршрут по причине
Если тест не запускается из-за отсутствующего контейнера, это проблема среды. Если проверка выполнилась и обнаружила неправильную выдачу, это расхождение поведения. Если сам сценарий не отражает согласованное требование, нужно пересмотреть тест. Возвращать все три случая разработчику с командой «добейся зелёного» опасно.
В отчёте оставляйте результат команды и короткую классификацию, которую можно проверить. При новой гипотезе следующий запуск должен проверять именно её. Повторять ту же команду без изменения условий имеет смысл только при объяснимой временной причине.
Человек отвечает за переход к приёмке: все ли требования закрыты, кто выполнил проверки, что осталось неизвестным. Хороший маршрут делает эти решения видимыми. Он не превращает цепочку автоматических ответов в разрешение опубликовать результат, который никто не понял.
