Файл: Алан Купер Психбольница в руках пациентов.pdf

144 встречаем, существуют лишь потому, что уже существовали ранее.
К примеру, приложения для настольных компьютеров содержат так много меню и текстовых диалоговых окон потому, что все оконные системы Мiсrоsоft Windows, Мас
OS, OS/2, Solaris - предоставляют готовые модули кода, обеспечивающие работу таких функций. И наоборот, ни одна из этих систем не содержит большого количества кода для механизмов drag-and-drop; вот почему в приложениях так мало непосредственного манипулирования (direct manipulation). Диалог можно создать при помощи шести-восьми строк простого декларативного кода. Идиома drag-and-drop требует примерно сотни строк весьма запутанного процедурного кода. Выбор программиста здесь очевиден.
Выгоды конечного пользователя в контексте такой экономии обычно не рассматриваются.
История с мексиканским строителем все время повторяется в разработке программного обеспечения, в основном благодаря стремлению программистов повторно использовать код. Эд Форман (Ed Forman), руководящий разработкой ПО в Elemental
Software, прежде чем загрузить программистов работой, создает подробный и точный набросок внешнего вида экрана. Несмотря на это, говорит Эд, экран готовой программы являет собой лишь бледную тень этого эскиза.
Происходит это следующим образом. Набросок Эда содержит темно-серые кнопки на светло-сером фоне. Программист начинает создание интерфейса с копирования исходных текстов из другой, уже работающей части программы. Это хороший способ сэкономить время и силы в программировании, способ, очевидно, полезный для всех.
Минус в том, что существующий код обрамляет кнопки дополнительной темно-серой линией. Кроме того, к темно-серой рамке крепится еще и текстовая подсказка. Вместо того чтобы удалить текст и рамку в соответствии с наброском Эда, программист оставляет их, сохраняя множество строк кода. Код требует какой-то текстовой подсказки для каждой кнопки, поэтому программист вбивает некий подходящий, в его понимании, текст.
Увидев, наконец, программу с ненужными рамками и невнятными текстовыми подсказками, Эд изумленно качает головой. Когда он указывает на отличия программисту, тот просто не может понять, в чем проблема. Подобно мексиканскому строителю, программисты полагают, что их собственные императивы простоты создания и простоты комплектования готовым кодом имеют более высокий приоритет, чем чьи бы

145 то ни было предложения.
Эда такое явление не только изумляет, но и раздражает, однако он не способен объяснить его. Его программисты, как один, сообразительны, способны, глубоко озабочены качеством продуктов и успехом компании, однако не могут устоять перед зовом сладкоголосых сирен. Разумеется, они постараются воплотить в жизнь задумки
Эда, но не за счет собственных принципов реализации.
* * *
Привычка программистов повторно использовать код интересна их готовностью иметь дело с кодом сомнительного происхождения. Некоторые неопытные программисты начинают с черновых набросков первой попавшейся на глаза идеи, и этот фрагмент кода, будучи созданным, становится основой всех последующих усилий по разработке благодаря интенсивному повторному использованию.
Для примера: ядро операционной системы Windows создавали очень опытные программисты, а вот первые приложения, показывающие приемы взаимодействия программы с пользователем, были написаны практикантами и начинающими программистами той же Мicrosoft. Внутренний код Windows совершенствовался и переписывался, постепенно улучшаясь. При этом возмутительно большое количество популярных приложений до сих пор содержит длинные фрагменты кода, написанные двадцатилетними студентами, проводившими лето в Редмонде. То же верно и для
Всемирной - паутины. Экспериментаторы-дилетанты сварганили первые веб-сайты, а их последователи просто соорудили клоны этих первых сайтов, а их собственные сайты снова клонировали другие люди.
Как видите, существует явный конфликт интересов программистов и пользователей.
Предвидя конфликты интересов в бесчисленных областях деятельности и профессиях, мы встраиваем защитные механизмы, ограничивающие влияние конфликта. Судьи и адвокаты имеют общие навыки, однако мы никогда не позволяем адвокатам выносить решения по делам. Мы никогда не позволяем баскетболистам судить собственные встречи. И вот налицо еще один конфликт интересов, однако, мы последовательно позволяем программистам принимать архитектурные решении, основанные на их личных предпочтениях.
В индустрии программного обеспечения и корпоративных компьютерных отделах широко распространено мнение, что именно программисты лучше всего подходят для

