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