Чему не учат в школе: как мы готовим инженеров техподдержки

Вот и обещанная “другая история”.

Challenge

Если бы четыре года назад меня спросили: “Как можно обучать новичков в ИТ отделе/компании?” — я, не задумываясь, выдал бы: “По методу “обезьянка видит — обезьянка подражает”, то есть прикрепите новичка к более опытному сотруднику, и пусть смотрит, как выполняются типичные задачи”. Этот подход работал у меня раньше, он работает и сейчас, да и какое-то время назад в Veeam, когда деревья были большими, логотипы зелеными, а продукт маленьким, так тоже можно было обучать — и обучали!

Постепенно же продукт становился большим и сложным, новых инженеров становилось все больше и больше, и подход в стиле RTFM (Read The Freaking Manual) работал все хуже и хуже — дело в том, что так могут учиться те, кто уже “в теме”, кто понимает специфику работы и нуждается в некоторых, не столь критичных деталях.

А как быть с теми, кто пришел из смежных областей и хочет расти и развиваться, но не знает, как к этому подступиться? Как быть, например, с владеющими условно-редким языком (например, редким для среднего айтишника итальянским)? Или как обучить по такой схеме перспективного выпускника ВУЗа, у которого за плечами нет большого опыта работы?

Давайте на секунду прервем наш рассказ и представим: вот вы, тимлид в команде поддержки, сами в прошлом хороший и успешный инженер, с большим опытом системного администрирования и общения с разными людьми. Ваша задача — передать свой опыт новому (даже можно сказать “зеленому”) бойцу-инженеру, выпускнику ВУЗа, умному и сообразительному. Есть только нюанс — это человек без опыта поддержки и даже банального хелпдеска, а еще он будет первым турецкоговорящим инженером в вашей компании.

Как вы будете решать эту задачу?

А когда вы ответите на этот вопрос (а вы ответите, я в вас верю), давайте усложним задачу — что если таких инженеров будет десять? А если двадцать? А если это постоянное развитие отдела, и в любой момент времени будет новичок, которого надо обучить, показать минимальный стандарт качества работы (и этот стандарт высок) и сделать так, чтобы человек при этом не захотел сбежать как можно быстрее?

(Пожалуйста, подумайте над этим вопросом, прежде чем будете читать дальше.)

Our Story

Именно с таким вызовом/задачей мы и столкнулись.

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

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

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

Один из наших инженеров выступил на VeeamOn в Лас-Вегасе с блестящей презентацией о том, из каких кусочков состоит Veeam Backup & Replication, и с небольшими доработками она стала лекцией “Components”. К этому времени у нас уже было несколько лекций по разным частям функционала, но именно та лекция “задала тон” всем, которые были до и после. Именно то, как та лекция была выстроена, какие материалы использовались и прочее, и стало стандартом для нас.

Мы стали много рассказывать о виртуализации, технологиях Microsoft, наших собственных продуктах, ввели базовые тренинги для наших новичков без опыта в IT, на которых рассказываем все, что может понадобиться инженеру поддержки — начав с “железа” и наращивая уровни абстракции: Disk API, Operation Systems, Applications, Networking, Virtualization.

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

А что же кроме?

Я люблю говорить, что у нас работает правило Парето: своими тренингами мы даем примерно 20% того, что необходимо успешному инженеру, и 80% остаются на его совести — чтение мануалов, работа в лабе, решение тестовых и боевых заявок и тд.

20% — тренинги — на самом деле, это почти 100% теоретической базы, но ведь одной теорией всего не добьешься — работает классическая схема Знания-Умения-Навыки. Мы можем дать Знания, но нарабатывать Умения и превращать их в Навыки — это уже совершенно другая задача.

Именно поэтому можно очень быстро наши начальные теоретические лекции дополнились другими вещами, и теперь общая схема выглядит так:

• Лекции/тренинги;
• Самостоятельная работа;
• Менторство.

С первым пунктом все ясно: берем группу новичков, читаем им теорию и плавно переходим ко второму пункту, выдав в конце лекции “домашнее задание” — некую практическую задачу, которую новичок должен “наиграть” в лабе и предоставить отчет в какой-то форме (обычно форма свободная, но бывают и исключения).

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

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

У нас таким “помогатором” для новичка выступает ментор.

Переоценить ментора просто невозможно. Судите сами, он — первая “точка контакта” для закрепленного за ним новичка, тот, кто может ответить на большинство вопросов и помочь в большинстве ситуаций — и исправить те плохие паттерны (в технической части, в бизнес-этике, в культуре Компании), которые может пропустить как тренер, так даже и тимлид.

