От повторяющихся инцидентов к бэклогу улучшений
Иллюстративный сценарий использования, а не кейс клиента.
Повторяющиеся инциденты группируются по вероятной причине и оцениваются относительно стоимости заявок, чтобы ответственный мог расставить приоритеты исправлений в бэклоге улучшений.
Проблема
Одни и те же инциденты возвращаются каждый месяц: сбоящий интерфейс, отчёт, который не успевает выполниться при закрытии периода, конфигурация, которая расходится после каждого релиза. Каждый из них решается отдельно, никто не владеет закономерностью, и бюджет поддержки снова и снова платит за одну и ту же проблему.
Как это работает сегодня
Инциденты закрываются по отдельности, как только исчезает симптом. Ежемесячный отчёт считает заявки по категориям. Анализ первопричин проводится только для крупных инцидентов. Запросы на улучшения конкурируют с потребностями новых проектов и редко попадают в план, поэтому повторяющаяся работа остаётся в очереди поддержки.
Посмотрите сценарий
Краткий обзор
Иллюстративный рабочий процесс. С субтитрами.
Текстовая версия
- Одни и те же инциденты возвращаются каждый месяц. Каждый устраняют отдельно, за закономерность никто не отвечает, и бюджет поддержки снова платит за ту же проблему.
- Решённые инциденты группируются по вероятной причине. Для каждой группы исправление оценивается и сопоставляется с тем, во что обходится повторение в заявках и часах.
- Владелец утверждает исправления для бэклога улучшений. Изменения проходят релизные проверки, а данные об инцидентах показывают, возвращается ли проблема.
- Измеряем долю повторений и часы поддержки на повторяющиеся инциденты. Иллюстративный сценарий использования. Давайте обсудим ваш.
Подробный сценарий
Иллюстративный сценарий. Вымышленный инженер поддержки превращает ежемесячно повторяющийся инцидент в приоритизированное владельцем улучшение, которое проходит релизные проверки. 1:07
Текстовая версия
- Sam узнаёт заявку ещё до того, как открыть её. Тот же симптом вернулся, а вместе с ним и то же расследование.
- По отдельности инциденты были решены. Вместе они указывают на повторяющуюся проблему, которой нужен владелец.
- Сгруппируйте инциденты по вероятной причине, проверьте закономерность и сравните трудозатраты на исправление с работой поддержки, которую создают повторы.
- Владелец решает, включать ли исправление в бэклог улучшений и где оно стоит среди других приоритетов.
- Утверждённые изменения проходят релизные и регрессионные проверки. Предложенное улучшение не является разрешением менять продуктивную среду.
- После релиза отслеживайте, возвращается ли проблема и сколько усилий поддержки она отнимает. Какую повторяющуюся проблему вашей команде стоит изучить следующей?
- [Финальный кадр] Какую повторяющуюся проблему вашей команде стоит изучить следующей? Обсудить ваши повторяющиеся инциденты. qxorbit.ai/ru/contact
- Иллюстративный сценарий использования, а не кейс клиента.
Предлагаемый рабочий процесс
- Сгруппировать решённые инциденты по вероятной первопричине, используя таксономию инцидентов, примечания к решению и затронутые компоненты
- Для каждой повторяющейся группы оценить исправление: необходимое изменение, затрагиваемые среды, усилия на релиз и регрессию
- Сопоставить исправление с повторяющейся стоимостью: заявки в месяц, часы инженеров, влияние на бизнес по описанию владельцев
- Представить ранжированных кандидатов владельцу приложения, который решает, что попадает в бэклог улучшений
- Поставить утверждённые исправления через процесс релизов с регрессионными проверками и отслеживать повторяемость после релиза
Где контроль остаётся за человеком
- Группировка и оценка — это предложения; владелец решает, что исправляется и в каком порядке
- Плановые улучшения следуют согласованному процессу релизов и регрессии; срочные изменения требуют согласованной экстренной авторизации
- Данные о повторяемости проверяются за согласованный период наблюдения, прежде чем решать, закрывать ли пункт улучшения
Привязка к платформам указывает среды, в которых имеет смысл оценить эту идею. Фактическая реализация зависит от конфигурации, лицензий, API, данных и прав доступа. Преимущества описаны качественно; числовые утверждения требуют задокументированной базовой линии.