Думаю ни для кого не секрет, что инциденты рано или поздно закрываются. Обычно это происходит после того, как найдено и применено решение, в некоторых случаях требуется подтверждение пользователя, в некоторых нет. Иногда это делает участник одной из ролей (например, менеджер процесса), иногда – система автоматизации, после получения подтверждения или по прошествии определенного времени после решения. При этом обычно указывается так называемый "Код закрытия", указывающий, на каком основании был закрыт инцидент. Справочник кодов закрытия – отдельная история. Обычно в нем присутствуют коды: "Решен", "Не удалось воспроизвести", "Отказ пользователя" и так далее.
На днях обсуждали с одним из клиентов возможность ситуации, при которой инцидент закрывается с кодом закрытия "Нет решения". Понятно, что такие ситуации могут возникать, например, когда пользователь обратился к нам с сообщением о некорректной работе приложения, а на самом деле для приложения это обычный стиль работы и изменить приложение мы не можем. Поэтому целесообразность такого кода закрытия не вызывает сомнений.
Однако есть вопрос, что делать с такими инцидентами. Можно оставлять их без внимания. Но есть ряд рисков. Вот основные:
- злоупотребление данным кодом закрытия со стороны ИТ-специалистов (лень искать решение, спишем все на то, что решения нет)
- недовольство со стороны пользователей
Таким образом, желательно контролировать подобные инциденты, – например, силами менеджера процесса, который сможет анализировать:
- причины их возникновения,
- возможности применения обходных решений,
- необходимость порождения проблем для применения структурных решений.
А что вы делаете с подобными инцидентами? Есть ли у вас такой код закрытия?
У нас я бы руководился следующей логикой.
Инцидент – это прерывание или деградация сервиса.
Если приложние так работает by design, то скорее всего конечную задачу пользователь выполнить может. И прерывания и деградации не было.
Классификация при этом была бы “Insufficient user training”, так как ответственный key user или Application owner не провёл разьяснительную работу что это не баг а фича.
(В данном случае вина не возлагается на пользователя)
Если фича вызывает недовольство и потенциально виден impact, то надо открыть проблему, классифицировать её как Known Error (надеюсь мы знаем, почему так разработано приложение).
После этого она страновится ответственностью Application support или Application owner, которые дальше решают как с этим жить. Дорабатывать, жить с этим.
Так же на этом уровне можно будет проводить анализ и приоритезацию, а куда ж мы хотим бросить ресурсы, когда появится время на улучшения.