Тайм-менеджмент для системных администраторов - [17]
Конечно, все клиенты хотят, чтобы их запросы были удовлетворены, но каждый знает, что не всегда удается получить желаемое. Однако если люди не чувствуют уважительного отношения, они не будут довольны. В худшем случае они решат, что вы их игнорируете; в лучшем — сочтут, что вы заняты чем-то другим, когда на самом деле вы решаете их проблему.
Разве клиенты не хотят всего и сразу? Нет. Я полагаю, что в глубине души клиенты понимают, что это не всегда возможно. Прося вас заказать новый компьютер, они отдают себе отчет, что нет смысла стоять в вашем кабинете и ждать, пока он прибудет, даже при условии поставки на следующий день. Их вполне удовлетворит, если вы примете запрос и сообщите дату выполнения заказа.
Клиентам важнее видеть деятельность, чем получить ее результаты
Однажды ко мне в комнату ворвался клиент.
«Сервер XYZ полетел!» — вскричал он в панике.
«Я им занимаюсь!» — ответил я.
Я повернулся к монитору и продолжал время от времени вводить команды. С точки зрения клиента все выглядело так, словно я вернулся к своей работе, полностью игнорируя его беспокойство.
Это было в те времена, когда еще только появились удаленные консоли и дистанционные коммутаторы «клавиатура/видеоадаптер/мышь» (KVM-устройства). Я делал все, чтобы решить проблему, но клиент не видел моей реакции на его слова.
Он был очень разочарован. По его представлениям, чтобы «починить сервер», я должен был вскочить с места, побежать по коридору, набрать секретный код на двери, ведущей в машинный зал, и начать копаться в сервере. Поскольку мое поведение не соответствовало его ожиданиям, он высказал свое недовольство, не стесняясь в выражениях. Он решил, что я собираюсь сидеть и ждать, пока сервер починится сам собой. Я сумел разубедить его, только показав, что происходит на мониторе.
Теперь, если происходит нечто подобное, я исхожу из того, что клиент ничего не знает о консольных серверах и дистанционных коммутаторах «клавиатура/видеоадаптер/мышь». Сперва я проверяю, что сервер действительно отказал и поясняю клиенту, какой тест я выполняю. Я говорю: «Запустим ping! Действительно, сервер не отвечает». Затем вместо того, чтобы броситься в машинный зал, я говорю: «Смотрите. Я могу обратиться к консоли удаленным образом, словно бы я находился в машинном зале!» Я поворачиваю монитор так, чтобы клиент видел, что я делаю. Я устраиваю небольшое «показательное выступление», а затем приступаю к непосредственному решению проблемы.
Вскоре клиенту становится скучно, и он уходит довольный, что я работаю над его вопросом.
Моя демонстрация немного тормозит работу, но все равно занимает меньше времени, чем если бы я отправился в машинный зал. А клиент удовлетворен, потому что получает визуальное подтверждение того, что его запрос принят.
Скучающий, но довольный клиент гораздо лучше клиента беспокойного и нетерпеливо ждущего.
И наоборот, клиенты будут крайне недовольны, если у них возникнет впечатление, что вы их игнорируете. Совершенно не имеет значения, игнорируете ли вы их на самом деле. Если вы начнете решать их проблему, но клиенты этого не будут знать, они предположат, что вы ничего не делаете. Обидно, но это правда. Надеюсь, я убедил вас, как важно принимать запросы клиентов. Не менее важно для вас организовать свое время в соответствии с вашими приоритетами. Как разрешить этот конфликт? С помощью метода «Делегируйте, регистрируйте или действуйте».
Читайте следующий раздел.
Когда клиент прерывает вашу работу над проектом, у вас есть три варианта:
• Делегировать запрос. Если кто-то другой может решить проблему, передайте запрос ему.
• Зарегистрировать запрос. Если справиться с проблемой можете только вы, но она несрочная, зарегистрируйте запрос. Сделайте это убедительно для клиента; простого обещания запомнить недостаточно.
• Действовать. Если проблема действительно неотложная, например отказ какой-то службы, отложите текущую работу и займитесь решением проблемы.
Я каждый раз обдумываю, как поступить, — делегировать, регистрировать или действовать. Это помогает мне сосредоточиться на выполнении запроса клиента, который, увы, прервал мою работу. Подробности этого процесса описаны в следующих разделах.
Если вы установили взаимную защиту от прерываний, описанную в начале главы 1, вы можете отослать клиента к своему партнеру. Вовсе не обязательно говорить: «Я сейчас занят проектом, так что оправляйтесь к другому сисадмину». Можно поступить гораздо вежливее.
Поскольку людям требуется визуальное позитивное подтверждение, что их слышат и воспринимают всерьез, я думаю, что лучшей тактикой в данном случае будет звонок вашему партнеру по взаимной защите и делегирование запроса на глазах у клиента.
Люди не хотят заново объяснять свою проблему каждому, к кому их делегируют, поэтому я всегда излагаю суть вопроса своему коллеге. Я часто могу сформулировать ее в технических терминах гораздо эффективнее, чем клиент.
Итак, вот общая линия поведения. Я громко говорю: «Я попрошу Мэри заняться этой проблемой». Затем я звоню Мэри: «Привет! Тут у меня Джо. Ему нужно то-то и то-то». Я поворачиваюсь к клиенту: «Мэри ждет Вас и готова Вам помочь». Джо получает подтверждение, что его запрос принят, а Мэри готова решить проблему.