Книга: Тайм-менеджмент для системных администраторов

Как прогнать клиента, не нахамив ему

Как прогнать клиента, не нахамив ему

Предположим, кто-то прерывает вашу работу. Как избавиться от него повежливее? Секрет в том, чтобы принять его запрос со всем уважением.

Как говорилось в предыдущей главе, иногда наша работа заключается именно в обработке прерываний — в том, чтобы оградить от прерываний других системных администраторов, которым надо сосредоточиться над проектами. Однако и у нас бывает время работы над проектом, когда нам надо сохранять сосредоточенность. Как поступать, если нас отвлекают в это время?

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

Когда клиент входит в мою комнату и просит сделать что-то, что я планирую отложить на более позднее время, я вербально и визуально даю ему понять, что его запрос принят. Сперва я говорю: «Я понял Вашу проблему. Сейчас я запишу, чтобы не забыть». Далее я при нем записываю его запрос, произнося его вслух. Обычно я формулирую так: «[Сделать то-то и то-то] для [такого-то] к [такой-то дате]». Теперь я поворачиваюсь к клиенту и спрашиваю: «Я Вас правильно понял?» Если он отвечает «Да», вопрос закрыт, и клиент уходит сам, если я только не произнесу чего-нибудь такого, что разрушит ситуацию. Я экспериментально установил, что лучший вариант — сказать «Спасибо» и кивнуть.

Любой другой ответ приведет к возобновлению диалога. Когда вопрос закрыт, клиенту трудно требовать, чтобы я тут же начал действовать. Если он все-таки требует этого, значит, я недооценил срочность его проблемы, и нам следует обсудить сроки ее решения. Однако теперь уже я веду беседу и, следовательно, владею инициативой в переговорах.

Автоматизированные системы регистрации запросов тоже должны проявлять уважение к клиентам. Когда клиент отправляет электронное сообщение такой системе, она должна автоматически возвращать идентификационный номер запроса. Если клиент обращается к веб-системе, она должна немедленно вывести статус запроса, чтобы клиент был уверен, что запрос сохранен в базе данных. Людям неприятно ощущать, что они отправляют запрос в черную дыру. Идеальным вариантом был бы персональный ответ, но это нереально. Вполне достаточно автоматического подтверждения, что запрос принят. Отсутствие отклика системы держит клиента в «подвешенном» состоянии. К тому же это невежливо. Отсутствие реакции — одна из причин, по которым я не люблю отправлять большие отчеты некоторым производителям. Сейчас стало модным встраивать в приложения автоматическую отправку сообщения о произошедшем сбое. У Netscape есть FullCircle, у Microsoft — свой агент обратной связи, в Apple Mac OS X тоже есть нечто подобное. Эти производители оставляют меня в состоянии неудовлетворенности, поскольку не подтверждают получение моего сообщения. У меня нет никакого способа убедиться, что это не мистификация, призванная убедить пользователей, что производитель о них заботится, в то время как все запросы фактически уничтожаются. Я не ожидаю, что раздастся звонок от менеджера по продажам: «Помните ваше сообщение о сбое на прошлой неделе? Спасибо! Мы устранили ошибку и присвоили вам почетное звание Лучшего клиента месяца!» И все-таки было бы неплохо получить электронное уведомление о получении моего сообщения. (Должен заметить, что когда Том Рейнголд (Tom Reingold) служил в Bell Labs, он не только звонил каждому, кто прислал очередной тысячный запрос, но и приглашал этого клиента на ланч, пользуясь возможностью узнать его мнение о том, как можно улучшить обслуживание. Вот так!)

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

Разве клиенты не хотят всего и сразу? Нет. Я полагаю, что в глубине души клиенты понимают, что это не всегда возможно. Прося вас заказать новый компьютер, они отдают себе отчет, что нет смысла стоять в вашем кабинете и ждать, пока он прибудет, даже при условии поставки на следующий день. Их вполне удовлетворит, если вы примете запрос и сообщите дату выполнения заказа.

И наоборот, клиенты будут крайне недовольны, если у них возникнет впечатление, что вы их игнорируете. Совершенно не имеет значения, игнорируете ли вы их на самом деле. Если вы начнете решать их проблему, но клиенты этого не будут знать, они предположат, что вы ничего не делаете. Обидно, но это правда. Надеюсь, я убедил вас, как важно принимать запросы клиентов. Не менее важно для вас организовать свое время в соответствии с вашими приоритетами. Как разрешить этот конфликт? С помощью метода «Делегируйте, регистрируйте или действуйте».

