Алан Купер

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

Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие

Посвящается Сью, Скотт и Мери с любовью
Отзывы на книгу Алана Купера

От этого становится не по себе, но это правда. Персональные компьютеры породили новую взаимозависимость Новой Эры. Они позорят нас, раздражают нас, но мы продолжаем тратить на них деньги. Книга Алана Купера объясняет, почему все должно быть не так и что мы можем сделать для исправления ситуации. Чтение доставляет удовольствие и помогает спуститься с небес на землю.

- Жан-Луи Гассе, президент Be, Inc.



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

- ДонНорман, Nielsen Norman Group; автор книги «The Invisible Computer»



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

- Питер Хиршберг, президент Elemental Software



Подход к проектированию, предлагаемый Купером, быстро завоевывает последователей, среди которых и такие клиенты, как Sun Microsystems, Coca-Cola, Compaq и Dow Jones.

- Fast Company Magazine



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

- Карен Ивенсон, руководитель инженерных разработок Sony Trans Com



Браво! Живой и проникновенный трактат о проектировании взаимодействия от того, кто стоит у истоков. Раздавайте экземпляры друзьям, коллегам, своим клиентам. Об этой книге обязательно будут говорить, а возможно, и спорить.

- Клемент Мок, основатель Archetype Studio, креативный директор Sapient



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

- Джефф Хадфилд, главный редактор Visual Basic Programmer\'s Journal



Мы находимся под сильным впечатлением от энтузиазма, профессионализма и методов работы нескольких команд Cooper Interaction Design, сотрудничающих с нами над перепроектированием центральных модулей R/3.

- Маттиас Беринг, руководитель программы, SAP



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

- Терри Виноград, профессор информатики Стэнфордского университета



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

- Ларри Кили, президент Doblin Group



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

- Хайди Ройзен, Be, Inc.



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

- Пол Саффо, директор Института Будущего

Об авторе

По мнению Митча Уэйта, основателя Waite Group Press, Алан Купер – «Отец Visual Basic». Перу Алана Купера принадлежит книга «About Face: The Essentials of User Interface Design» (IDG Books, 1995). В 1994 году Билл Гейтс представил Алана к редкой и желанной награде Windows Pioneer Award, признав, что его вклад в изобретение Visual Basic способствовал успеху системы Microsoft Windows. В 1998 году Алан был представлен к награде Software Visionary Award. Сегодня он возглавляет Cooper Interaction Design, консультирующую фирму, которая выполняла работы по проектированию продуктов для таких компаний, как 3М, Elemental, Ericsson, Fujitsu, IBM, Logitech, McGraw-Hill, Sagent, SAP, Sony, Varian, VISA и Sun Microsystems.

Алан открыто выступает в защиту тех, о ком забывают в процессе разработки электронных продуктов, – покупателей.

В течение двадцати лет Алан Купер проектировал и создавал потребительские программные продукты, среди которых SuperProject, MicroPhone II для Windows, а также интерфейс визуального программирования для Visual Basic. В 1976 году Купер основал компанию Structured Systems Group Inc., которая, как сказано в книге «Fire In the Valley» (Пожар в Кремниевой Долине), выпустила «возможно, первое серьезное бизнес-приложение для микрокомпьютеров».

Купер состоит в организациях Corporate Design Foundation и American Center for Design. Он бывший директор калифорнийского отделения ассоциации проектирования программного обеспечения (Association for Software Design), а также член совета директоров этой организации. Купер – директор Software Design и Software Forum, а также основатель SEF Windows SIG, крупнейшей в мире группы разработчиков для Windows. Он часто и уверенно выступает как делегат индустрии и пишет о пользовательском интерфейсе и концептуальном проектировании программных продуктов.

Благодарности

