Комментарии 1
Артем, раз уж Вы ссылаетесь на ITIL не путайте пожалуйста понятия инцидент и проблема.
Инцидент - это незапланированное прерывание или снижение качества услуги (сервиса), а проблема - причина возникновения одного или нескольких инцидентов. Поэтому если по SLA у нас вход в систему 5 секунд, а окно авторизации висит уже 7 - это инцидент. Также как и сбой у одного только пользователя.
В продуктовом подходе, в отличие от сервисного, оперируют понятием баг. Вот тут два понятия заменяются одним.
Важно понимать также что разбор полетов (post mortem) ближе к практике управления проблемами, хотя и в управлении инцидентами применяется, но для критических инцидентов (major incidents), поскольку уводит от цели практики - скорейшее восстановление, а не предотвращение повторений (для управления проблемами).
Инцидент может быть закрыт как обходным решением (workaround), так и постоянным. Вот тут для сравнения с продуктовым подходом вместо будет упомянуть про технический долг, как совокупность этих обходных решений или компромиссов, которые важно фиксировать на досках в виде отдельных элементов работы. Т.е. при решении бага с помощью обходного решения здорово создавать связанную сущность, как тех. долг. В то время как при постоянном таких телодвижений не потребуется.
Если будет интерес продолжить, то мы друг в друга в контактах LinkedIn 😀

Инцидент-менеджмент с нуля: практический гайд для растущих команд