146 проектирования программ, ведь они в этой области специалисты, обладающие наиболее глубокими познаниями в соответствующих вопросах. Кажется, вполне безобидным и естественным позволить программистам определять форму и поведение создаваемых ими программ, однако выбравшему этот путь не избежать ловушки конфликта интересов. Коварство этой ловушки не в различиях между программистом и пользователем, но в их сходстве. Пользователь желает достичь своих целей, а программист - своих. Проблема кроется в тонких различиях между этими целями.
* * *
Программисты настолько свыклись с повторным использованием кода, что часто копируют существующие методы, даже не копируя отдельные строки кода. Это происходит естественным образом, усугубляясь склонностью про грамм истов к консерватизму. К примеру, большинство программ содержит многочисленные диалоги подтверждений, в основном ненужные. Многие из этих диалогов просто перекочевали из созданного ранее кода, но многие остались потому, что программисты привыкли включать их в код.
Недавно на конференции я встретил Джеффа Безоса (Jeff Bezos), основателя
Aтazon.coт, и рассказал ему, как мне нравится интерфейс «в один щелчок» (1-Click) на его веб-сайте. Этот интерфейс позволяет посетителю заказать книгу - большой сюрприз - в один щелчок. Интерфейс действительно хорош, поскольку избавляет посетителя от докучающих деталей можно просто, нажать кнопку и не указывать повторно адрес и информацию по оплате.
Джеффри было приятно слышать, что мне понравился 1-Click, и он рассказал, что разработал идею со своими проектировщиками, после чего идею показали программистам. Те, разумеется, покивали и согласились, что задача решаема.
Программисты удалились, и какое-то время писали код, а затем показали результаты
Джеффу. Он нашел желаемую книгу и нажал кнопку 1-Сlick. И тут программа отобразила сообщение, требующее подтверждения! Программисты превратили интерфейс «в один щелчок» в интерфейс «в два щелчка». Для программистов это был лишь один дополнительный щелчок (делов-то?). Для Джеффа, как и для любого пользователя, это все равно что стопроцентный рост инфляции. Джеффу пришлось действовать кнутом и пряником, прежде чем программисты создали интерфейс 1-Click, позволяющий делать заказ в один щелчок. Джефф не скажет мне, насколько l-Click

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

148 подготовкой, нетипичной индивидуальностью и нетипичными склонностями.
Это подчеркивает другой ключевой аспект культуры разработки программного обеспечения. Эта культура, построенная на особенной природе программистов, получает поддержку со стороны руководителей, многие из которых, что скрывать, - бывшие программисты. Джефф Безос говорит, что самый громкий голос в защиту интерфейса 2-
Click (в два щелчка) принадлежал менеджеру этого продукта!
Преклонение перед технической квалификацией имеет и другой эффект.
Большинство людей считают, что программирование - задача более техническая, чем проектирование взаимодействия. С этим спорить не буду, однако возражаю против заключения, которое обычно делается на основе этого утверждения: что программирование должно предшествовать проектированию взаимодействия в процессе разработки. Ведь в этом случае пользователь вынужден адаптироваться под технологию.
Если же проектирование взаимодействия предшествует программированию, технология будет соответствовать целям пользователя. Мне приходилось слышать от руководителей этой индустрии фразы вроде: «Мы включим в процесс проектировщиков после того, как программисты закончат работу над функциональностью». Такой подход ведет к катастрофическому снижению шансов проектировщика взаимодействия внести свою лепту.
Культура программирования в Мicrоsоft
Трудно переоценить роль и значение культуры разработки программного обеспечения. Изучая эту, наиболее типичную компанию, занимающуюся разработкой
ПО, Фред Муди (Fred Moody) в своей книге «I Sing the Body Electronic»
1
(Электронное тело пою) показывает, насколько глубоко укоренилась в индустрии программирования культура нердов. Этот писатель и журналист, пишущий на околокомпьютерные темы, провел год в стенах Microsoft, наблюдая за созданием нового мультимедийного продукта, названного в итоге «Explorapedia». Муди получил свободный доступ в
Microsoft, и его книга рисует откровенную картину жизни и культуры ведущей компании индустрии. Если вы не поняли этого по продуктам Microsoft, то эта фирма глубоко чтит программирование, но не осознает или почти не осознает потребность в проектировании взаимодействия. Эта книга содержит захватывающее исследование процессов,
1
Fred Moody «I Sing the Body Electronic», 1995, Viking, New York.

