Когда поставленная клиентом задача — нестандартная, многоэтапная или зависит от множества параметров, велик соблазн не называть ему никаких сроков. Казалось бы, лучше промолчать, чем обмануть и подвести. Однако это вредная установка: отказаться от сроков — все равно что снять с себя ответственность за решение проблемы (а это признак дремучего непрофессионализма для всех, кто имеет дело с клиентами). Cроки следует называть всегда — просто нужно «уметь их готовить».
Решение любой задачи состоит из нескольких шагов. На первом этапе мы еще не знаем, когда наступит пятый, но можем смело предположить время наступления второго.
В разговоре с клиентом любую задачу можно декомпозировать. Объясните ему, как именно будет решаться его проблема, и назовите сроки следующего шага (или шагов), которые вам точно известны. Вот несколько примеров, как это работает:
— У вас тут что-то сломалось, когда почините?
— Похоже на баг, передаю задачу нашим тестировщикам. Не позднее 16:00 я к вам вернусь и сообщу итоги. Далее задача пойдет на оценку (она у нас по вторникам). Как только разработчики оценят, во вторник я вам сообщу, в каком из спринтов окажется задача.
— А можете сделать фичу? И когда?
— Обычно продуктовая команда обсуждает новые запросы клиентов по средам. Если фичу примут в работу, ее нужно будет спроектировать, а потом оценить и определить приоритет, — и тогда мы поймем, сколько на нее понадобится времени. Ждите от меня в четверг промежуточный результат решения продуктовой команды.
— А когда вы пришлете коммерческое предложение?
— Мы готовим для вас персональное предложение, поэтому я хочу обсудить с руководством дополнительные услуги и скидки для вас. Встреча у нас назначена на 18:00, а подробный документ я пришлю вам завтра не позднее 14:00.
Называйте сроки с запасом
Так вы убьете сразу двух зайцев: обезопасите себя от несоблюдения дедлайна, а если успеете сделать быстрее — превзойдете ожидания клиента. Для простоты умножайте на 2: если знаете, что выполните задачу завтра, — обещайте на послезавтра.
И ни в коем случае не называйте сроки раньше реальных (иногда на это идут, чтобы удержать клиента). Если вы нарушите договоренности, сделаете себе только хуже.
Не доводите дело до стадии, когда клиент начнет «пинать» вас по срокам. Напротив, вы сами должны каждый раз в оговоренное время сообщать ему о ходе выполнения задачи, а именно:
- на какой стадии сейчас находится решение вопроса;
- когда приступят к следующему этапу;
- конкретные сроки следующего «касания».
Последнее — самое важное. Забудьте о вариантах «в течение дня», «как только, так сразу», «постараемся к концу недели». Устанавливайте четкие сроки: например «не позднее 18:00», «во вторник до 12 я вернусь к вам».
Здесь важно понимать, что вы работаете с клиентом («продажник», поддержка или аккаунт-менеджер) и не занимаетесь непосредственно разработкой, продактом или юридическим сопровождением. А значит, не можете повлиять на решение бага, сроки проектирования фичи или согласования договора. Вы можете только общаться с клиентом, держать его в курсе, выполнять обещания и создавать впечатление, что все под контролем. От вас не требуется называть конкретные даты выполнения задачи, главное — обещать и возвращаться вовремя с новым статусом.
А если что-то пошло не так?
- Иногда невозможно назвать даже время следующего шага (скажем, произошел крупный сбой и для начала нужно разобраться в его причинах). В этом случае сообщаем клиенту сроки, в которые появится хоть какая-то ясность, например: «Нам нужен таймаут от получаса до 2 часов, не позднее 17.00 я вернусь к вам с апдейтом».
- Случается, что коллеги дезинформировали вас по срокам. Как только вы это поняли — сообщите клиенту об изменениях (но сделайте это раньше уже оговоренного с ним ближайшего «касания»).
- Чтобы ваши коллеги не подводили вас по срокам, договаривайтесь с ними «на берегу», например: «Если что-то изменится, сообщи мне за 4 часа до дедлайна». Таким образом вы даете себе время на workaround, а коллегу избавляете от позора, когда он за 5 минут до дедлайна говорит: «Ничего не готово, прости». В идеале, все участники цепочки по выполнению задачи должны относиться друг к другу как к клиентам — в этом случае вероятность дезинформации сведется к минимуму.