Психбольница в руках пациентов

В прошлом руководители считали проектирование взаимодействия задачей программирования и делегировали ее решение программистам, которые прилежно трудились, хотя их опыт, подготовка, настрой и рабочее расписание не позволяли добиться успеха. С целью диагностирования проблемы эта книга подробно описывает такой провал, который всегда оказывается провалом программиста. Некоторые из программистов обиделись на мои описания, вообразив, что я злословлю или пытаюсь возложить на программистов вину за некачественные программы. Определенно, они являются агентами в создании некачественных программ, но никоим образом не заслуживают осуждения. Я не виню программистов за сложные в использовании программы, и мне очень жаль, что у некоторых из них сложилось обратное впечатление. За некоторыми исключениями, знакомые мне программисты прилежны и добросовестны в своем желании угодить конечным пользователям, равно как и неустанны в стремлении повышать качество своих программ. Подобно пользователям, программисты – лишь жертвы неверного процесса, оставляющего слишком мало времени, дающего слишком много противоречивых приказов и слишком мало действительно ценных указаний. Мне очень жаль, если у кого-то из программистов сложилось впечатление, что я их обвиняю.

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

В своих недавних путешествиях я заметил нарастающую тревогу в сообществе программистов. С прискорбием могу сообщить, что хуже всего чувствуют себя лучшие и самые опытные программисты. Они прикладывают титанические усилия, но впадают в цинизм и испытывают тоску, понимая, что их умения растрачиваются впустую. Они могут и не знать точно, как именно получается, что их квалификация не находит правильного применения, но они не могут не видеть очевидных фактов. Многие из лучших программистов вообще перестали программировать, поскольку работа раздражает их. Они ушли в преподавание, стали проповедниками, писателями, консультантами, потому что эти занятия не оставляют ощущения пустой траты времени и сил. Но этих неприятнейших потерь вполне можно избежать. (В некотором смысле движение свободных программ с открытым кодом можно назвать раем для этих отчаявшихся программистов – тут они могут писать код по своим стандартам и быть судимыми только равными, не выслушивая советы и не имея необходимости терпеть вмешательство маркетологов или руководителей.)

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

Мудрый руководитель Питер Дрюкер (Peter Drucker) в свои девяносто два года, большую часть которых он провел, наблюдая и направляя руководителей, смотрит на эту проблему со своей, уникальной точки зрения. В недавнем интервью журналу «CIO» он упомянул о наивном оптимизме руководителей в пятидесятые и шестидесятые годы, когда компьютеры только пробились в деловой мир. Эти руководители думали, что компьютеры «окажут огромное воздействие на способы ведения бизнеса», но Дрюкер говорит, что «произошло совсем не это. Очень немногие руководители задавали вопрос: "Какая информация мне требуется, чтобы выполнять эту работу?"» Цифровые машины дали руководителям небывалые объемы данных, но лишь немногие поинтересовались, подходят ли эти данные для управления корпорацией. Образ существования бизнеса менялся очень быстро, однако менеджмент при этом не менялся. Дрюкер атакует наши устаревшие бухгалтерские системы, рожденные в эпоху меркантилизма, повзрослевшие в век пара и стали и угасающие на пороге XXI века, эры информации. Дрюкер утверждает: «Самая нужная вам информация – информация об окружающем мире, и этой информации у вас нет».

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

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

В индустриальную эру, до появления программ, продукты создавались из реальных материалов – из атомов. Затраты на добычу, плавку, приобретение, транспортировку, нагрев, формовку, сварку, окраску и снова транспортировку преобладали над всеми прочими расходами. В бухгалтерском учете эти расходы называются «переменными», поскольку они различны для каждого созданного продукта. «Фиксированные расходы», как вы, наверное, догадываетесь, очевидным образом не варьируются и включают такие затраты, как корпоративное администрирование или начальная стоимость завода.

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

