Огонь, в котором вы сгораете, надо обслуживать.
В.О.Пелевин, “Generation П”
Привет, Хабр! Меня зовут Александр Соловьев, я руководитель технической поддержки дата-центров Миран.
Скажите, вот вы пробовали писать учебники? Я — нет. Тем не менее, текст ниже — это своего рода методичка по организации технической поддержки. В рамках статьи я хотел бы рассказать вам, что из себя представляет техническая поддержка дата-центров Миран: какие “шестеренки” крутятся и почему они крутятся именно так, а не иначе.
Для удобства читателя я разделю эту статью на несколько смысловых частей.
- В первой мы поговорим о базовых элементах работы ТП — штатное расписание, жизненный цикл заявки, приоритезация.
- Во второй части мы коснемся вопросов поддержания знаний инженеров технической поддержки на заданном уровне.
- В третьей, заключительной части мы поговорим о том, как заставить всё перечисленное выше работать.
Я расскажу о мотивации, в частности, нефинансовой, а также дам пару советов по организации корпоративных поощрений и наказаний.
Основы работы службы техподдержки
Чтобы организовать работу технической поддержки, нужно ответить на несколько простых вопросов:
- Требуется поддержка одного продукта (услуги) или речь идет о мультипродуктовой поддержке, т.е. поддержке нескольких совершенно разных продуктов?
- Какой SLA требуется обеспечить для обращений в техническую поддержку?
- Нужно ли обеспечивать круглосуточную поддержку?
Первое
Монопродуктовая поддержка требует минимального количества специалистов. К примеру, если предполагается около десяти заявок за смену, можно попытаться переложить поддержку на профильного инженера.
Мультипродуктовая поддержка требует либо выделения специалистов по продуктам, либо разделения трафика обращений по сложности, что выражается в организации нескольких линий поддержки.
Мы пошли по пути разделения инженеров в соответствии с их знаниями и компетенциями на три составляющие: первая, дополнительная и вторая линии техподдержки.
Второе
Чем жестче SLA, тем больше ресурсов компании потребуется для его соблюдения. Это самые разные ресурсы: квалифицированные инженеры, информационные системы, оборудование, нормативная документация и прочее. Рассмотрим вопрос штата. Для выполнения требований SLA штат сотрудников должен быть пропорционален среднему количеству обращений в техподдержку с учетом временных и качественных нормативов.
Исходя из вышенаписанного, штат наших инженеров следующий:
• первая линия — 10 человек;
• дополнительная линия — 4 человека;
• вторая линия — 5 человек.
Третье
Круглосуточная техническая поддержка — услуга недешевая. Качественное исполнение этой услуги в режиме 24х7х365 потребует как минимум 5 инженеров, и это в самом простом случае, т.е. в случае монопродуктовой поддержки. Если необходимо организовать круглосуточную поддержку, смело умножайте затраты на 5. Но, прежде всего, подумайте, так ли она нужна (нельзя ли обойтись порталом самообслуживания и т.д.). Если все же нужна — нельзя ли отдать ее на аутсорс.
Чем заняты все эти люди
Задача инженеров первой линии — быстро и качественно обработать обращение клиента. Обработать означает правильно классифицировать и отправить в работу.
После обработки инженер первой линии либо решает заявку самостоятельно, если она из раздела “сделать быстро, здесь и сейчас”, либо передает заявку на другую линию, если она “долгоиграющая” или речь идет о “неисправностях”.
Задача инженеров дополнительной линии — работать с заявками, выполнение которых занимает более одного дня.
Задача инженеров второй линии — как можно быстрее устранять неисправности и решать сложные заявки “здесь и сейчас”.
Режимы работы инженеров
Первая линия: график — 2/2, 12-часовые смены с 08:00 и 20:00.
Дополнительная линия: график — пятидневка, 8-часовые смены с 08:00 и с 12:00.
Вторая линия: график — 2/2, 12-часовые смены с 08:00 и 20:00.
Графики смен инженеров ведутся посредством Google Календаря.
Жизненный цикл и статус заявок в ТП
Проследить жизненный цикл заявки проще всего по этой схеме:
Отдельно поясню каждый из пунктов.
- Статус new приобретает любая заявка, полученная из внешнего источника. Задача инженера первой линии — первично обработать поступившую заявку и передать исполнителю.
- Статус open присваивается заявке, когда решением занят специалист.
- Если заявка была определена как спам, она приобретает статус deleted.
- Если заявка не является спамом, но и не содержит сущностного обращения в техническую поддержку, ей присваивается статус rejected.
- Статус resolved присваивается заявке после решения задачи/проблемы по мнению исполнителя.
- Статус stalled означает, что работа над заявкой временно приостановлена по инициативе клиента или по согласованию с ним.
- Статус closed присваивается после того, как клиент посчитает, что его задача успешно решена.
Типизация заявок
Тип заявки — это самый важный критерий. Он определяет скорость реакции и время устранения проблемы, указанной в тикете. В Миран, в соответствии с ITIL, запросы делятся по следующим типам. Привожу их в порядке значимости:
Инциденты
К инцидентам относятся неисправности и сбои в работе оборудования, а также любые другие события, повлекшие значительное ухудшение качества сервисов. Заявки этого типа выполняются в порядке приоритета и имеют преимущество над прочими типами заявок. Только инциденты могут иметь приоритет при обработке.
Примеры инцидентов: недоступность сервиса, отказ аппаратных средств.
RFS — Запрос на обслуживание
Заказчик имеет потребность в обслуживании в рамках предоставляемых услуг. Запрос не связан со сбоем или отказом в IT-инфраструктуре. Выполняется незамедлительно в порядке общей очереди при отсутствии заявок с приоритетом.
Пример: запрос на перезагрузку сервера.
RFC — Запрос на изменение
Запрос на изменение состава и/или объема предоставляемых клиенту услуг. Время обработки определяется менеджментом компании индивидуально по согласованию с клиентом.
Примеры: запрос на коммутацию оборудования.
RFI — Запрос на предоставление информации
Запрошена информация по услуге, включая отчеты по объему электропотребления, сервисные отчеты и прочее. Выполняется незамедлительно в порядке общей очереди при отсутствии заявок с приоритетом.
Приоритет заявки, влияющий на скорость реакции и решения, рассчитывается на основании полученной от клиента информации с учетом ряда внутренних правил и распоряжений. Есть два приоритета: начальный и финальный. Начальный приоритет устанавливается со слов клиента и определяет скорость обработки инцидента. Финальный приоритет устанавливается инженером после завершения работ и отражает фактический уровень деградации услуг. Часто эти приоритеты не равны.
Распределяются приоритеты следующим образом:
- нарушено функционирование сегмента сети (недоступен узел связи, вышел из строя опорный коммутатор) — 40;
- существенная деградация нескольких услуг, предоставляемых клиенту — 30;
- существенная деградация одной из услуг, предоставляемых клиенту — 20;
- деградация услуг, которая не оказывает существенного влияния на их сущность — 10;
- влияние на услуги клиента отсутствует — 0.
Думаю, на этом можно плавно закончить разбор теории. За кадром останутся тайминги реакций на инциденты и запросы, уровни эскалации, финансовая мотивация и прочая информация, более-менее стандартная для других компаний. Перейдем к более интересным вещам.
Поддержание необходимого уровня знаний
В работе службы техподдержки мы стремимся регулировать всё, что регулируется, быть прозрачными для клиента, а также формализовать и оцифровывать любую информацию, которая в дальнейшем может оказаться полезной и применимой. Фидбек от клиентов, уровень знаний наших сотрудников, их достижения и факапы, – все это скрупулезно оцифровывается, анализируется и в последующем влияет на управленческие решения.
За несколько выходных дней инженера технической поддержки какие-то регламенты могут изменится, появятся новые “вводные”, а значит в начале смены необходимо позаботиться о проверке актуальности знаний инженеров. Делается это при помощи технологии ситуационного моделирования, путём тренировок по разрешению ситуаций, в которых указанные знания востребованы. Одну ситуацию мы называем юзкейсом. В начале смены инженер получает порцию из нескольких юзкейсов. Подобный подход позволяет инженерам поддерживать в уме нужные знания и постоянно обновлять их. Как следствие, повышается качество работы. Для снижения стресса дедлайн решения юзкейсов установлен на конец смены, хотя по факту спецу достаточно десяти минут.
Из чего же конкретно состоит типовой юзкейс?
Всего в нем 4 смысловых блока:
- Информационный блок
В нем содержится полезная информация, которая должна быть усвоена. - Блок-связка
Этот блок позволяет связать новую информацию с «транспортом» этой информации в память человека. - Варианты ответа
Фактически, это и есть «транспорт» информации в память. - Proof Link
Ссылка на какой-либо доверенный источник, где можно изучить эту информацию.
Так выглядит стандартный юзкейс на примере исторического материала
Все блоки юзкейса связаны по смыслу и теме. В идеале информационный блок должен содержать намек на вариант ответа, а для уточнения требуется открыть prooflink и детально изучить там разбираемый вопрос.
Внедряя эту практику, я столкнулся с одним неприятным моментом: на рынке не существует ни одного полноценного инструмента, который позволял бы хранить в себе базу знаний, “умно” распределять юзкейсы по сотрудникам и проверять их ответы.
На текущий момент мы задействуем связку из нескольких инструментов.
- Request Tracker (RT) — определяет логику взаимодействия систем.
- Google Calendar по API “отдает” список сотрудников и количество юзкейсов для каждого.
- Google Spreadsheets выдает информацию для формирования юзкейса.
На деле система работает следующим образом:
- Формируется список сотрудников, участвующих в тренировке знаний.
- Для каждого сотрудника определяются темы юзкейсов.
- На каждую тему создается юзкейс и передается сотруднику.
- В течение рабочего дня инженер должен решить все юзкейсы.
- Ответы проверяются, а результат проверки каждого юзкейса сохраняется в системе.
Хороший инженер решает один юзкейс примерно за минуту. Схитрить и “считерить” достаточно проблематично, мы позаботились и о собственной античит-системе.
Помните: ни в коем случае не пытайтесь управлять уровнем знаний сотрудников в тех отделах, где вы не управляете мотивацией.
Пистолет, попугаи и мотивация
Я достаточно подробно рассказал о том, как работает служба техподдержки. Осталось понять еще один важный момент: почему она вообще работает? :)
Всё держится на двух столпах. Столпы эти — нефинансовая и финансовая мотивация.
Знаменитый гангстер Аль Капоне говорил: “Добрым словом и пистолетом вы можете добиться куда большего, чем одним только добрым словом”. Как ни прискорбно, в этой метафоре финансовая мотивация — это доброе слово, а нефинансовая — это уже “старый-добрый” пистолет.
Нефинансовая мотивация
Три кита нефинансовой мотивации:
Любой человек очень негативно реагирует на штрафы выраженные в деньгах… но к счастью, гораздо легче переживают насчет штрафов в “попугаях”. А между тем, попугаи, если уметь их готовить, очень и очень существенно мотивируют сотрудников.
Мы выбрали в качестве. попугая отгул, но теоретически можно выбрать что-то другое. Отгул хорош тем, что осязаем всеми сотрудниками, востребован по прямому назначению и не приходится объяснять подчиненным что это такое и для чего это нужно. Прежде всего, при выборе единицы учета следует исходить из того, что она не должна быть “сферическим конем в вакууме”. Единица учета должна быть осязаема для сотрудника.
В рамках нефинансовой мотивации сотрудники лишаются не денег, а отгулов и, соответственно, возможностей пользоваться благами нефинансовой мотивации. Это неприятно, но не так, как денежный штраф: стимул расти есть, а лояльность человека к компании не страдает. “Подвиги” поощряются отгулами. Сотрудник может использовать отгул по прямому назначению: например, поваляться дома, но это не так интересно. Интереснее —
Единственный минус отгула по сравнению с деньгами — каждый вариант использования либо в прямом, либо в денежном эквиваленте нужно отдельно аппрувить у начальства, что не всегда удобно. Цена отгула у нас составляет 3000 рублей, у вас может быть больше или меньше. Главное — обоюдный комфорт от использования единицы нефинансовой мотивации.
Приведу живой пример, когда конкретная работа награждается нефинансовым образом.
Составление хороших документов с юзкейсами для базы знаний — это не столько задача, сколько процесс. Каждый месяц появляется что-то новое: клиенты, оборудование, софт. Всё это по уже названным выше причинам требует внимательного отношения и документирования.
Если в самом начале я работал над составлением этих документов самостоятельно, то сейчас система пополнения базы знаний работает почти автономно. Моя задача — направлять сотрудников в нужное русло, давать им вектор движения и осуществлять выходной контроль.
Мой опыт показывает, что «цена» одного хорошего документа, снабженного достаточным количеством юзкейсов — это три отгула.
Два отгула инженер получает за документ, который не требует значительных исправлений.
Один отгул человек получает, если требуется много исправлений, и легче внести их самому, чем объяснять, как сделать правильно.
Мы пробовали давать больше отгулов за эту работу — от 10 дней и больше. Но практика показала, что слишком большая награда отпугивает, и желающих ее получить практически нет. Поэтому важно не переборщить с поощрением сотрудников. Это может встать вам боком самым неожиданным образом. Экспериментируйте, но делайте это аккуратно.
Финансовая мотивация
Каждая заявка, выполненная инженером ТП, поощряется бонусами. Величина бонуса прямо пропорциональна сложности заявки и требуемой для ее выполнения квалификации. Финальная заработная плата инженера определяется суммой этих бонусов. Разумеется, в случае “кривого” выполнения заявки бонус за нее сгорает.
Еще один нюанс: зарплата инженера всегда находится в диапазоне, определенном его должностью. В самый ленивый месяц человек не получит меньше нижней границы этого диапазона, как и не получит больше верхней в самый продуктивный. Тем не менее, никто не уйдет обиженным: все косяки наказываются, а переработки поощряются через нефинансовую мотивацию.
Подводим итоги
Статья получилась неожиданно объемной, но это и не удивляет: мы рассмотрели жизнь технической поддержки Мирана почти целиком, опустив лишь самые скучные или общие детали. Тем не менее, если я все-таки забыл написать о чем-то интересном для вас или во время чтения у вас появились вопросы, касающиеся организации службы ТП, я буду рад ответить на них в комментариях.
Материалы по теме
- Мой доклад о управлении знаниями в технической поддержке на конференции KnowledgeConf 2019.
- Статья на хабре KPI техподдержки.
- Статья на хабре о управлении знаниями в технической поддержке.