Привет! Меня зовут Андрей, и это третья, финальная часть моего рассказа об эволюции службы технической поддержки внутренней CRM системы для малого и среднего бизнеса в Росбанке.
Во второй части я рассказал, как мы совершили гиперпрыжок от поддержки сотрудников через почту во внутреннюю helpdesk‑систему банка SD, а также о том, как мы сделали нашу реализацию обработки обращений на нашей доске в Jira.
В этой статье я расскажу о том, как мы продумали и внедрили способ контроля за соблюдением SLA для инцидентов внутри продуктовых команд. Поделюсь нашим способом ведения отчетности и поделюсь некоторыми фичами, которые сделали работу нашей команды технической поддержки легче.
Таймеры SLA – наше все?
Здесь и далее нам понадобится таблица со сроками выполнения обращений, которую я показывал во второй части цикла статей, поэтому повторим ее.
Приоритет | Время решения | Пояснение |
Низкий | 32 часа | Как правило, запросы на выдачу доступов. Решаются силами поддержки. |
Средний | 24 часа | Неточность в отражении данных на странице, ошибка в карточке клиента, которая носит информационный характер. |
Высокий | 8 часов | Инцидент или ошибка, которые так или иначе мешают выполнению прямого функционала, но есть альтернатива. |
Критический | 3 часа | Аналогично высокому, но при этом у сотрудника нет альтернативы и присутствует риск потери клиента. |
Продублирую здесь один из основных вопросов, который прозвучал ближе к концу предыдущей второй части статей этого цикла. Он звучит таким образом: «Как отслеживать время выполнения того или иного клона в соответствии с приведенной выше таблицей SLA?».
Jira предлагает нам для решения этого вопроса прекрасный инструментарий. Не буду лить воду и придумывать плавную подводку к решению вышеуказанного вопроса, а сразу покажу как мы к нему подошли.
В Jira есть плагин, который называется SLA. Он дает проекту возможность создания таймеров для описанных в его настройках задач. Поэтому если вы решите внедрить в своих проектах указанный ниже функционал, попросите ваше ответственное подразделение обеспечить вам установку этого плагина.
Имея права администратора, перейдите на страницу настройки проекта и, первым делом, создайте ваш рабочий календарь во вкладке Work calendars. В рамках Jira можно создать тот календарь, по которому работает ваша команда. Иными словами, отметить все дни от понедельника до пятницы с началом и окончанием вашего рабочего дня. Таймер, который вы впоследствии создадите, будет работать именно по нему. Пример такого рабочего календаря вы можете видеть на рисунке 1.
Во-первых, в разделе SLA (рисунок 2) мы видим текущие настройки календаря, по которому живет наша доска в Jira. И если у нас появилась идея внедрения какого бы то ни было таймера, то необходимо создать определенное расписание, на основе которого этот таймер будет существовать.
На рисунке 3 мы видим уже созданный таймер (конкретно в нашей реализации). Название здесь можно написать произвольное, но будет лучше, если мы четко обозначим что это и для чего это нужно. Если, исходя из названия, вы можете четко ответить на вопросы: «что это за таймер?» и «зачем он нужен?», то можно считать, что с этим вы справились.
Также не лишним будет пояснить и другие поля этого уже созданного таймера:
Поле Issue types — определяет тип задачи, для которой этот таймер будет существовать. В нашем случае выбран тип Incident, но его также можно добавить и к любому другому типу задач в Jira, например, для типа Bug.
Поле Условия — без тавтологии не обойтись, но это условия начала и завершения отсчета времени.
Количество целей — немного забегая вперед, это те цели, которые будут описаны на рисунке 4. В нашем случае это 4 цели на каждый из приоритетов (Low, Medium, High, Critical).
И одна цель по умолчанию на 72 часа для рабочего календаря.
Важное уточнение! Что будет с таймером по истечении его срока? Он пропадет? Нет, начнется отсчет времени просрочки исполнения.
Во‑вторых, вы можете добавить свои конкретные сроки этого таймера для того или иного приоритета (рисунок 4). В этих полях мы уже видим подсказки для их заполнения, но будет не лишним описать их текстом:
JQL запрос. Здесь с помощью языка запросов JQL вы можете задать нужные вам условия для выборки.
Цель. В этом поле необходимо ввести количество часов, которое будет установлено в виде стартового значения таймера для заданного в предыдущем поле пула задач.
Производственный календарь. Здесь в выпадающем списке необходимо выбрать тот календарь, по которому будет работать таймер.
В данном случае у нас уже созданы такие цели и увидеть вы их можете на рисунке 5.
Но здесь есть одна очень важная деталь. Все вышеуказанные действия необходимо выполнять в тех проектах, на чьих досках вы хотите видеть этот таймер. Иными словами, если у вас есть пространство Jira, в котором вы работаете и где есть несколько досок, то необходимо создать таймер лишь единожды.
И после всех этих манипуляций на вашей доске в Jira в том типе задач, для которого вы создали счетчик (в нашем случае это тип задач Incident), появится этот таймер. Увидеть его вы можете на рисунке 6.
Подытоживая этот раздел, скажу, что с помощью плагина SLA для Jira мы можем реализовать таймер для своего производственного календаря и определенных условий в нем и, тем самым, решить проблему отслеживания времени на выполнение той или иной задачи.
Как напомнить команде об истекающих сроках?
Хорошо, с созданием таймера мы разобрались. Но как быть с тем, чтобы не просрочить обращение сотрудника? В таблице выше я привел такие сроки для каждого из приоритетов, но давайте расширим ее и добавим еще один столбец, который будет отражать количество часов для каждого из приоритетов, за истечением которых будет срабатывать механизм напоминания.
Приоритет | Время решения | Напоминать за |
Низкий | 32 часа | 16 часов |
Средний | 24 часа | 8 часов |
Высокий | 8 часов | 4 часа |
Критический | 3 часа | 1,5 часа |
Для того, чтобы вовремя напоминать нашим аналитикам и разработчикам о задачах, чей SLA подходит к концу, мы решили использовать правила автоматизации в Jira из раздела Project automation.
Как создать такое правило автоматизации? Нужен всего лишь простой советский… Ладно, если серьезно, то во вкладке Project automation нажимаем синюю кнопку Create rule и настраиваем правило таким образом:
Вписываем наименование и опционально описание правила автоматизации.
Для триггера Scheduled указываем cron expression: 0 0 16 ? * MON,TUE,WED,THU,FRI *
В поле JQL-запрос указываем условие. В примере мы возьмем выборку инцидентов с приоритетом Low: "[PRO Business]Крайний срок выполнения инцидента" in searchBySlaTime("<", "90M") and priority = Low.»
Добавляем нашему правилу действие (action) отправки почты (Send email) и во вкладке Content прописываем верстку для получаемого письма (опционально), используя выражения Jira (рисунок 7).
Сохраняем правило автоматизации.
Для приведенных выше значений cron-выражения и JQL-запроса вы будете получать письмо каждый день в период с понедельника по пятницу в 16:00 по местному времени. Пример такого письма вы можете видеть на рисунке 8.
Таким образом, мы создали правило автоматизации. Оно будет отрабатывать на стороне Jira и по заданному cron-выражению для JQL выборки присылать на указанные адреса письмо со списком задач, чей таймер подходит к концу.
Как быть с массовыми инцидентами?
Мы уже знаем, что на каждое обращение в поддержку создается задача в Jira. И если сотрудник поддержки не может решить его самостоятельно, он создает клон в пространстве профильной команды. Но как быть, если произошел массовый сбой, и все сотрудники ринулись писать в поддержку по одной и той же проблеме.
На самом деле плодить кучу клонов по одной и той же проблеме нет никакой необходимости. Более того, такое «закидывание» клонами лишь ухудшит ситуацию на доске в Jira, и в ней будет труднее ориентироваться.
На такие случаи у нас тоже приготовлен особый порядок действий. Если за последний час к нам по одной и той же проблеме обратилось два и более сотрудников, мы на своей же доске в Jira связываем все последующие обращения с первым поступившим. Сделать это можно на странице самой задачи через вкладку «Еще» — «Связать», и указываете номер задачи в поле Задача, не забыв отметить тип связи. Пример на рисунке 9.
Следим за показателями, чтобы быть лучше
Для анализа эффективности работы команды и применяемых подходов мы реализовали кастомный отчет, расчет метрик в котором производится на основе данных, которые мы получаем из Jira через Jira-API.
Сами метрики, способ их расчета и наименование выбраны исходя из потребностей бизнеса, т.е. для нас важно общее количество инцидентов, количество решенных кейсов за заданный период, а также понимание, какая часть обращений была решена силами поддержки, а какая часть была передана на обработку в бизнес-команду. Для подготовки такого еженедельного отчета мы привлекли разработчиков. В отчете дополнительно мы выводим данные по инцидентам для каждой команды отдельно, ориентируясь на приоритет инцидента. Пример вы можете видеть на рисунке 10.
Послесловие
Вот и закончился мой цикл статей‑рассказов о том, как мы в Росбанке командой поддержки выстроили свой процесс поддержки сотрудников, которые работают с нашей внутренней CRM‑системой PRO Business.
Не могу сказать, что это было легко. Напротив, мы сталкивались с большим количеством трудностей и неточностей; экспериментировали, пробовали новое и дружно брэйнштормили. Но все эти проблемы мы восприняли как вызов, который необходимо преодолеть. И мы преодолели.
Заканчивая, хочу озвучить два своих принципа, которые в своей работе я пытаюсь транслировать всем нашим пользователям и командам: «Идеальной системы не существует. Но есть система, в которой пользователям удобно взаимодействовать» и «Проблема считается решенной не когда мы что‑то по ней сделали, а когда пользователь подтвердил решение».
Хочу сказать огромное спасибо своему IT‑лидеру Головой Анастасии, которая помогала сделать эти статьи лучше; скажу даже больше — без нее этот цикл статей вряд ли бы состоялся.
С уважением, Вишневский Андрей, лидер поддержки сотрудников малого и среднего бизнеса внутренней CRM‑системы в Росбанк.