Я не смог бы написать эту книгу без помощи и участия многих замечательных друзей и коллег. В частности, несколько человек выполнили трудную и кропотливую работу – прочитали и прокомментировали рукопись, иногда по несколько раз. Их комментарии вынуждали меня отвечать на сложные вопросы, предлагать читателю новые темы, резюмировать свои соображения, умиротворяли мой пыл, усмиряли мое дикое негодование. Эта книга стала гораздо лучше благодаря вкладу Ким Гудвин (Kim Goodwin), Лейн Хэлли (Lane Halley), Келли Боумен (Kelly Bowman), Скотта Мак-Грегора (Scott McGregor), Дэвида Уеста (David West), Майка Нельсона (Mike Nelson), Марка Джирска (Mark Dziersk), Алана Карпа (Alan Karp), Терри Суок (Terry Swack), Луи Вейцмана (Louie Weitzman), Уэйна Гринвуда (Wayne Greenwood), Райана Ольшавски (Ryan Olshavsky), Джона Майера (John Meyer), Лайзы Сондерс (Lisa Saunders), Винни Шоуз (Winnie Shows), Кевина Вандрайка (Kevin Wandryk), Глена Халстеда (Glenn Halstead), Брайана О\'Салливана (Bryan O\'Sullivan), Чака Оуэна (Chuck Owen), Майка Суэйни (Mike Swaine), а также Скипа Уолтера (Skip Walter). Спасибо вам за время, участие и мудрость. Особенно ценными для меня в плане кристаллизации тем книги стали комментарии и советы Джонатана Кормана (Jonathan Korman). Я должен также поблагодарить всех талантливых и усердных сотрудников CID1, которые делали за меня мою работу, пока я был занят книгой. Особой благодарности заслуживает Уэйн Гринвуд (Wayne Greenwood), который замечательно работал под жестким прессингом, сохраняя наш боевой дух и высокое качество наших проектов.

Создание иллюстраций стало одной из наиболее интересных задач. Чед Кубо (Chad Kubo), мастер изобразительного искусства, проделал замечательную работу – превратил мои расплывчатые идеи в четкие, запоминающиеся образы. Они многое привнесли в книгу. И эти иллюстрации никогда не появились бы без неутомимого художественного руководства со стороны Пенни Бейлес (Penny Bayless) и Дэвида Хейла (David Hale). Были и другие люди, решавшие производственные задачи. Спасибо Брит Кацен (Brit Katzen) за изучение и перепроверку фактов, спасибо Майку Генри (Mike Henry) за литературное редактирование.





Создание книги – это деловое предприятие, и за то, что оно стало успешным, я должен поблагодарить команду сведущих в технологии предпринимателей, возглавляемую моим агентом, Джимом Левайном (Jim Levine), и включающую Глена Халстеда (Glenn Halstead), Линн Боумен (Lynne Bowman), Келли Боумен (Kelly Bowman), а также Сью Купер (Sue Cooper). Со стороны издательства Macmillan поддержку на протяжении всего проекта осуществлял Брэд Джоунс (Brad Jones), однако наибольшего внимания заслуживает Крис Вебб (Chris Webb), чья целеустремленность, сосредоточенность и тяжелый труд сделали возможным создание этой книги.

