Как собирать правки клиента, если они приходят в Telegram, почту и макет

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

Сначала отделите получение правок от их выполнения

Самая дорогая ошибка — начинать исправлять каждое замечание сразу после появления. Один комментарий пришёл в мессенджер — дизайнер уже открыл макет. Через час клиент уточнил формулировку, ещё через два часа отменил часть предыдущих изменений, а работа уже сделана.

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

Это не означает, что клиенту запрещают писать в привычных каналах. Он может оставить замечание хоть в Telegram, хоть в письме, хоть в Figma. Но внутри команды должен быть один человек или один понятный процесс, который переносит все эти комментарии в единый список.

Не заставляйте исполнителя искать изменения по перепискам

Фраза «там ещё клиент что-то писал вчера вечером» не должна становиться частью рабочего процесса. Исполнитель получает не историю общения, а готовый перечень изменений: что поменять, где именно, на какую формулировку и что оставить без изменений.

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

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

Зафиксируйте момент, когда пакет правок закрывается

У каждого раунда изменений должна быть граница. Например: все комментарии, полученные до 15:00 вторника, входят в текущий пакет и передаются исполнителю; всё, что приходит позже, относится к следующему раунду.

Без этой границы работа превращается в движущуюся мишень. Исполнитель исправляет пункт №7, пока клиент добавляет №8, №9 и меняет №3, поэтому невозможно даже понять, когда работа действительно закончена.

Граница не обязана быть жёсткой по времени. Можно использовать другой принцип: менеджер собирает замечания, клиент подтверждает итоговый список, после подтверждения пакет получает статус «В работе». Главное, чтобы существовал конкретный момент, после которого содержимое текущего раунда перестаёт меняться.

Дайте каждой правке понятный статус

Одного списка недостаточно, если в нём двадцать пунктов и непонятно, что с каждым происходит. Для рабочего пакета достаточно нескольких состояний: «Нужно уточнить», «Принято», «В работе», «Готово», «Отклонено».

Статус «Отклонено» здесь особенно полезен. Некоторые предложения клиента могут противоречить техническим ограничениям, уже согласованным требованиям или другим изменениям. Если просто удалить такой пункт, через неделю он легко появится снова. Лучше оставить его в истории с коротким пояснением, почему правку не вносили.

То же относится к объединённым комментариям. Если клиент трижды написал об одной проблеме разными словами, не нужно превращать это в три задачи. Сведите их в одну правку и сохраните исходные комментарии как контекст.

Версия должна определяться не названием файла

final.psd, final_2.psd, final_new.psd и final_new_really_final.psd работают ровно до первой серьёзной правки. После этого команда начинает открывать файлы и сравнивать их глазами.

Лучше привязывать версию к раунду изменений. Например: «Версия после правок №2 от 5 октября». Тогда понятно не только какая версия новее, но и какие именно изменения в неё должны были войти.

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

Новая правка после старта — это отдельное решение

Самая неудобная ситуация начинается, когда пакет уже в работе, а клиент присылает ещё одно «маленькое изменение». Автоматически добавлять его в текущую работу не стоит, потому что эта мелочь может затронуть уже выполненные пункты.

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

Так команда видит реальную стоимость поздних правок. Вместо ощущения «мы просто ещё кое-что поправили» появляется конкретный факт: после начала работы добавилось четыре новых изменения, два из них потребовали переделать уже готовые блоки.

Соберите весь раунд в одной карточке

Для клиентского проекта удобно создавать отдельную карточку на каждый пакет правок. В ней можно хранить финальный список изменений, приложить актуальные материалы, назначить исполнителя, поставить срок и пройтись по чек-листу перед отправкой результата клиенту.

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

После завершения карточку не нужно удалять. Она остаётся историей: какие изменения просил клиент, что команда сделала, какие предложения отклонила и какая версия стала результатом этого раунда.

Правки становятся проблемой не тогда, когда их много

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

Если определить единую точку сбора, момент закрытия пакета, статусы и правило для поздних изменений, команде больше не приходится выяснять, «учли ли сообщение из вчерашнего Telegram». У неё появляется конкретный список того, что нужно изменить сейчас, и понятная граница того, что относится уже к следующему раунду.