Привет, Хабр! Меня зовут Анна, я начальник управления поддержки проектов и клиентских сервисов в X5 Tech. Последние 16 лет я работаю в области сопровождения, и для меня одним из самых загадочных этапов в поддержке всегда был процесс приёма нового функционала. Ты как будто берёшь кота в мешке: вы ещё с ним не знакомы, он не приучен к лотку, ты не знаешь его возраст, цвет и как сильно он кусается.

У нас получилось кардинально изменить один из подходов в разработке, а именно – процесс передачи решений в централизованную поддержку. Для этого мы провели с коллегами 50+ интервью, на расшифровку которых у нас ушло 120 часов, выпили 20+ литров кофе, выявили около 40 проблем, написали 80 выводов и выдвинули 30 гипотез возможных решений. Что именно мы сделали в итоге для бесшовной передачи сервиса в централизованную поддержку под ключ – рассказываю в статье.

Небольшое лирическое отступление

Почему я пишу, что процесс передачи на поддержку – это один из подходов в разработке? Всё просто: этап реализации идеи не должен исключать участия эксперта сопровождения. В этом наша инновация. Невозможно предоставить высокий уровень сервиса в короткие сроки, если поддержка подключена в самом конце, когда сложно уже что-то поменять.

Мне нравится сравнивать передачу функционала в поддержку с вводом дома в эксплуатацию. Построить многоэтажку и передать её в использование жильцам не даёт гарантии высокого качества жизни будущим новосёлам. Дальнейшее содержание жилья может быть весьма дорогостоящим из-за низкого качества труб, неровностей стен и высокой слышимости. Метрики качества успешной постройки дома – это и есть техническое задание перед началом стройки, а управляющая компания – это централизованная поддержка.

Наши "коты в мешке"

Продолжая аналогию, наша команда решила познакомиться с тем самым «котом в мешке». Мы составили СJM и на основе аналитики выявили 4 ключевые проблематики процесса передачи новых решений на поддержку.

«Кот № 1». Затяжные сроки передачи.

Инициатива всегда ограничена в ресурсах и сроках. Зачастую руководитель проекта вспоминает об этапе передачи решения в централизованную поддержку после опытно-промышленной эксплуатации. К этому моменту большая часть требуемых документов не готова, решение не стабилизировано, поддержка боится брать в сопровождение «кота в мешке».

Задача – сократить время передачи до одного месяца.
Цель – вовремя сдать проект.

«Кот № 2». Увеличение стоимости этапа передачи на поддержку.

В самом страшном сне лидер инициативы хочет повторно защитить бюджет на продление срока проекта. Поддержка не готова принять решение к себе на сопровождение, дефекты лежат в бэклоге, а сердце неровно бьётся от ТРИДЦАТЬ третьего кофе. Это приводит к повышению стоимости решения, а значит растут потери для компании.

К моменту передачи решение зачастую сырое, рутинные задачи копятся, в подручных средствах поддержки нет настроенных роботов и чат-ботов, которые бы обрабатывали заявки без участия специалиста. С внедрением эксперта поддержки эта задача решается на этапе пилотирования: сценарии роботов внедрены и обкатаны, число обращений сокращено до оптимального состояния, problem management помогает набрать фактуру по дефектам, время поддержки тратится только на сложные обращения с новыми кейсами.

Задача – сократить стоимость этапа передачи.
Цель – стабилизация решения до этапа передачи сервиса в промышленную эксплуатацию.

«Кот № 3». Отсутствие прозрачности процесса.

На интервью участники опроса чаще всего указывали на неоднозначность статуса передачи сервиса в поддержку. Их самое востребованное желание – понимать, на каком этапе находится продукт для перевода в эксплуатацию и как измерить надёжность и стабильность решения? Эти и другие проблемы решаются внедрением метрик качества.

Задача – внедрить метрики качества.
Цель – передавать статус готовности решения к переводу в эксплуатацию.

«Кот № 4». Низкое качество передаваемого решения.

Качественная поддержка – это решение пользовательских заявок в срок, предотвращение инцидентов до их появления и знание работоспособности системы в любой момент времени. 

Мониторинги – глаза поддержки. Роботы – её руки. Предвосхищение проблем – суперспособность. Нам нужен новый подход для разработки решения, который включает в себя внедрение инструментов автоматизации для сопровождения.

