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

Лимончелли Томас

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

(На самом деле, скорее всего, раздраженный нетерпеливый клиент не стал бы ждать целый день. Он «пинговал» бы IP-адреса до тех пор, пока не нашел свободный на тот момент и не воспользовался бы им. Мог случиться какой-нибудь конфликт, и вся система перестала бы работать, и вы потеряли

бы на этом целый день. Впрочем, я отвлекся…).

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

Вы начинаете свой день с выполнения задач Т1 и Т7, потому что клиенты ожидают их скорого выполнения, и еще потому, что эти задачи, скорее всего, тормозят крупные проекты. Вы, конечно, уложитесь в предполагаемые сроки выполнения этих задач.

Следующая задача (Т5) относится к категории «Поспеши и подожди». Независимо от того, насколько быстро вы оформите заказ, он будет выполнен только через день-два. Однако если вы не будете тянуть с заказом, то избежите претензий со стороны клиента.

Следующая задача (Т4) выполняется за 30 минут. Можете проверить.

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

Рис. 8.2. Задачи, упорядоченные в соответствии с ожиданиями пользователей

Если бы возникла аварийная ситуация (например, из-за того, что два хоста оказались сконфигурированы с одним IP-адресом) и вся работа остановилась, то наше расписание было бы нарушено. Тем не менее я все равно постарался бы создать учетную запись до появления нового сотрудника. Другие дела пришлось бы отложить на день, и это не вызвало бы непонимания клиентов в условиях аварийной ситуации. Но ради создания учетной записи я готов остаться на работе допоздна, чтобы не нарушить срок.

Установку нового сервера (ТЗ) я отношу к категории «черных дыр». По идее, требуется несколько минут на монтаж оборудования, около часа на установку операционной системы и чуть больше часа на ее конфигурирование. По крайней мере, так считают производители. Мы-то, системные администраторы, знаем, что это нереально. В первый раз монтируя незнакомое устройство, вы не один час потратите на то, чтобы разобраться со своеобразной системой монтажа, изобретенной производителем. Процесс установки операционной системы на сервере, как правило, включает в себя ее многократную установку, настройку и последующее удаление, пока не будет достигнута идеальная конфигурация. (Этот ящик будет стоять тут несколько лет, так что имеет смысл потратить время на то, чтобы довести все до ума.) Конфигурирование тоже никогда не укладывается в предполагаемые рамки. Следовательно, браться за задачи типа «черная дыра» следует только после успешного завершения задач, время выполнения которых прогнозируется точнее.

Присваивая приоритет задаче Т6, мы немного отклонились от правил. Учитывая ожидаемое время выполнения этой задачи,

можно было ожидать, что я запланирую ее на более раннее время — где-нибудь до задачи ТЗ. Однако на всех сайтах, с которыми я работал, сетевые новости Usenet имеют низкий приоритет, и работа с ними считается очень простой, чем-то вроде подарка для сотрудника. (Я никогда не встречал интернет-провайдера, у которого ситуация была бы иной.) Таким образом, решение низкоприоритетного вопроса переносится в конец списка. Общее правило гласит: если все согласны с низким приоритетом какой-то задачи (или он установлен руководством), то ее следует поместить в конец списка. Задумайтесь: если кто-то пожалуется, что одна из других задач не выполнена, как вы будете смотреть в глаза шефу, объясняя, что отложили клиентский запрос, занимаясь устранением небольшой ошибки в Usenet? Нет, только не это!

Просто? Да. Вам потребуется какая-то практика, но клиенты быстро заметят разницу.

Делегируйте, регистрируйте или действуйте

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

В таком случае следует применять технологию «Делегируйте, регистрируйте или действуйте», описанную в главе 2, где речь шла о прерываниях. Решая, как поступить, вы можете руководствоваться ожиданиями клиентов.

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

Взаимная защита от прерываний

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

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

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

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

Приоритеты проектов

В предыдущих разделах были описаны способы расстановки приоритетов отдельных задач. Теперь я приведу некоторые полезные приемы присваивания приоритетов проектам.