Как авиакатастрофа может улучшить разбор факапов в ИТ
16.11.2018
Фото с места аварии из Бюро архивов авиационных инцидентов
Вечером 16 августа 1987 года из аэропорта Детройта вылетел рейс 255 компании Northwest Airlines. Он разбился спустя минуту, и в катастрофе погибли 156 человек. Вроде бы очевидная ошибка пилотов привела к исследованиям с участием NASA, изменениям конструкции самолетов и полетных процедур.
А еще эта история имеет отношение к управлению качеством, управлению проектами и к вопросу вины и наказания не только сборщиков потерпевшего аварию "Союза МС-10", но и людей, совершивших ошибки на вашей работе.
Примечание Владимира Зыкова. Факап (от англ. "fuck up" - проиграть, провалиться) неудача, провал, поражение. Как правило, факап - это не просто досадная ошибка и неудача, а нечто масштабное, сравнимое с полноценным эпикфейлом, какой-то конкретный облом. Употребляться может в контексте любой провальной ситуации. Факапнуться - значить облажаться по полной программе.
Катастрофа
Вечер 16 августа 1987 года в Детройте не радовал погодой. Приближалась гроза, и экипаж рейса 255 компании Northwest Airlines спешил продолжить полет - Детройт был третьим из пяти аэропортов маршрута, а отставание от расписания составляло уже полчаса. По закону подлости, изменилось направление ветра, и диспетчеры перенаправили самолет на другую полосу. Она была самой короткой во всем аэропорту, поэтому второму пилоту пришлось пересчитывать массу самолета и его пробег при взлете, чтобы убедиться, что с нее можно взлетать. Беда не приходит одна - вечером, в дождь, экипаж потерялся на рулежных дорожках, и когда самолет наконец выехал на взлетно-посадочную полосу, отставание от расписания составляло уже 45 минут.
Взлет произошел в 20:44, и сразу стало понятно, что что-то пошло совсем не так, как надо - в кабине звучало предупреждение об опасности сваливания, самолет не хотел набирать высоту и кренился из стороны в сторону. Спустя несколько секунд он врезался в осветительный столб на парковке, потерял часть крыла и, уже неуправляемый, упал на автомобильную дорогу, проскользил по ней до путепровода, врезавшись в который полностью разрушился. В катастрофе погибли оба пилота, четыре стюардессы, 149 пассажиров и два человека в раздавленном автомобиле. Еще пять человек на земле были ранены. Единственной выжившей оказалась четырехлетняя Сесилия Шин, потерявшая в катастрофе отца, мать и старшего брата.
Вещественные доказательства и данные "черных ящиков" показали удивительную вещь - опытный и профессиональный экипаж совершил абсолютно "детскую" ошибку - забыл выпустить закрылки!
Взлетающий самолет семейства MD-80, аналогичный разбившемуся, фото Wikimedia Commons
Увеличенное фото, хорошо видна механизация крыла
Небольшой ликбез. Предкрылки и закрылки - специальные поверхности, которые отклоняются и/или выдвигаются в передней и задней частях крыла для создания дополнительной подъемной силы на малой скорости. Используются при взлете и посадке.
Расследование показало, что забыты были не просто закрылки, а целая полетная карта (чеклист) из нескольких пунктов, которые надо было выполнить на рулении. У экипажа в процессе взлета даже возникла было подсказка, что они что-то пропустили - бортовой компьютер оказался не в полетном режиме, и не включился автомат тяги. Но человек, особенно в условиях стресса и спешки, способен не заметить или забыть что угодно - подсказку экипаж проигнорировал и взлет не прервал.
Вопросов меньше не стало, наоборот. Как раз на случай того, что экипаж забудет подготовить самолет к взлету, была создана специальная система, которая должна была подать сигнал, что закрылки и предкрылки не находятся во взлетном положении. Но она почему-то молчала. Далее, сигнал об опасности сваливания должен был для надежности идти из двух динамиков, а шел только из одного. Официальное расследование установило, что по неизвестной причине был разомкнут переключатель P-40, который находится позади левого кресла - этот переключатель одновременно запитывал и предупреждение о невзлетной конфигурации, и один из динамиков системы предупреждения о сваливании. Панель с этим переключателем была сильно повреждена в катастрофе, и установить, сломался ли переключатель или же был выключен вручную, не получилось. Но одна история является очень важным косвенным доказательством.
Панель переключателей в левой части кабины MD-80, источник
Следователь Национального совета по безопасности на транспорте (NTSB) Джон Кларк в рамках расследования попросил пилота однотипного с разбившимся MD-80 показать различные предупреждения. Пилот воспроизвел и правильное предупреждение о сваливании из двух динамиков, и индикацию невыпущенных закрылков. Для демонстрации прозвучавшего в роковом полете монофонического сигнала пришлось отключить один из каналов. И пилот сказал "Я этого, конечно же, никогда не делал, но, говорят, некоторые специально отключают предупреждение о невыпущенных закрылках, потому что оно часто ложно срабатывает на рулении и очень раздражает", после чего, не глядя, потянулся к тому самому переключателю P-40 у себя за спиной и явно привычным движением выключил его. А на панели переключателей вокруг P-40 было больше грязи, как будто бы его постоянно включали и выключали...
Так что казалось бы очевидный вывод "ошибка пилотов" по сути маскировал две большие проблемы:
С контрольными картами что-то не то, раз их забывают выполнить.
Если убрать ложные срабатывания системы предупреждения о невыпущенных закрылках, то у пилотов пропадет искушение ее выключать.
Специально еще раз повторю - опытные профессионалы тоже совершают ошибки. Попытки исправить ситуацию репрессивными мерами боролись бы со следствием, а не причиной - экипаж рейса 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 могут помочь. Удачи в улучшении процессов!
Перепечатка материалов приветствуется, при этом гиперссылка на статью или на главную страницу сайта "Технополис завтра" обязательна. Если же Ваши правила строже этих, пожалуйста, пользуйтесь при перепечатке Вашими же правилами.