По мне, это один из самых криповых терминов в IT-менеджменте 
Однако менее полезным его значение от этого не становится
И термин этот…
ПОСТМОРТЕМ 
Само слово образовано от латинских post — «после» и mortem — «смерть». То есть дословно — «после смерти».
Исторически термин обозначал процедуру вскрытия тела для точного установления причины смерти — аутопсию
Со временем в IT и бизнесе термин трансформировался в документированный технический анализ инцидента или завершённого проекта.
Постмортем обычно запускают после стабилизации ситуации, когда сам инцидент уже закрыт
Процесс проработки постмортема проходит по следующим этапам:
#1 Сбор первичных данных
Логи, метрики мониторинга, записи в чатах, история изменений кода и другие цифровые следы, связанные с инцидентом.
#2 Формирование хронологии
Детальная последовательность событий, зачастую поминутная: момент возникновения проблемы, её обнаружение, действия по диагностике и исправлению, ключевые коммуникации.
Это фактологическая база дальнейшего анализа.
#3 Аналитическая сессия
Встреча ключевых участников для обсуждения собранных данных. Здесь применяются техники поиска корневых причин
Например метод «Пять почему» — последовательные вопросы «Почему это произошло?», пока команда не доберётся до фундаментальной причины сбоя.
#4 Подготовка отчёта
Результаты анализа фиксируются в стандартизированном формате.
#5 Определение корректирующих действий — action items
Формируется список конкретных задач, которые должны устранить выявленные причины или снизить вероятность повторения инцидента.
У каждой задачи должны быть ответственный и срок.
#6 Публикация и распространение
Отчёт размещается в базе знаний компании, чтобы с выводами могли ознакомиться все заинтересованные стороны.
ВАЖНО 
Безобвинительность — главный принцип постмортема! 
И, к сожалению, именно он нередко нарушается
На постмортеме не должно быть обвинений конкретных людей в некомпетентности или халатности.
Базовая установка выглядит так:
Сотрудники действовали максимально разумно, исходя из информации, инструментов и условий, которые были у них в тот момент.
Поэтому фокус смещается с вопроса:
«Кто виноват?»на вопросы:
— Почему система позволила совершить эту ошибку?
— Каких инструментов, проверок или ограничителей не хватило, чтобы её предотвратить?
— Где в процессе был пробел, который привёл к сбою?Человеческая ошибка в таком подходе рассматривается не как конечная причина, а как симптом более глубокой проблемы — в системе, документации, обучении или процессе
