Как авиакатастрофа может улучшить разбор факапов в ИТ

в 4:10, , рубрики: autopsy without blame, Northwest Airlines Flight 255, solution without blame, Научно-популярное, управление качеством, управление проектами

Вечером 16 августа 1987 года из аэропорта Детройта вылетел рейс 255 компании Northwest Airlines. Он разбился спустя минуту, и в катастрофе погибли 156 человек. Вроде бы очевидная ошибка пилотов привела к исследованиям с участием NASA, изменениям конструкции самолетов и полетных процедур. А еще эта история имеет отношение к управлению качеством, управлению проектами и к вопросу вины и наказания не только сборщиков потерпевшего аварию «Союза МС-10», но и людей, совершивших ошибки на вашей работе.

Как авиакатастрофа может улучшить разбор факапов в ИТ - 1
Фото с места аварии из Бюро архивов авиационных инцидентов

Катастрофа

Вечер 16 августа 1987 года в Детройте не радовал погодой. Приближалась гроза, и экипаж рейса 255 компании Northwest Airlines спешил продолжить полет — Детройт был третьим из пяти аэропортов маршрута, а отставание от расписания составляло уже полчаса. По закону подлости, изменилось направление ветра, и диспетчеры перенаправили самолет на другую полосу. Она была самой короткой во всем аэропорту, поэтому второму пилоту пришлось пересчитывать массу самолета и его пробег при взлете, чтобы убедиться, что с нее можно взлетать. Беда не приходит одна — вечером, в дождь, экипаж потерялся на рулежных дорожках, и когда самолет наконец выехал на взлетно-посадочную полосу, отставание от расписания составляло уже 45 минут.

Взлет произошел в 20:44, и сразу стало понятно, что что-то пошло совсем не так, как надо — в кабине звучало предупреждение об опасности сваливания, самолет не хотел набирать высоту и кренился из стороны в сторону. Спустя несколько секунд он врезался в осветительный столб на парковке, потерял часть крыла и, уже неуправляемый, упал на автомобильную дорогу, проскользил по ней до путепровода, врезавшись в который полностью разрушился. В катастрофе погибли оба пилота, четыре стюардессы, 149 пассажиров и два человека в раздавленном автомобиле. Еще пять человек на земле были ранены. Единственной выжившей оказалась четырехлетняя Сесилия Шин, потерявшая в катастрофе отца, мать и старшего брата.

Как авиакатастрофа может улучшить разбор факапов в ИТ - 2
Схема полета, источник

Расследование

Вещественные доказательства и данные «черных ящиков» показали удивительную вещь — опытный и профессиональный экипаж совершил абсолютно «детскую» ошибку — забыл выпустить закрылки!

Как авиакатастрофа может улучшить разбор факапов в ИТ - 3
Взлетающий самолет семейства MD-80, аналогичный разбившемуся, фото Wikimedia Commons

Как авиакатастрофа может улучшить разбор факапов в ИТ - 4
Увеличенное фото, хорошо видна механизация крыла

Небольшой ликбез. Предкрылки и закрылки — специальные поверхности, которые отклоняются и/или выдвигаются в передней и задней частях крыла для создания дополнительной подъемной силы на малой скорости. Используются при взлете и посадке.

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

Вопросов меньше не стало, наоборот. Как раз на случай того, что экипаж забудет подготовить самолет к взлету, была создана специальная система, которая должна была подать сигнал, что закрылки и предкрылки не находятся во взлетном положении. Но она почему-то молчала. Далее, сигнал об опасности сваливания должен был для надежности идти из двух динамиков, а шел только из одного. Официальное расследование установило, что по неизвестной причине был разомкнут переключатель P-40, который находится позади левого кресла — этот переключатель одновременно запитывал и предупреждение о невзлетной конфигурации, и один из динамиков системы предупреждения о сваливании. Панель с этим переключателем была сильно повреждена в катастрофе, и установить, сломался ли переключатель или же был выключен вручную, не получилось. Но одна история является очень важным косвенным доказательством.

Как авиакатастрофа может улучшить разбор факапов в ИТ - 5
Панель переключателей в левой части кабины MD-80, источник

