Разработка ПО: что скрывает ложь?
Добрый день.
Полет космического челнока “Челленджер”, намеченный на 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, все это здорово, но в реальной жизни все не так? Страх за свое место? Мнительность и паранойя? Инициатива не приветствуется? Приветствуется, но не поощряется? Манипуляции, увертки, лицемерие, страх? Бывает и так. В таких случаях важно не корчить из себя героя: “Я один пекусь о качестве продукта”. Это была бы еще одна форма лжи, уже непреднамеренная: мышление и поступки, диктуемые чувствами и эмоциями (не стоит забывать, что мы видим в людях черты, присущие нам самим). Лучше попытаться понять мотивы всех участников проекта. Возможно, есть варианты, при которых интересы каждого игрока будут учтены, но уже на других, более достойных принципах? Чем не вызов – помочь человеку преодолеть свой страх и все то, что за ним следует: двуличность, бездействие, неосознанные плохие поступки? Важно попробовать, приложить усилия. Не выходит? Что ж, тогда остается быть честным с самим собой, достойно работать в круге своего влияния. И затачивать пилу. Всегда пригодится. Оставайтесь с нами.
