Между первой и второй
Привет, Хабр!
Меня зовут Ольга Хромина, и в этой статье я расскажу о выстраивании отношений между первой и второй линиями поддержки с учётом некоторых особенностей.
У вас всех этих особенностей может не быть, и вообще, всё рассказанное может показаться прописными истинами. Именно рассказанное, потому что этот материал — больше рассказ, нежели научно-практическая статья. Но мне всё же хочется зафиксировать свой опыт, потому что ходят слухи, что не всегда всё просто между уровнями поддержки.
Я — руководитель группы второй линии поддержки систем. Мы работаем над разными интересными и сложными платформами, одна из них — приложение для удобной и быстрой продажи SIM-карт. Именно при поддержке этого приложения мы столкнулись с разными нюансами и особенностями. Выделю из них ключевые и расскажу, какой опыт накопили.
Первая линия поддержки — это не IT
Наша первая линия поддержки не входит в IT-подразделения. Здесь работают эксперты сервисного обслуживания, бизнес-администраторы и даже владельцы продуктов. То есть нетехнические специалисты. Они должны добиться максимально качественного клиентского сервиса. Это очень здорово для пользователей. Но когда от такой группы передаётся информация о технических проблемах, может возникнуть недопонимание. В переданном инциденте может не хватать информации, это потребует уточнений и увеличит срок решения проблемы. А еще сведения бывают избыточными. Например, наша первая линия настолько прокачанная, что может собирать логи в ELK и прикладывать их к заявке. Однако логи могут не относиться напрямую к инциденту, их наличие искажает ожидания о скорости дальнейшей обработки запроса.
Для сглаживания этого нюанса важно иметь зафиксированные инструкции и рекомендации. Можно написать мануалы о том, что именно проверять по какой конкретно проблеме. Можно вшить некоторые пункты в параметры, фиксируемые в заявках. Проводить обучающие встречи, записывать их для новых коллег. Приветствуется настройка мониторинга первой линии, ниже об этом пишу подробнее.
Важно поддерживать контакт между линиями, иметь поле для общения только на темы поддержки системы и пользователей. У нас есть чат, называется «срочные вопросы». У чата есть обратная сторона: кроме срочных вопросов, там обсуждаются несрочные. Нужно помнить, что чат — это альтернативное информационное поле и точно не трекер задач. Если процесс постановки задач и их приоритизации налажен, то чат приносит только пользу.
Стремительное развитие системы
Так сложилось, что все поддерживающие систему лица привыкли к минимальному функционалу в ней. Все всё знают, неважно, какой путь эскалации проблемы: она же все равно понятна всем и точно не потеряется. Тем временем за год был выпущен 41 релиз, принеся с собой следующие изменения:
Было шесть кнопок на главном экране — стало в два раза больше.
Пользователей стало в три раза больше.
Появились новые фоновые и асинхронные процессы, которые не видны в приложении, но важны для поддержки.
Изменился сервис авторизации пользователей.
Менялись процессы, стоящие далеко за нашей системой, но влияющие на ожидания пользователей.
И это только то, что касается самих пользователей и может привести к инцидентам. Здесь не учитывается увеличение количества сервисов, которые нужно поддерживать, или изменение инфраструктуры.
Что может помочь при таких условиях? Информирование об изменениях всех участников поддержки.
Есть практика участия второй линии в регулярных встречах команды разработки. Это позволяет инженерам быть в курсе надвигающегося объёма и сложности функциональности, сразу подключаться к внедрению доработок, получать регулярно обратную связь о решении заведённых ошибок, оказывать прочую поддержку команде, своевременно выполнять приёмку в поддержку и подготовку к релизам. Но первой линии на этих встречах нет, и часто получалось так, что коллеги узнавали о специфике работы нового функционала уже из жалоб пользователей. Поэтому крайне важно, чтобы менеджер в адресаты запроса на релиз включал и первую линию. Так коллеги знают дату релиза, его состав и описание, номер новой версии приложения.
Отлаженный процесс приёмки в поддержку как первой, так и второй линиями
Про приёмку на вторую линию можно говорить долго, это тема отдельной статьи. На мой взгляд, главное отличие между ними было в том, что первая принимала доработки только на проде и только в работающем виде. Вторая линия принимает новый сервис или функционал в любой среде. Главное, чтобы в момент выноса на прод уже было представление о том, как его поддерживать. Мы формируем это представление на основе регламента, в котором по пунктам описаны все действия. Из-за разницы в критериях приемки образовывалась нестыковка, было непонятно, кем и что принято, кто и что делает. Вывод: важно не только отладить процессы приёмки функционала, но и синхронизировать их между собой.
Наше решение. В регламент приёмки второй линией мы добавили обязательные пункты:
руководство пользователя;
факт приёмки бизнесом;
отметка о проведении обучения новому функционалу пользователей;
метрики для постановки на мониторинг.
В процесс приёмки второй линией и так входит постановка на мониторинг. Базовые метрики: health checks сервисов, количество ошибок методов, контроль времени ответа, интеграционные запросы и дополнительные метрики — запрошенные заказчиком или аналитиком бизнес-показатели. В наш чек-лист мы добавили и постановку задачи на мониторинг метрик для первой линии. Он сильно зависит от функционала, тем не менее, обсуждать его и ставить соответствующие задачи нужно. Пример таких показателей: количество заблокированных пользователей, ошибки прохождения двухфакторной авторизации пользователем, суммарное количество ошибок по сервисам или здоровью системы. В общем то, что поможет провести первичный анализ на этапе сбора данных о проблеме и понять, а должно ли оно было работать в тот момент вообще.
Первая линия, в свою очередь, договорилась подключаться к бизнесовым приёмкам, чтобы иметь представление о поставленных задачах и ожидаемых результатах. Владельца команды обязали на каждое демо звать все линии поддержки.
Смена владельца продукта и полная смена команды разработки.
А вот и ещё один интересный нюанс, с которым мы столкнулись. Глобально на эти вещи инженеры и специалисты всех поддержек мира повлиять, конечно, не смогут, не буду выводить здесь никакие решения и факты. Все прекрасно понимают, что это может быть чувствительно. В поддержке мы учились обходить два угла:
это личные наработанные годами (или меньше) взаимоотношения между членами команды;
и, как ни удивительно, наличие ошибок в системе.
Говоря про личные взаимоотношения, я не имею в виду выпитый в пятницу вечером в баре молочный безалкогольный коктейль совместно с коллегами — с этим перебоев нет, бары не простаивают. На обеих линиях поддержки люди привыкли решать вопросы в личных переписках, даже при наличии сущностей заявок, ошибок и очевидных правил их обработки и эскалации. Конечно, информация из личных переписок может быть утеряна. Я даже однажды слышала разговор: «Вот когда был Иван Петров, он мне скидывал инструкцию, а потом он эмигрировал, удалил свой Telegram, и инструкция потерялась» (имя в цитате изменено). Звучит страшно, правда? Поэтому независимо от того, какой год на дворе, насколько цивилизован мир и технологичности компании-работодателя, вы должны быть уверены, что сотрудники поддерживают корпоративные браузеры, а все инструкции фиксируются на wiki. К слову о wiki, к хорошей можно отнести практику вести базу инцидентов в поддержке — тогда не придётся по чатам искать, кто, когда и как решал тот или иной вопрос.
Более чувствительный нюанс в этой главе ждал нас со стороны наличия зафиксированных ошибок в системе.
К определённому моменту на доске был накоплен скоуп багов, которые прежний владелец считал приоритетными и строил планы на их исправление. Следующий владелец принял решение заморозить все ошибки ниже второго приоритета. Хотя были пользователи, которые ждали улучшения. И целых две линии поддержки тоже имели свои ожидания: исправления этих ошибок, применения обходных решений обработки жалоб, связанных ними. Как вы помните, у нас ещё и быстроразвивающаяся система — нет-нет да и новые ошибки успевают подъезжать. Получается, на этот момент влияет не только смена команды, но и все нюансы вместе взятые, озвученные и не озвученные.
Вопросы ошибок у нас заняли больше всего времени. Для налаживания процесса взаимодействия между линиями объединились все ключевые участники процесса: владелец продукта, владелец команды, плюс все светлые головы наших поддержек.
Итак, решения в этом разделе:
Однозначное определение приоритетов проблем.
a) Определение приоритета обращений, создаваемых первой линией, находится на пересечении критичности функционала для бизнеса и массовости влияния на пользователей. Для этого нужно: определить список бизнес-процессов, их критичность и регулярно этот список пополнять (можно включить в процесс приёмки в поддержку).
b) Определение приоритета ошибки, созданной на доске, для эскалации на третью линию. Здесь у нас есть признаки и критичности, и приоритета. Первый и второй приоритет определяются инженерами второй линии и предполагают немедленное включение команды в исправление ошибки. Следующие по важности приоритеты определяет владелец продукта на регулярных встречах. Степень критичности ошибки зависит от влияния на пользователей и наличия обходных путей — это определяют инженеры поддержки.
Все упомянутые приоритеты расписаны на wiki с примерами — каждый член поддержки их знает. Таким образом, на всех уровнях поддержки есть понимание, чего ждать от определённого бага. Ни у кого нет иллюзии, что кто-то кинется день в день исправлять высокохудожественный промах с неработающими шрифтами при администрировании новостей. И при этом нет сомнений, что при падении основного функционала все необходимые силы незамедлительно будут направлены на его исправление.
Существуют такие полезные встречи, как «груминги» по ошибкам. На них важно звать всех: первую линию поддержки, вторую линию поддержки, владельца продукта, владельца команды и многоуважаемого представителя разработки. Всегда есть риск, что при всей нашей совершенной схеме приоритизации владелец скажет, мол, не нужно пока это исправлять, не так важно для бизнеса. А ненавязчивый комментарий разработчика о том, что это исправляется в одно касание, картину поменяет. Инженеры могут обосновать весомый вред для здоровья при дальнейшей поддержке системы без исправления этой ошибки. Первая линия зафиксирует обратную связь для управления ожиданиями пользователей и/или отметит, что всплеск жалоб прошёл, и этот функционал уже никому не интересен. Всегда есть, что обсудить. И всегда важно всем периодически смотреть на весь список ошибок, а не только на те, вовремя спродюсированные, которым повезло двигаться по доске.
Итого, зафиксируем ещё одно решение: вовлечение в приоритизацию ответственных лиц от всех заинтересованных сторон. И оно не последнее.
Налаженный путь эскалации проблем
Что у нас было. Специалист первой линии мог перевести обращение в статус «На третьей линии». Он означает, что ошибка эскалирована на уровень разработки. Но за самими ошибками на доске команды первая линия не следит: заявка так и провисит в этом статусе, пока пользователь не получит глубокую душевную рану. Инженер второй линии мог отправить обращение на уточнение, не обратив внимания, что заявка будет назначена оператору контактного центра, а связь с этим пользователем должна вестись через почту дилера. Как итог, заявка так и провисит, медленно по крупице уничтожая веру пользователя в важность своей персоны. Могу ещё вспоминать примеры из жизни, дополняя их лирическими фразами, но, думаю, суть ясна.
Мы договорились не перескакивать между линиями. Все общение с пользователем — любые уточнения, сбор информации, голосовые контакты, письма и голуби, отправленные пользователям — идет только через первую линию. Непонятно, что и как спрашивать/уточнять — собираем звонок, обсуждаем, разъясняем и фиксируем на wiki.
Всё, что передаётся в смежные подразделения (интеграции) или в разработку, должно быть обязательно обогащено техническими данными, которые собирает инженер второй линии, опираясь на сценарий воспроизведения. Опять-таки, если непонятно, повторяем предыдущее упражнение и фиксируем на wiki. Через линии мы не перескакиваем, даже если кажется, что такой путь решения короче.
Есть ещё одно решение, влияющее на взаимодействие между линиями поддержки, которое можно включить в текущую главу про ошибки. Это автоматизация отработанных задач.
На картинке вы можете видеть этапы решения проблемы; все пункты после исправления у нас автоматизированы. Регулярно автоматически, без участия человека, проверяются все обращения в статусе «на третьей линии», проверяются статусы ошибок, к которым прикреплены эти заявки. В зависимости от статуса выполняются различные действия: пишутся комментарии или фиксируются решения, отправляются письма пользователям. Конечная цель этого процесса — сокращение рутинной работы на всех уровнях поддержки и оповещение пользователя о разрешении его беды.
Здесь важно договариваться между линиями и иметь однозначное понимание со всех сторон, какие обращения проверять, какие ошибки считать закрытыми, какой срок давности у неисправленных ошибок и подобное. К слову, у нас налажена автоматизация не только отработанных задач. Можно будет это обсудить отдельно.
Пункт со звездочкой
То, что я здесь называю первой линией, — далеко не первая точка соприкосновения с пользователем. Я не буду об этом писать подробно, так как не имею в этом достаточной экспертности. Но коротко затрону вопрос как пункт со звёздочкой, ибо этот факт тоже имеет влияние на взаимодействие между поддержками.
В классическом понимании первая линия поддержки — это точка входа проблемы пользователя. Обычно, это первый контакт человека на пути разрешения своей боли, но в случае нашей системы это не так. У пользователя есть несколько вариантов передачи задачи в компанию: например, он может позвонить в контактный центр — там ему ответит оператор, зафиксирует проблему таким образом, что она попадёт на упомянутую выше много раз первую линию. Ещё знаю такой путь. Продавец, использующий приложение, делает скриншот ошибки или описывает свои впечатления от работы с сервисом. Потом скидывает отзыв в личных сообщениях специалисту по обучению или иному ответственному за распространение навыков продажи через приложение. Тот, в свою очередь, просто пишет письмо внутри компании на первую линию — тут оператор контактного центра не участвует. Ещё есть другие группы, которые обрабатывают проблемы пользователей, только параллельно. Так, бэк-офис или группа мониторинга следит за уровнем накала страстей посредством подсчёта создаваемых обращений в единицу времени и влияет на быстрое повышение приоритета по задаче на уровне компании.
В общем звёздочка заключается в том, что вырисовывается довольно специфичный и разветвлённый механизм получения информации о проблеме, с участием нескольких разных групп и нескольких разных систем фиксации задач. Это имеет значение, потому что влияет на факт решения, на приёмку конечным пользователем. И здесь важно, наряду со всеми описанными и внедрёнными решениями, нашего любимого пользователя не потерять.
Важно ли инженерам второй линии, команде разработчиков, аналитиков и другим классным техническим ребятам знать, что пользователю кто-то сказал: «Друг, твоя история продаж заработала корректно, посмотри. Ты так хотел?» По двум причинам важно: человеческая и бизнесовая. 1. Мы неравнодушные люди и очень хотим, чтобы пользователь знал, что его слышат, радовался, что его проблемы решают, и испытывал только позитивные чувства от работы в системе. 2. Пользователь больше не придёт со своей проблемой, он больше не позвонит в контактный центр и не будет расходовать человеческие ресурсы. Никто из его коллег, с которыми он на досуге ходит по выставкам и барам, тоже не придёт с этой проблемой, если они точно будут знать, что её нет и она решена.
Как мы учитываем это в своей работе? Регулярно договариваемся с первой линией о маршрутах уточнения и трансляции итогового решения и при необходимости эти маршруты корректируем. Например, недавно все обращения пользователей, фиксируемые операторами, создавались в одной bpm-системе, а потом стали фиксироваться в другой. Нам важно об этом знать, чтобы вовремя корректировать свои скрипты, алгоритмы проверки, автоматизации и возможные ручные действия.
Такая получилась история :) Это далеко не все сложности, но это точно то, что вылилось в регламенты и помогло всей поддержке работать качественнее и быстрее.
