По сфере своей деятельности я часто общаюсь со своими коллегами по цеху – системными администраторами, программистами и другими работниками ИТ-деятельности не только в своей компании. При обсуждении повседневных задач с ними меня поражает то, что время, потраченное ими на «авральные» и аварийные работы, превышает время, которое тратится на нормальный ритм работы. А вовремя попасть домой для них – большая редкость. Еще больший отпечаток на такой режим работ вводят корпоративная культура и принципы менеджмента в вашей организации. Нормальным я считаю такое время, когда системный администратор занимается планированием развития сети и серверной инфраструктуры, когда проверяет резервные копии. Это еще могут быть плановые работы по установке обновлений для почтового сервера, написание инструкции для пользователей, ведение документации серверной инфраструктуры, тестирование нового ПО и самообучение. Все идет спокойно и предсказуемо. Да, бывают аварийные работы, но это исключение из нормального режима работы, а не правило.

Сейчас модной тенденцией стали управление своим временем и применение принципов «тайм-менеджмента» в работе и личной жизни. Шекспир в уста Макбета вложил базовую позицию по отношению ко времени: «Мы время вспять не властны повернуть». Ну раз обратно нельзя, то то, что предстоит, можно провести более эффективнее. Время для сотрудников ИТ-службы и их задач бежит по-другому, и классические методы «тайм-менеджмента», которые эффективны там, где рабочее время с «9 до 18», не всегда применимы. Чтобы ИТ-специалисту довести себя до состояния «загнанной и больной лошади», особых усилий не требуется. Достаточно на работе просто плыть по течению ИТ-процессов и не вдумываться в смысл слов «эффективная трата рабочего времени». Не надо искать способности оптимизировать текущее, достаточно залатывать возникающие дырки, чаще предлагать обходные решения и собирать что-нибудь на коленке вместо кардинального изменения, и наступит момент, когда ваша работа превратится в каторгу и будет забирать слишком много времени в сутки.

Общаясь с коллегами, я выявил несколько наиболее актуальных вопросов управления временем в ИТ-проектах:

• Как правильно ранжировать задания, как устоять и не сломаться, если начальников много, а технических и психологических ресурсов не хватает?

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

• Как можно извлечь из рутинной работы время для самообразования, выполнения важных плановых работ, на которые никогда не хватало времени?

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

Рис. 10.1. Магический квадрат приоритетов – способ сортировки наших ежедневных задач

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

Надо понять, за что браться сразу, а за что потом. Что главнее. Слово приоритет происходит от латинского prior – первый, старший. Но все задачи не могут быть главными. Можно распределять задачи по группам A, B, C и выставлять коэффициенты от 1 до 3, чтобы понимать, за какую задачу нужно браться сначала, а за какую потом. Мне кажется такой подход сложным, он требует траты драгоценного времени на двойное ранжирование, перемещения уже имеющихся задач в текущем списке. Ну и наконец, давайте будем откровенны сами с собой – даже половину того, что мы «напланировали», мы, скорее всего, не сможем выполнить. А наша деятельность в глазах работодателя или начальника должна быть эффективной, приносящей пользу компании. Если мы продемонстрируем работодателю все это, тогда наши результаты могут положительно сказаться на нашем карьерном росте.

Для быстрого ранжирования задач лучше использовать простой квадрат приоритетов – всего 4 ячейки, куда и будем ранжировать поступающие к нам задачи. Для отнесения задачи используются всего 2 критерия – принесенный решением задачи эффект и ее сложность. Каждую поступающую задачу нужно регистрировать. Абсолютно любую, даже самую мелкую. В ежедневник или ServiceDesk-систему. Это может быть даже Excel-файл. И несколько секунд потратим, чтобы понять, в какой из квадратов мы определим задачу.

Почему регистрировать задачи важно:

• это позволяет быстро давать отчет вышестоящему руководству на вопрос «чем вы занимались и сколько времени ушло на решение ваших задач»;

• позволяет не забыть о том, что вы должны сделать в будущем, и быть уверенным, что ни одно дело не будет потеряно;

• позволяет планировать свое время и взглянуть на список дел стратегически, когда они все сведены вместе.

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

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

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

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

Важным фактором для расстановки приоритетов может оказаться и субъективная сторона заказчика. Чем важнее по нашей внутренней шкале заказчик, чем более требователен, влиятелен – тем больше вероятность того, что его заявку мы выполним в первую очередь. Этого стесняться не надо. Не все равны в компании, всем мил не будешь. Главное – выделить правильные критерии заказчиков, но не вводить много градаций и забивать голову расчетом, для кого и как быстро будем выполнять задачу. Проще всего, когда для нас заказчиков две категории – быстро (1-я ячейка) или медленно (2-я ячейка).

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

Я часто на работе практикую «правило первого часа». Дело в том, что в первый час официальной работы компании инцидентов не так много, а то, что осталось с ночи или все-таки возникло с утра, – может этот 1 час подождать. А если приехать еще на час раньше, то в нашем распоряжении почти 2 часа времени, которое можно использовать эффективнее, чем закрывать инциденты и писать письма тем, кто их не будет пока читать.

Почти такое же правило работает в последний час работы компании, когда все уже в «пятиминутной готовности» к отбытию домой. И если задержаться еще на 1 час, можно так же эффективно провести время. Тут зависит от нашего темперамента, жаворонки мы или совы, насколько выматывает нас работа, во сколько начался наш рабочий день и какой ритм у компании.

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