Читайте следующий раздел.

Когда клиент прерывает вашу работу над проектом, у вас есть три варианта:

• Делегировать запрос. Если кто-то другой может решить проблему, передайте запрос ему.

• Зарегистрировать запрос. Если справиться с проблемой можете только вы, но она несрочная, зарегистрируйте запрос. Сделайте это убедительно для клиента; простого обещания запомнить недостаточно.

• Действовать. Если проблема действительно неотложная, например отказ какой-то службы, отложите текущую работу и займитесь решением проблемы.

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

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

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

Люди не хотят заново объяснять свою проблему каждому, к кому их делегируют, поэтому я всегда излагаю суть вопроса своему коллеге. Я часто могу сформулировать ее в технических терминах гораздо эффективнее, чем клиент.

Итак, вот общая линия поведения. Я громко говорю: «Я попрошу Мэри заняться этой проблемой». Затем я звоню Мэри: «Привет! Тут у меня Джо. Ему нужно то-то и то-то». Я поворачиваюсь к клиенту: «Мэри ждет Вас и готова Вам помочь». Джо получает подтверждение, что его запрос принят, а Мэри готова решить проблему.

? Будучи технически грамотными, мы нередко забываем, каково нетехнарю сформулировать запрос. Это очень трудно, может быть, даже страшно. Объясняя Мэри, чего хочет Джо, я облегчаю ему жизнь.

Иногда запрос оказывается достаточно сложным, и я боюсь, что в разговоре с Мэри что-то упущу. Тем не менее я должен помочь ей подготовиться. Например: «Привет! Тут у меня Джо. У него довольно сложная проблема с веб-сервером. Я его сейчас пришлю к тебе».

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

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

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

Если вы придерживаетесь системы Цикл, описанной в главе 5, занесите запрос в список дел. Это приемлемо для небольших задач, решаемых за короткое время.

Большие задачи я предпочитаю регистрировать с помощью специализированной программы. Я обнаружил, что приложение с открытым кодом RT от компании Best Practical (http://www.BestPractical.com) лучше любой коммерческой системы. (Издательство O'Reilly не так давно выпустило книгу «RT Essentials» (Основы RT), где подробно описаны конфигурирование и работа с RT.) При отправке электронного сообщения в адрес RT этот запрос автоматически регистрируется и отслеживается. Если у вас нет RT, отправьте запрос клиента самому себе по электронной почте. А пока клиентов нет, отправьте себе напоминание установить RT.

Чтобы продемонстрировать клиенту, что его запрос принят, я громко сообщаю «Сейчас я внесу Ваш запрос в список дел» или «Сейчас я сделаю запись в RT". Затем, вводя текст, я читаю его: "Джилл нужно установить принтер. Он у нее в комнате в коробке. Это надо сделать в четверг до 9 часов вечера».

? Всегда записывайте время, к которому должна быть выполнена работа. Если вы напишете просто «четверг», клиент может подумать, что речь идет об утре четверга, в то время как вы имеете в виду вечер.

Введя запрос (текст которого клиент слышал), я спрашиваю: «Я ничего не упустил?» Это помогает избежать недопонимания. Кроме того, клиент получает удовлетворение от мысли, что он управляет процессом; в какой-то мере, так оно и есть.

Щелкнув по нужной кнопке, я говорю «Готово!» и возвращаюсь к своим делам. Регистрация запроса в RT, органайзере или списке дел свидетельствует о вашем профессионализме и заставляет вашего клиента доверять вам. Запись на случайных обрывках бумаги или самоклеящихся листочках производит обратный эффект.

Ни в коем случае не полагайтесь только на свою память. Я уже говорил о необходимости загружать переднюю часть мозга более важными вещами. Не пытайтесь запомнить запрос клиента. Вы умны (и отлично выглядите), но не следует поручать мозгу то, что лучше доверить бумаге. Запишите запрос и забудьте о нем. Освободите свой мозг. В результате нас ожидает…

Третий вариант — выполнить запрос немедленно. Вы потеряли сосредоточенность над текущей работой, но по крайней мере сделали две попытки отклонить запрос. Если его решение потребует две минуты, то дешевле сделать все сразу, чем записывать вопрос, а потом возвращаться к нему.

Конечно, если проблема неотложная или возникла аварийная ситуация, то у вас нет выбора. В конце концов, аварийная ситуация может повлиять и на вас лично, так что лучше действовать, не мешкая.

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

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

Оглавление книги