Я очень ценю людей, оказавших мне моральную поддержку, предоставивших реальные истории, советы и потративших свое время. Большое спасибо Дэниелу Эпллману (Daniel Appleman), Тодду Баше (Todd Basche), Крису Байеру (Chris Bauer), Джеффу Безо (Jeff Bezos), Элис Блэр (Alice Blair), Мишель Борк (Michel Bourque), По Бронсону (Ро Bronson), Стиву Калде (Steve Calde), Дэвиду Карлику (David Carlick), Джеффу Карлику (Jeff Carlick), Кэрол Кристи (Carol Christie), Клэй Коллье (Clay Collier), Кендаллу Косби (Kendall Cosby), Дэну Крэйну (Dan Crane), Роберту Крингели (Robert X. Cringely), Трою Дэниелсу (Troy Daniels), Лайзе Пауэрс (Lisa Powers), Филипу Энглхарту (Philip Englehardt), Карен Ивенсен (Karen Evensen), Риджели Эверс (Ridgely Evers), Ройял Фаррос (Royal Farros), Пэт Флек (Pat Fleck), Дэвиду Фору (David Fore), Эду Форману (Ed Forman), Эду Фридкину (Ed Fredkin), Жану-Луи Гассе (Jean-Louis Gassee), Джиму Гею (Jim Gay), Paccy Голдину (Russ Goldin), Владу Горелику (Vlad Gorelik), Марсии Грегори (Marcia Gregory), Гарренту Грюнеру (Garrett Gruener), Чаку Хартледжу (Chuck Hartledge), Теду Харвуду (Ted Harwood), Уиллу Хирсту (Will Hearst), Тамре Хитершоу-Харт (Tamra Heathershaw-Hart), ДжейДи Хильдебранду (JD Hildebrand), Лори Хиллз (Laurie Hills), Питеру Хиршбергу (Peter Hirshberg), Ларри Кили (Larry Keeley), Гэри Краткину (Gary Kratkin), Деборе Курата (Deborah Kurata), Тому Лефлеру (Tom Lafleur), Полу Лотону (Paul Laughton), Элен Леви (Ellen Levy), Стивену Листу (Steven List), ТиСи Мангану (ТС Mangan), Дэвиду Майстеру (David Maister), Роберту Мэю (Robert May), Дону Мак-Кини (Don McKinney), Кэтрин Медоуз (Kathryn Meadows), Лайзе Митчелл (Lisa Mitchell), Джеффри Муру (Geoffrey Moore), Брюсу Мовери (Bruce Mowery), Нату Майерсу (Nate Myers), Эду Нихаусу (Ed Niehaus), Констанс Петерсен (Constance Petersen), Кейту Плису (Keith Pleas), Роберту Райнману (Robert Reimann), Джону Ривлину (John Rivlin), Говарду Рейнгольду (Howard Rheingold), Гейди Ройцену (Heidi Roizen), Нилу Рубенкингу (Neil Rubenking), Полу Сафо (Paul Saffo), Джошу Зайдену (Josh Seiden), Paccy Зигельману (Russ Siegelman), Донне Слоут (Donna Slote), Линде Стоун (Linda Stone), Тони Уокеру (Toni Walker), Кевину Уиксу (Kevin Weeks), Кевину Уэлшу (Kevin Welch), Дэну Уиллису (Dan Willis), Хэзер Уинкль (Heather Winkle), Стефану Уайлдстрому (Stephen Wildstrom), Терри Винограду (Terry Winograd), Джону Цикеру (John Zicker) и Пьерлуиджи Заппакосте (Pierluigi Zappacosta).

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

Предисловие научного редактора

От своего лица благодарю издательство «Символ-Плюс» за выпуск этой в высшей степени актуальной книги.

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

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

Во-первых, дешевизна многих рабочих мест, например кассиров супермаркета или работников операторских центров (call-centres), снижает мотивацию работодателя, перестающего требовать от программных продуктов высоких эргономических характеристик. Часто работодатель нанимает несколько дополнительных сотрудников вместо того, чтобы вложить средства в повышение эффективности труда уже работающих.

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

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

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

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

Первое издание книги вышло пять лет назад (1999). С этого момента многие ведущие компании, например Microsoft, SAP, Oracle, взяли предлагаемые Купером методы на вооружение. Так, Microsoft использует персонажей при разработке Longhorn.

Я надеюсь, что российский рынок ИТ также услышит голос Алана Купера

Алексей Копылов,

ведущий специалист компании UIDesign Group,

разрабатывающей пользовательские интерфейсы

Предисловие

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

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

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

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

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

Пол Саффо (Paul Saffo),

директор Института Будущего

Введение

Книга-обоснование