Представим задачу – нам нужно потратить 2–3 часа на обучение. Но нас все время отвлекают, и «настрой» на учебу не приходит. Поэтому мы все поступающие запросы, кроме «сверхпожарных», отсылаем… Нет, не в сад, конечно. В записную книжку, наклейкой на монитор, чтобы не забыть.

Есть еще действенный способ «отогнать» от нас «просителя», чтобы была пауза. Кстати, надеюсь, ваши пользователи достаточно «выдрессированы», чтобы зазря не приходить к вам или звонить по телефону. Они пишут свои просьбы вам на электронную почту. И пришедшего к нам «просителя» просим написать письмо нам с просьбой выполнить его задачу. Это даст для решения задач самообразования «временной буфер». Можно объяснить просьбу тем, что нужно отчитываться перед начальством, чем занимался, почему сделал, что без письма нельзя ничего делать. Сложно поначалу, а потом этот способ очень эффективно работает. Можно даже, в рамках приличия, позаниматься «уточняющей» перепиской с сотрудником, чтобы опять же выиграть время для более важных дел. Можно попросить, чтобы проситель написал письмо своему начальнику с просьбой это сделать, а начальник перешлет письмо нам. Этим убиваем 2 зайцев. Во-первых, это даст цепочку пересылок писем и нам паузу. Во-вторых, может оказаться, что на этапе начальника заявка застопорится, так как в выполнении ее руководство не видит необходимости.

В большинстве книг по тайм-менеджменту справедливо рекомендуется планировать на день, неделю, месяц (для краткосрочных задач) или год (для долгосрочных задач). Единственное, на что имеет смысл обратить внимание, – так это на то, что при планировании задач, привязанных ко времени, обязательно выделяйте небольшой пустой буфер после 2–3 дел. Не всегда четко можно выделить время для настройки какой-нибудь системы, особенно если делаем это в первый раз. Что-нибудь может не скомпилироваться или оказаться, что какой-то важной dll'ки не хватает. Это может сломать наш план буквально в самом начале. А имея вот этот запас, мы можем спокойно доделывать дела, понимая, что, кроме запланированных 2 часов, у нас есть еще 30–60 минут, которые примут удар ломающегося плана на день, в случае если мы не успеваем расправиться с первыми задачами. А если мы управились вовремя, мы всегда найдем, как с пользой провести освободившееся время.

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

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

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

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

Разбирая с коллегами вопросы, что же самое важное в работе, у меня получился список из трех самых важных вопросов:

• информационная безопасность – брандмауэры, пароли пользователей, права доступа, отчеты о действиях пользователей;

• резервное копирование и сценарии восстановления – четкий список того, что копируется, сколько времени требуется на восстановление каждых конкретных данных, регулярные учения по восстановлению данных;

• закрытие срочных аварийных заявок пользователей – жизненно необходимо, чтобы такие заявки были закрыты. Тут секрет прост: если пользователи не могут работать нормально и спокойно, тогда они атакуют ИТ-подразделение и нормальной работы над проектами не получится.

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

Важно учесть, что прежде чем начинать осуществлять действия по какому-либо сложному проекту, сначала лучше разбить на задачи, назначить ответственных, распределить действия внутри задачи. Главное тут – «материализуйте свои планы». Такое оформление мыслей в осязаемые формы особенно важно, вы ведь работаете в команде. Не нужно будет играть в «телепатов», всем понятно, что, когда и, самое главное, ради чего нужно делать.

Для графического изображения как нельзя лучше подойдет диаграмма Ганта. Огромное количество знакомых мне менеджеров и ИТ-руководителей про нее даже не знают. На ней всегда хорошо видна последовательность действий, какая задача зависит от завершения других. Не нужно ставить сложные программные продукты, чтобы нарисовать ее. Можно даже воспользоваться Visio или ручкой и бумагой.

Планирование убережет от спешки и отвратительного чувства – «за что хвататься», особенно после того, как отвлекли чем-либо.

Рис. 10.2. Диаграмма Ганта позволяет видеть «ответственных», сроки и распределять параллельно идущие задачи. То, что нужно нам как руководителям

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

Жизненно необходимо перекладывать заботу проверки здоровья локальной сети на специальные системы мониторинга (например, Nagios, Zabbix и подобные). С внедрения такого решения стоит начинать работу в новом ИТ-отделе, если его еще нет. Пусть автоматика экономит наше время и сохраняет нервы. Невозможно в голове держать все проверки всех сервисов, а также пороговые значения. Да и никто не будет в ручном режиме все проверять. Просто будут заниматься своей работой, и падение сервера будет совершенной неожиданностью. А такие проверки позволили бы быстро локализовать аварийный сектор, найти сбойный элемент. И самое главное – благодаря постоянному мониторингу инфраструктуры они позволяют предупреждать сбои еще до того, как они возникли. Например, если система заранее сообщит о том, что вот-вот место на диске закончится, мы сможем не допустить переполнения диска с почтовой базой данных, а значит, у нас не упадет почтовый сервер, а это, в свою очередь, обозначает, что не возникнет сбоя и необходимости его устранения. Мы сэкономим время, которое можно будет потратить на действительно важные дела. А еще, если настроены СМС-ки или почта о сбое, нам не придется все время нервничать и думать, что у нас еще отвалилось.