И это все о нем?

Лекции-тренинги, менторство, самостоятельная работа — вот три основных кирпичика, которые составляют нашу программу обучения. Но разве это все, что можно рассказать? Конечно, нет!
Даже имея неплохую схему, четыре полных программы обучения (пятая на подходе), мы не останавливаемся собирать свои “троды плудов”. Обучение живое настолько, насколько живой наш продукт, и поэтому постоянно появляется как новая информация, так и новые способы, как ее донести.

Например, важной вехой для нас стало понимание, что мы действительно повторяем школьное/университетское обучение чуть более, чем полностью, и оно не всегда работает. Мы учим взрослых людей, с опытом, со своими страхами и предпочтениями. И такая “школьная” система людей немного пугает (давайте называть вещи своими именами — в 95% случаев любая фрустрация из-за школьной модели идет от страха): мы все так или иначе проходили через школу и университет, и чаще всего это было все-таки травмирующим опытом, поэтому повторять его совсем не хочется.

Отсюда мы начинаем (да, только начинаем, но “путь в тысячу ли…” и так далее) переделывать свои подходы. Мы вспомнили/узнали про андрагогику (обучение взрослых людей — в противоположность педагогике, которая, по сути, про обучение детей) с ее ориентацией на опыт, понимание целей, с нюансами про усвоение информации и комфорт обучаемых, важностью эмоциональной составляющей (для детей это даже более важно), необходимостью практической составляющей и так далее. Узнали про цикл Колба и теперь крутим наши тренинги, думая, как же нам даже человека абсолютно “не в теме” привести к тренингу уже с каким-то опытом, который мы поможем актуализировать и дополнить, углубить и причесать, и, что важно, дать не только голую теорию, но и практические знания, которые можно трансформировать в навыки с помощью ментора или же самостоятельно.

Мы пригласили бизнес-тренеров, которые провели с нашими лекторами большую работу над публичными выступлениями, рассказали об эмоциях, потренировали ассертивность, дали инструменты по управлению групповой динамикой и, конечно, помогли нам ответить на вопросы “что мы хотим от обучения?” и “какая у нас конечная цель?”. Результаты уже есть — некоторые тренинги, собиравшие больше всего фидбека в стиле “скучно и ничего не понятно” теперь называют едва ли не самыми интересными и душевными — а ведь лектор остался тем же!

А еще совсем недавно к нам пришла пара очень крутых и мотивированных ребят, рассказывающих про Knowledge Centered Support и про то, как строить видеокурсы — и мы у них почерпнули много хороших идей, как переделать последние и уйти от “запись вебинара-стайл” в красивые и простые курсы, которые просто и понятно рассказывают все, что мы хотим, и не позволяют утонуть в разнообразии методов предоставления информации.

Более того, теперь мы занялись не только технической составляющей обучения, то есть так называемыми hard skills, но еще и работаем с soft skills, причем не только для лекторов или менеджмента, но и для инженеров. Мы делаем это для того, чтобы условный Игнат, приходя в компанию, мог потренировать те навыки, которые ему будут на 100% необходимы в работе, умел управлять своими эмоциями, и знал, что в любой, даже самой сложной и безысходной ситуации он не будет один: ведь Поддержка — это про людей, и “мы своих в беде не бросаем”. Перед первыми входящими телефонными звонками мы поиграем с новичком в ролевые игры, помогая втянуться в процесс и найти свой стиль ответов, перед первыми кейсами расскажем, как с ними лучше работать и на что смотреть, и во всем процессе будем следить и помогать.
Мы поддержка. И кого ж нам поддерживать в первую очередь, как не своих?

И в заключенье пару слов…

Я отдаю себе отчет, что мой рассказ звучит хвалебно. И при этом я не хвастаюсь — это наша история, наше настоящее и всего лишь небольшая часть планов на будущее.

Наше обучение ни разу не идеально. Недостатков у нас много, и ошибок мы понаделали — мама дорогая! Мы получаем много фидбека, и чаще всего он не хвалебный, нам пишут про проблемы, недостатки, желаемые улучшения — а так как мы обучаем worldwide, то получается очень много разнообразного фидбека, а если еще учесть культуральные особенности…

Нам есть куда расти, и слава Богу, у нас есть те, кто готов работать, критиковать, обсуждать и предлагать новое. Это большой ресурс и большая поддержка.

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

… и на этом позвольте мне закончить дозволенные речи.