Рис. 8.2. Задачи, упорядоченные в соответствии с ожиданиями пользователей
Если бы возникла аварийная ситуация (например, из-за того, что два хоста оказались сконфигурированы с одним IP-адресом) и вся работа остановилась, то наше расписание было бы нарушено. Тем не менее я все равно постарался бы создать учетную запись до появления нового сотрудника. Другие дела пришлось бы отложить на день, и это не вызвало бы непонимания клиентов в условиях аварийной ситуации. Но ради создания учетной записи я готов остаться на работе допоздна, чтобы не нарушить срок.
Установку нового сервера (ТЗ) я отношу к категории «черных дыр». По идее, требуется несколько минут на монтаж оборудования, около часа на установку операционной системы и чуть больше часа на ее конфигурирование. По крайней мере, так считают производители. Мы-то, системные администраторы, знаем, что это нереально. В первый раз монтируя незнакомое устройство, вы не один час потратите на то, чтобы разобраться со своеобразной системой монтажа, изобретенной производителем. Процесс установки операционной системы на сервере, как правило, включает в себя ее многократную установку, настройку и последующее удаление, пока не будет достигнута идеальная конфигурация. (Этот ящик будет стоять тут несколько лет, так что имеет смысл потратить время на то, чтобы довести все до ума.) Конфигурирование тоже никогда не укладывается в предполагаемые рамки. Следовательно, браться за задачи типа «черная дыра» следует только после успешного завершения задач, время выполнения которых прогнозируется точнее.
Присваивая приоритет задаче Т6, мы немного отклонились от правил. Учитывая ожидаемое время выполнения этой задачи, можно было ожидать, что я запланирую ее на более раннее время — где-нибудь до задачи ТЗ. Однако на всех сайтах, с которыми я работал, сетевые новости Usenet имеют низкий приоритет, и работа с ними считается очень простой, чем-то вроде подарка для сотрудника. (Я никогда не встречал интернет-провайдера, у которого ситуация была бы иной.) Таким образом, решение низкоприоритетного вопроса переносится в конец списка. Общее правило гласит: если все согласны с низким приоритетом какой-то задачи (или он установлен руководством), то ее следует поместить в конец списка. Задумайтесь: если кто-то пожалуется, что одна из других задач не выполнена, как вы будете смотреть в глаза шефу, объясняя, что отложили клиентский запрос, занимаясь устранением небольшой ошибки в Usenet? Нет, только не это!
Просто? Да. Вам потребуется какая-то практика, но клиенты быстро заметят разницу.