Следователь Национального совета по безопасности на транспорте (NTSB) Джон Кларк в рамках расследования попросил пилота однотипного с разбившимся MD-80 показать различные предупреждения. Пилот воспроизвел и правильное предупреждение о сваливании из двух динамиков, и индикацию невыпущенных закрылков. Для демонстрации прозвучавшего в роковом полете монофонического сигнала пришлось отключить один из каналов. И пилот сказал «Я этого, конечно же, никогда не делал, но, говорят, некоторые специально отключают предупреждение о невыпущенных закрылках, потому что оно часто ложно срабатывает на рулении и очень раздражает», после чего, не глядя, потянулся к тому самому переключателю P-40 у себя за спиной и явно привычным движением выключил его. А на панели переключателей вокруг P-40 было больше грязи, как будто бы его постоянно включали и выключали…

Так что казалось бы очевидный вывод «ошибка пилотов» по сути маскировал две большие проблемы:

  1. С контрольными картами что-то не то, раз их забывают выполнить.
  2. Если убрать ложные срабатывания системы предупреждения о невыпущенных закрылках, то у пилотов пропадет искушение ее выключать.

Специально еще раз повторю — опытные профессионалы тоже совершают ошибки. Попытки исправить ситуацию репрессивными мерами боролись бы со следствием, а не причиной — экипаж рейса 255 не был безответственным, и, конечно же, не хотел умирать и уносить с собой в могилу ни в чем не повинных людей. Командир корабля проработал в этой авиакомпании 31 год, второй пилот имел налет несколько тысяч часов, они оба, по отзывам коллег, были хорошими летчиками, но это ничуть не помогло.

Увы, решения не сумели найти быстро — в следующем году по той же причине (забыли выпустить закрылки) разбился самолет другой модели, Boeing 727, в Далласе. Из 108 человек на борту погибли 14. Там, правда, вина экипажа была больше — пилоты явно нарушили правило «стерильной» кабины и беседовали перед взлетом с зашедшей стюардессой. Но на записи речевого самописца второй пилот произносит, что закрылки выпущены на правильный угол, несмотря на то, что это не так.

Проблемой контрольных карт занялись в NASA. В результате появились рекомендации по улучшениям, начиная от длины чеклистов и заканчивая шрифтом которым они печатались. К тому же в конце 80-х в авиацию активно внедрялись компьютеры, и чеклисты начали делать электронными — компьютер не только помнит, на каком пункте ты остановился, если тебя отвлекли, но и проверит, сделал ли ты то, что отметил как выполненное. Но, увы, еще есть что улучшать — катастрофа Ан-148 в феврале этого года произошла из-за того, что пилоты отложили один из пунктов чеклиста и забыли его потом выполнить (для справедливости надо отметить, что конструкторы самолета тоже недоработали — этот пункт нельзя было выполнить заранее в спокойной обстановке).

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

Причем тут ИТ?

История рейса 255, на мой взгляд, несет выводы, которые мы можем применить у себя, в ИТ.

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

Одна из методологий для реализации этих принципов называется autopsy without blame («вскрытие без обвинений»). Вариант, использующийся в компании, где я работаю, называется solution without blame, SWOB («решение без обвинений»). Позволю себе кратко процитировать его принципы:

Цели:

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

Важно:

  • Улучшение процессов — дело каждого.
  • Каждый будет услышан.
  • Начальство открыто новому.

Обещания:

  • Не бойтесь копать глубоко и озвучивать даже неприятные причины. Никто никогда не будет наказан за участие в SWOB или что угодно, обнаруженное на SWOB.
  • Нетерпимо только неуважение друг к другу.

Организационные моменты:

  • Выберите независимого фасилитатора, который будет вести заметки и модерировать дискуссию. В фасилитаторы выбирают человека, пользующегося уважением, поэтому быть им почетно. Но руководство нельзя выбирать в качестве фасилитатора.
  • Лучше всего провести SWOB с не совсем сразу после факапа, чтобы успокоиться, но и не слишком поздно, чтобы люди не забыли, что случилось. Идеальный срок в течение недели после проблемы.
  • Формат документирования: сначала описание события, затем идеи по улучшению процессов.

Заключение

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

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

Серебряной пули не существует, но кому-нибудь из вас идеи SWOB могут помочь. Удачи в улучшении процессов!

Автор: lozga

Источник

Поделиться

* - обязательные к заполнению поля