Катастрофа Скотта Адамса: Анатомия бедствия
Четверг, 30 Август, 2007Скотт Адамс(Scott Adams), отец комикса Dilbert, был сильно озадачен результатом, потратив много часов, редактируя комментарии своего блога. После публикации, он с удивлением обнаружил, что все изменения пропали. Веки(Veky) хочет знать, в чем причина и кто виноват в ошибке. Его вопрос подразумевает, был ли виноват сам Скотт?
Уважаемый, Tog:
Скотт Адамс промодерировал около пятисот комментариев в своем блоге, а затем удалил их, несмотря на постоянные предупреждения об удалении. Чья здесь ошибка?
~Veky
Скотт не виноват
Цепочка из пяти ошибок привела Скотта Адамса к потере результатов своей работы. Он не совершил ни одну из этих ошибок. Скотт Адамс еще не начал работу над своим блогом, а ошибки уже были совершены. Месяцы и годы ранее, задолго до начала работы. Это был несчастный случай, ждущий чтобы случиться. Несчастный случай, который почти наверняка случился бы с большим количеством людей, использующих аналогичное ПО.
Когда я учился управлять самолетом, мой инструктор подчеркнул, что несчастные случаи в самолете – результат ряда неудачных ошибок и событий. В каждом отдельном случае все могло бы закончиться благополучно, но именно цепочка взаимосвязанных событий и ошибок привела к трагедии.
Например, на пути в Тахо(Tahoe), мы с инструктором приземлились в маленьком авиа палаточном лагере Сьерра-Невада. Пилот другого самолета, приземлившегося ранее, обнаружил механическую поломку, которая не давала ему взлететь. Он спросил, не подбросим ли мы его до Тахо, чтобы он мог вызвать помощь (мы были вне зоны доступа сотовых операторов).
Я инстинктивно хотел ответить «да». В конце концов, наш самолет был оборудован для четырех пассажиров. Однако, мой инструктор, ответил «нет», дав понять, что примет меры и свяжется с кем-либо, кто сможет приехать пилоту на помощь. Вызовет помощь, но не возьмет еще одного пассажира. Это был жаркий день, что естественно вызвало снижение подъемной силы, даже, несмотря на то, что мы были на достаточной большой высоте (немного выше, чем Денвер, Колорадо), но, тем не менее, ответ инструктора показался вызывающе грубым.
Я продолжал так считать, вплоть до момента, когда нас настиг нисходящий поток. Мы были в двух километрах(6750 футов) от аэропорта Саус-Лэйк Тахо (South Lake Tahoe) и начали камнем падать вниз. Запаса по высоте у нас не было, но я все-таки сумел благополучно зайти на посадку. Если бы мы взяли еще одного пассажира – наш самолет усыпал своими останками окружающий ландшафт. Почти наверняка, никто не выжил.
В моем случае, цепочка из трех ошибок могла привести к трагедии:
1. Механическая поломка другого самолета.
2. Готовность пилота сократить запас прочности, взяв еще одного пассажира.
3. Внезапный, непредсказуемый нисходящий поток.
Номер один и три были неизбежными. Номер два был преодолим. К счастью, мой инструктор обладал достаточным опытом, чтобы прервать цепочку, отказавшись взять третьего пассажира и, тем самым, в соответствии с текущими погодными условиями, отказавшись перегрузить самолет. (Производителям малых самолетов разрешают переоборудовать самолет под большее число мест, но пользоваться им исходя из погодных условий). Сегодня, я бы нарушил цепочку, также как нарушил ее тогда мой инструктор.
Достаточно часто, именно ошибка пилота – основная причина авиа катастроф. Пилоты могут учиться и переучиваться, тем не менее, исследование ошибок пилотов – важная часть расследования причин несчастных случаев. Однако, мы не получим никакой выгоды от наблюдения за ошибками наших пилотов-пользователей. Наша работа заключается в построении систем, устраняющих либо избегающих ошибок пилотов. Скотт Адамс – опытный пилот, с тысячью часов наработки технологий за плечами. Что-то должно быть серьезно испорчено в проекте, чтобы он потерял столько информации. Этот проект мы и должны исследовать.
Расследование несчастного случая Скотта Адамса
Давайте посмотрим, что не так с блогом Скотта Адамса. Где здесь цепочка событий, приведшая к ошибке?
Ошибка первая: Пользовательская Модель не отражала Модель Проекта.
Скотт Адамс полагал, что было два документа, отражающих его комментарии. Первый документ он назвал «временное хранилище» базы данных. Оно используется до тех пор, пока он не опубликовал 500 комментариев. Второй документ – общедоступная база данных.
С другой стороны, проектировщики, думали, что существует только одна база данных. В действительности так и было - одна база данных.
В концептуальной модели Дона Норманна(Don Norman) проектировщик разрабатывает «Модель Проекта»(Design Model) программной системы, которая взаимодействует с пользователем через «Образ Системы»(System Image) - управление, представление и поведение интерфейса. Пользователь, в свою очередь, пытается пересмотреть «Модель Проекта» в силу своего опыта использования ПО. Такое понимание взаимодействия пользователь-система формирует предположение, что существует некий фильтр, через который пользователь по-своему интерпретирует поведение системы.
Концептуальная Модель Нормана, иллюстрация Лори Вертелней(Laurie Vertelney)
Взаимодействие в таком случае терпит неудачу. Это хорошо видно на примере опасного непонимания «Модели Пользователя» в случае Скотта, но почему он смог совершить эту ошибку?
Пользователь, в попытке точно понять модель проекта, может совершить ошибку, следуя двумя путями:
1. Пользователь пытается понять только часть системы.
2. Пользователь пытается понять всю систему, это не правильно.
В первом случае, у пользователя может возникнуть множество вопросов. Он может оказаться в неведении, что вещи могли спутаться. Во втором случае, пользователь полагает, что он успешно «решил загадку». У него не возникает вопросов, т.к. он не понимает, что понял модель неправильно. Второй случай наиболее опасен: Проектировщик и Пользователь находятся в двух различных мирах и оперируют двумя различными наборами понятий. Ни один из них не знает об этом, и ни один из них не предпринимает каких-либо действий, чтобы исправить это. Пользователь, в течение продолжительного времени (минуты, дни или даже месяцы) систематически «извращает» то, что задумал проектировщик.
Рассмотрим следующую инструкцию, описывающую как нужно заходить в плавательный бассейн:
1. Подойти к краю.
2. Убедиться что глубина больше двух метров (6 футов).
3. Держите ваши руки над головой.
4. Начните наклоняться вперед, сгибая ноги в коленях.
5. Оттолкнитесь как можно сильнее от бортика, убедившись, что голова смотрит прямо вниз, для правильного входа в воду.
Теперь подумайте, что случилось бы, если эти инструкции использовались для спуска в кратер вулкана.
Если бы пользователь исходил в своих суждениях только из информации об «Образе Системы», то он создал бы разумную «Пользовательскую Модель». Пользователь так не делает. Он скорее смешивает свой опыт с информацией из «Образа Системы» и строит свою собственную «Модель Пользователя». Когда прошлый опыт не совпадает однозначно с «Образом Системы», пользователь, вероятнее всего, извратит намерения проектировщика.
Начните с изучения области, чтобы гарантировать понимание предыдущего опыта пользователя. Сделайте так, чтобы ваш «Образ Системы» или отслеживал предыдущий опыт пользователя или четко показывал, где «Образ Системы» расходится с виденьем пользователя.
Ошибка вторая: Метафоры, вводящие в заблуждение.
[…]
The Scott Adams Meltdown: Anatomy of a Disaster
AskTog, февраль 2006