149 происходящих в культуре программирования.
Во вступлении Муди готовит почву:
В Мiсrоsоft корпоративная структура формируется из небольших команд, работающих над конкретными продуктами. Команды самостоятельно определяют свою внутреннюю иерархию и сами организуют работу. Это рискованный подход, ведь степень неконтролируемости таких коллективов немыслима в обычных американских корпорациях.
Мiсrоsоft известна тем, что нанимает очень одаренных и очень напористых молодых людей чуть ли не со школьной скамьи. Муди пишет: «Было такое ощущение, что банда подростков проскользнула в штаб квартир у какой-то корпорации после окончания рабочего дня и забралась в зал заседаний совета директоров, чтобы поиграть в бизнес».
Мiсrоsоft известна и тем, что нещадно эксплуатирует эти молодые таланты, чтобы получить от них как можно больше. Муди пишет: «В кампусе всегда очень беспокойно, и там постоянно импровизируют».
Эта книга - замечательный рассказ о том, насколько часто методы разработки в
Мiсrоsоft произвольны, непрофессиональны и какое морально разлагающее действие они оказывают. Муди и сам был озадачен увиденным, но не сомневался, что увидел нечто важное. А увидел он, что всем здесь заправляют программисты. И даже если не делают этого явно, то делают это опосредованно, силой своей воли. Муди ни в единой букве не подвергает сомнению собственное и общественное мнение, что программистам и
следует быть у руля, однако отмечает трение, разногласия, неприятные эмоции и ощущение провала, характерные для такой ситуации. Вот что он пишет:
Не могу сказать, что хорошо понимаю, что происходит в Мicrosoft. Грустная действительность такова, что покинул я кампус в большем замешательстве, чем когда прибыл туда. Оглядываясь на уже написанные страницы, я прихожу в еще большее недоумение и все еще не в состоянии определить, что за история рассказывается на них - история успеха, или же история поражения, или история успеха, замаскированная под историю поражения, а быть может, история поражения, замаскированная под историю успеха.
Разумеется, Фред стал свидетелем создания танцующего медведя - продукта, безотрадно сложного в применении, единственным достоинством которого стали возможности, не существующие где-либо еще.

150
Проект Explorapedia - классический пример деградации типичного процесса разработки. Ни минуты не сомневаюсь, что продукт стал провалом. Муди же смутило то, что продукт был сдан вовремя и принес прибыль. На последних страницах книги, озаглавленных автором «Postmortem», он пишет:
До первого контакта с Мiсrоsоft мне и в голову не приходило, что я могу стать летописцем провального проекта. И все же, практически с самого начала и до конца моего пребывания в компании, я считал, что являюсь свидетелем предметного урока в том, как не следует создавать продукт. Все, кто имел отношение к проекту Explorapedia, были настолько несчастны и злы, непрестанно говорили о раздражении разочаровании, что какой еще вывод я мог сделать, как не тот, что волею судьбы становлюсь свидетелем катастрофы? Однако проект несомненной победой.
Удивительно? В следующем предложении какие-то два слова отделяют Муди от термина «танцующий медведь», он пишет: «Каждая из возможностей Explorapedia в отдельности - лишь бледная пародия на изначальный замысел... и, тем не менее, эта энциклопедия стала на рынке единственным продуктом в своем роде». Легко победить, не имея конкурентов обладая поддержкой приводящего в трепет брэнда Microsoft, ее связей чудовищных размеров банковского счета.
Слабость продукта - фактор, превосходящий по губительности все прочие. Ближе к концу книги автор цитирует участницу проектирования Сару Фокс (Sara Fox), которая смотрит на
...книгу издательства Dorling Кindersley, положенную в основу Explorapedia. Она шокирована тем, что книга предоставляет читателям больше свободы в изучении, чем компьютер. Ведь компьютер, предполагалось, станет великой силой, освобождающей от ограничений печатной книги. В книге, указала она, текст свободно окаймлял изображения, и читатели имели возможность листать страницы в свое удовольствие, окидывая взглядом огромные объемы информации. Ехplorapedia же принуждает их рыться в пронумерованных всплывающих окошках, каждое из которых содержит лишь несколько предложений. Это был отвратительный парадокс: компьютер имел ограничений больше, чем книга. «Dorling Кindersley сделало противоположное, тому, что делали мы, а мы превратились в посредников».
В Microsoft самые важные проекты задумываются, управляются, реализуются программистами. Проект мультимедийного компакт-диска, описанный в книге Муди,

