ситуации. Но ради создания учетной записи я готов остаться на работе допоздна, чтобы не нарушить срок.
Установку нового сервера (ТЗ) я отношу к категории «черных дыр». По идее, требуется несколько минут на монтаж оборудования, около часа на установку операционной системы и чуть больше часа на ее конфигурирование. По крайней мере, так считают производители. Мы-то, системные администраторы, знаем, что это нереально. В первый раз монтируя незнакомое устройство, вы не один час потратите на то, чтобы разобраться со своеобразной системой монтажа, изобретенной производителем. Процесс установки операционной системы на сервере, как правило, включает в себя ее многократную установку, настройку и последующее удаление, пока не будет достигнута идеальная конфигурация. (Этот ящик будет стоять тут несколько лет, так что имеет смысл потратить время на то, чтобы довести все до ума.) Конфигурирование тоже никогда не укладывается в предполагаемые рамки. Следовательно, браться за задачи типа «черная дыра» следует только после успешного завершения задач, время выполнения которых прогнозируется точнее.
Присваивая приоритет задаче Т6, мы немного отклонились от правил. Учитывая ожидаемое время выполнения этой задачи, можно было ожидать, что я запланирую ее на более раннее время — где-нибудь до задачи ТЗ. Однако на всех сайтах, с которыми я работал, сетевые новости Usenet имеют низкий приоритет, и работа с ними считается очень простой, чем-то вроде подарка для сотрудника. (Я никогда не встречал интернет-провайдера, у которого ситуация была бы иной.) Таким образом, решение низкоприоритетного вопроса переносится в конец списка. Общее правило гласит: если все согласны с низким приоритетом какой-то задачи (или он установлен руководством), то ее следует поместить в конец списка. Задумайтесь: если кто-то пожалуется, что одна из других задач не выполнена, как вы будете смотреть в глаза шефу, объясняя, что отложили клиентский запрос, занимаясь устранением небольшой ошибки в Usenet? Нет, только не это!
Просто? Да. Вам потребуется какая-то практика, но клиенты быстро заметят разницу.
Когда я излагаю эту систему, основное возражение, выдвигаемое моими слушателями, заключается в том, что их список дел меняется. В начале рабочего дня у них нет фиксированного списка дел, которые надо сделать. Новые дела добавляются в список на протяжении всего дня.
В таком случае следует применять технологию «Делегируйте, регистрируйте или действуйте», описанную в главе 2, где речь шла о прерываниях. Решая, как поступить, вы можете руководствоваться ожиданиями клиентов.
Запрос на восстановление пароля должен быть выполнен быстро, поскольку он задерживает другую работу. Следовательно, лучше сделать это самому, чем делегировать запрос другому сотруднику. И уж, конечно, не стоит регистрировать этот запрос, откладывая его выполнение и расстраивая планы клиента.
Описанные приемы годятся не только для расстановки приоритетов в вашем личном списке дел, но и для более масштабного планирования. Воспользуйтесь ими для организации работы всего отдела компьютерной поддержки!
Помните технику взаимной защиты от прерываний, описанную в главе 1? По сути, она позволяет вам действовать с учетом ожиданий клиентов. Ваш коллега перехватывает все прерывания в течение половины дня, чтобы вы могли поработать над проектами, а во второй половине дня вы меняетесь ролями. Фактически этот подход обеспечивает постоянное наличие системного администратора, готового снять вопросы, решение которых, по мнению клиентов, не займет много времени.
Большинство служб технической поддержки имеют двухуровневую структуру. Сотрудники первого уровня отвечают на телефонные звонки и переадресуют их на второй уровень, только если не в состоянии решить вопрос самостоятельно. Это не что иное, как вариант взаимной защиты от прерываний для всей команды, который обеспечивает время отклика, соответствующее ожиданиям пользователей!
Расстановка приоритетов, основанная на ожиданиях клиентов, и применение взаимной защиты от прерываний копируют работу службы технической поддержки, что свидетельствует в пользу предложенного мной подхода. А, может, как раз наоборот: двухуровневая структура службы технической поддержки хороша именно потому, что учитывает ожидания пользователей. В любом случае это круто, не так ли?
Приоритеты проектов
В предыдущих разделах были описаны способы расстановки приоритетов отдельных задач. Теперь я приведу некоторые полезные приемы присваивания приоритетов проектам.
Предположим, вы со своими коллегами-сисадминами по итогам мозгового штурма запланировали на следующий год двадцать замечательных проектов. Однако выделенного бюджета и имеющегося в вашем распоряжении персонала недостаточно для выполнения всех проектов. Какие выбрать?
Обычно я считаю, что получается лучше, когда выбираешь проекты, сулящие «максимальный эффект».
Заманчиво начать с самых легких проектов. Вы знаете, что делать; по поводу этих проектов нет разногласий, так что вы, по крайней мере, уверены, что они будут завершены.
Также заманчиво взяться за проекты, интересные лично вам, или за политически безопасные проекты, или за проекты, являющиеся логическим продолжением прежних проектов.
Устояв перед этими соблазнами, определите проекты, которые будут иметь максимальный положительный эффект в вашей организации. По сути, я утверждаю, что лучше осуществить один крупный проект со значительным положительным эффектом, чем несколько поверхностных проектов. Я убеждался в этом неоднократно. Когда вся команда работает над одним проектом, дело идет лучше, чем если бы каждый вел отдельный проект. Это происходит, потому что вместе мы работаем лучше.
Можно взглянуть на ситуацию с другой точки зрения. Все проекты можно разбить на четыре категории, как показано на рис. 8.3.
Очевидно, что начинать следует с проектов категории А. Простые проекты, имеющие значительный эффект, встречаются редко, и если у вас волшебным образом появляется такая работа, ее надо выполнять без раздумий. (Предупреждение: будьте бдительны, принадлежность проекта к категории А может быть кажущейся.)
Столь же очевидно, что нужно избегать проектов категории D. За трудоемкий проект, который ничего, в сущности, не изменит, не стоит и браться.
Однако большинство проектов принадлежит к категории В или С, а человек по натуре склонен к более легким проектам С. Вы можете заполнить весь год простыми проектами, отчитаться об их выполнении и выглядеть героем. В то же время в наиболее успешных компаниях применяется практика поощрения сотрудников, берущихся за проекты категории В — трудные, но необходимые.
Переформулируем вопрос в терминах возврата на инвестиции (return on investment, ROI), чтобы подтвердить разумность описанного подхода. Предположим, вы собираетесь в будущем году потратить определенную сумму. Вложите ли вы деньги в большое количество несущественных проектов? Нет, вы постараетесь найти более эффективный проект и инвестируете средства в него.
Важно убедиться, что выбранный вами проект скоординирован с задачами вашей фирмы. Это важно как для компании, так и для вас. В результате вас будут выше ценить.
Запросы, поступающие от начальства