Я собирался написать совсем другую книгу – книгу-руководство о процессе проектирования взаимодействия. В мае 1997 года во время поездки в Тоскану двое моих друзей, Дон Мак-Кини (Don McKinney) и Дэйв Карлик (Dave Carlick), уговорили меня написать книгу, которую вы держите в руках. Они убедили меня, что следует, прежде всего, обращаться к деловой аудитории.

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

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

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

Дэйв перебивает меня: «Алан, это называется главами».

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

Инженер, сведущий в бизнесе, либо бизнесмен, сведущий в технологии

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

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

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

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

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

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

* * *

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

Недавно я познакомился с руководителем высокого ранга одной из крупнейших технологических компаний мира. Официальное название его должности – вице-президент по вопросам удобства использования продуктов (юзабилити), и он несет ответственность за очень многие программные продукты, как небольшие, так и крупные. Это выдающийся и состоявшийся человек, выходец из сообщества HCI (Human-Computer Interaction, взаимодействие человека и компьютера), где принят формализованный подход. Он, как и его компания в целом, искушен в «эргономике» — в тестировании и наблюдении из-за односторонних зеркал. Однако он пришел говорить со мной не о тестировании, а о проектировании, и не о пользователях, а о персонажах. Он рассказал, что в его компании полностью прекращено эргономическое тестирование (называемое в этой книге юзабилити – тестированием) на завершающей стадии разработки; вместо этого усилия прикладываются до начала разработки — при проектировании. Более того, он упомянул, что все его люди, умеющие и привыкшие наблюдать за пользователями в искусственных условиях, проходят переподготовку и будут заниматься этнографическими исследованиями в «полевых» условиях.

Этот руководитель и его компания – символ тех огромных изменений, которые произошли в отрасли за пять коротких лет с момента выхода в 1999 году первого издания книги «The Inmates Are Running the Asylum» («Психбольница в руках пациентов»). Книга послужила одновременно манифестом для революции и учебником для науки. Не сосчитать, сколько писем я получил от менеджеров среднего звена, в которых рассказывалось, как после прочтения книги они покупали по экземпляру каждому из вышестоящих руководителей. Между тем разработчики программного обеспечения и университеты восприняли три главы части IV «Проектирование взаимодействий – выгодный бизнес» как исходный материал для руководства «сделай сам» по претворению в жизнь целеориентированного (Goal-Directed®) проектирования при помощи персонажей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алан Купер,

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

www.cooper.com

inmates@cooper.com

Часть I

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

Глава 1

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

Что получится, если скрестить компьютер с самолетом?

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

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

* * *

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

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

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

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

Что получится, если скрестить компьютер с фотокамерой?

Вот загадка информационного века: что получится, если скрестить компьютер с фотокамерой? Ответ: компьютер! Тридцать лет назад в моем первом фотоаппарате, 35-миллиметровом Pentax H, была маленькая батарейка, питавшая экспонометр. Я просто менял батарейку каждые два года, как в наручных часах.





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

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

Год назад моя цифровая фотокамера второго поколения, Panasonic PalmCam, содержала еще более сообразительную компьютерную микросхему. Настолько сообразительную, что простой выключатель эволюционировал в переключатель Off/Rec/Play. Появились режимы: чтобы снимать, необходимо было перевести камеру в режим Rec, а чтобы просматривать фотографии на маленьком экране – в режим Play.

Моя последняя фотокамера – Nikon CoolPix 900 – цифровой фотоаппарат третьего поколения, и она еще умнее. Настолько умнее, что содержит полноценный компьютер, отображающий песочные часы а-ля Windows при «загрузке». Словно какая-то рыба-мутант с лишними головами, выключатель дорос уже до четырех позиций: Off/ARec/MRec/Play. ARec обозначает автоматическую запись, а MRec – ручную. Насколько я могу судить, разницы между этими режимами нет. Режим On (включено) вообще отсутствует, и без подробных объяснений никто из моих друзей не может сообразить, как включить устройство.

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