Сегодня наиболее нужные и дорогие продукты состоят (полностью или почти полностью) из программного обеспечения. Они не требуют сырья. У них нет стоимости производства. Они не требуют затрат на транспортировку. Не требуют литья, обработки, покраски. Вот она, реальная разница между экономикой индустриальной эры и экономикой эры информационной: в информационную эру отсутствуют или невелики переменные затраты, тогда как в позднюю индустриальную эру именно эти затраты были главным фактором. Действительно, именно отсутствие переменных затрат делает новую экономику новой.

Зарплата программистов в вашем штате – фиксированные затраты или переменные? Один час работы программистов нельзя связать с одной продажей продукта – один и тот же код можно продавать много раз. Вложение в программирование можно амортизировать продажей миллионов копий продукта – точно так же, как продажа продуктов, созданных на заводе, амортизирует вложения в этот завод.

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

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

Программисты создают приложения, а руководящие работники создают потоки прибылей и структурные подразделения. Программисты оценивают свой успех по качеству продукта, а руководящие работники – по прибыльности вложений. Эту прибыльность они оценивают на языке математических терминов, позволяющем учитывать фиксированные затраты, переменные издержки, затраты на корпоративное администрирование, исследования и разработку, но, к сожалению, не описывающем подходящие модели для программ и программирования. Бухучет – основной язык бизнеса, и перечисленные категории настолько фундаментальны для всех измерений и коммуникаций в бизнесе, что современные руководители полностью их усвоили. Программирование для них – еще одна статья корпоративных расходов, которую следует причислить к одной из существующих категорий. На практике большинство руководителей расценивают программирование как производственный процесс, имеющий переменные издержки. (Для целей налогообложения в большинстве компаний, создающих программные продукты, программирование проходит по статье исследований и разработок, но во всех остальных отношениях расценивается как деятельность с переменными издержками.) Это худший выбор из всех существующих, поскольку он наносит серьезный ущерб возможности принимать эффективные решения, связанные с бизнесом.

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

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

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

Более того, единственный возможный источник экономического подъема – это повышение качества и, как следствие, привлекательности продукта или услуги, а повышения качества невозможно добиться, сокращая затраты на проектирование и программирование. Правда в том, что в исследования, анализ, планирование и проектирование следует вкладывать больше времени и денег, чтобы полученный результат лучше соответствовал потребностям покупателей.

Разумеется, такой подход требует мышления, с которым не знакомы деловые люди XXI века. Им следует не снижать затраты на создание каждого объекта в отдельности, но повышать затраты на создание всех объектов в совокупности. Это сущность новой экономики, и именно об этом говорил Питер Дрюкер.

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

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

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

К сожалению, в большинстве руководителей живет практически непобедимое стремление сокращать вложения времени и денег в программирование. Они ошибочно считают устаревшую тактику сокращения издержек подходящей и не понимают, что сокращение инвестиций в программирование оказывает сильное негативное влияние на качество, привлекательность и прибыльность продукта в долгосрочной перспективе. Разумеется, простым повышением затрат не добиться улучшений, а часто ситуация и ухудшается, если дополнительные деньги вливаются в обход мудрости, анализа, правильного руководства. Мой первый наставник, Дэн Хоакин (Dan Joaquin), любил повторять, что правильный обратный вариант старой истины «получаешь то, за что платишь» звучит так: «не получаешь того, за что не платишь». Действия без планирования всегда чреваты риском потратить слишком много. Фокус в том, чтобы потратить нужное количество денег, и он требует значительных познаний в управлении созданием программного обеспечения. Он требует также и процессов, обеспечивающих руководителей пониманием и информацией для принятия верных решений. Дать компаниям такие процессы – цель этой книги.

В буме доткомов участвовали компании с бизнес-моделями, полностью ориентированными на снижение переменных затрат. Хотя многие доткомы рекламировали преимущества покупок через Интернет, их сайты, тяжеловесные и неудобные, выглядели бледно по сравнению с обычной поездкой в торговый комплекс. Основатели доткомов просто лучились от восторга (и пресса, кстати, тоже), потому что им удалось создать предприятия розничной торговли с невероятно низкими переменными затратами. Феерический провал этих предприятий, несомненно, доказывает, что информационной эрой правят иные экономические правила.

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

