Конечно, все клиенты хотят, чтобы их запросы были удовлетворены, но каждый знает, что не всегда удается получить желаемое. Однако если люди не чувствуют уважительного отношения, они не будут довольны. В худшем случае они решат, что вы их игнорируете; в лучшем — сочтут, что вы заняты чем-то другим, когда на самом деле вы решаете их проблему.
Разве клиенты не хотят всего и сразу? Нет. Я полагаю, что в глубине души клиенты понимают, что это не всегда возможно. Прося вас заказать новый компьютер, они отдают себе отчет, что нет смысла стоять в вашем кабинете и ждать, пока он прибудет, даже при условии поставки на следующий день. Их вполне удовлетворит, если вы примете запрос и сообщите дату выполнения заказа.
Клиентам важнее видеть деятельность, чем получить ее результаты
Однажды ко мне в комнату ворвался клиент.
«Сервер XYZ полетел!» — вскричал он в панике.
«Я им занимаюсь!» — ответил я.
Я повернулся к монитору и продолжал время от времени вводить команды. С точки зрения клиента все выглядело так, словно я вернулся к своей работе, полностью игнорируя его беспокойство.
Это было в те времена, когда еще только появились удаленные консоли и дистанционные коммутаторы «клавиатура/видеоадаптер/мышь» (KVM-устройства). Я делал все, чтобы решить проблему, но клиент не видел моей реакции на его слова.
Он был очень разочарован. По его представлениям, чтобы «починить сервер», я должен был вскочить с места, побежать по коридору, набрать секретный код на двери, ведущей в машинный зал, и начать копаться в сервере. Поскольку мое поведение не соответствовало его ожиданиям, он высказал свое недовольство, не стесняясь в выражениях. Он решил, что я собираюсь сидеть и ждать, пока сервер починится сам собой. Я сумел разубедить его, только показав, что происходит на мониторе.
Теперь, если происходит нечто подобное, я исхожу из того, что клиент ничего не знает о консольных серверах и дистанционных коммутаторах «клавиатура/видеоадаптер/мышь». Сперва я проверяю, что сервер действительно отказал и поясняю клиенту, какой тест я выполняю. Я говорю: «Запустим ping! Действительно, сервер не отвечает». Затем вместо того, чтобы броситься в машинный зал, я говорю: «Смотрите. Я могу обратиться к консоли удаленным образом, словно бы я находился в машинном зале!» Я поворачиваю монитор так, чтобы клиент видел, что я делаю. Я устраиваю небольшое «показательное выступление», а затем приступаю к непосредственному решению проблемы.
Вскоре клиенту становится скучно, и он уходит довольный, что я работаю над его вопросом.
Моя демонстрация немного тормозит работу, но все равно занимает меньше времени, чем если бы я отправился в машинный зал. А клиент удовлетворен, потому что получает визуальное подтверждение того, что его запрос принят.
Скучающий, но довольный клиент гораздо лучше клиента беспокойного и нетерпеливо ждущего.
И наоборот, клиенты будут крайне недовольны, если у них возникнет впечатление, что вы их игнорируете. Совершенно не имеет значения, игнорируете ли вы их на самом деле. Если вы начнете решать их проблему, но клиенты этого не будут знать, они предположат, что вы ничего не делаете. Обидно, но это правда. Надеюсь, я убедил вас, как важно принимать запросы клиентов. Не менее важно для вас организовать свое время в соответствии с вашими приоритетами. Как разрешить этот конфликт? С помощью метода «Делегируйте, регистрируйте или действуйте».
Читайте следующий раздел.
Когда клиент прерывает вашу работу над проектом, у вас есть три варианта:
• Делегировать запрос. Если кто-то другой может решить проблему, передайте запрос ему.
• Зарегистрировать запрос. Если справиться с проблемой можете только вы, но она несрочная, зарегистрируйте запрос. Сделайте это убедительно для клиента; простого обещания запомнить недостаточно.
• Действовать. Если проблема действительно неотложная, например отказ какой-то службы, отложите текущую работу и займитесь решением проблемы.
Я каждый раз обдумываю, как поступить, — делегировать, регистрировать или действовать. Это помогает мне сосредоточиться на выполнении запроса клиента, который, увы, прервал мою работу. Подробности этого процесса описаны в следующих разделах.
Если вы установили взаимную защиту от прерываний, описанную в начале главы 1, вы можете отослать клиента к своему партнеру. Вовсе не обязательно говорить: «Я сейчас занят проектом, так что оправляйтесь к другому сисадмину». Можно поступить гораздо вежливее.
Поскольку людям требуется визуальное позитивное подтверждение, что их слышат и воспринимают всерьез, я думаю, что лучшей тактикой в данном случае будет звонок вашему партнеру по взаимной защите и делегирование запроса на глазах у клиента.
Люди не хотят заново объяснять свою проблему каждому, к кому их делегируют, поэтому я всегда излагаю суть вопроса своему коллеге. Я часто могу сформулировать ее в технических терминах гораздо эффективнее, чем клиент.
Итак, вот общая линия поведения. Я громко говорю: «Я попрошу Мэри заняться этой проблемой». Затем я звоню Мэри: «Привет! Тут у меня Джо. Ему нужно то-то и то-то». Я поворачиваюсь к клиенту: «Мэри ждет Вас и готова Вам помочь». Джо получает подтверждение, что его запрос принят, а Мэри готова решить проблему.
♥ Будучи технически грамотными, мы нередко забываем, каково нетехнарю сформулировать запрос. Это очень трудно, может быть, даже страшно. Объясняя Мэри, чего хочет Джо, я облегчаю ему жизнь.
Иногда запрос оказывается достаточно сложным, и я боюсь, что в разговоре с Мэри что-то упущу. Тем не менее я должен помочь ей подготовиться. Например: «Привет! Тут у меня Джо. У него довольно сложная проблема с веб-сервером. Я его сейчас пришлю к тебе».
Конечно, бывают ситуации, когда вы спешите и просто не можете позвонить партнеру. Я думаю, неприемлемо отвечать клиенту: «А с Мэри Вы разговаривали?» Гораздо лучше: «Сейчас за это отвечает Мэри. Поговорите с ней, пожалуйста». Звучит официально и выглядит как инструкция. Следуя официальным процедурам, люди испытывают определенный комфорт.
Если ваш партнер по взаимной защите от прерываний отвечает, что не сумеет справиться с той проблемой, которую вы ему делегируете, у вас есть несколько вариантов. Во-первых, можно воспользоваться случаем, чтобы научить его самостоятельно решать такие проблемы впредь. Это окажется кстати в будущем. Во-вторых, вы можете договориться с клиентом решить его проблему позже. Если вам удастся, зарегистрируйте запрос.
Если вопрос может подождать, зарегистрируйте его, чтобы решить в более удобное время. Сделайте это так, чтобы он потом не потерялся. Все должно произойти на глазах клиента, чтобы он получил визуальное подтверждение, что его не игнорируют.
Если вы придерживаетесь системы Цикл, описанной в главе 5, занесите запрос в список дел. Это приемлемо для небольших задач, решаемых за короткое время.
Большие задачи я предпочитаю регистрировать с помощью специализированной программы. Я обнаружил, что приложение с открытым кодом RT от компании Best Practical (http://www.BestPractical.com) лучше любой коммерческой системы. (Издательство O'Reilly не так давно выпустило книгу «RT Essentials» (Основы RT), где подробно описаны конфигурирование и работа с RT.) При отправке электронного сообщения в адрес RT этот запрос автоматически регистрируется и отслеживается. Если у вас нет RT, отправьте запрос клиента самому себе по электронной почте. А пока клиентов нет, отправьте себе напоминание установить RT.