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