OpenQuality.ru
Качество программного обеспечения
Добрый день.
Полет космического челнока “Челленджер”, намеченный на 28 января 1986 года, должен был войти в историю достижений американской индустрии. Криста МакОлифф, преподавательница гуманитарых дисциплин из штата Нью-Гэмпшир, планировала дать первый открытый урок из космоса. Телевидение вело прямую трансляцию с мыса Канаверал, видеокамеры фиксировали все происходящее, миллионы телезрителей прильнули к экранам. Но урок не состоялся. Семьдесят три секунды полета вместили в себя белый дымок из правого ускорителя, клубы черного дыма, вспышку пламени и мощнейший взрыв, превративший челнок в груду раскаленных обломков. Страна застыла в ужасе, но для сотрудников фирмы “Morton Thiokol” произошедшее не было неожиданным. Накануне группа инженеров рекомендовала отложить запуск челнока, а Алан МакДоналд, руководитель отдела разработки двигателей, отказался подписать акт о готовности корабля к запуску. Ожидалась холодная погода, которая могла привести к снижению эластичности колец изоляции, что в свою очередь могло привести к утечке топлива и взрыву двигателей. Именно так и произошло. Герметичность уплотнителей была нарушена – образовалась щель, в которую попали горячие газы. В результате были повреждены водородный и кислородный баки. Последовавший взрыв топлива унес жизни всего экипажа и заморозил космическую программу США на несколько лет.
Как руководство NASA могло отправить челнок в космос, зная о высокой вероятности взрыва (один к тридцати пяти)? Президентская комиссия пришла к выводу, что топ-менеджеры NASA, принимавшие решение о запуске корабля, ничего не знали об опасениях инженеров. Информация застряла у основания “управленческой пирамиды”. Лоуренс Маллой, сотрудник NASA, знал о возможности взрыва, но посоветовал руководителю “Thiokol” мыслить как мыслит управленец, а не как инженер. По сути, Маллой продавил “добро” на старт в обход позиции инженеров и технического менеджмента “Thiokol”. Запуск челнока откладывался три раза, и Маллой решил не расстраивать свое руководство. Очередная задержка могла повлиять на размер субсидий, выделяемых Конгрессом, и привести к неприятным последствиям для гонца, принесшего дурную весть. Маллой находился под сильным давлением. “Давай, давай, давай”, – его начальству был нужен результат. Только положительный и как можно быстрее. Маллой не видел другого выхода кроме как счесть позицию инженеров преувеличением и поставить судьбу челнока на рулетку погодных условий.
“Это больше не повторится. Выводы сделаны и меры приняты”, – звучало из уст руководителей NASA после оглашения результатов работы комиссии. Семнадцать лет спустя, 1 февраля 2003 года, другой челнок, “Колумбия”, потерпел катастрофу при посадке. Корабль развалился на две части в результате разрушения наружного теплозащитного слоя на левом крыле. Как и в случае с “Челленджером”, инженеры предвидели такой исход по результатам старта челнока и требовали провести анализ поверхности крыла. Аппаратно-программный комплекс “Кратер” предсказал повреждение, но руководство NASA сочло эту информацию несущественной, сняв с нее гриф “High Importance” и отклонив запрос на дорогостоящую инспекцию корабля. История учит тому, что ничему не учит.
Катастрофы “Челленджера” и “Колумбии” иллюстрируют две наиболее типичные формы лжи, проявившиеся в позиции чиновников NASA: умолчание (как в случае с “Челленджером”) и искажение информации (”Колумбия”). Что общего у этих двух катастроф? Позиция менеджмента NASA и их подход к управлению рисками. “Этого не может быть. Нет, нет, нет, этого не должно быть. Мы не можем этого допустить, потому что тогда вместо челнока полетят сроки”. Иными словами, “этого не может быть, потому что не должно быть никогда”. Раз так, то в ход идет умолчание, любые средства. Главное – “не допустить”. Притупляется чувство реальности, способность взглянуть на ситуацию со стороны. Подменяются понятия: теперь управление риском не подразумевает стремление предвидеть и предовратить неполадки. Их просто не может быть, нас не поймут. Вместо этого – дикое, необоримое желание закрыть глаза и отмахнуться от неприятных сведений. Мозг размышляет примерно так: “если разгласим, то будет неминуемо плохо, а если промолчим, то есть шанс прорваться”. На одной чаше весов – крах карьеры и потеря бенефитов, на другой – “ложь во спасение”. Нет, чиновники NASA не желали гибели челноков. Они просто хотели проскочить.
Встречаются ли подобные ситуации в проектах по разработке ПО?
Мы должны отдать систему к 1 ноября, или нас задушат. Значит, идем напрямик. Agile у нас или не agile? Сделаем ровно столько, сколько требуется в итерации. Модульные тесты не врут, все работает. О стабильности и масштабировании подумаем 2 ноября. Остались баги с приоритетами P1-P2? Что-то здесь не так. Наверное, это все-таки P3. Значит, их можно отложить.
Или так: у нас просто нет времени на тестирование производительности. Сначала все было слишком сыро – лишь бы функциональность работала, ей все внимание. А потом стало слишком поздно – пора выпускать. Но за нами не встанет. Мы вернемся к этому 2 ноября.
Или так: низкая производительность? Что вы. Это повышенная безопасность, сверхнадежная защита. Это инновации. Так и задумывалось. Нам только надо грамотно изложить это в маркетинговых проспектах. Железо помощнее – и все будет летать.
Или так: пожалуй, эти баги никому не интересны. Все равно их никто не найдет. Кому эта фишка нужна? Вон в прошлый раз нашел и потом замучался перепроверять. Ни тебе спасибо, ни тебе пожалуйста. Что у меня, других дел нет? Вон Гоша на все забил и радуется жизни. Изо дня в день, из месяца в месяц. И хорошо живет. Это мудро. Кстати, слишком умных начальство не любит и даже боится. Лучше не высовывать нос из норы.
Или так: блин, вожусь с этим багом вторую неделю, а все не выходит. Введу-ка я пару-тройку констант. Ну да, никакого масштабирования. Но нам же потом выделят время на рефакторинг?
Список можно продолжать до бесконечности. У каждого проекта своя специфика, но такие ситуации роднит одно важное свойство: сокрыть или исказить информацию гораздо выгоднее чем правдиво изложить. В результате проигрывают все участники цепочки – от рядового разработчика до пользователя системы. Даже если все обошлось, результат уже плачевный: система, построенная на хлипком фундаменте страха и лжи. Что делать? Как избежать таких последствий?
Нет, не надо вызывать доктора Лайтмена или устанавливать детектор лжи. Не надо вводить тотальный контроль всего и вся с многочисленными бюрократическими завихрениями. Нужно пересмотреть базовые принципы, на которых строится разработка. Если программисту, тестировщику и линейному менеджеру выгодно/комфортно работать по совести, он будет работать по совести. Если его трудности находят понимание, если его инициатива поощряется, то он будет работать не только на свое благо, но и на благо проекта. Если во главу угла ставится качественный, надежный продукт, то искажениям информации просто не будет места.
OK, все это здорово, но в реальной жизни все не так? Страх за свое место? Мнительность и паранойя? Инициатива не приветствуется? Приветствуется, но не поощряется? Манипуляции, увертки, лицемерие, страх? Бывает и так. В таких случаях важно не корчить из себя героя: “Я один пекусь о качестве продукта”. Это была бы еще одна форма лжи, уже непреднамеренная: мышление и поступки, диктуемые чувствами и эмоциями (не стоит забывать, что мы видим в людях черты, присущие нам самим). Лучше попытаться понять мотивы всех участников проекта. Возможно, есть варианты, при которых интересы каждого игрока будут учтены, но уже на других, более достойных принципах? Чем не вызов – помочь человеку преодолеть свой страх и все то, что за ним следует: двуличность, бездействие, неосознанные плохие поступки? Важно попробовать, приложить усилия. Не выходит? Что ж, тогда остается быть честным с самим собой, достойно работать в круге своего влияния. И затачивать пилу. Всегда пригодится. Оставайтесь с нами.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Автор комментария : Ochir | November 3, 2009
хорошая и актуальная статья ))
К сожалению, менеджеры проектов и разработчики зачастую недооценивают замечания специалистов по качеству, поэтому могут возникать такие проблемы. Но кажется чем сложнее системы, тем наша профессия больше ценится ))
[Ответить]
Автор комментария : Юлай | November 3, 2009
В целом согласен. Есть неточности, люди лгут ради кратковременной выгоды здесь и сейчас. Любое решение имеет недостатки и преимущества, преимущество ЛЖИ в кратковременном спокойствии лично себя, недостаток - потери в стратегическом плане всей компании. И так как каждый принимает решение с учетом своих эмоций, мы “имеем то что имеем”. Европейцы это поняли уже давно “никаких эмоций, только бизнес”, наши не поймут еще длительное время.
[Ответить]
Автор комментария : Капитан Аляска | November 3, 2009
@ Ochir, Юлай, спасибо за отзывы.
@ Юлай. Если в шутку предположить, что мы видим черты, присущие нам самим, то можно допустить, что ради долговременной выгоды вы не слукавите :) Если говорить серьезно, то люди лгут в силу разных причин. Теории лжи посвящены целые исследования (того же Поля Экмана, к примеру), которые, безусловно, в одной статье не осветить. Да, возможно, и не стоит, поскольку множество вариаций бесконечно. Лучше сосредоточиться на своем круге влияния, ибо это гораздо более продуктивно – как в краткосрочной, так и в стратегической перспективе. Кстати, европейский подход “никаких эмоций, только бизнес” в случае с челноками не помог бы. Люди – не роботы. Они таки беспокоятся не только за бизнес, но и за себя тоже. На мой взгляд, лучше сосредоточиться на том, чтобы правда поощрялась, а ложь отталкивала. Создавать соответствующую среду для этого.
[Ответить]
Автор комментария : Михаил | November 13, 2009
Прикольная подтасовка фактов :-)
Я не сильно слежу за полетами челноков, и мне все равно, сколько штук и какого вида взорвались / упали / еще что-то.
Но PM - то принимает решение на основе многих фактов. Между строк этой статьи можно прочитать следующее:
1. Мы (инженеры) предупреждали, что взорвется, вы (руководитель полетов, PM или еще кто-то) нас не послушали, и челнок взорвался.
2. Второй раз случилось тоже самое с тем же результатом
3. Вывод. Вы - идиоты, потому что никогда не слушаете нас, умных инженеров. Будете слушать, будут летать Ваши Шатлы еще 300 лет, только бензоколонку подавай. :-)
М.б. применительно к Шатлу можно посчитать вероятности. Может быть.
Но в реальной жизни - то не так. PM, это конечно диагноз, но не диагноз хронического идиота. Он смотрит, что из 100 установок одна прошла плохо. Не такой плохой результат. Учитывая тот неоспоримый факт, что качество разработки неуклонно падает, а профессионализм как минимум не растет, не такой плохой результат.
Кстати, возвращаясь к Шатлам. Даже американцы признали, что наши ракеты - самые надежные. А почему? Да потому что простые! (конечно по сравнению !!! по мне, так очень сложные :-) ).
То же и у нас в разработке ПО. Внедряются вещи, мало проверенные. Давайте попробуем, может быть и пойдет бизнес … Раньше все оплачивали счета в Сберкассе, а теперь? Сберкассу переименовали в Сбербанк, и работает это заведение так же, но добавили кучу терминалов, других банков стало много, Интернет … Конечно, ПО стало намного сложнее. Учитывая всеобщее раздолбайство в процессе разработки, вообще не понятно, как это работает !
Короче, возвращаясь к нашему PM. Он же не просто так дает добро. У него куча разной информации, и он должен принять решение. И не всегда оно правильное. Для космонавтов, к сожалению, это означает смерть :-(
Так что не стреляйте в пианиста, он играет, как может. А лучше найдите хорошего пианиста.
P.S. У хороших пианистов тоже бывают проколы, мы же люди !
[Ответить]
Автор комментария : Капитан Аляска | November 13, 2009
Михаил, спасибо за комментарий! Никакой подтасовки фактов, только наблюдения. На самом деле ни о чем подобном (”Вы - идиоты, потому что никогда не слушаете нас, умных инженеров”) и мыслей не было. Речь шла о том, насколько важна открытость в проекте, насколько важно не скрывать, не искажать факты. Насколько важно культивировать среду, в которой таким искажениям просто не будет места. Об этом, кстати, говорилось в итоговом докладе Ричарда Фейнмана, великого физика и Нобелевского лаурета. Ричард возглавлял президентскую комиссию, исследовавшую причины катастрофы Челенджера, и при всей своей учености и академическом подходе сделал акцент именно на организационных факторах, которые привели к катастрофе.
Тут не пианисты (инженеры) виноваты. И даже не дирижеры (Маллой). Скорее, руководители филармонии (верхушка NASA), которые из своих “высоких” интересов закрывали глаза на то, что происходит в проекте.
[Ответить]
Автор комментария : AntonK | June 22, 2012
Интересная статья. В целом суть изложена верно: некорректная коммуникация как правило приводит к проблемам…
И мне вот, что любопытно: за всю историю космических полётов сколько предупреждений инженеров были “напрасными” - несмотря на предсказанные риски, чудо-устройство взлетело и приземлилось без явных негативных спецэффектов?
[Ответить]
Капитан отвечает:
June 22nd, 2012 в 7:04 pm
Антон, спасибо за комментарий. Рискну предположить, что:
1) о “напрасных” предупреждениях статистики нет
2) вероятность негативных спецэффектов есть всегда. К примеру, полет Гагарина. Но то, что он и другие челноки возвращаются, ничего не говорит о будущем…
[Ответить]