Компьютеры и люди

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

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

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

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

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

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

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

Обучаем собак кошачьим повадкам

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

Каждому разработчику программного обеспечения свойственно считать себя особенным, единственным, кто способен выполнить обе задачи сразу. На самом деле это далеко не так, и печальная судьба General Magic ясно иллюстрирует это. Отдел разработки в General Magic возглавляли Билл Аткинсон и Энди Херцфельд. Оба они когда-то были ведущими разработчиками программного обеспечения для Apple Macintosh и, бесспорно, значительно превосходили многих программистов по уровню своего таланта, креативности и изобретательности. Их совместная работа над проектированием и программированием Macintosh привела к успеху в 1984 году (хотя Джеф Раскин, не участвовавший в программировании, также внес значительный вклад в проектирование). Тем не менее спустя 14 лет после их успеха мир уже не был прежним, и их методы работы уже не подходили. В начале 1993 года я взял интервью у Энди Херцфельда в головном офисе разработки General Magic, который располагался в гостиной дома Энди в Пало-Альто, – тогда он и поведал мне философию его взгляда на проектирование и программирование. Я слушал с удивлением, осознавая, как мала вероятность успеха этой теории. Однако история дала второй шанс проявиться выдающемуся таланту Энди.

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

Из статьи Мишель Куин о General Magic видно, что сложившийся в отрасли образ мышления попросту пренебрегает очевидными выводами. Автор статьи склоняется в пользу того, чтобы возложить вину за провал продукта на высокомерие и эгоизм Пората, только в Кремниевой долине не найти президента компании, которому не были бы присущи эти качества в непомерном количестве. Высокомерие и эгоизм уж точно не могут привести к провалу компании.

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

* * *

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

Многие программисты склонны считать себя талантливыми проектировщиками. На самом деле обычно действительно так оно и есть, однако существует превеликая разница между тем, что называется «проектирование для функционирования» и «проектирование для людей».

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

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

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

* * *

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

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

* * *

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

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

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

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

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

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

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

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

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