Портал №1 по управлению цифровыми
и информационными технологиями

Предсмертный или пост-смертный анализ или как избежать катастроф

“Цена неудачи – образование”

Девин Каррауэй (Devin Carraway).

“Вскрытие покажет” – знакомая многим фраза, это когда мертвые учат живых. Обычно вскрытие проводят, чтобы выяснить и проанализировать причину смерти, только оно уже никак не поможет умершему...

Каждый, кто работал с технологиями, проектами, услугами сталкивался со сбоями или неудачами. Разные масштабы, разные последствия — все имеет свою цену. А можно ли было избежать мелких проблем, значительных неудач или глобальных катастроф? У всего есть причина и следствие. Или если уж это произошло, то как мы должны на это реагировать и какие уроки вынести?

Есть два подхода, позволяющих учиться на прошлых ошибках и избегать их в будущем:

  1. Подход с угрожающим названием — Post mortem (лат. «после смерти») или посмертное вскрытие.
  2. Pre-mortem (предварительное/предсмертное вскрытие).

Post-mortem

В процессе создания, предоставления, совершенствования услуг, мы неизбежно сталкиваемся с инцидентами. Техника выходит из строя, люди делают ошибки, процессы не совершенны – все это проявляется в инцидентах. Назначение практики управления инцидентами – минимизировать негативное влияние за счет скорейшего восстановления нормальной работы услуги. Но быстро восстановить услугу – это не избавиться от инцидентов. И если не будет формализованной деятельности изучения первопричин инцидентов, то мы можем работать в режиме пожарной машины бесконечно, прилагая героические усилия в лечении симптоматики, а не болезни. Анализ возникновения инцидентов и устранение первопричины инцидентов – задача для практики управления проблемами. Но как мы исследуем возникающие инциденты? Применяем ли подход посмертного вскрытия и как мы это делаем?

Post-mortem – это задокументированный отчет об инциденте, его последствиях, предпринятых действиях для минимизации или устранения причин, а также предотвращения повторения инцидента. Все это напоминает обзор после восстановления значительного инцидента. Не так ли? Основная цель такого отчета или обзора – это изучение и документирование и понимание основных причин инцидента, принятие превентивных мер, уменьшающих последствия или вероятность возникновения инцидентов. Важно понимать, что при анализе первопричин мы не должны играть в игру поиска крайнего и виноватого в возникновении инцидента. Мы не должны уничижать себя, посыпая голову пеплом. Post-mortem обзор не является наказанием, это возможность для роста, возможность вынести урок из происшедшего для всех. 

Понимаю, что, читая эти строки, найдутся и противники идеи не искать виноватого. Когда что-то идет не так, всегда хочется найти виновного. Поиск крайнего заставляет людей “защищаться”, скрывать истинные причины неудач, чтобы избежать наказания. Это явно не способствует открытости, доверию и гарантиям конструктивности, дающим право ошибаться, экспериментировать, улучшать и развивать инновации.

Post-mortem без обвинений (Blameless PostMortems) – это часть внутренней культуры в компании, требующей постоянных усилий. Но выгоды от такой культуры очевидны:

  • Улучшение коммуникаций и поддержки
  • Повышение инициативы
  • Готовность к совершенствованию и экспериментам
  • Улучшение культуры обучения

Post-mortem — это способ выстроить процессы вашей команды и активизировать сотрудничество, поощряя культуру открытого обсуждения острых вопросов, совершенствования, поиска решений, а не поиска крайнего.

Pre-mortem

Минута профилактики стоит часов восстановления – эта истина хорошо известна. Но не все задумываются о возможных последствиях. Можно ли их предотвратить? Можно! И здесь поможет Pre-mortem.

Pre-mortem является гипотетической противоположностью Post-mortem’a. В бизнес-обстановке Pre-mortem проводится перед началом проекта, а не в конце, это поможет улучшить проект, а не заставит сокрушаться из-за последствий неудач, когда ничего уже не исправить.

Pre-mortem – это управленческая стратегия, которая позволяет представить, что проект провалился. Такая техника дает возможность оценить ситуацию еще до достижения конечного результата, т. е. проанализировать потенциальные угрозы, лучше подготовиться или даже предупредить потенциальные риски. Кроме этого, если команда заранее представляет провал, она сможет сохранить равновесие при любых обстоятельствах.