Компания Pets.com, специализирующаяся на продаже корма для собак через Интернет, не предлагала более качественный корм, как не предлагала и шоппинг, более приятный, чем в обычном местном магазине; она не предлагала новую информацию, новые возможности, новую уверенность. Она предлагала лишь дешевую доставку, складирование и торговлю (все это переменные затраты) на сайте Pets.com. Компания применила классическую тактику снижения затрат, присущую экономике индустриальной эры, полностью игнорируя фундаментальные принципы новой экономики. Конечно, это было еще не первое дыхание новой экономики, но для старой это было последнее издыхание. Я совершенно убежден, что любой товар можно продавать через Интернет успешно и прибыльно. Фокус в том, чтобы в онлайновом магазине было бы ощутимо приятнее покупать, чем в конкурирующих розничных сетях, и цена здесь – всего лишь одна из составляющих. Есть лишь один способ добиться этого: архитектуру системы следует создавать с целью максимально удовлетворить конечного пользователя. Отношение к любому аспекту проектирования и создания программного обеспечения, как к производственному процессу, служит причиной провала. Проектирование и программирование – попросту неподходящие цели для традиционных методов сокращения издержек. Конечно, можно потратить на создание программ слишком много времени и денег, но опасность потратить меньше необходимого гораздо серьезнее.

Скорее всего, эта опасность вам знакома и удивления не вызывает, но для большинства высокопоставленных руководителей крупных компаний немыслима сама идея. Эти руководители до сих пор работают по моделям бухгалтерского учета, вошедшим в моду в эпоху паровых машин, тогда как все аспекты жизни их компаний – функционирование, принятие решений, коммуникации и финансы – полностью зависимы от программного обеспечения. Термины и понятия, которыми оперируют эти руководители, просто не принимают во внимание уникальную природу бизнеса в эпоху, когда инструменты и продукты коммерческой деятельности являют собой неосязаемые переплетения битов вместо вагонов с железом. Отмечу, впрочем, что куклы из носков – идея классная.

Корпорации уже нанимают проектировщиков взаимодействия и начали применять целеориентированный подход, однако качество программных продуктов не слишком улучшилось. Более того, высокие затраты на программирование и неподатливость процесса создания программ остаются на своих местах. Почему?

Перемены невозможны, пока администраторы компаний не осознают, что проблемы с программами – это не технические сложности, а значимые для бизнеса вопросы. Наши проблемы останутся неразрешенными до тех пор, пока мы не изменим процесс и организацию.

Компании живут не только по устаревшим финансовым моделям, но еще и по негодной организационной модели. Эта модель – копия той, что имеет хождение в учебных заведениях, в ней создание программы смешивается с планированием и решением инженерных задач. Такова природа исследований. Прискорбно, что эта парадигма без объявления войны была перенесена в неизменном виде в мир бизнеса, где ей не место.

Корни всех современных производственных дисциплин уходят в доиндустриальные времена. Всех, кроме дисциплины программного обеспечения, которая возникла, когда индустриализация уже закончилась. Только программирование произошло сразу из учебных заведений, где время исследований не ограничивалось, студенческой рабочей силы было хоть отбавляй, о прибылях вообще не говорили, а неработающая программа могла сойти за весьма удачный эксперимент. Неслучаен тот факт, что Microsoft, IBM, Oracle и другие ведущие компании-производители ПО расположены в «кампусах». Университетам не нужны прибыли, они не стараются успеть вовремя создать привлекательные и полезные продукты.

Любой бизнес, не связанный с программным обеспечением, начинается с исследований и заканчивается распространением продуктов или предложением услуг. Компания тщательно планирует время между этими двумя событиями, осознавая, что преждевременный выпуск непродуманного продукта опасен как для банковского счета, так и для ее репутации. Руководители знают, что время, размышления и деньги, вложенные в планирование, обернутся крупными дивидендами – гладким и быстрым процессом производства, популярностью и прибыльностью конечных продуктов.