В моем старом механическом Pentax была ручная фокусировка, ручная экспозиция, ручная выдержка, однако пользоваться им было гораздо менее мучительно, чем полностью компьютеризованным современным Nikon CoolPix 900, в котором фокусировка, экспозиция и выдержка автоматические. Эта фотокамера по-прежнему позволяет фотографировать, но ведет себя уже не как фотокамера, а как компьютер.

* * *

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

Что получится, если скрестить компьютер с будильником?

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

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





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

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

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

* * *

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

* * *

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

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

Что получится, если скрестить компьютер с автомобилем?

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

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

* * *

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

Что получится, если скрестить компьютер с банком?

Компьютер! Всякий раз, снимая деньги в банкомате, я сталкиваюсь с одним и тем же угрюмым и сложным поведением, столь присущим компьютерам. Если я сделаю малейшую ошибку, банкомат блокирует всю транзакцию и вышвырнет меня из процесса. Я должен вытащить карту, снова вставить ее, повторно набрать свой PIN-код, а затем повторить запрос. Обычно и ошибка-то не моя, это компьютер банкомата дипломатично сбивает меня с толку. Он постоянно спрашивает, с какого счета я хочу снять деньги – с текущего, с депозитного или же с валютного – хотя счет у меня всего один, текущий. Я постоянно забываю, какого типа у меня счет, и такой вопрос сбивает меня с толку. Примерно раз в месяц я безо всякого умысла выбираю депозитный счет, и адская машина бесцеремонно заставляет меня начать все сначала. Чтобы отказать в снятии денег с депозитного счета, машина должна знать, что у меня такого счета нет, но она предлагает мне этот счет в качестве одного из вариантов. Единственная разница между мной, когда я выбираю банковский счет, и пилотом рейса 965, выбравшим «ROMEO», – в масштабах последствий.

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

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

Компьютер позволяет легко попасть в беду

Компьютеры на рабочих столах ведут себя тем самым вызывающим раздражение способом, который им так присущ; им даже не требуется какое-либо скрещивание. Моя подруга Джейн когда-то работала координатором в области связей с общественностью. Она работала в Microsoft Word на своем компьютере под управлением Windows 95 – редактировала записки и контракты. Файловая система в Windows 95 имеет иерархическую структуру. Все документы Джейн хранились в маленьких папках, которые хранились в других маленьких папках. Джейн этого не понимала, равно, как не видела преимуществ в таком хранении информации. Вообще говоря, Джейн не слишком над этим задумывалась, а просто следовала по пути наименьшего сопротивления.





Джейн только что вчерне закончила новый контракт на пиар для начинающей компании из Кремниевой Долины. Она выбрала Закрыть из меню Файл. Вместо того чтобы сделать как сказано и закрыть документ, программа Word открыла диалог. Разумеется, речь идет о до боли знакомом запросе Do you want to save changes? (Сохранить изменения?). Она ответила – как обычно – нажатием кнопки Yes. Она так часто давала этот ответ, что даже перестала смотреть на диалоговое окно.





За первым диалогом немедленно последовал еще один – тоже очень знакомый Save As (Сохранить как). Этот диалог явил Джейн множество непонятных кнопок, пиктограмм и текстовых полей. Единственное, что Джейн здесь понимала и чем пользовалась, – поле ввода для имени файла. Она набрала подходящее имя и нажала кнопку Сохранить. Программа сохранила контракт в папке Мои документы. Джейн настолько привыкла к этой ненужной процедуре, что проходила ее, не задумываясь.

В обед, пока Джейн не было в офисе, Сунил, компьютерный специалист компании, установил на ее машину новую версию антивируса VirusKiller. Работая на компьютере Джейн, Сунил воспользовался программой Word, чтобы просмотреть файл Readme для VirusKiller. Просмотрев файл, Сунил закрыл его и привел компьютер Джейн в прежнее состояние. То есть он так думал.

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

Разумеется, когда Сунил использовал Word для просмотра файла Readme, он велел программе заглянуть в загадочную папку на шестом уровне вложенности файловой системы и безо всякого умысла сбил привычную для Джейн настройку на Мои документы.

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

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

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

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

