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

Рис. 9.1. Рост количества рабочих связей между разным количеством сотрудников отделов

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

Очень важно, чтобы начальник доносил до подчиненных общий смысл действий, а не ставил список разрозненных задач.

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

Уменьшение влияния «фактора» я как начальник решаю через последовательное решение задач:

• повышение квалификации персонала;

• эффективность сотрудников через личный и корпоративный тайм-менеджмент;

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

Кажется, что ничто так быстро не меняется, как информационные технологии. Даже в юриспруденции не так часто претерпевают изменения «базовые нормы», как в нашей сфере. Те знания, которые еще несколько месяцев назад были актуальными, сегодня оказываются устаревшими. ИТ-лексикон пополняется новыми терминами. «Консьюмиризация», BOYD, «гибридное облако» и «программноопределяемое хранилище данных», которые сильно меняют устоявшиеся классические схемы предоставления услуг.

Для того чтобы сохранить конкурентное преимущество и адекватный уровень безопасности, ИТ-подразделениям необходимо следить за тенденциями, вовремя и качественно предоставлять бизнес-заказчику современные сервисы.

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

На квалификацию персонала влияют не только технические знания, полученные специалистами. Но еще психологические и коммуникативные навыки. Как правило, сотруднику в момент времени требуются конкретные знания, узкоспециализированные и закрывающие текущие потребности, связанные с выполняемыми обязанностями. Чаще всего это решается через самообразование или специализированные курсы. Но редко, когда бывает, что человек учится навыкам командной работы, когда он думает о своих рабочих действиях как о части работы коллектива. К настройкам, которые только что были сделаны, через несколько дней может подключиться другой сотрудник, и для него может быть загадкой, почему сделано все именно так и что может сломаться, если внести изменения. Особенно остро это касается вопроса, правил брандмауэра и групп пользователей. Писать комментарии и пользоваться полями «Примечание» ('Notes') в GUI-интерфейсах почему-то не принято. Так же остро стоит проблема передачи информации между сотрудниками по пересекающимся сферам ответственности. Тут царят забывчивость, сплошное незнание и просто неуважение к коллегам.

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

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

Основная цель управления временем – ответить, ради чего управлять (на самом деле более правильно описать, как «экономить время “для главного и важного”»). Если мы правильно написали план и решили наши повседневные задачи и высвободили, допустим, один час. Но его потратили на сидение в соцсетях или банально играли. Повысилась ли наша эффективность? Безусловно, да, мы ведь за меньшее время закрыли заявки. Принесло ли это сотруднику или отделу пользу – сомнительно. Сэкономленный час потрачен впустую. Оптимизация нужна, чтобы сэкономленное рабочее время потратить на осуществление важных проектов, обучение. При этом уровень нашей культуры должен позволять исходить из формулы: «организованность – это мера уважения к коллегам и клиентам». И тогда коллеги обязательно ответят тем же, а значит, работать будет комфортнее.

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

Про приемы эффективного тайм-менеджмента читайте в следующей главе.

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

Вот краткий список классических ответов на претензию о том, что задача не выполнена.

• Я думал, что это ты сделаешь.

• Я за это не отвечал.

• Почему меня не проинформировали о том, что происходит.

• Я отвечал за эту работу, но у меня не было полномочий.

• Я знал, как исправить ситуацию, но никто не спросил у меня.

• Я видел, что проблема вот-вот случится, но я думал, на исправление не дадут денег.

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

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

• Responsible – ответственный непосредственно за выполнение работы;

• Accountable – несет ответственность; согласно модели, эту роль должен иметь только один человек на одной задаче;

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

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

Пример реализации такого подхода продемонстрирован на рис. 9.2. Тут видно, кого необходимо информировать о процессе выполнения, какой из сотрудников будет исполнителем и с кем необходимо проконсультироваться. С более сложным и глубоким примером можно ознакомиться по ссылке [1].

Рис. 9.2. Пример RACI-матрицы

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

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

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

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

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

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

Но после испытательного срока, когда сотрудник попытался вспомнить эту договоренность ИТ-директору, тот совершенно забыл про это и пошел в глухой отказ. И вот возникла конфликтная ситуация, из которой, по-моему, было только 2,5 варианта решения:

1) сотруднику отказаться официально от обязанности, пойти на конфронтацию с руководством, лишиться квартальной премии, в которую пытались вложить некий бонус за закрытие задач по порталу;

2) пустить все на самотек, так как нагрузка резко спала в результате массированной деятельности по улучшению и «допиливанию»;

2,5) понимая свой уровень квалификации, подыскивать во втором варианте новое место.

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

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

Какие уроки можно извлечь из данной ситуации: мне нужно было вовремя задать вопрос: какие были договоренности и какие ожидания у кандидата во время испытательного срока? А еще надо было до последнего момента присутствовать на собеседовании, чтобы знать и контролировать все договоренности между заинтересованными лицами.

Приведу еще в виде одного примера фрагмент реального диалога, в котором системный администратор одного из филиалов обращается к своему начальнику (то есть ко мне) и описывает проблему, которую он наблюдал у пользователя: «в XYZUBZ не могут войти, на айпи 172… Что-то с туннелем опять, что ли… Вводят пароль, и та же ошибка, не удается подключиться к этому айпи у Ивановной Натальи».