151 был в некотором роде исключением, потому проектировщики вовлекались в него на каждом шаге. Однако они никоим образом не проявили умения, которые я считаю обязательными для роли проектировщика взаимодействия. Казалось, они совершенно имеют представления о важных для проектировщика взаимодействия вещах: не понимают до конца, что в действительности делают программисты, не понимают принципы и методы процесса проектирования взаимодействия, не знают состава пользователей продукта и не понимают этих пользователей. Муди ясно показывает, что единственные таланты проектировщиков Microsoft заключались в сообразительности, безграничной энергии и чувстве прекрасного.
Таким образом, Муди и мог увидеть только дисфункциональную модель. «Задание проектировщиков состояло в том, чтобы напридумывать как можно больше возможностей, разработчики сопротивлялись во имя сроков сдачи, а работа менеджера продукта заключалась в медитациях и выдаче вердиктов». Любые антагонистические отношения, подобные описанным, обязательно приводят к тяжелым последствиям.
Страдают люди, продукт или же компания.
Сотрудники Microsoft, работавшие над проектом, остались столь же непросвещенными, как Муди. Кевин Геммил (Kevin Gammill), ведущий программист:
Кэролин постоянно называет это Адским проектом, а Крэйг не перестает повторять, что никогда еще ему не приходилось проходить через подобное. Но Крэйг также не перестает повторять, что мы совершили эту ошибку и еще вот эту ошибку, а еще вон ту ошибку с энциклопедией Encarta, и вот сейчас снова ее совершаем. А Сара твердит, что
«жизненный цикл продукта такой... цикличный». Здесь каждый проект такой! Мы повторяем, что учимся на своих ошибках... однако снова и снова проходим через ту же
[непечатное слово].
Эти неформальные портреты от Геммила захватывают не меньше, чем железнодорожная катастрофа. Читатель, не знакомый с индустрией программного обеспечения, может испытать соблазн списать изложенное на гиперболы или обвинить
Муди в выборе нетипичного человека из этой культуры. Однако Геммил - архетип, поэтому его поведение весьма типично. Я встречал сотни мужчин и несколько женщин в точности таких, как он.
Членам той команды было нелегко говорить с Геммилом даже в относительно нормальной ситуации. Между разработчиками и дизайнерами в Мiсrоsоft пролегала

152 гигантская культурная пропасть. Разработчик часто не мог заставить дизайнера понять простейшие элементы проблемы программирования. Так же часто дизайнеры неделями трудились над каким-то аспектом продукта лишь для того, чтобы, показав результат разработчику, получить грубый ответ, что реализация задуманного невозможна.
В последние годы ситуация несколько улучшилась, но эти два лагеря буквально говорили на разных языках, рассматривая мир компьютеров с противоположных интеллектуальных, культурных, психологических и эстетических полюсов. Дизайнеры приходили в Мiсrоsоft из гуманитарных дисциплин; разработчики - из мира математики и науки. Разработчики смотрели на дизайнеров сверху вниз, поскольку считали их мышление нечетким и неструктурированным, а вкусы непостоянными. Дизайнерам казалось, что разработчики лишены воображения, консервативны, склонны отвергать предложения по дизайну сразу же, не пытаясь найти способ претворить их в жизнь.
Поскольку программирование оставалось для разработчиков необъяснимым таинством, они не имели возможности оценить весомость доводов разработчиков о том, что нарисованное невозможно реализовать. «Дизайнеры, - любил говаривать Том Корддри, - это непременно женщины, они болтливые, живут в мансардах, сидят на вегетарианских диетах и носят в ушах найденные предметы. Разработчики - обязательно мужчины, питаются приготовленным на скорую руку и произносят только одно слово: «Неверно».
Он мог бы еще добавить, что дизайнеры и разработчики разрешают конфликты различным образом. Когда разработчики, склонные к вспышкам озорных игр, начинают осыпать дверь кабинета дизайнера шариками из детского помпового ружья, жертва жалуется вышестоящему начальству. Разработчик же сам открывает ответную стрельбу.
Я хочу подчеркнуть, что Мiсrоsоft и Муди говорят «дизайнер» там, где я употребляю слово «графический дизайнер». Графический дизайнер обладает развитым чувством прекрасного, мыслит зрительными образами, умеет делать наброски или рисовать. Такой человек участвует в каждом, без исключения, нашем предприятии по проектированию. Однако дизайнеры вносят свою магию в наши работы лишь после того, как подготовленные проектировщики взаимодействия завершат основную работу по концептуальному и поведенческому проектированию.
Кстати сказать, сварливое «неверно», цитируемое Корддри, - хорошая иллюстрация к фразе По Бронсона: «Не я ответил неправильно, вы задали не тот вопрос».
Муди очень хорошо осознавал уникальные культурные отличия программистов и