Коммерческое программное обеспечение тоже страдает

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

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

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

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

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

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

Что получится, если скрестить компьютер с военным кораблем?

В сентябре 1997 года, участвуя в морских маневрах в Атлантике, корабль ВМФ США Yorktown, один из новых крейсеров с оборонительной системой Aegis,2 замер на месте. Техник ВМФ, калибруя топливный клапан, ввел нулевое значение в один из управляющих компьютеров – с процессором Pentium Pro и операционной системой Windows NT. Программа попыталась разделить другое число на этот нуль, то есть выполнить операцию, не определенную в математике, что и стало причиной сбоя всей системы управления бортом. Без участия компьютеров двигатель прекратил работать, и корабль два часа сорок пять минут качался на волнах, пока не прибыл буксир. Хорошо, что это произошло не в зоне боевых действий.





Что получится, если скрестить компьютер с военным кораблем? Адмирал Нимиц3 в гробу перевернулся бы! Несмотря на описанную неудачу, в ВМФ приняли решение о компьютеризации всех кораблей, поскольку это позволяло сэкономить на персонале, а чтобы отразить критику, объявили причиной «происшествия» человеческий фактор. Раз процесс создания программного обеспечения вышел из-под контроля, индустрия высоких технологий должна либо привести этот процесс в порядок, либо продолжать сваливать вину на обычных пользователей, в то время как все более грандиозные механизмы беспомощно плещутся в воде.

Техноярость

В недавнем номере WallStreetJournal появилась статья, посвященная анонимному видеоклипу, широко распространившемуся посредством электронной почты. В клипе «…Усатый Рядовой Гражданин в рубашке с коротким рукавом озадаченно склонился над компьютером. Внезапно, в порыве раздражения, он ударяет по своему монитору. Любопытствующий коллега заглядывает в его отсек, в то время как этот человек лупит клавиатурой по монитору, сшибая его на пол. Поднявшись со своего места, он добивает упавший монитор последним жестоким ударом».





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

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

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

Индустрия в «несознанке»

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

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

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

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

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

Мотивы создания этой книги

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

Совершив такое открытие, я начал понимать, почему программные продукты настолько плохи с точки зрения пользователя. В 1995 году я написал книгу5 о том, что узнал, и она оказала существенное влияние на разработку некоторых из программ.

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

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

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

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

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

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

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

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

Глава 2

Когнитивное сопротивление

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

Поведение, не связанное с физическими силами

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

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

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

Клавиши ЙЦУКЕНГ на печатной машинке не имеют мета-функций. Если нажать на клавишу У, на странице появится буква «У». Если нажать последовательно клавиши СТЕРЕТЬ ВСЕ, на дисплее появятся слова «СТЕРЕТЬ ВСЕ». На компьютере, в зависимости от контекста, могут присутствовать и мета-функции. Будет выполнена операция более высокого уровня, и компьютер действительно что-то сотрет. Поведение машины уже не соответствует вашим действиям в отношении один к одному.

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

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

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

Проектирование6 – слово емкое

В этой книге говорится о том, что интерактивные продукты должны проектироваться проектировщиками взаимодействия (interaction designers), а не разработчиками программного обеспечения (software engineers). Это утверждение часто вызывает мгновенную неприязнь у программистов, которые всю жизнь занимались проектированием. Более того, эти программисты боятся, что, отнимая у них проектирование, я отнимаю лучший и наиболее творческий аспект их работы, приговаривая их к унылому написанию кода, не способному приносить удовольствие. Это совершенно не так. Их беспокойство происходит из неточной природы термина «проектирование».

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





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

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

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

Отношения между программистами и проектировщиками

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

Большинство программ проектируются случайным образом

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

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

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

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

Проектирование «взаимодействия» против проектирования «интерфейса»

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

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

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

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

Отличительные черты продуктов, основанных на программном обеспечении

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

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

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