В современных ИТ-компаниях эффективное обучение и адаптация новых сотрудников уже стали критически важными задачами, особенно в условиях быстрого роста и усложнения внутренних процессов. На примере команды поддержки Nexign проследим, как эволюционирует подход к внедрению и развитию систем передачи знаний в условиях, когда стандартные методы перестали работать, а требования к компетенциям специалистов только растут. В этой статье ведущий инженер поддержки Денис Сохранный поделится опытом построения системы обучения, расскажет о трудностях, с которыми столкнулась команда, и о решениях, позволивших повысить эффективность адаптации новичков.
База знаний — это добро, которое должно быть с кулаками? Мы строили, строили и, наконец, построили эффективную систему обучения, адаптации и проверки знаний новых сотрудников.
Привет, Хабр! Я — Денис Сохранный, ведущий инженер саппорта и старший одной из смен поддержки в Nexign. Много лет работаю в IT-индустрии, связанной с телекомом и биллингом, на разных позициях от инженерных до тимлидских.
Nexign делает софт, но она не на слуху у широкого потребителя, как Яндекс или Mail. И всё же если вы находитесь в России или в странах СНГ, отправляете SMS, пытаетесь выйти в интернет или позвонить, то почти наверняка столкнётесь с каким-то нашим продуктом.
На конференции TeamLead++ я рассказывал о пути, который прошла наша команда при построении системы обучения и адаптации новичков — как мы прыгали на граблях и заходили в тупики. Возможно, наш опыт поможет вам избежать похожих ошибок.
Nexign сегодня: чем мы занимаемся
Для начала расскажу о нашей компании. На рынке Nexign уже больше 30 лет, у нас много продуктов и клиентов. Большая часть из них — телеком-операторы (МегаФон, Ростелеком, Yota и т.д.), а за последние несколько лет мы вышли за пределы телеком-индустрии.
У нас большая линейка продуктов — мы называем их подсистемами. Они работают как в комплексе, так и отдельно.
Моя команда начиналась с небольшого отдела поддержки 24/7 — всего несколько инженеров и продуктов на сопровождении. Пока она была маленькой и подсистем на поддержке было немного, мы легко справлялись с вводом в строй новых сотрудников. Но когда продуктов на поддержке стало больше, и штат расширился, мы столкнулись с тем, что не успевали в адекватные сроки обучить новичков, чтобы они могли приносить пользу.
Как работает линия поддержки в Nexign
Когда люди слышат о техподдержке, обычно представляют себе что-то про «ваш звонок очень важен для нас» или бегающих по офису ребят, которые переключают принтеры и спрашивают, перезапустили ли вы уже ноутбук? Support в Nexign — это совсем другое.
Наш заказчик — крупный телеком-оператор, у которого развёрнуты все наши продукты. Система большая и сложная, и если что-то идёт не так, мы проводим расследование, находим причину, выдаём решение и устраняем последствия.
Поддержка работает круглосуточно — у нас четыре смены: две на Востоке (Владивосток) и две на Западе (Самара, Екатеринбург, Краснодар). Это команды около DevOps, с примесью аналитики и немного — детективов.
Продуктов на поддержке у нас больше 60-ти, и чтобы люди не сошли с ума, изучая их, мы разделили их внутри по направлениям:
платёжники — поддерживают наши платёжные сервисы;
тарификаторы — обеспечивают корректную работу сервисов, превращающих ваши минуты, мегабайты и звонки в рубли;
обслуживание — отвечают за сервисы обслуживания и самообслуживания абонентов: личные кабинеты, порталы операторов в описах, CRM и т.д.
Мы — вторая линия поддержки или L2. Сначала оператор пытается решить мелкие проблемы самостоятельно, но если произошло что-то массовое, то создается инцидент нам. Мы проводим анализ и пытаемся устранить влияние, но если и мы не справляемся, за спиной есть ещё более крутые специалисты — третья линия поддержки и разработка.
Выстраивание системы обучения: главные проблемы
Изначально наш отдел задумывался как кузница кадров: мы берём и опытных специалистов, и новичков. Работа в L2 — это хороший старт, чтобы потом двигаться внутри компании. Много ребят в дальнейшем уходят в разработку или в L3.
В каждой смене примерно 10 человек, и почти всегда есть спецы, которых нужно учить.
В 2015 году, когда запускался проект поддержки 24/7, адаптация первого поколения инженеров держалась на курсах от нашего корпоративного центра обучения и документации (до 200-300 страниц на продукт). Для следующих поколений появились кураторы из числа опытных инженеров L2. Но со временем это перестало работать: человек смотрел записанные курсы, читал много документации, но потом смотрел на инциденты и не понимал, что делать.
Нужно было менять подход. Мы посмотрели, как все устроено у других команд, и пришли к выводу: самый лучший способ наладить процесс — аккуратно позаимствовать идеи у коллег из L3.
Как мы «украли» программу адаптации у другой команды
L2 — это широкий специалист, как терапевт в поликлинике: у него большие познания в разных областях, и он может решить солидный пласт проблем, но не все. За ним стоят L3 — «узкие специалисты», которые знают всё про свой участок, но по соседним областям знаний сильно меньше. Мы взяли программу адаптации L3, но столкнулись с проблемами.
Во-первых, одному направлению L2 могло соответствовать 7−8 направлений L3, а это 7-8 программ адаптации для одного инженера. Во-вторых, разнились задачи: мы в L2 только решаем инциденты и пытаемся всех спасти, а наши коллеги проводят тестирования, общаются с аналитикой, внедрением, разрабатывают новые фичи и т.д. В итоге получалось, что для L2 эта программа была перегружена лишней информацией — адаптации L3 на не подошли.
Устаревшие данные для обучения
В нашей стартовой программе адаптации тоже было много проблем. Те самые записи курсов, которые появились в далёком 2015 году устарели. Кроме того, не было практики. Мы вываливали на человека ведро разной информации, давали ему куратора, но во время ознакомления с теорией молодой специалист ничего не трогал, и в голове мало что откладывалось. А знания, которые человек усвоил, никак не проверялись.
База знаний тоже не работала, как нам бы хотелось: саппортеры-новички L2 не знали, что там искать и есть ли там это «что-то», а опытные не понимали, чем её наполнять.
Перевыпускать курсы центра обучения — тоже показалось нам идей не очень, они были общими, а работа L2 специфическая, и нам нужны своеобразные курсы под собственные потребности. А значит нужно делать их самим.
Больше L2 Богу L2
Чтобы сократить и упростить адаптацию самая логичная, казалось бы, идея: у нас есть три направления — надо сделать четыре! Логика проста: больше направлений — меньше продуктов у каждого на поддержке, меньше продуктов — меньше и проще обучение, и жизнь наладится.
Но не всё так просто. Тут на сцену выходят четыре всадника апокалипсиса — это август, январь, февраль и март, когда люди массово ходят в отпуск или на больничные.
Чем меньше людей в направлении, тем выпадение из работы даже одного просаживает производительность смены. И наоборот, чем в направлении больше инженеров, тем проще сбалансировать нагрузку и переводить людей из смены в смену, двигать графики отпусков и так далее.
В итоге от этой идеи мы отказались и пошли другим путём.
Компетенции
Параллельно мы думали, как повысить эффективность L2, чтобы больше инцидентов решалось на уровне второй линии и при этом меньше нагружать третью. Вопрос: почему не хватает компетенций? Я назвал эту проблему «туманом войны».
Есть инженер второй линии, который поддерживает набор продуктов своего направления. Он получил какие-то знания на старте при обучении, он приобрел какой-то опыт при работе – благодаря этому он знает какую-то часть продукта. Подсистема частично открыта у инженера, как часть карты в компьютерной игре. Этой карты хватает для решения проблем до какой-то сложности. Но когда проблема выходит «за пределы карты», инженеру L2 не хватает знаний, и мы идем за третьей линией, у инженеров которой карта открыта вся, они знают продукт полностью и помогают решить вопрос — вин-вин.
Пытаясь поднять производительность L2, мы придумали такую штуку как специализация внутри направлений.
Например, мы даём тарификатору продукт GUS на прокачку. Инженеру L2 нужно час-два в день тратить на своё развитие по выданному продукту: погружаться в документацию, знакомиться с ходом работы по инцидентам не в его смену, читать об исправленных багах, смотреть новые версии, ходить на летучки к L3 — в общем, делать всё для повышения компетенций в нужной подсистеме. Так он остаётся тарификатором, продолжает решать аварии своего направления, но при этом постепенно становится человеком с «открытой картой» по продукту. В одной смене, в одном направлении такие продукты мы выдаём разные, и специалисты дополняют друг друга.
Так, когда кто-то сталкивается с «туманом войны», рядом уже есть человек, у которого зона знаний о продукте больше, и он может помочь решить вопрос.
После реализации проекта со специализациями процессы, которые шли параллельно, улучшились:
внутри L2 появились свои эксперты, на мнение которых можно опереться;
появились свои прокачанные ребята L2, силами которых можно было переделывать адаптационную программу и заполнять Базу знаний;
мы поняли, что перераспределяя знания, можем приносить пользу при гораздо меньших ресурсах.
Как огнём и мечом, улучшить работу базы знаний
Чтобы сделать базу знаний действительно полезной, мы внедрили обязательную проверку на финальном этапе решения инцидента. Инженер должен был ответить на простой вопрос: была ли в базе статья, которая помогла решить инцидент? Если нет, он должен был написать запрос на неё. Без этого инцидент закрыть нельзя.
Теперь молодые инженеры L2 понимают, что им нужно для решения задач, а более опытные коллеги — каких знаний не хватает остальным. Так наша база знаний стала наполняться.
Затем мы переписали наши программы адаптации силами опытных инженеров. Но даже после того, как они выкинули всё лишнее, адаптация всё равно оставалась слишком громоздкой. У каждого направления L2 на поддержке в среднем по 15 продуктов.
Тогда мы условно разделили продукты на поддержке на две группы:
Подсистема «33 несчастья». По закону Парето 20% чего-нибудь дают 80% работы и наоборот. Например, есть у нас подсистема CRAB, провиженинг: заявки на изменение профиля абонентов в ЦОДАХ, на коммутаторах, где-нибудь в глухой сибирской тайге и т.д. Передача команд идёт по сети, проблемы на которой приводят к тому, что заявки не долетают, абонент перестаёт быть консистентным, появляется рассинхрон между системами и много других неприятных вещей. Когда связь восстановится, нужно проводить «устранение последствий»: повторять заявки, убирать рассинхрон. Делать это нужно быстро и такую подсистему обязательно нужно знать на старте.
Подсистема «вспомнить всё». Такие ломаются раз в полгода и реже. Главная проблема инженера — не столько починить, сколько вспомнить, как она вообще работала, потому что он мог ни разу с ней не взаимодействовать.
Исходя из этого принципа, мы поделили наши продукты на три приоритета. Первый — это четыре самые аварийно опасные системы, и только их мы включили в первые три месяца адаптации. Второй и третий приоритеты — продукты, с которыми проблем меньше, их изучение растянуто на год после приёма в штат.
Более того, внутри каждой подсистемы мы разделили информацию на два блока: кейсы и знания.
Кейсами мы назвали базовые знания и типовые действия, которые могут решить проблему без проведения глубокого анализа или которые придётся делать регулярно. Знания — это уже углублённый подход к изучению подсистемы, обладая этой информацией, можно «копать» сложные проблемы и проводить глубокий анализ.
Сильно углубляться в подсистему молодому инженеру не обязательно, у него нет опыта, и он всего не запомнит. Но когда инженер пройдёт все подсистемы и получит практический опыт, можно будет брать задачу на повышение квалификации. Такой подход отлично ложился в наше грейдирование.
В итоге адаптация растянулась больше чем на год, но новички почти сразу получают только базу и начинают брать реальные задачи очень быстро.
Как решили вопрос практики
Если просто читать и смотреть, в голове мало что остаётся — нужна практика.
Мы развернули сервер для задач, а ведущим инженерам дали задание: «Ты решаешь инцидент, никого не трогаешь. Но если в какой-то момент ты понимаешь, что для обучения кейс из этого инцидента может быть интересен, делаешь слепок данных и переносишь их на базу заданий».
Инженеру за год нужно сделать пять таких задач. Например, он копирует какие-то логи, разбавляет это рандомными данными, чтобы было «интереснее копать», и размещает их на специальном сервере. Затем пишет преамбулу: «Вы видите на мониторинге такую картину или есть абонент с указанным ID. Проблема такая-то. Расскажите, в чем причина? Прав ли абонент?». И пишет ответ для куратора — что должен был найти испытуемый. Затем мы это вставляем в программу адаптации.
Метрики
Важно не только обучить специалиста, но и оценить его знания. Для этого мы добавили «собеседование после собеседования». Это помогает избежать ситуации «что-то читал, что-то смотрел, но ничего не понял — учите меня ещё».
Во время периода адаптации инженер идёт по программе. Затем ведущий специалист L2 (отличный от его куратора) интервьюирует его, чтобы выявить пробелы в знаниях. В итоге проходящий обучение L2 получает обратную связь и перечень материалов для повторного изучения с куратором.
Такая же проверка проводится через полгода и год. В треке на 12 месяцев расписаны продукты, которые инженер должен изучать постепенно. Время от времени к нему приходят старшие товарищи, проверяют и дают обратную связь.
Важно было донести до учащихся, что это не экзамен, и главная цель заключается в том, чтобы помочь им выровнять уровень знаний.
По итогу всех этих нововведений мы получили инженера, у которого может и нет полноты картины, но есть набор знаний, навыков и кейсов, которые он будет реально применять с первых же самостоятельных задач. Через месяц после первого этапа адаптации молодые специалисты начинают приносить пользу, решать инциденты и спасать абонентов.
Итоги
Какие выводы мы сделали:
Чтобы принести пользу, инженеру не нужно знать всё.
Можно быть полезным и с небольшим набором знаний, но имея план повышения квалификации на будущее. Не нужно наваливать на инженера слишком много информации.
Нужны метрики.
Если их нет и вы не контролируете, что происходит, то и прогресс/просадку отследить не получится.
Необходима практика.
Если вы ничего не делаете руками — в голове ничего не остаётся.
База знаний — это добро, но добро должно быть с кулаками.
Это классный продукт, им нужно заниматься и не забрасывать.
2 июня в Москве пройдёт Knowledge Conf Х, где я буду выступать с новым докладом: «Как моделировать работу на собеседовании и получить простой и легкий онбординг» — сможем обсудить тему управления знаниями в команде и онбординг новичков с немного другой стороны.
Спойлер: расскажу почему в нашей команде техподдержки все любят разгадывать загадки.
AndreyYu
Статья качественная.