У нашей техподдержки сложная структура: основной офис первой линии — в Обнинске, ещё есть площадки в Томске и Волгограде, а несколько сотрудников работают полностью удалённо. И мы хотим, чтобы наш пользователь получал человечный сервис. Проблема в том, что такое понятие, как «человечность», очень сложно покрыть требованиями. Можно только измерить на выходе по мнению пользователя. Но ведь надо же как-то давать ориентиры заранее, да?
Все эти вопросы помогает решить внутренняя культура. В каждой компании отдельно существуют две системы: ценности и правила. Они могут соприкасаться, но обычно правила меняются долго и нужны для формализации процесса, а ценности показывают, что реально важно командам. В первую очередь стоит ориентироваться на ценности.
Собственно, мы стараемся отразить в правилах наши ценности, и это помогает. Сейчас я расскажу, как мы меняем поддержку в этом направлении.
Всего у нас работают 35 человек. Первая линия появилась, ещё когда по планете ходили динозавры, — 13 лет назад. Когда мы только начинали, у нас не было даже столов. Вместо них тогда были тумбочки, на которых стояли компы. А вместо стульев — перевёрнутые мусорные корзины. Мы не смогли найти фотки тех лет (но пытались!), так что поверьте на слово.
Это такая стартаповская тема. У «Амазона» в своё время вместо нормальных столов тоже стояли сдвинутые тумбы. Изначально это было вынужденным решением, но потом стало трендом.
Сейчас так делают многие конторы.
Потом, лет шесть назад, из первой линии выделилась, как мы её называем, полуторная. Она занимается решением инцидентов с основными банковскими системами, аналитикой, поиском каких-то повторяющихся ошибок. Вторая линия состоит из нескольких элементов: под каждую банковскую систему есть своя команда, которая всё «разруливает» в тандеме с первой и полуторной линиями. Ну и, само собой, у нас есть инженеры, которые работают с железом на местах.
И вот вся эта махина из 35 человек должна работать как часы. В этом как раз помогает внутренняя культура. Она даёт сотрудникам чёткое понимание того, что они делают и ради чего вообще работают.
Из чего состоит внутренняя культура:
У нас клиентоориентированная техподдержка. Соответственно, от кандидата нам нужны эмпатия и навыки психолога, потому что мы работаем с живыми людьми. Безусловно, важно, чтобы у него были хотя бы базовые технические знания, желание развиваться в IT. Я даже скажу так: кандидату не обязательно иметь технический бэкграунд, но у него должно быть подтверждённое желание работать в этом направлении. Например, если он проходит какие-нибудь курсы, читает книжки про ИТ, статьи, смотрит ролики на «Ютубе» — в общем, понимает материал и может об этом рассказать на собеседовании, — то это наш человек.
Естественно, всё это мы определяем на этапе собеседования. Лично я пользуюсь моделированием ситуаций, в которых проявляются те или иные нужные нам качества.
Например, прошу его вспомнить какой-то случай из практики: что он делал, как решал проблему.
Зависел ли её исход от его действий, и если да, то на сколько процентов. И здесь он уже раскрывается, более честно отвечая на стандартные HR-вопросы.
Сейчас в техподдержке работают сотрудники разных возрастов. Раньше это были в основном молодые люди, но рынок сильно изменился. Сейчас приходят и ребята немножко за 30 с опытом работы в других сферах, но которые решили вкатиться в IT. Самому взрослому нашему кандидату было 35.
Нам, в свою очередь, надо понять, что именно человек умеет и насколько хорошо он впишется в нашу атмосферу. Если мы с ним на одной волне, понимаем друг друга, то нарастить технические скиллы — не проблема.
Например, у нас есть какой-либо процесс, и для него существуют определённые правила. Но ситуация такова (мир BANI, ага), что процессы и подходы могут меняться практически мгновенно.
И если это происходит, то формальный подход всё замедляет, процессы останавливаются.
Появляются неразрешимые противоречия и барьеры. Так вот, ориентация на внутреннюю культуру, её ценности и конечный результат позволяет эти барьеры пробить, а потом постфактум и оптимизировать сам процесс.
Это своего рода полу-agile-подход: люди важнее процессов. С последними всегда можно разобраться потом, если сотрудники разделяют наши ценности и культуру.
Примеров того, как это работает, — вагон и маленькая тележка. Из самого яркого: во время пандемии ковида нам нужно было срочно перевести сотрудников банка на удалёнку. Никакого отлаженного процесса такого массового перевода, естественно, не было. Зато была отлаженная культура, которая помогла быстро среагировать и по-новому выстроить работу без деградации сервиса. Люди делали своё дело без паники и старались помогать клиентам, потому что мы, повторюсь, клиентоориентированная поддержка: клиент не должен уйти от нас с какой-то бездушной отбивкой с нашей стороны.
Есть много историй про, скажем так, сферическую техподдержку в вакууме. Клиенты часто облекают наболевшее в различные мемы, приколы, анекдоты и так далее. Судя по ним, основные проблемы среднестатистической техподдержки — это:
Мы стараемся перевернуть своей работой такой взгляд на техподдержку. Решаем если не все, то многие вопросы уже в момент обращения клиента без заведения лишних тикетов и другой бюрократизации.
Естественно, у нас есть показатели, по которым мы оцениваем качество работы сотрудников.
Например, FCR (First Call Resolution), которая заводится как тикет в ITSM-системе. Если сотруднику позвонили даже за обычной консультацией, то он в любом случае заводит обращение и ставит пометку: вот здесь подключился онлайн, там выполнил удалённую перезагрузку, сбросил пароль и т. д. И в метриках всё это учитывается. Но пользователям мы этого не показываем, дабы не грузить, разве только при сборе CSI по итогу оказанной консультации. Ещё у нас есть метрика «нулевая очередь запросов». Пустая очередь — гарантия того, что первый попавший в неё запрос будет немедленно принят в работу. Наша средняя скорость решения инцидентов (даже при учёте возможных эскалаций) — три часа.
Мы вообще стараемся быть техподдержкой «с человеческим лицом». У нас есть маскот — смеющийся человечек вроде Fallout-боя с оттопыренным большим пальцем. Так вот, мы его вставляем в рассылки, он у нас маячит на дашбордах, на мерче. Мы об этом писали подробнее в одной из статей. Кроме того, стараемся в своей работе не использовать излишне официальных формулировок. Понятное дело, что можно расписать стандартные скрипты на типовые ситуации.
Но нам звонят люди, которые хотят, чтобы с их обращениями поработали нормально, по-человечески, объяснили всё простыми словами и решили проблему. Например, когда звонит пользователь, мы, со своей стороны, видим в карточке, он в компании недавно или «старослужащий». В первом случае человек может не знать каких-то нюансов про те же селф-сервисы, и мы с чуть большими вниманием и пониманием относимся к таким обращениям.
Если у техподдержки плохая организация, то пользователь чувствует себя брошенным.
Буквально ему кажется, что он столкнулся с какой-то непреодолимой преградой, вся работа встала и его мир рухнул.
Наша задача состоит как раз в том, чтобы пользователь такого не ощущал. Это не значит, что мы просто улыбаемся и машем. Нет, с нашей стороны должны быть глубокое понимание всех процессов, какой-то уровень автоматизации и в целом зрелости структуры техподдержки. А культура человечного обращения с пользователем уже завершает общую картину.
Когда я ещё не был на своей текущей позиции, то наблюдал внутренние процессы со стороны и выработал такой принцип: делай как для себя и думай о других. То есть помогай так, как хотелось бы, чтобы помогли тебе, окажись ты в аналогичной ситуации. С точки зрения организации работы, комфортно должно быть всем участникам процесса: и клиентам, и исполнителям, и менеджерам.
Такой себе кантовский категорический императив в контексте техподдержки.
Я уже говорил про саппорт «с человеческим лицом», все эти истории с проактивностью. Мы стараемся предугадывать появление каких-то проблем. У нас есть сервис по контролю тонера и других ЗИП в печатной технике. Для этого мы разработали дашборд, на котором отображается, что в таком-то конкретном аппарате что-то износилось или заканчивается тонер.
Другой пример — сервис по контролю здоровья жёстких дисков. С помощью SCCM (установщика пакетов для удалённой подготовки развёртывания рабочих мест от Microsoft) мы контролируем смарты состояния жёстких дисков. И если смарт сигнализирует, что хард вот-вот сломается, то мы связываемся с человеком: «У тебя скоро отъедет жёсткий диск, давай планово его заменим».
Иными словами, мы не ждём, когда возникнет какой-то инцидент, а стараемся его предупредить.
В плане комфорта сотрудников мы стараемся уйти от рутины, максимально автоматизировав выполнение типовых задач. 60 % софта ставится без участия техподдержки. В том же SCCM у нас есть магазин приложений, где пользователь может заказать себе прогу через ITSМ-систему.
Если для этого нужно согласование, то пользователь получает его тоже без участия человека.
Потом просто заходит в магазин приложений, кликает нужную программу, и она устанавливается автоматически.
Предоставление и отзыв доступов также автоматизированы. Когда в банке только появился сервисдеск, у нас была целая группа из семи человек. Они целый день только и делали, что предоставляли и отзывали доступы в случае переводов, увольнений, приёма новых сотрудников и т. д. Сейчас этим занимается IDM-система. Она ежемесячно обрабатывает десятки тысяч запросов, связанных с доступами, — абсолютно нереальная цифра для человека!
Если автоматизировать какой-то запрос через IDM-систему не получилось, то есть RPA — робот, который уже и решает проблему. Всё это, естественно, работает в безопасном контуре с учётом всех правил информационной безопасности.
Мы, конечно, не делали всё с нуля: значительная база для создания техподдержки в её нынешнем виде уже была.
Но мы внесли в неё принципы философий Lean и Кайдзен: это такие концепции бережливого, ресурсосберегающего производства для минимизации издержек и потерь. Применительно к нашей ситуации смотрим, на что сотрудники тратят больше всего времени и что с этим можно сделать: улучшить, автоматизировать, написать какого-нибудь бота, чтобы выполнял это самостоятельно. В общем, стараемся расширять «узкие места» и находить точки роста.
Вообще философии Lean и Кайдзен — это из сферы производства, но для техподдержки они подходят идеально, только по конвейеру вместо деталей незавершённого производства едут запросы на обслуживание и инциденты. Возьмём диаграмму «спагетти» — её обычно применяют к какому-нибудь работнику цеха, который бегает по нему и что-то делает. По этой диаграмме потом можно отследить его действия.
Однако она применима и к сотруднику техподдержки. Вот у него, допустим, открыто 15 разных приложений: в одном сбросил пароль, в другом посмотрел запросы, в третьем узнал ещё какую-то информацию по компьютеру пользователя. По этим действиям мы составили похожую «тепловую карту» действий сотрудника и узнали, что работники много времени тратят на переключение между приложениями.
Подумали, проанализировали и сделали систему, которая агрегирует в себе всю эту информацию, о ней у нас тоже был пост. Мы назвали её ЦУП — Центр управления полётами, — и в ней у нас AD, SAP, ITSM и т. д. В неё же вытягиваем информацию по компьютеру: сколько места на диске, IP-адрес, подсеть. И по пользователю: последняя авторизация, дата смены пароля, количество ошибок входа и прочее. К этой же системе прикрутили API с нашими инструкциями и базой знаний для пользователей.
То есть создали такой информационный центр, в котором аккумулируется вся нужная информация.
Допустим, нам позвонил человек: «Не могу настроить почту на мобильном телефоне!» Наш оператор сначала задаёт стандартные вопросы, а если пользователь всё равно не знает, то просто находит в ЦУПе нужную инструкцию и парой кликов отправляет ему. Это существенно снижает время обработки запроса, консультации. А заодно ускоряет онбординг, потому что новому сотруднику не приходится показывать каждую из наших 10–15 систем. Всё агрегируется в одной системе, работать с которой мы его и обучаем. Таким образом он быстрее выходит на, скажем так, проектную мощность, а каждую из этих 10–15 мастер-систем осваивает уже по ходу работы.
Кстати, немного возвращаясь к вопросу о сервисе «с человеческим лицом», я вспомнил один забавный случай. По моему настоянию в ЦУП добавили прикольную фичу: если в техподдержку звонит пользователь и у него в этот день — ДР, то в системе это отображается в виде конфетти по экрану. И если оператор это видит, то он должен поздравить пользователя с днём рождения.
Пользователи, понятное дело, этого не видят. Они не знают, какими инструментами мы пользуемся. Но вот среди самих сотрудников техподдержки нашёлся один, кому эта инициатива не понравилась. Я ему объяснил: если вдруг тебе попадётся такой пользователь, то просто помоги с проблемой, а в конце скажи: «Большое спасибо! Поставьте нам оценку и, кстати, с днём рождения!»
В общем, он так и сделал. «Я его поздравил, а он так обрадовался!» Сам же и получил массу приятных впечатлений, хотя изначально был настроен против.
На онбординге стоит остановиться подробнее. Он у нас проходит быстро, мы его делим на две части. Подробнее об этом можно почитать в нашем отдельном посте. Если коротко — у нас есть портал для джунов «Войди в IT». После изучения нужных материалов практическая часть занимает меньше недели. Они уже знают процессы и системы, остаётся только показать им, как работать с тикетами и пользоваться базой знаний. И всё — какие-то простые задачи они уже могут решать.
Для сотрудников, пришедших извне, обучение, конечно, занимает чуть больше времени — около пары недель. Его мы тоже ускорили — разместили там же, на «Войди в IT», цикл обучающих роликов. Новичок смотрит эти видео и может задать своему бадди уточняющие вопросы.
Бадди — это такой друг-наставник из числа опытных сотрудников. Он помогает не только с рабочими вопросами, но и с бытовыми, например, проведёт экскурсию по офису, покажет, где туалет или микроволновка. Ну и помогает с теми же доступами, хотя в основном они все зашиты в ролевую модель и автоматически присваиваются IDM-системой, о которой я уже говорил. Если новичок столкнулся с совсем уж неразрешимой задачей, с которой и бадди не может помочь, то он просто обращается к своему тимлиду.
Наша модель ориентирована на то, чтобы набирать персонал уровня джуниор или предджуниор.
Из них мы уже сами растим специалиста до какого-то уровня. У нас есть карьерная лестница с разбивкой по скиллам. И если человек растёт по ним, то у него со временем меняются должность и оклад. А когда он достигает определённого уровня на первой линии, то переходит на другую должность на полуторной или второй, инженерной линии либо уходит дальше в смежные подразделения сопровождения, аналитики, разработки и т. д.
Внутри банка есть много путей, по которым может пойти спец из техподдержки.
Например, к нам в техподдержку пришёл один сотрудник, заряженный на карьерный рост.
Сначала отработал полгода на линии, потом попросил перевестись в инженеры. За полгода он освоил весь свой функционал и попросил перевода, чтобы расширить компетенции. Ещё через полгода перевёлся на позицию системного администратора уже на второй линии и сейчас занимается сопровождением серверных ОС в банке.
А всё потому, что пришёл с мотивацией и выполнял все рекомендации из нашего «кандидатского минимума». Это такой вордовский документ на три страницы с тремя курсами на портале «Войди в IT», тремя книжками и списком задач на ДЗ. Он даёт кандидату основы IT-инфраструктуры, computer-science и работы с SQL. Ему остаётся пройти три этих курса, прочитать три книжки и решить домашние задания.
ДЗ — это достаточно простые задания вроде поставить Linux на домашнем ПК, установить Windows второй системой, настроить две виртуальные машины под разные ОС, создать между ними сеть, поднять веб-сервер и т. д. Специально всё задано тезисно и достаточно сухо, чтобы человек, начав выполнять эти задания, сам полез на форумы, на «Ютуб» и в другие источники. И в процессе этого решения он приобретёт нужные для дальнейшего развития и роста знания.
Изначально мы стараемся брать в техподдержку ребят, заряженных на развитие. Но бывает всякое: иногда ожидание и реальность немного не совпадают. В этом случае, конечно, мы стараемся мотивировать таких сотрудников. Но в основном мотивацию они приобретают сами в процессе движения по карьерной лестнице. Если же не приобретают, не развивают в себе компетенции, навыки, знания, то остаются на тех позициях, на которых пришли. Мы об этом регулярно напоминаем в рамках обратной связи, которая происходит между спецами и тимлидами.
Нашу внутреннюю культуру мы стараемся донести до сотрудников в интересной форме.
Событие не происходит так, что выходит какой-то тимлид и начинает пафосно вещать о ценностях техподдержки: это, как правило, только раздражает.
Вместо этого мы постоянно проводим различные мероприятия, например, квизы, арбузные пятницы летом и безалкогольно-глинтвейные среды зимой. Ещё мы любим праздники — как традиционные вроде Дня сотрудника техподдержки, так и выдуманные нами самими, например, Междугородный день беляша. Ещё у нас есть практика награждения лучших сотрудников каким-нибудь мерчем.
Так как довольно часто случаются изменения в кадровом составе, мы придумали фактологическую пятницу. Это такая игра для знакомства ребят, чтобы они быстрее и лучше вливались в команду. Мы проводим её прямо на работе в пятницу в обеденный перерыв. Перед этим просим каждого сотрудника рассказать о себе какой-то факт. Например, упал в детском саду и получил огромный фингал, с которым сфоткался на выпуске, и эта фотография теперь стоит у него дома. А потом на общем собрании озвучиваем этот факт, а остальные члены команды должны угадать, о ком идёт речь. Это помогает ребятам познакомиться друг с другом, узнать что-то интересное о своих коллегах.
Команда распределённая, часть сотрудников (те, кто работает в обнинском офисе) на таких фактологических пятницах присутствует очно, остальные (из Томска, Волгограда) участвуют по видеосвязи.
У нас текучка кадров, но это нормальный эволюционный процесс: и новые сотрудники, и опытные лиды вырастают из своих должностей и идут дальше, например, в разработку или аналитику. Ну и, конечно, новые ребята — это свежие кровь и взгляд. Лиды пестуют новичков, а те не дают им закостенеть. В общем, все в выигрыше.
Все эти вопросы помогает решить внутренняя культура. В каждой компании отдельно существуют две системы: ценности и правила. Они могут соприкасаться, но обычно правила меняются долго и нужны для формализации процесса, а ценности показывают, что реально важно командам. В первую очередь стоит ориентироваться на ценности.
Собственно, мы стараемся отразить в правилах наши ценности, и это помогает. Сейчас я расскажу, как мы меняем поддержку в этом направлении.
Как устроен отдел техподдержки Хоум Банка
Всего у нас работают 35 человек. Первая линия появилась, ещё когда по планете ходили динозавры, — 13 лет назад. Когда мы только начинали, у нас не было даже столов. Вместо них тогда были тумбочки, на которых стояли компы. А вместо стульев — перевёрнутые мусорные корзины. Мы не смогли найти фотки тех лет (но пытались!), так что поверьте на слово.
Это такая стартаповская тема. У «Амазона» в своё время вместо нормальных столов тоже стояли сдвинутые тумбы. Изначально это было вынужденным решением, но потом стало трендом.
Сейчас так делают многие конторы.
Потом, лет шесть назад, из первой линии выделилась, как мы её называем, полуторная. Она занимается решением инцидентов с основными банковскими системами, аналитикой, поиском каких-то повторяющихся ошибок. Вторая линия состоит из нескольких элементов: под каждую банковскую систему есть своя команда, которая всё «разруливает» в тандеме с первой и полуторной линиями. Ну и, само собой, у нас есть инженеры, которые работают с железом на местах.
И вот вся эта махина из 35 человек должна работать как часы. В этом как раз помогает внутренняя культура. Она даёт сотрудникам чёткое понимание того, что они делают и ради чего вообще работают.
Из чего состоит внутренняя культура:
- Проактивный подход — мы не ждём, что у пользователя случится какой-то инцидент, а работаем на опережение. По крайней мере, стараемся.
- Карьерная лестница — в ней прописаны функции сотрудников поддержки и сопровождения, перечень знаний и навыков, которые необходимо получить для профессионального роста.
- Поощрение околорабочих проектов ребят, которыми они занимаются в свободное от работы время.
- Система бадди — опытные сотрудники, которые помогают новичкам с рабочими и бытовыми вопросами.
- Социальная активность — кибертурниры, внутренние квизы с подарками, традиционные и несуществующие праздники вроде Дня беляша, Арбузной пятницы и т. д.
Базовые требования к сотрудникам техподдержки
У нас клиентоориентированная техподдержка. Соответственно, от кандидата нам нужны эмпатия и навыки психолога, потому что мы работаем с живыми людьми. Безусловно, важно, чтобы у него были хотя бы базовые технические знания, желание развиваться в IT. Я даже скажу так: кандидату не обязательно иметь технический бэкграунд, но у него должно быть подтверждённое желание работать в этом направлении. Например, если он проходит какие-нибудь курсы, читает книжки про ИТ, статьи, смотрит ролики на «Ютубе» — в общем, понимает материал и может об этом рассказать на собеседовании, — то это наш человек.
Естественно, всё это мы определяем на этапе собеседования. Лично я пользуюсь моделированием ситуаций, в которых проявляются те или иные нужные нам качества.
Например, прошу его вспомнить какой-то случай из практики: что он делал, как решал проблему.
Зависел ли её исход от его действий, и если да, то на сколько процентов. И здесь он уже раскрывается, более честно отвечая на стандартные HR-вопросы.
Возраст кандидатов
Сейчас в техподдержке работают сотрудники разных возрастов. Раньше это были в основном молодые люди, но рынок сильно изменился. Сейчас приходят и ребята немножко за 30 с опытом работы в других сферах, но которые решили вкатиться в IT. Самому взрослому нашему кандидату было 35.
Нам, в свою очередь, надо понять, что именно человек умеет и насколько хорошо он впишется в нашу атмосферу. Если мы с ним на одной волне, понимаем друг друга, то нарастить технические скиллы — не проблема.
Зачем нужна культура внутри техподдержки
Например, у нас есть какой-либо процесс, и для него существуют определённые правила. Но ситуация такова (мир BANI, ага), что процессы и подходы могут меняться практически мгновенно.
И если это происходит, то формальный подход всё замедляет, процессы останавливаются.
Появляются неразрешимые противоречия и барьеры. Так вот, ориентация на внутреннюю культуру, её ценности и конечный результат позволяет эти барьеры пробить, а потом постфактум и оптимизировать сам процесс.
Это своего рода полу-agile-подход: люди важнее процессов. С последними всегда можно разобраться потом, если сотрудники разделяют наши ценности и культуру.
Примеров того, как это работает, — вагон и маленькая тележка. Из самого яркого: во время пандемии ковида нам нужно было срочно перевести сотрудников банка на удалёнку. Никакого отлаженного процесса такого массового перевода, естественно, не было. Зато была отлаженная культура, которая помогла быстро среагировать и по-новому выстроить работу без деградации сервиса. Люди делали своё дело без паники и старались помогать клиентам, потому что мы, повторюсь, клиентоориентированная поддержка: клиент не должен уйти от нас с какой-то бездушной отбивкой с нашей стороны.
Чем наша техподдержка круче среднестатистической
Есть много историй про, скажем так, сферическую техподдержку в вакууме. Клиенты часто облекают наболевшее в различные мемы, приколы, анекдоты и так далее. Судя по ним, основные проблемы среднестатистической техподдержки — это:
- Стереотипные, повторяющиеся паттерны поведения сотрудников.
- Медленная работа, отсутствие ориентации на результат.
- Некачественная обратная связь, как от каких-то роботов.
Мы стараемся перевернуть своей работой такой взгляд на техподдержку. Решаем если не все, то многие вопросы уже в момент обращения клиента без заведения лишних тикетов и другой бюрократизации.
Естественно, у нас есть показатели, по которым мы оцениваем качество работы сотрудников.
Например, FCR (First Call Resolution), которая заводится как тикет в ITSM-системе. Если сотруднику позвонили даже за обычной консультацией, то он в любом случае заводит обращение и ставит пометку: вот здесь подключился онлайн, там выполнил удалённую перезагрузку, сбросил пароль и т. д. И в метриках всё это учитывается. Но пользователям мы этого не показываем, дабы не грузить, разве только при сборе CSI по итогу оказанной консультации. Ещё у нас есть метрика «нулевая очередь запросов». Пустая очередь — гарантия того, что первый попавший в неё запрос будет немедленно принят в работу. Наша средняя скорость решения инцидентов (даже при учёте возможных эскалаций) — три часа.
Мы вообще стараемся быть техподдержкой «с человеческим лицом». У нас есть маскот — смеющийся человечек вроде Fallout-боя с оттопыренным большим пальцем. Так вот, мы его вставляем в рассылки, он у нас маячит на дашбордах, на мерче. Мы об этом писали подробнее в одной из статей. Кроме того, стараемся в своей работе не использовать излишне официальных формулировок. Понятное дело, что можно расписать стандартные скрипты на типовые ситуации.
Но нам звонят люди, которые хотят, чтобы с их обращениями поработали нормально, по-человечески, объяснили всё простыми словами и решили проблему. Например, когда звонит пользователь, мы, со своей стороны, видим в карточке, он в компании недавно или «старослужащий». В первом случае человек может не знать каких-то нюансов про те же селф-сервисы, и мы с чуть большими вниманием и пониманием относимся к таким обращениям.
Если у техподдержки плохая организация, то пользователь чувствует себя брошенным.
Буквально ему кажется, что он столкнулся с какой-то непреодолимой преградой, вся работа встала и его мир рухнул.
Наша задача состоит как раз в том, чтобы пользователь такого не ощущал. Это не значит, что мы просто улыбаемся и машем. Нет, с нашей стороны должны быть глубокое понимание всех процессов, какой-то уровень автоматизации и в целом зрелости структуры техподдержки. А культура человечного обращения с пользователем уже завершает общую картину.
Чем мы руководствовались, когда создавали техподдержку в её нынешнем виде
Когда я ещё не был на своей текущей позиции, то наблюдал внутренние процессы со стороны и выработал такой принцип: делай как для себя и думай о других. То есть помогай так, как хотелось бы, чтобы помогли тебе, окажись ты в аналогичной ситуации. С точки зрения организации работы, комфортно должно быть всем участникам процесса: и клиентам, и исполнителям, и менеджерам.
Такой себе кантовский категорический императив в контексте техподдержки.
Я уже говорил про саппорт «с человеческим лицом», все эти истории с проактивностью. Мы стараемся предугадывать появление каких-то проблем. У нас есть сервис по контролю тонера и других ЗИП в печатной технике. Для этого мы разработали дашборд, на котором отображается, что в таком-то конкретном аппарате что-то износилось или заканчивается тонер.
Другой пример — сервис по контролю здоровья жёстких дисков. С помощью SCCM (установщика пакетов для удалённой подготовки развёртывания рабочих мест от Microsoft) мы контролируем смарты состояния жёстких дисков. И если смарт сигнализирует, что хард вот-вот сломается, то мы связываемся с человеком: «У тебя скоро отъедет жёсткий диск, давай планово его заменим».
Иными словами, мы не ждём, когда возникнет какой-то инцидент, а стараемся его предупредить.
В плане комфорта сотрудников мы стараемся уйти от рутины, максимально автоматизировав выполнение типовых задач. 60 % софта ставится без участия техподдержки. В том же SCCM у нас есть магазин приложений, где пользователь может заказать себе прогу через ITSМ-систему.
Если для этого нужно согласование, то пользователь получает его тоже без участия человека.
Потом просто заходит в магазин приложений, кликает нужную программу, и она устанавливается автоматически.
Предоставление и отзыв доступов также автоматизированы. Когда в банке только появился сервисдеск, у нас была целая группа из семи человек. Они целый день только и делали, что предоставляли и отзывали доступы в случае переводов, увольнений, приёма новых сотрудников и т. д. Сейчас этим занимается IDM-система. Она ежемесячно обрабатывает десятки тысяч запросов, связанных с доступами, — абсолютно нереальная цифра для человека!
Если автоматизировать какой-то запрос через IDM-систему не получилось, то есть RPA — робот, который уже и решает проблему. Всё это, естественно, работает в безопасном контуре с учётом всех правил информационной безопасности.
Как концепции бережливого производства помогли в организации техподдержки
Мы, конечно, не делали всё с нуля: значительная база для создания техподдержки в её нынешнем виде уже была.
Но мы внесли в неё принципы философий Lean и Кайдзен: это такие концепции бережливого, ресурсосберегающего производства для минимизации издержек и потерь. Применительно к нашей ситуации смотрим, на что сотрудники тратят больше всего времени и что с этим можно сделать: улучшить, автоматизировать, написать какого-нибудь бота, чтобы выполнял это самостоятельно. В общем, стараемся расширять «узкие места» и находить точки роста.
Вообще философии Lean и Кайдзен — это из сферы производства, но для техподдержки они подходят идеально, только по конвейеру вместо деталей незавершённого производства едут запросы на обслуживание и инциденты. Возьмём диаграмму «спагетти» — её обычно применяют к какому-нибудь работнику цеха, который бегает по нему и что-то делает. По этой диаграмме потом можно отследить его действия.
Однако она применима и к сотруднику техподдержки. Вот у него, допустим, открыто 15 разных приложений: в одном сбросил пароль, в другом посмотрел запросы, в третьем узнал ещё какую-то информацию по компьютеру пользователя. По этим действиям мы составили похожую «тепловую карту» действий сотрудника и узнали, что работники много времени тратят на переключение между приложениями.
Подумали, проанализировали и сделали систему, которая агрегирует в себе всю эту информацию, о ней у нас тоже был пост. Мы назвали её ЦУП — Центр управления полётами, — и в ней у нас AD, SAP, ITSM и т. д. В неё же вытягиваем информацию по компьютеру: сколько места на диске, IP-адрес, подсеть. И по пользователю: последняя авторизация, дата смены пароля, количество ошибок входа и прочее. К этой же системе прикрутили API с нашими инструкциями и базой знаний для пользователей.
То есть создали такой информационный центр, в котором аккумулируется вся нужная информация.
Допустим, нам позвонил человек: «Не могу настроить почту на мобильном телефоне!» Наш оператор сначала задаёт стандартные вопросы, а если пользователь всё равно не знает, то просто находит в ЦУПе нужную инструкцию и парой кликов отправляет ему. Это существенно снижает время обработки запроса, консультации. А заодно ускоряет онбординг, потому что новому сотруднику не приходится показывать каждую из наших 10–15 систем. Всё агрегируется в одной системе, работать с которой мы его и обучаем. Таким образом он быстрее выходит на, скажем так, проектную мощность, а каждую из этих 10–15 мастер-систем осваивает уже по ходу работы.
Кстати, немного возвращаясь к вопросу о сервисе «с человеческим лицом», я вспомнил один забавный случай. По моему настоянию в ЦУП добавили прикольную фичу: если в техподдержку звонит пользователь и у него в этот день — ДР, то в системе это отображается в виде конфетти по экрану. И если оператор это видит, то он должен поздравить пользователя с днём рождения.
Пользователи, понятное дело, этого не видят. Они не знают, какими инструментами мы пользуемся. Но вот среди самих сотрудников техподдержки нашёлся один, кому эта инициатива не понравилась. Я ему объяснил: если вдруг тебе попадётся такой пользователь, то просто помоги с проблемой, а в конце скажи: «Большое спасибо! Поставьте нам оценку и, кстати, с днём рождения!»
В общем, он так и сделал. «Я его поздравил, а он так обрадовался!» Сам же и получил массу приятных впечатлений, хотя изначально был настроен против.
Как мы адаптируем новичков к работе и мотивируем к дальнейшему росту
На онбординге стоит остановиться подробнее. Он у нас проходит быстро, мы его делим на две части. Подробнее об этом можно почитать в нашем отдельном посте. Если коротко — у нас есть портал для джунов «Войди в IT». После изучения нужных материалов практическая часть занимает меньше недели. Они уже знают процессы и системы, остаётся только показать им, как работать с тикетами и пользоваться базой знаний. И всё — какие-то простые задачи они уже могут решать.
Для сотрудников, пришедших извне, обучение, конечно, занимает чуть больше времени — около пары недель. Его мы тоже ускорили — разместили там же, на «Войди в IT», цикл обучающих роликов. Новичок смотрит эти видео и может задать своему бадди уточняющие вопросы.
Бадди — это такой друг-наставник из числа опытных сотрудников. Он помогает не только с рабочими вопросами, но и с бытовыми, например, проведёт экскурсию по офису, покажет, где туалет или микроволновка. Ну и помогает с теми же доступами, хотя в основном они все зашиты в ролевую модель и автоматически присваиваются IDM-системой, о которой я уже говорил. Если новичок столкнулся с совсем уж неразрешимой задачей, с которой и бадди не может помочь, то он просто обращается к своему тимлиду.
Наша модель ориентирована на то, чтобы набирать персонал уровня джуниор или предджуниор.
Из них мы уже сами растим специалиста до какого-то уровня. У нас есть карьерная лестница с разбивкой по скиллам. И если человек растёт по ним, то у него со временем меняются должность и оклад. А когда он достигает определённого уровня на первой линии, то переходит на другую должность на полуторной или второй, инженерной линии либо уходит дальше в смежные подразделения сопровождения, аналитики, разработки и т. д.
Внутри банка есть много путей, по которым может пойти спец из техподдержки.
Например, к нам в техподдержку пришёл один сотрудник, заряженный на карьерный рост.
Сначала отработал полгода на линии, потом попросил перевестись в инженеры. За полгода он освоил весь свой функционал и попросил перевода, чтобы расширить компетенции. Ещё через полгода перевёлся на позицию системного администратора уже на второй линии и сейчас занимается сопровождением серверных ОС в банке.
А всё потому, что пришёл с мотивацией и выполнял все рекомендации из нашего «кандидатского минимума». Это такой вордовский документ на три страницы с тремя курсами на портале «Войди в IT», тремя книжками и списком задач на ДЗ. Он даёт кандидату основы IT-инфраструктуры, computer-science и работы с SQL. Ему остаётся пройти три этих курса, прочитать три книжки и решить домашние задания.
ДЗ — это достаточно простые задания вроде поставить Linux на домашнем ПК, установить Windows второй системой, настроить две виртуальные машины под разные ОС, создать между ними сеть, поднять веб-сервер и т. д. Специально всё задано тезисно и достаточно сухо, чтобы человек, начав выполнять эти задания, сам полез на форумы, на «Ютуб» и в другие источники. И в процессе этого решения он приобретёт нужные для дальнейшего развития и роста знания.
Изначально мы стараемся брать в техподдержку ребят, заряженных на развитие. Но бывает всякое: иногда ожидание и реальность немного не совпадают. В этом случае, конечно, мы стараемся мотивировать таких сотрудников. Но в основном мотивацию они приобретают сами в процессе движения по карьерной лестнице. Если же не приобретают, не развивают в себе компетенции, навыки, знания, то остаются на тех позициях, на которых пришли. Мы об этом регулярно напоминаем в рамках обратной связи, которая происходит между спецами и тимлидами.
Внутрикорпоративные праздники и активности
Нашу внутреннюю культуру мы стараемся донести до сотрудников в интересной форме.
Событие не происходит так, что выходит какой-то тимлид и начинает пафосно вещать о ценностях техподдержки: это, как правило, только раздражает.
Вместо этого мы постоянно проводим различные мероприятия, например, квизы, арбузные пятницы летом и безалкогольно-глинтвейные среды зимой. Ещё мы любим праздники — как традиционные вроде Дня сотрудника техподдержки, так и выдуманные нами самими, например, Междугородный день беляша. Ещё у нас есть практика награждения лучших сотрудников каким-нибудь мерчем.
Так как довольно часто случаются изменения в кадровом составе, мы придумали фактологическую пятницу. Это такая игра для знакомства ребят, чтобы они быстрее и лучше вливались в команду. Мы проводим её прямо на работе в пятницу в обеденный перерыв. Перед этим просим каждого сотрудника рассказать о себе какой-то факт. Например, упал в детском саду и получил огромный фингал, с которым сфоткался на выпуске, и эта фотография теперь стоит у него дома. А потом на общем собрании озвучиваем этот факт, а остальные члены команды должны угадать, о ком идёт речь. Это помогает ребятам познакомиться друг с другом, узнать что-то интересное о своих коллегах.
Команда распределённая, часть сотрудников (те, кто работает в обнинском офисе) на таких фактологических пятницах присутствует очно, остальные (из Томска, Волгограда) участвуют по видеосвязи.
У нас текучка кадров, но это нормальный эволюционный процесс: и новые сотрудники, и опытные лиды вырастают из своих должностей и идут дальше, например, в разработку или аналитику. Ну и, конечно, новые ребята — это свежие кровь и взгляд. Лиды пестуют новичков, а те не дают им закостенеть. В общем, все в выигрыше.