Задача – внедрить архитектурные принципы (основные правила, согласно которым реализуется новое решение).
Цель – увеличить инструментарий поддержки для более эффективного сопровождения.

Все эти «коты в мешке» казались нам тогда неподъёмными, а задачи космическими.  Менять в крупной компании процессы – перспектива не из лёгких. Но наша команда была непробиваемой.  

Пути решения

Итак, к каким решениям мы пришли и какие изменения мы внедрили в прошлом году.

1. Метрики качества

Мы разработали и внедрили 6 обязательных метрик качества, без выполнения которых сдать решение в поддержку невозможно. Эффективность – это когда просто, поэтому наши метрики – основа основ качественного сервиса.

• SLA
  Простыми словами, это процент пользовательских обращений, решённых в срок, согласованный с бизнесом. Показатель даёт представление ещё до выхода в промышленную эксплуатацию о стабильности решения и наличия инструментов автоматизации. Если показатель ниже целевого значения – значит важно минимизировать аварии и дефекты и внедрить «помогаторов» для поддержки. К «помогаторам» мы относим роботов, которые самостоятельно обрабатывают заявки, а также различные встроенные чат-боты, которые дают пользователю найти решения без привлечения экспертов.

• Доступность
  Отражает общее состояние сервиса (доступен/недоступен), выраженное как отношение времени реальной работоспособности сервиса ко времени требуемой работоспособности согласно SLA за отчётный период.
  Дополнительно согласовываются пороги аварийности с бизнесом, после превышения которых регистрируется авария. Эксперт поддержки собирает данные по всем авариям инициативы и ведёт их в единый реестр.

• Наполненность артефактов чек-листа
  Мы актуализировали чек-лист документов, которые необходимо собрать в процессе реализации инициативы для полной её комплектации.

• Наличие дефектов
  Для будущей эксплуатации важно отсутствие дефектов уровня Блокирующий (Blocker), Важный (Critical), которые полностью или частично влияют на работоспособность основного функционала. При наличии хотя бы одного такого дефекта передача в поддержку заблокирована до его устранения.

• Архитектурное соответствие
  Метрика показывает соответствие реализованного решения последней согласованной архитектуре. В случае несоответствия важно привести решение к согласованному формату или довести до ума текущее архитектурное решение с solution архитектором по проекту/продукту.

• Сверка наличия мониторингов
  Проверяем наличие инфраструктурных мониторингов по внедряемой системе в зависимости от типа решения и бизнес-мониторингов по критичным сервисам. Безусловно, наличие мониторингов укрепит качество реагирования на сбои и предотвратит часть аварийных событий.

По достижению каждой метрики качества проекту/продукту присваивается процент, пропорциональный весу показателя. Максимально возможный процент – 100%.  Каждая метрика весит 16,67% и может быть как блокирующей (выполнена/не выполнена), так и составной (0%-16,67%). 

Для прозрачности мы создали отчёт по этим метрикам качества в Telegram-канале и в “Карте здоровья” (так мы называем отчёт по статистическим данным в режиме реального времени). Таким образом, любой участник инициативы всегда может посмотреть статус готовности решения и его динамику как с телефона в чат-боте в Telegram, так и с рабочего компьютера.

Давайте поясню расчёт на примере инициативы «Кот в мешке»:

• Solution архитектор дал положительное заключение по архитектурному соответствию (+16,67%).

• SLA выше 95% (+0%).

• Доступность сервиса ниже 99,95% (0%).

• Нет критичных и блокирующих дефектов (+16,67%).

• Реализовано 25 мониторингов из 45 (+9,17%).

• Предоставлено 20 обязательных артефактов чек-листа из 30 (+11,11%).

ИТОГО: готовность передачи сервиса в эксплуатацию составляет 53,62%. «Кот в мешке» не готов к новому хозяину, так как пороговое значение должно превышать 90% и сохранять позиции не менее трёх недель.

Также мы разработали набор опциональных метрик, которые не влияют на процесс передачи сервиса в промышленную эксплуатацию, но дают представление о новом сервисе. Эти метрики мы передаём команде инициативы индивидуально вместе с отчётностью раз в неделю.

Например, команда продукта по мобильному приложению “Чижика” запросила внести показатель за неделю «Средний чек покупки», а проект по социальной программе – «Количество транзакций».

