3 вопроса на засыпку кандидатам в техподдержку

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

Независимо от уровня конкретных профессиональных знаний, многие кандидаты «плавают» в ITSM (IT Service Management). Для многих это просто система, в которой ведется учет заявок на IT-обслуживание. И это сегодня, когда ITSM стал привычным стандартом взаимодействия бизнеса и IT в рамках техподдержки!

Бизнесу гораздо удобнее и понятнее управлять IT-услугами, чем детально разбираться в особенностях их реализации на уровне серверов и систем. Давно существуют хорошо работающие подходы к управлению IT-услугами, такие как ITIL, MOF, Cobit. Не нужно изобретать велосипед, все давно известно. Точнее, должно быть известно. Но знания по этой важнейшей теме обычно весьма поверхностны.

Итак, что обязательно нужно проверить у соискателей технических вакансий, претендующих на работу в IT-компании?

1. SLA – соглашение о качестве обслуживания

Некоторые никогда не слышали про SLA. Поэтому, например, крайние сроки устранения инцидентов и выполнения запросов воспринимаются как пожелания. Между тем, для IT-компании такая необязательность – это не только обманутое доверие пользователей, но и денежные штрафы.

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

2. Разница между запросами на обслуживание и изменение IT-системы

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

Например, небольшое (минорное) обновление версии платформы «1С.Предприятие» может привести к изменению работы подсистемы разбора XML, в результате чего документы просто перестанут открываться. Поэтому такие запросы надо рассматривать именно как запросы на изменение. Их выполнение должно быть согласовано с сотрудниками, ответственными за все IT-системы, на которые это изменение может повлиять. И аварийный план восстановления рабочего состояния, если что-то пойдет не так, тоже совершенно необходим.

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

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

Вместо этого масштабного комплекса аналитики и отработанных действий IT-специалисты нередко стремятся что-то «попробовать» или «сделать по-быстрому».

3. Разница между инцидентами и проблемами

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

Поверхностный подход, латание дыр. В этом случае все приносится в жертву скорейшему восстановлению работоспособности. Ошибки и сбои устраняются быстро, но и речи не идет об анализе повторяющихся инцидентов, поиске и устранении истинных причин их появления. В ход идут обходные решения («костыли»), нагромождение которых медленно и верно разрушает IT-инфраструктуру. Пример: часто пропадает Wi-Fi — давайте просто перезагружать точку доступа раз в неделю. После этого не у всех сотрудников восстанавливается связь? Давайте напишем скрипт. Связь стала пропадать еще чаще? Ну, будем перезагружать точку доступа каждый день.

Излишняя дотошность. Здесь обратная картина. IT-специалисты знают, что нужно разбираться в причинах. Они даже знают, что существует управление IT-проблемами – процесс, который дополняет и уравновешивает управление инцидентами. Дополняет, а не отменяет! Но кандидаты с избыточной дотошностью часто забывают об этом. И воспринимают любое нештатное событие как системную проблему, в борьбе с которой можно выгнать пользователя с компьютера на целый день и забыть о главном. О том, что цель IT состоит не в прекрасно работающих компьютерах и системах, а в том, чтобы с их помощью пользователи могли выполнять свою работу. Поэтому прежде чем углубляться в изыскания, нужно позаботиться о том, чтобы у сотрудников была возможность выполнять свои задачи. Например, на подменных рабочих станциях.

Что делать с провалившими собеседование

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

Брать на работу и надеяться, что «среда все исправит»? Действенный вариант, к которому – осознанно или нет – прибегают все компании, в которых нет программ обучения. Все-таки ITSM основан на здравом смысле. А, как показывает опыт, IT-сотрудники его хорошо перенимают. Однако часто успевают наломать дров.

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

• Компания должна обладать своей логичной и понятной процессной моделью. Не общей, из интернета, а собственной, учитывающей особенности работы реального предприятия.
• Процессная модель должна быть задокументирована и детализироваться регламентами и инструкциями. Таким образом, она передается не из уст в уста, а доступна в любой момент всем сотрудникам.
• Знание процессной модели должно непосредственно влиять на работу сотрудников. Новые сотрудники в обязательном порядке должны не просто читать про процессы и осваивать инструкции, но и в конце испытательного срока проходить экзамен с непосредственным руководителем. А для дальнейшего повышения расти не только технически (то есть приобретать новые знания по продуктам, технологиям), но и в организационном плане.
• И главное: знания должны пройти полный цикл усвоения. Одного вводного тренинга и фразы «Остальное найдешь в базе знаний» недостаточно! Необходима методичная, глубокая, планомерная работа.