Во всех других конструкторских дисциплинах инженеры создают стратегию, а ремесленники претворяют ее в жизнь. Инженеры не занимаются строительством мостов, этим занимаются другие специалисты. Только в области программного обеспечения перед инженером ставится задача создать собственно продукт. Только в области программного обеспечения перед «строителем мостов» ставится задача определить, как следует создавать продукт. Только в области программного обеспечения эти две задачи решаются не последовательно, а одновременно. Однако компании, создающие программы, похоже, не осознают существования такой аномалии. Инженерное дело и конструкторское дело так плотно пересекаются, что специалисты и руководители их не разделяют и, вероятно, не различают. Планированием любого рода здесь пренебрегают или откладывают его до тех пор, пока не станет слишком поздно. Считается нормальным откладывать решение очень сложных инженерных проблем до момента, когда уже экономически слишком накладно откатываться к фазе проектирования, потому что полным ходом пишется код для коммерческой версии продукта.

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

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

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

За последние тринадцать лет фирма Cooper выступала в роли консультанта сотен компаний. Мои талантливые проектировщики создали для большинства клиентов «чертежи» продуктов, позволяющие коренным образом изменить ситуацию, но лишь немногие сумели воспользоваться всеми полученными преимуществами. В большинстве этих компаний проектирование взаимодействия и архитектуру программ считают лишь советом, в этих компаниях последнее слово всегда остается за программистами и инженерами. Ни один из президентов в этих компаниях не имеет ни малейшего понятия о том, что происходит в боксах инженеров, и потому расписание ужимается безо всякой причины. Программисты постоянно работают в условиях дефицита ресурсов и, прежде всего – времени на хорошее программирование, а также времени, чтобы определить, где вообще требуется программирование. Они вынуждены защищаться, отвергая советы, и изворачиваться, общаясь со своими менеджерами.

На мой взгляд, существует два типа руководителей: инженеры и запуганные инженерами. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно испорчена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у деловых людей и программистов нет общих инструментов и общих целей. Человек разумный делегирует человеческие проблемы хомо логикус, не осознавая, что решение могло бы оказаться намного более приятным в случае применения – на исполнительном уровне – уместных финансовых и организационных моделей.

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

Алан Купер,

Пало, Альто, Калифорния

www.cooper.com

[e-mail]

Часть I

Компьютерная безграмотность

Глава 1

Загадки века информации

В декабре 1995 года рейс 965 компании American Airlines вылетел по регулярному маршруту из Майами в Кали, Колумбия. На подлете к посадочной полосе пилоту Боинга-757 потребовалось выбрать следующий радиомаяк по имени «ROZO». Он набрал букву «R» в своем навигационном компьютере. Компьютер отобразил перечень ближайших радиомаяков с именами на «R», а пилот выбрал первую позицию в списке, потому что широта и долгота показались ему верными. К несчастью, вместо «ROZO» пилот выбрал маяк «ROMEO», расположенный в 210 километрах к северо-востоку. Самолет направлялся на юг и находился в тот момент в долине, пролегающей с юга на север, так что любое отклонение от курса было опасно. Следуя показаниям полетного компьютера, пилоты начали корректировать курс к востоку, и самолет врезался в гранитный пик на высоте трех километров. Сто пятьдесят два пассажира и восемь членов экипажа погибли. Четыре пассажира выжили, получив серьезные травмы. Национальная комиссия по безопасности транспорта провела расследование и – как обычно – заявила, что причиной явился человеческий фактор. Вспомогательное навигационное средство, показаниями которого руководствовались пилоты, выдало корректную информацию, но не для посадки в Кали. Человеческий фактор, если следовать буквальному смыслу фразы, действительно был причиной – ведь именно пилот выбрал неправильный маяк. Однако если взглянуть на ситуацию в целом, вины пилота здесь не было.

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

* * *

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

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