Сразу замечу: данное сообщение приведено, как было отправлено мне, без изменений, то есть IP не полный, расшифровки, какая такая «та же ошибка», тоже нет, приветствия нет.

В данной ситуации у меня, наверное, должен быть соблазн начать разбираться; может, и правда, что-то с туннелем, и помочь сотруднику Наталье в ее беде. Чувство человечности, соучастия и желания помочь в беде – первое, с которым приходится бороться. Оно затуманивает разум. Но в данной показательной ситуации видно, как сразу же нарушаются договоренности (часть из них вы уже видели в книге). Бизнес-процессы не соблюдаются. И две самые важные договоренности – любая заявка должна быть оформлена в системе и почему идет «форвардинг» непроверенной и непроанализированной информации. Тем более искажение информации.

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

Увы, но руководители видят в лучшем случае 20 % того, что происходит, и, используя эту 5-ю часть информации, вынуждены оценивать и судить действия наших подчиненных. Поэтому не всегда наша оценка заслуг наших подчиненных адекватна их ожиданиям. Мне кажется, что самый убыточный для компании сотрудник – это демотивированный высококвалифицированный профессионал. А получить такого сотрудника можно, если банально не оценить результаты его труда. Разговор 1 на 1 за «рабочую жизнь» хотя бы раз в неделю позволит более объективно оценить его вклад в общее дело и показать, что его ценят, прислушиваются.

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

Соблюдая требования «финансов», был запрошен счет в отечественной компании, но оказалось, что разработчик уже вписал в свою базу данных первоначальную лицензию, выданную вместе с инвойсом, и российский продавец не может ее отгрузить. Получилась смешная ситуация: оплатить инвойс нельзя, так как подтверждающих документов по законодательству РФ нет и не будет, а по оплаченному в РФ счету лицензию не получить. В результате попытка сэкономить для компании несколько тысяч рублей повлекла в простом проекте, который должен быть не сложнее, чем купить банку консервов, траты различных подразделений, которые свели экономию на нет. В проект включились последовательно руководители четырех подразделений: финансы, бухгалтерия, ИТ-директор и юристы. Пришлось писать письмо и контролировать возврат средств по ошибочному счету, оплаченному российскому поставщику. Если посчитать потраченное ими время, то никакой по факту экономии для компании не получилось. К чему вся эта история? А к тому, что чуть более дорогой путь может оказаться на самом деле более экономичным, если пытаться идти более короткой дорогой. Главное – уметь считать и научить подчиненных понимать, где экономить можно, а где не стоит.

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

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

Еще хочу для построения качественной коллективной работы дать такой совет: собирайте контакты и «волшебные слова» к ним в одном месте. И это не должна быть чья-либо голова.

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

Телефонные контакты общего назначения обязательно нужно структурировать. Неплохим вариантом хранения может оказаться Wiki или отдельный OU для Active Directory, где можно создать целое дерево. Тогда все контакты будут храниться в одном месте. Обязательно оговорите общие правила заполнения такой общей телефонной книги.

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

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

• После того когда вы изложили суть вашего обращения, попросите оператора повторить то, что занесено в основные поля их системы учета. Возможно, нас не совсем правильно поняли на том конце провода, что-нибудь забыли внести. Может оказаться, что и мы в процессе озвучивания вспомнили что-нибудь существенное и сможем добавить в наше обращение.

• Для ситуаций, когда сотрудники службы поддержки не сообщают номера обращения или забывают это сделать, обязательно ближе к концу разговора попросите оператора сообщить номер.

• Обязательно оставляйте заранее оговоренные контакты, проверяйте их, даже если оператор сообщает, что контакты есть в их системе обращений. Чаще всего может оказаться, что в общей системе хранится e-mail бухгалтерии или устаревший сотовый телефон уволившегося сотрудника.

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

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

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

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

Поэтому требуется выработать график пересмотра инструкций, прогона их выполнения в тестовой лаборатории. Инструкции обязательно нужно дополнять и совершенствовать. Не имеет смысла писать инструкции для «одноразовых» действий в надежде, что вдруг могут понадобиться. Таким может быть установка «хитрой версии» драйвера RAID-контроллера на сервер. Как правило, вероятность такого события очень невысока. А инструкция по восстановлению базы данных портала SharePoint или ProjectServer может оказаться как нельзя кстати.

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

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

Допустим, вы обслуживаете службы 24×7, если авария произойдет в два часа ночи, как быстро смогут сотрудники приступить к устранению неисправностей? По каким каналам связи и как они будут связываться между собой? Как быстро они смогут понять, что именно произошло, и устранить неисправность? Кто и когда должен появиться на поле боя, чтобы все прошло четко и правильно? Насколько такие цифры приемлемы для бизнеса? Еще о многом нужно подумать начальнику, и учения как никогда могут оказаться кстати.

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

Еще нужно помнить и обращать внимание на «вещи, которые все знают, но вечно забывают». Можно просто распечатать и повесить на видном месте.

• Забываем «контрольно» перезагрузить компьютер, отдавая его пользователю.

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

• Забываем информировать о своих действиях и достигнутых результатах пользователей, подчиненных, партнеров.

• Забываем, что существуют регламенты и инструкции.

• Забываем проверить бекапы.

• Забываем убирать на столах.

• Забываем, приходя к руководителю по сложному вопросу, предложить варианты его решения.