Самая дорогая фраза менеджера: «Да, сделаем на следующей неделе»

Клиент попросил «небольшую правку», менеджер сразу назвал срок, а команда узнала об обещании через несколько дней — вместе с вопросом «ну что, успеваем?». Так одна вежливая фраза превращается в незапланированную работу, сдвинутые задачи и дедлайн, на который никто из исполнителей не соглашался. Разбираемся, как принимать клиентские запросы, не превращая каждое «давайте добавим» в пожар.

Запрос клиента ещё не задача команды

Представим обычную ситуацию. Клиент пишет менеджеру: «А можем ещё добавить небольшой блок на лендинг? Хорошо бы на следующей неделе». Изменение выглядит мелким, поэтому ответ возникает автоматически: «Да, конечно».

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

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

Уберите из переписки автоматическое «сделаем»

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

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

«Небольшая правка» должна пройти проверку на размер

Размер изменения лучше оценивать не по количеству слов в сообщении клиента. «Добавьте ещё одно поле» может означать пять минут, а может потянуть изменения формы, валидации, интеграции, аналитики и текста ошибки.

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

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

Новая срочная задача должна вытеснять конкретную старую

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

Рабочее правило здесь простое: новая срочная задача не добавляется к плану — она меняет план. Если изменение клиента нужно сделать во вторник, сразу зафиксируйте, какая задача переезжает со вторника на другой срок. Желательно назвать её прямо в момент решения, а не надеяться, что команда somehow «ужмётся».

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

Соберите все клиентские изменения в одном месте

Ещё хуже обещаний в переписке — обещания в пяти разных переписках. Одна правка приходит в Telegram, вторая обсуждается на звонке, третья остаётся комментарием в макете. Через несколько дней никто уже не видит полный объём изменений, а менеджер помнит только самые свежие.

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

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

Введите короткое окно для оценки изменений

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

Клиент при этом не остаётся без ответа: менеджер подтверждает, что запрос получил, но срок называет после оценки. Так работа не останавливается после каждого сообщения, а менеджеру не приходится выдумывать дедлайн на ходу. Реальная критическая ошибка, конечно, не должна ждать условных 16:00 только ради красивого процесса, но если всё объявлять аварией, правило перестаёт что-либо значить.

У обещания должен быть хозяин

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

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

Раз в неделю посмотрите на цену клиентских «мелочей»

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

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

Это не запрещает клиенту менять мнение. Просто изменение начинает менять и план — явно, а не тайком.

Как собрать процесс на доске

Для клиентских запросов можно выделить простой поток: «Запрошено → На оценке → Согласовано → В работе → Готово». Сначала карточка фиксирует пожелание клиента, после оценки в ней появляется объём и возможный срок, и только после согласования задача попадает в рабочий план.

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

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