Про наказание невиновных и награждение непричастных

В который раз встретил фразу про наказание виновных в неполадках космической техники - в этот раз в статье про Фобос-Грунт у Зеленого кота:

Согласно заключению госкомиссии, авария произошла “вследствие недооценки фактора космического пространства разработчиками и создателями межпланетной станции”. Виновные в просчёте сотрудники НПО имени Лавочкина были привлечены к административной ответственности.

Подобная фраза встречается довольно часто, обычно - в статьях изданных по результатам анализа причин той или иной аварии. Также бывает, что речь о наказании виновных заходит и в интернетных обсуждениях тех же аварий, причем частенько в контексте, что, мол, опять стрелочника наказали, а надо было кого-нибудь повыше, лучше всего - самого главного.

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

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

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

Или, скажем, разработчики не подумали про common mode failure, расположили оба резервных компьютера рядом, и их прошило частицей космического излучения. Еще один напуганный косяк рыбы и плач Ярославны на весь интернет про загубленные полимеры. Государственная комиссия устанавливает первопричину аварии и товарищи, поставившие свои подписи под результатами critical design review, идут на нары, как растратчики государственных средств. Их последователи четко усваивают урок, что отсвечивать в официальных документах чревато. В результате design review из способа найти и исправить ошибки превращается в политическую игру “нас тут не стояло”.

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

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

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

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

Вот как-то так.