Подход Pre-mortem может быть применен при управлении рисками, управлении проектами, проактивной работе практики управления проблемами, проектирования услуг, тестирования и др.

Что потребуется для Pre-mortem анализа:

  1. Определите сколько времени вам потребуется для спокойной работы
  2. Постарайтесь пригласить все заинтересованные стороны для диалога, не ограничиваясь только лидерами мнений, тем самым избежав слепых пятен, которые в последствии смогут повлиять на конечный результат. Важный момент — обсуждение лучше проводить вживую, лицом к лицу. Чаты, мессенджеры, электронная почта будут не эффективны.
  3. Чтобы важные идеи и мнения не упустить – делайте пометки и записи (или поручите это сделать кому-то из вашей команды).
  4. Проведите мозговой штурм всех возможных причин гибели проекта или возможных неудач.
  5. Выберите 10-15 проблем, имеющих решающее значение для вашего проекта. Нет смысла учитывать проблемы вне вашей зоны контроля. Сфокусируйтесь только на тех, которые вы способны исправить.
  6. Теперь определите решения для каждой проблемы: будь то контрмера или резервное копирование.
  7. Распределите роли и ответственность среди членов команды, если не хотите получить неразбериху и замешательство в самый ответственный момент.

Учтите, нет никаких гарантий, что все будет гладко и легко. Не всегда можно предугадать или предвидеть все возможные ситуации развития событий, но имеет смысл сыграть в игру под названием “Предсмертный анализ”. Она стоит вашего душевного спокойствия в будущем.

Преимущества такого подхода:

  • Он дает голос тем, кого мы зачастую не слышим, ценит независимое мышление и создает чувствительность к проблемам
  • Он помогает преодолеть проблему «группового мышления», когда небольшая группа единомышленников не может мыслить нестандартно и заставлять себя думать, что все в порядке
  • Стресс вызывает выработку кортизола, а он в свою очередь, затуманивает наше мышление. Предсмертный анализ опережает стрессовую ситуацию и помогает мыслить рационально.
  • Он улучшает результаты проекта за счет снижения неоправданной самоуверенности и повышает уверенность в решениях проблем

Pre-mortem или Post-mortem – игры стоят свеч. Они могут стать хорошим дополнением вашей корпоративной культуры.

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

Комментариев: 7

  • Лилия Арсентьева (менеджмер процесса PrbM)

    Добрый день!

    Отличная статья! Спасибо!

    Немного из опыта.

    1. На практике хорошо себя показала деятельность, когда саппорт привлекается к проекту за несколько дней\недель (зависит от объема проекта) до старта пилота (то есть даже еще не продакшена).

    Кроме познавания особенностей новой реализации для эффективной последующей технической поддержки, команда проблем-менеджмента проводит анализ рисков (бизнес-процессы, интеграция, влияние новой реализации на текущий функционал, возможности доп.мониторинга).

    При этом мы (PrbM) участвуем на этапе принятия решения по переносу в продуктив (как в пилот, так и в полное развертывание), используя те же инструменты при анализе влияния обновления.

    2. Еще один момент, который можно отметить. часто можно видеть, что при анализе корневых причин обычно забывают, что конкретная причина является частным случаем системной недоработки в организации какого-либо процесса (практики) в компании\проекте\команде. То есть, всегда потом надо подняться еще на один уровень абстракции, и починить какую-то причину в процессах\практиках.

    Спасибо!

  • Владимир Невский

    Всё так! Like за статью! Спасибо!

  • хро

    Ну здрасьте, опять 25.

    А ведь не далее как 15.11.2009 уже постили правильную статью Ричарда Кука.

    • Статью не читал. Пришлите ссылку, с удовольствием ознакомлюсь.

      • xpo

        • Отличная статья, отличный автор, отличный перевод Романа Журавлева! Да и тема интересная. Спасибо!

          • xpo

            Ну, про pre-mortem там формально нет, но это ж обычный риск-менеджмент, который просто для симметрии назван не своим именем. Впрочем, и в нем можно предположить ситуацию из нескольких совпавших по времени событий, которые по отдельности сочли несущественными для митигации.

            А с post-mortem типичная картина описана прекрасно: если система навороченная, то простые причины отказов вычищены/заэкранированы, и дальше управление проблемами с его фокусом на root-cause в лучшем случае не приносит эффекта.


Добавить комментарий для Владимир НевскийОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT