Бесконечные «Как?» (или об опасности метода «Пяти почему»)

14 ноября 2014

Автор: John Allspaw

I am currently a co-founder of Adaptive Capacity Labs, LLC. Previously, I was Chief Technology Officer at Etsy

(эта статья также опубликована в блоге O'Reilly Radar. Огромная благодарность Дэниелу Шауенбергу, Моргану Эвансу и Стивену Шорроку за отзывы)

Прежде чем начать, хочу уточнить: эта статья — критика метода «Пяти почему», а не людей, которые его используют.

Моя критика не претендует на оригинальность — большая часть материала вдохновлена работами Тодда Конклина, Сидни Деккера и Нэнси Левесон.

Практика ретроспективного анализа инцидентов (или «постмортемов», как их обычно называют) уже прочно укоренилась в области веб-разработки и эксплуатации. Мне бы хотелось верить, что концепции, заимствованные нами из Нового взгляда на «человеческие ошибки», становятся всё более известными, и люди начинают исследовать свои собственные истории через эту призму.

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

Метод «Пяти почему» — как раз то, от чего, на мой взгляд, стоит отказаться.

В этой статье я объясню, почему считаю его бесполезным, и покажу, как его использование может скорее навредить организации, чем помочь. Вот моя структура: сначала я расскажу о недостатках этого подхода, затем предложу альтернативу, а потом попрошу вас просто попробовать её применить.

Вот суть моих утверждений в двух словах:

«Почему?» — это неправильный вопрос.

Если ваша цель — научиться чему-то (а именно такой должна быть цель любой ретроспективы или расследования), вам нужны множественные и разнообразные точки зрения. Вы получаете их, когда просите людей рассказать их собственные истории. По сути, вы спрашиваете «как?»

Вопрос «почему?» слишком легко приводит к ответу на вопрос «кто?» (который почти всегда неуместен) или «уводит к «загадочным» мотивам и стимулам, которые люди приносят на рабочее место».

Вопрос «как?» позволяет вам описать (хотя бы частично) условия, которые позволили событию произойти, и получить ценные операционные данные.

Серия вопросов «почему?» делает слишком много предположений о выборе спрашивающего и о каждом полученном ответе. В лучшем случае, она загоняет вас в причинно-следственную цепочку, а именно так мир не работает. Это конструкция, которая игнорирует огромный пласт сложности события, а ведь именно эту сложность мы и хотим исследовать, если надеемся чему-то научиться.

Но это же отличный способ начать!

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

1. «Анализ первопричин»* — это не то, что вам вообще нужно делать, и
2. Это «хороший первый шаг» лишь потому, что его легко объяснить и понять, а значит, легко внедрить. Проблема в том, что концепции, на которых держится метод «Пяти почему», не только ошибочны, но и могут быть опасны для организации.

Если цель — обучение (а так и должно быть), тогда метод ретроспективного обучения должен быть уверен в том, что он извлекает данные, которые можно превратить в практическую информацию. Проблема «Пяти почему» в том, что у него туннельное зрение: он видит только линейное и упрощённое объяснение того, как выполняется работа и происходят события. Такое сужение может быть крайне проблематичным.

В лучшем случае оно может привести организацию к ложному ощущению улучшения (или предотвращения будущих инцидентов), хотя на самом деле ничего не меняется.

В худшем случае оно может закрепить ошибочное мировоззрение чрезмерного упрощения причинности и создать структуру, где люди не чувствуют себя в безопасности, рассказывая свои истории, потому что либо им не задали правильный вопрос «почему?», либо ответ на заданный вопрос указал на «человеческую ошибку» или индивидуальные качества как на причину.

Давайте рассмотрим пример. На своих тренингах на конференции Velocity в Нью-Йорке я использовал часто повторяемое чучело для иллюстрации:

Этот же пример «Пяти почему» можно найти в книге Web Operations.

Эта причинно-следственная цепочка заканчивается на индивидуальных качествах человека, а не на описании множественных условий, которые позволяют произойти подобному событию. Давайте разберём некоторые из ответов…

«Почему сервер упал? Потому что малоизвестная подсистема была использована неправильно»

Этот ответ зависит от результата. Мы знаем, что подсистема была использована «неправильно», только потому, что связали это с последующим сбоем. Другими словами, мы как «следователи» имеем преимущество ретроспективы. Мы легко можем судить об использовании сервера, потому что знаем результат. Если бы мы вернулись назад во времени и спросили инженера(ов), использовавших его: «Вы уверены, что делаете это правильно?», они бы ответили: да, уверены. Мы хотим знать, какие различные факторы привели их к такому мнению, а это просто не уместится в ответ на вопрос «почему?»

Этот ответ также ограничивает следующий вопрос, который мы зададим. В диалоге нет места для обсуждения таких вещей, как возможность использовать сервер неправильно и при этом не получить сбой, или что вообще означает «неправильно» в этом контексте. Можно ли использовать сервер только двумя способами — «правильным» или «неправильным»? И определяет ли успех (или отсутствие сбоя), каким из этих способов он был использован? Мы не дойдём до этих критически важных вопросов.

«Почему он был использован неправильно? Инженер, который его использовал, не знал, как его правильно использовать»

Этот ответ, по сути, тавтология и содержит ретроспективное суждение. Он не говорит нам ничего о том, как именно инженер использовал систему, что предоставило бы богатый источник операционных данных, особенно для инженеров, которым, возможно, придётся работать с этой системой в будущем. Действительно ли речь только об этом конкретном инженере? Или, возможно, речь об окружении (инструментах, дашбордах, элементах управления, тестах и т.д.), в котором работает инженер? Если речь о последнем, как это отразить в «Пяти почему»?

Что же мы находим в этой выстроенной нами цепочке? Мы находим:

• инженера с недостаточными (или хотя бы неполными) знаниями
• недостаточную подготовку инженеров
• менеджера, который всё испортил, не будучи достаточно тщательным в обучении новых инженеров (более того: мы можем вынести ретроспективное суждение о её убеждениях)

Если считать это примером метода «Пяти почему», то как инженер или менеджер по разработке, я, возможно, не буду ждать этого с нетерпением, поскольку он фокусируется на наших индивидуальных качествах и мало что говорит нам о событии, кроме банальности о том, что обучение (и убеждение людей в важности обучения) важно.

Это в основном ответы на вопрос «кто?», а не описания того, какие условия существовали. Другими словами, задавая «почему?» таким образом, мы используем сбои для объяснения сбоев, что бесполезно.

Если мы спросим: «Почему конкретный сервер упал?», мы можем получить множество ответов, но один из них будет использован как основной способ перехода к следующему шагу «почему?». Мы также потеряем огромное количество важных деталей, потому что помните: у вас есть только один вопрос перед следующим шагом.

Если вместо этого мы спросим инженеров, как они подошли к реализации нового кода (или «подсистемы»), мы можем услышать много чего, например:

• какие подходы они использовали при написании кода
• каким образом они приобретали уверенность (тесты, ревью кода и т.д.), что код будет работать так, как они ожидали, до его развёртывания
• какую историю успехов или неудач они имели с похожими фрагментами кода
• какие компромиссы они делали или управляли при проектировании новой функции
• как они оценивали масштаб проекта
• насколько (и каким образом) они испытывали временное давление
• и список можно продолжать, если вы готовы спрашивать больше, а они готовы рассказывать больше

Вместо того чтобы осуждать людей за то, что они не сделали то, что должны были, новый взгляд предлагает инструменты для объяснения того, почему люди сделали то, что сделали. Человеческая ошибка становится отправной точкой, а не выводом. (Деккер, 2009)

Когда мы спрашиваем «как?», мы просим рассказать историю. Нарратив.

В этих историях мы начинаем понимать, как люди работают. Следуя подходу «инженер был некомпетентен, нужно обучение, менеджеру нужно сказать обучать», мы можем не иметь места для вопросов, направленных на рекомендации для будущего, таких как:

• Что мы могли бы сделать, чтобы было очень сложно случайно выкатить этот код в продакшн?
• Какие источники уверенности для инженеров мы могли бы усилить?

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

Повторюсь, эта мысль не моя. Локальная рациональность (или, как назвал её Герберт Саймон, «ограниченная рациональность») прочно опирается на несколько десятилетий когнитивной науки.

Эти истории, которые мы ищем, содержат детали, за которые можно зацепиться и о которых можно спросить подробнее, что критически важно для фасилитатора постмортем-дебрифинга, потому что люди не всегда знают, какие детали важны. Как вы увидите далее в этой статье, реальность работает не как цифровой видеорекордер; нельзя ставить на паузу, перематывать назад и вперёд по желанию вдоль единственной и объективной оси, собирая все кусочки по пути, играя в CSI. Воспоминания несовершенны, а перспективы ограничены, поэтому необходим другой подход.

Не только «как»

Чтобы получить эти нарративы, вам нужно копать в поисках вторых историй. Вопрос «почему?» даст вам ответ в форме первых историй. Они не только недостаточны, но и могут быть очень вредны для организации, в зависимости от контекста. Напомню…

Из книги Behind Human Error вот разница между «первыми» и «вторыми» историями о человеческих ошибках:

Теперь перечитайте приведённый выше пример «Пяти почему». Вопросы, которые мы задаём, формируют ответы, которые мы получим в форме первых историй. Когда мы задаём больше и лучше вопросов (таких как «как?»), у нас появляется шанс добраться до вторых историй.

Вы можете спросить: как я перешёл от «Пяти почему» к теме «человеческих ошибок»? Потому что как только «человеческая ошибка» становится кандидатом на роль причины (а она станет, потому что это простой и потенциально удовлетворительный ответ на «почему?»), вы непременно её используете.

В начале моего тренинга в Нью-Йорке я задал аудитории этот вопрос:

В начале выступления большое количество людей ответили «да», это правильно. Стивен Шоррок (который выступает на следующей неделе на Velocity в Барселоне именно на эту тему) написал отличную статью об этом способе мышления: Если бы не люди. К концу моего выступления я смог убедить их, что это также неправильный фокус для постмортем-описания.

Эта идея слишком часто сопровождает «Пять почему», и я хотел бы пролить свет на два момента:

Миф о дихотомии «человеческий или технический сбой»

Это дуалистическое мышление, и мне нечего добавить к тому, что сказал об этом Деккер (Деккер, 2006):

«Авария была вызвана механическим сбоем или человеческой ошибкой? Это стандартный вопрос сразу после инцидента. Действительно, кажется таким простым, невинным вопросом. Для многих это нормальный вопрос: если у вас произошла авария, имеет смысл выяснить, что сломалось. Однако этот вопрос воплощает в себе определённое понимание того, как происходят аварии, и рискует ограничить наш причинный анализ этим пониманием. Он загоняет нас в фиксированный интерпретационный репертуар. Вырваться из этого репертуара может быть сложно. Он определяет вопросы, которые мы задаём, предоставляет направления, которые мы преследуем, и улики, которые мы исследуем, и определяет выводы, которые мы в конечном итоге сделаем».

Миф: во время ретроспективного расследования что-то ждёт, чтобы быть «найденным»

Скажу прямо: нет ничего, что ждёт, чтобы быть найденным, или «раскрытым». Эти «причины», которые мы думаем, что «находим»? Мы их конструируем, а не находим. Мы конструируем их, потому что мы сами выбираем, где (и когда) начать задавать вопросы и где/когда прекратить их задавать. Мы «нашли» первопричину, когда перестали искать. И во многих случаях мы просто лениво списываем это на «человеческую ошибку».

Как сказал Эрик Холлнагель (Холлнагель, 2009, стр. 85):

«В расследовании аварий, как и в большинстве других человеческих начинаний, мы становимся жертвами принципа «Что-ищешь-то-и-находишь» (WYLFIWYF). Это простое признание того факта, что предположения о том, что мы собираемся увидеть (Что-ищешь), в значительной степени определят то, что мы действительно найдём (Что-находишь)».

Более того: «Что-ищешь-то-и-чинишь»

Мы думаем, что существует что-то вроде причины инцидента (иногда мы называем её первопричиной или основной причиной), и если мы достаточно усердно будем искать в обломках, мы её найдём. Реальность в том, что не существует такой вещи, как причина, или основная причина, или первопричина. Причина — это то, что мы конструируем, а не находим. И то, как мы конструируем причины, зависит от модели аварии, в которую мы верим. (Деккер, 2006)

Нэнси Левесон комментирует это в своей превосходной книге Engineering a Safer World (стр. 20):

Субъективность в выборе событий

Выбор событий для включения в цепочку событий зависит от правила остановки, используемого для определения того, как далеко назад идёт последовательность объясняющих событий. Хотя первое событие в цепочке часто называется «инициирующим событием» или «первопричиной», выбор инициирующего события произволен, и предыдущие события всегда могут быть добавлены.

Иногда инициирующее событие выбирается (обратная цепочка останавливается), потому что оно представляет тип события, который знаком и, таким образом, приемлем в качестве объяснения аварии, или это отклонение от стандарта [166]. В других случаях инициирующее событие или первопричина выбирается потому, что это первое событие в обратной цепочке, для которого считается, что можно что-то сделать для исправления.

Обратная цепочка также может остановиться, потому что причинный путь исчезает из-за отсутствия информации. Расмуссен предполагает, что практическое объяснение того, почему действия операторов, активно вовлечённых в динамический поток событий, так часто идентифицируются как причина аварии, — это сложность продолжения обратного отслеживания «через» человека [166].

Последняя причина, по которой может быть выбрана «первопричина», заключается в том, что она политически приемлема в качестве идентифицированной причины. Другие события или объяснения могут быть исключены или не изучены глубоко, потому что они поднимают вопросы, неудобные для организации или её подрядчиков, или политически неприемлемы.

Обучение — это цель. Любое предотвращение зависит от этого обучения

Итак, если не «Пять почему», то что же делать? Какой метод использовать?

Я бы хотел предложить альтернативу, которая заключается в том, чтобы сначала принять идею о том, что вам нужно активно искать и защищать истории от предвзятости (и суждений), когда вы задаёте людям вопросы в стиле «как?». Затем вы можете:

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

В качестве отправной точки для этих исследовательских вопросов мы можем обратиться к Гэри Кляйну и Сидни Деккеру за типами вопросов, которые вы можете задать вместо «почему?»…

Подсказки для фасилитации дебрифинга

(из Полевого руководства по пониманию человеческих ошибок, Сидни Деккер)

В каждой критической точке в последовательности событий (если вы хотите структурировать эту часть истории аварии таким образом) вы хотите узнать:

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

Вот некоторые вопросы, которые Гэри Кляйн и его исследователи обычно задают, чтобы выяснить, как ситуация выглядела для людей изнутри в каждой из критических точек:

Для тренингов, которые я проводил на Velocity, я сделал однастраничник с этими вопросами: http://bit.ly/DebriefingPrompts

Попробуйте

Я попытался изложить свои доводы о том, почему использование подхода «Пяти почему» неоптимально, и предложил альтернативу. Я сделаю ещё лучше и дам вам ссылки на тренинги, которые я проводил в Нью-Йорке в октябре и которые, я думаю, глубже раскрывают эти концепции. Это четыре части по 45 минут каждая.

Часть I — Введение и научная основа для ловушек ретроспективного анализа и обучения

Часть II — Язык дебрифингов, причинность, кейс-стади, команды, справляющиеся со сложностью

Часть III — Динамическое управление ошибками, подсказки для дебрифинга, сбор и контекстуализация данных, конструирование причин

Часть IV — Тейлоризм, обычная работа, «первопричина» программных ошибок в автомобилях, вопросы и ответы

Моя просьба в том, чтобы в следующий раз, когда вы собираетесь применить «Пять почему», вы вместо этого спросили «как?» или вариации вопросов, которые я привёл выше. Если вы считаете, что получаете больше операционных данных от «Пяти почему» и довольны этим — отлично.

Если вас больше интересует эта альтернатива и основы, на которых она базируется, есть ряд источников, к которым вы можете обратиться. Вы не ошибётесь, если начнёте с Полевого руководства по пониманию человеческих ошибок Сидни Деккера.

Объяснение

Для тех читателей, которые считают, что я слишком и необоснованно резок в отношении подхода «Пяти почему», я думаю, стоит объяснить, почему я так сильно к этому отношусь.

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

Мир программного обеспечения и мир вне его столкнулись и будут продолжать сталкиваться. Всё больше и больше оборудования и продуктов, критичных для жизни, полагаются на программное обеспечение и даже на интернет.

Эти области имели разный успех в ретроспективном понимании неожиданных событий, мягко говоря. Подходы к расследованию, которые твёрдо основаны на чрезмерном упрощении причинности и «теории плохого яблока» о недостаточных индивидуальных качествах (таких как «Пять почему»), показали, что они не только бесполезны, но и объективно затрудняют обучение, а не облегчают его. В результате люди, которые совершили ошибки или были вовлечены в аварии, были уволены, отстранены от профессии и даже заключены в тюрьму за некоторые из тех же вещей, которые вы могли бы найти в «Пяти почему».

Иногда я нервничаю, думая о том, что эти упрощения всё ещё будут существовать, когда моя дочь и сын станут старше. Если бы они совершили ошибку, обвинили бы их как причину? Я твёрдо верю, что мы можем оставить эти старые методы позади и сделать намного лучше.

Моя цель не в том, чтобы демонизировать подход, а в том, чтобы прямо заявить: если мир должен стать безопаснее, мы должны отказаться от этой простоты; он станет лучше, только если мы примем сложность, а не будем её игнорировать.

Эпилог: Расширенная версия для тех, кто готов к теории сложности

Подход «Пяти почему» следует ньютоново-декартовому мировоззрению. Это мировоззрение соблазнительно удовлетворительное и убедительно простое. Но оно также ложно в мире, в котором мы живём.

Что я имею в виду?

Есть пять причин, по которым «Пять почему» прочно укоренено в ньютоново-декартовом мировоззрении, от которого мы должны отказаться, когда речь идёт об обучении на прошлых событиях. Это краткая версия статьи «Сложность сбоя: последствия теории сложности для расследований безопасности» —

Во-первых, он редукционистский. Нарратив, построенный «Пятью почему», основан на идее, что если вы можете построить причинную цепочку, тогда у вас будет что-то, с чем можно работать. Другими словами: чтобы понять систему, вы разбираете её на составные части. Узнайте, как взаимодействуют части, и вы узнаете систему.

Во-вторых, он предполагает то, что Деккер назвал «симметрией причины и следствия» (Деккер, сложность сбоя):

«В ньютоновом видении мира всё, что происходит, имеет определённую, идентифицируемую причину и определённое следствие. Есть симметрия между причиной и следствием (они равны, но противоположны). Определение «причины» или «причин», конечно, рассматривается как наиболее важная функция расследования аварий, но предполагает, что физические следствия могут быть прослежены обратно к физическим причинам (или цепочке причин-следствий) (Левесон, 2002). Предположение, что следствия не могут происходить без конкретных причин, также влияет на юридические рассуждения после аварий. Например, чтобы поднять вопрос о халатности в аварии, вред должен быть вызван халатным действием (GAIN, 2004). Предположения о симметрии причины и следствия можно увидеть в том, что известно как предвзятость результата (Фишхофф, 1975). Чем хуже последствия, тем более любые предшествующие действия рассматриваются как заслуживающие порицания (Хью и Деккер, 2009)».

Джон Кэрролл (Кэрролл, 1995) назвал это «соблазном первопричины»:

Идентификация первопричины означает, что анализ нашёл источник события, и поэтому все могут сосредоточиться на решении проблемы. Это удовлетворяет потребность людей избегать неоднозначных ситуаций, в которых не хватает существенной информации для принятия решения (Frisch & Baron, 1988) или испытывается заметный пробел в знаниях (Loewenstein, 1993). Соблазнительность единичных первопричин также может подпитывать и поддерживаться общей тенденцией быть слишком уверенными в том, сколько мы знаем (Fischhoff, Slovic & Lichtenstein, 1977).

Последний момент о тенденции быть слишком уверенными в том, сколько мы знаем (в данном контексте, сколько мы знаем о прошлом), — это сильная часть исследований Баруха Фишхоффа, который первоначально исследовал то, что мы сейчас понимаем как предвзятость ретроспективы. Неудивительно, что научным руководителем докторской диссертации Фишхоффа был Даниэль Канеман (вы, вероятно, слышали о нём как об авторе Думай медленно… решай быстро), чьи исследования когнитивных предвзятостей и эвристик каждый должен хотя бы смутно знать.

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

Четвёртая часть этого заключается в том, что время необратимо. Мы не можем смотреть на причинную цепочку как на что-то, что можно перематывать вперёд и назад, как бы привлекательно просто это ни казалось. Это потому, что социотехнические системы, над которыми мы работаем и в которых мы работаем, сложны по своей природе и динамичны. Детерминированное поведение (или, по крайней мере, предсказуемость) — это то, что мы ищем в программном обеспечении; в сложных системах это глупый поиск, потому что эмерджентность — это свойство этой сложности.

И наконец, есть базовое предположение, что полное знание достижимо. Другими словами: нам нужно только постараться достаточно усердно, чтобы понять точно, что произошло. Проблема в том, что успех и неудача имеют много способствующих причин, и не существует всеобъемлющего и объективного отчёта. Лучшее, что вы можете сделать, — это исследовать перспективы людей в критических точках расследования. Невозможно понять прошлые события каким-либо образом, который можно считать всеобъемлющим.

Деккер (Деккер, 2011):

Как только произошёл результат, любые прошлые события, которые можно сказать, привели к нему, претерпевают целый ряд трансформаций (Fischhoff and Beyth, 1975; Hugh and Dekker, 2009). Возьмём идею, что это последовательность событий, которая предшествует аварии. Кто делает выбор «событий» и на основе чего? Сам акт отделения важных или способствующих событий от неважных — это акт конструирования, создания истории, а не реконструкции истории, которая уже была там, готовая быть раскрытой. Любая последовательность событий или список способствующих или причинных факторов уже контрабандой вносит целый массив механизмов отбора и критериев в предполагаемую «ре»конструкцию. Нет объективного способа сделать это — все эти выборы затронуты, более или менее неявно, опытом аналитика, предпочтениями, опытом, предвзятостями, убеждениями и целями. «События» сами определяются и ограничиваются историями, с помощью которых аналитик их конфигурирует, и невозможно представить вне этой избирательной, исключающей нарративной пред-структуры (Cronon, 1992).

Вот мысленный эксперимент: что если мы попытаемся использовать «Пять почему» для поиска «первопричины» успеха?

Почему у нас не было сбоя X сегодня?

Теперь на этот вопрос становится намного сложнее иметь один ответ. Это потому, что всё идёт хорошо по многим причинам, и не все из них очевидны. Мы можем потратить весь день, записывая причины, почему у нас не было сбоя X сегодня, и если мы настроены решительно, мы можем продолжать.

Итак, если успех требует «множественных способствующих условий, каждое необходимо, но только вместе достаточно» для того, чтобы произойти, то как получается, что для неудачи требуется только одно? «Пять почему», как обычно представляется в качестве подхода к улучшению (или: обучению?), заставит нас поверить, что не только одно условие достаточно, но что это условие каноническое, исключая все остальные.

* RCA, или «Анализ первопричин», также может легко превратиться в «Ретроспективное прикрытие задницы»

Список литературы

Carroll, J. S. (1995). Incident Reviews in High-Hazard Industries: Sense Making and Learning Under Ambiguity and Accountability. Organization & Environment, 9(2), 175—197. doi:10.1177/108602669500900203

Dekker, S. (2004). Ten questions about human error: A new view of human factors and system safety. Mahwah, N.J: Lawrence Erlbaum.

Dekker, S., Cilliers, P., & Hofmeyr, J.-H. (2011). The complexity of failure: Implications of complexity theory for safety investigations. Safety Science, 49(6), 939—945. doi:10.1016/j.ssci.2011.01.008

Hollnagel, E. (2009). The ETTO principle: Efficiency-thoroughness trade-off : why things that go right sometimes go wrong. Burlington, VT: Ashgate.
Leveson, N. (2012). Engineering a Safer World. Mit Press.