Delivery и процессы

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

Delivery и процессы

Постмортем: как разбирать инцидент без поиска виноватых

Project Manager и Delivery Manager: в чём разница

Управление процессами: как перестать быть ассистентом для всех