Три вопроса на засыпку кандидатам в техподдержку
Недавно общался с коллегой-эйчаром, и мы сошлись на мнении, что сегодня как никогда важно активно мониторить рынок в поиске лучших кандидатов. Но что конкретно это означает? Какие выводы о подготовке соискателей 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-сотрудники его хорошо перенимают. Однако часто успевают наломать дров.
Компенсировать нехватку знаний и обучать сотрудников? В этом случае важно, чтобы они учились на чужих, а не своих, ошибках и ошибались по минимуму. Для решения такой задачи, как обычно, нужен комплексный подход.- Компания должна обладать своей логичной и понятной процессной моделью. Не общей, из интернета, а собственной, учитывающей особенности работы реального предприятия.
- Процессная модель должна быть задокументирована и детализироваться регламентами и инструкциями. Таким образом, она передается не из уст в уста, а доступна в любой момент всем сотрудникам.
- Знание процессной модели должно непосредственно влиять на работу сотрудников. Новые сотрудники в обязательном порядке должны не просто читать про процессы и осваивать инструкции, но и в конце испытательного срока проходить экзамен с непосредственным руководителем. А для дальнейшего повышения расти не только технически (то есть приобретать новые знания по продуктам, технологиям), но и в организационном плане.
- И главное: знания должны пройти полный цикл усвоения. Одного вводного тренинга и фразы «Остальное найдешь в базе знаний» недостаточно! Необходима методичная, глубокая, планомерная работа.
Далее по теме:
