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