2. Эксперт поддержки.

Мы ввели новую роль главного специалиста по «котам в мешке» – эксперт поддержки. Это новый центр компетенций, который появляется в проектной/продуктовой команде с момента начала разработки и живёт там до момента перевода сервиса в промышленную эксплуатацию.

Эксперт поддержки – это технический специалист и лидер этапа передачи в одном флаконе. Его должность звучит у нас в компании как «консультант по стабилизации ИТ-решений».

Коротко о задачах эксперта поддержки:

• обработка заявок и внедрение problem management с первого обращения;

• стабилизация решения совместно с командой инициативы: отработка сбойных событий, написание регламента по работе с авариями;

• приоритизация бэклог поддержки;

• постановка ТЗ на бизнес-мониторинги;

• автоматизация рутинных задач: внедрение инструментов автоматизации (оркестратор, чат-бот, сценарии GPT);

• написание пользовательских инструкций и будущее обучение централизованной поддержки;

• достижение метрик качества.

Новый центр компетенций нацелен на основную задачу: бесшовно передать зрелое и понятное решение в срок в поддержку.

Немного цифр, наглядно показывающих эффект от работы эксперта поддержки (на конец мая 2024 года):

• Запрошено 75 оценок на вывод эксперта поддержки в новые инициативы.

• Выведен 21 эксперт поддержки на 27 новых инициатив.

• 4 инициативы переданы в промышленную эксплуатацию благодаря работе эксперта поддержки. Срок передачи сокращён до трёх месяцев относительно аналогичных стримов в 6 и более месяцев.

• За 3 месяца передана в промышленную эксплуатацию инициатива по одному портальному решению, которая до этого 4,5 года находилась на стадии "пилотирования”.

• Плановое количество инициатив за 2024 год с запросом на эксперта поддержки – 150.

3. Пилотная команда.

Для внедрения новых изменений мы выбрали 7 пилотных «котов в мешке» (4 проекта и 3 продукта) на разных этапах жизненного цикла и посадили в них по одному эксперту поддержки. На протяжении трёх месяцев он трудился над своими задачами. За 4-й квартал 2023 года мы сумели передать 3 решения в промышленную эксплуатацию с учётом того, что даже самые оптимистичные сроки были установлены на первое полугодие 2024 года.

Конечно, нам было важно получить обратную связь о пользе эксперта поддержки. Лидеры пилотных инициатив единогласно пожали нам руку, назвали эксперта «палочкой выручалочкой», вовлечённой в процесс. Хочу отметить, что наш «эксперт по котам» стоит на рынке не так дорого, при этом высвобождает одну FTE (эквивалент полной занятости, мера включённости сотрудника в проект) по разным функциям внутри команды инициативы: руководитель проекта, Devops, системный и бизнес-аналитики, технический писатель.

4. Новые архитектурные принципы компании.

Как я писала выше, мы разработали и утвердили два новых архитектурных стандарта:

- Архитектурный принцип мониторинга
Этот документ нацелен на обязательное покрытие мониторингами инфраструктурных компонент и бизнес-мониторингов информационной системы. Для удобства реализации этих мониторингов были проработаны шаблоны типовых решений на основе USE и RED методологий: ОС, web порталы, мобильные приложения, K8S и Docker, DB и микросервисной архитектуры. Таким образом, на выходе поддержка имела «глаза» для контроля работоспособности сервиса и системы.

- Архитектурный принцип автоматизации
Основная цель документа – для портальных решений с более 500 обращениями в день внедрить на этапе производства средства автоматизации: чат-бот, опрос Voice, роботизация, сценарии GPT и тому подобное для сокращения типовых запросов. На выходе поддержку не заваливает волной обращений, при этом каждый запрос пользователя своевременно отработан.

Подытожим

Теперь для передачи сервиса на сопровождение нужно довести качество внедряемого решения до уровня senior по обязательным метрикам, обеспечив поддержку необходимыми инструментами измерения работоспособности информационной системы и сократив количество однотипных заявок до перевода сервиса в промышленную эксплуатацию.

Сейчас решение у нас принимается в поддержку при готовности продукта более 90% на протяжении трёх недель. Показатель важно удерживать и следить за его стабильностью, так как неожиданный дефект может принести +100 500 обращений, и, как следствие, привести к снижению SLA и доступности системы.