Текст книги "Психбольница в руках пациентов"
Автор книги: Алан Купер
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 12 (всего у книги 28 страниц) [доступный отрывок для чтения: 12 страниц]
Программное обеспечение больше похоже на мост, чем на здание. Программы работают на высокотехнологичных микропроцессорах, а управляют ими и используют их простые смертные. Осваивая новые технологии и восхищаясь ими, мы упускаем из виду огромную разницу между компьютерами и людьми, эти компьютеры использующими.
К примеру, мы считаем, что раз у компьютеров есть память, она должна быть похожа на человеческую. Это совершенно не так. Память компьютера работает иначе. Моя память позволяет мне легко распознавать лица друзей, а мой собственный компьютер никогда не узнает даже меня. Мой компьютер хранит миллионы телефонных номеров с идеальной точностью, а я не всегда сразу вспоминаю даже собственный номер.
Чтобы программное обеспечение было мощным и надежным, оно должно создаваться в идеальной гармонии с потребностями кремниевых микросхем. Чтобы программисты работали профессионально, они также должны участвовать в этой гармонии.
Чтобы пользователи были довольны и могли эффективно применять программы, программы следует создавать в гармонии с потребностями человеческой природы. Проблема, понятно, в том, что человеческие потребности радикальным образом отличаются от потребностей кремниевых микросхем.
Очевидно, что одна часть программы, а именно внутренняя, должна создаваться с применением специальных технических знаний и учетом потребностей компьютеров. И точно так же очевидно, что вторая часть (внешняя) должна создаваться с применением специальных социальных знаний и учетом потребностей людей. Я убежден, что программисты способны справиться с первой задачей, но вторая задача требует участия проектировщиков взаимодействий.
Идеолог компьютерной отрасли Джерри Вайнберг говорит:
Многие десятилетия главной проблемой компьютерной отрасли оставалась эффективность. Компьютеры были, в основном, маленькими, дорогими, медленными и непроизводительными. Мы обожествляли хакеров, умевших создавать максимально эффективные программы и выжимать всю возможную производительность из дорогих ЭВМ. По существу, было гораздо дешевле обучать людей общению с непонятными, но производительными компьютерными программами, чем покупать дополнительные компьютеры. Неуклонное и неизбежное падение цен на компьютеры навсегда избавило нас от этой проблемы. Сейчас, оказывается, гораздо дороже обходится адаптация людей к «эффективным» программам, чем создание программ, соответствующих ожиданиям людей.
Решение очевидно: поставить программы на службу пользователям. Однако на пути такого решения встает культура, которую мы столь заботливо создавали последние сорок лет, культура, обожествляющая хакеров, стоящих у руля. Сообщество разработчиков программного обеспечения в целом готово включить проектирование взаимодействия в процесс разработки. «Конечно, – говорят они, – проектируйте сколько угодно, только дайте сначала продукт закончить». К сожалению, проектирование взаимодействия должно предшествовать строительству, поэтому открытость программиста проектированию совершенно бесполезна. Точно так же оператор бетономешалки может сказать плотникам, что они смогут начать создавать каркас, как только он закончит заливать бетон.
Учим собак быть кошкамиВ качестве отступного разработчики программного обеспечения всегда выражают готовность изучать проектирование. Меня постоянно просят «научить проектировать». Я приветствую такую открытость, но не верю в эффективность такого подхода. Любой разработчик программного обеспечения, достаточно квалифицированный, чтобы называться профессионалом, слишком погружен в буквальную и детерминированную сущность кремниевой логики. Слишком сильно погружен, чтобы достичь параллельно схожей эффективности в иррациональном, непредсказуемом, переполненном эмоциями мире людей. Я не хочу сказать, что программист неспособен стать проектировщиком, я лишь пытаюсь сказать, что практически невозможно делать то и другое хорошо одновременно.
Каждый разработчик программного обеспечения считает себя не таким, как все, считает, что способен делать и то и другое. Как ясно показала судьба General Magic, это попросту не так. Разработку в General Magic возглавляли Билл Аткинсон (Bill Atkinson) и Энди Герцфельд (Andy Herzfeld), в прошлом ведущие разработчики программного обеспечения для Apple Macintosh и, вероятно, два наиболее изобретательных и одаренных творца из числа программистов. Их совместное программирование проектирование для Macintosh превратилось в успех в 1984 году (хотя в проектирование пользовательского интерфейса существенный вклад внес Джеф Раскин (Jef Raskin), в программировании участия не принимавший). Однако за последующие четырнадцать лет вещи достаточно сильно изменились, и старые методы перестали быть применимыми. В начале 1993 года я брал интервью у Энди Герцфельда в штаб-квартире разработки General Magic, которая являлась одновременно и его жильем в Пало-Альто. Там он изложил мне свою философию проектирования программных продуктов. Я изумленно слушал его, понимая, насколько малы его шансы на успех. История признала выдающийся талант Энди.
Несомненно, что продукт, задуманный General Magic, был востребован, и таковым остается поныне. Несомненно, что технология в продукте применялась великолепная. Несомненно, что способность Марка Пората находить стратегических партнеров и заключать сделки мало кому удастся превзойти. Несомненно, что компания имела хорошую родословную и хорошее финансирование. Что же тогда уничтожило компанию? Я считаю главной причиной проектирование взаимодействия, а точнее – его отсутствие. Несмотря на звездную генеалогию и вселяющие трепет таланты, продукт General Magic был сконструирован, а не спроектирован.
Принятый в отрасли образ мышления не дает места столь очевидным выводам, как видно из статьи о General Magic. Чаша ответственности за провал продукта в статье склоняется, похоже, к высокомерию и честолюбию Пората, однако в Кремниевой Долине нет ни одного президента, у которого имеется недостаток таких проявлений собственного эго. Эти качества навряд ли могут быть причиной провала компании.
Наша высокотехнологическая культура настолько замкнута в себе, что мы слабо осознаем собственные провалы и слабые места. Невозможно стать успешным журналистом в этой области, не будучи компьютерным фанатиком – апологетом, поэтому журналисты сваливают вину за провалы на наши личные качества, недоброжелательность фортуны и форс-мажорные обстоятельства.
* * *
Разработка программного обеспечения не является самостоятельной профессией, такой как юриспруденция, архитектура или медицина, поэтому названия должностей в нашей отрасли весьма ненадежны. Некоторые мои друзья, высокопрофессиональные программисты, называют себя «проектировщиками программного обеспечения». Самоназвание, вне всякого сомнения, заслуженное, но не совсем верное. Скажем, Энди Герцфельд с готовностью отзывается на прозвище «проектировщик».
Многие программисты считают себя талантливыми проектировщиками. Вообще говоря, это действительно так во многих случаях, но существует огромная разница между проектированием функциональности и проектированием для людей.
Даже если программистов сложно оправдать в плане проектирования, они, по крайней мере, стараются удерживать проекты от окончательного расползания. Завидев узурпатора, они стараются не допускать к рулю безответственных людей. Большинство программистов очень ответственны, они часто считают сторонних консультантов, маркетологов и руководителей вздорными и некомпетентными личностями.
Программисты чувствуют чепуху за версту, и всего после пары случаев, когда маркетологи или руководители требуют «изменений, улучшающих интерфейс» и оказывающихся в итоге неэффективными, у программистов возникают защитные барьеры против такого вмешательства. Изменения могут быть к лучшему или к худшему, но в любом случае программисты вынуждены делать дополнительную работу. Каждое изменение снижает качество кода, поскольку неизбежно оставляет швы и рубцы. Если кто-то заявляет, что программой станет легче пользоваться, и достаточно лишь поместить каждую кнопку «ОК» в правый верхний угол диалогового окна, опыт и мудрость программиста подсказывают ему, что это пустая трата времени – его времени. И он прав в своей бдительности.
После нескольких напрасных погонь за недостижимыми целями они начинают относиться к поступающим извне рекомендациям по проектированию, как к обычным советам. Они словно строители, которым пришлось разрушить слишком много непродуманных стен и которые теперь смотрят на чертежи с предубеждением и зарекаются воспринимать их всерьез.
* * *
Разработчики программного обеспечения рисуют на досках диаграммы, изображая пользовательский интерфейс и код для работы с данными в виде отдельных прямоугольников. Однако реальной разницы в кодировании того и другого нет. Это не две стены, одна из которых сложена из гранитных блоков квалифицированным каменщиком, а соседняя – из деревянных досок, сколоченных плотниками и обшитых гипсовыми изоляционными панелями. Совсем нет. В коде, реагирующем на движения мыши, и коде, реорганизующем базу данных глубоко в недрах программы, используются примерно те же операторы, указатели, вызовы методов. Часто внутренний код системы и код для взаимодействия с пользователем пишет один и тот же человек. Он пользуется одним языком, теми же библиотеками, инструментами и методами для решения этих задач. Кто может сказать, где проходит граница между программой для компьютеров и программой для пользователей?
Программисты привыкли рассматривать задачи в рамках функций, так что им совершенно неясно, чем хороша идея взять фрагмент программы, нарушить множество границ функциональности и перенести его на сторону пользователя. Инженерам трудно осознать, чем код на языке С, реализующий взаимодействие с базой данных, разительно отличается от кода на языке С, реализующего взаимодействие с человеком.
* * *
Следующую историю рассказал мой коллега, Джим Гей (Jim Gay). Он показывает, как легко умные инженеры загораются увлекательными и интересными проблемами, вместо того чтобы заниматься решением проблем, действительно того требующих.
Начинающая компания TransPhone решила выйти на рынок электронной коммерции. Основной нашей идеей стало создание простого в применении смартфона, как основы для интернет-коммерции. Решающим фактором успеха нашей модели был простой интерфейс, с которым было бы удобно работать людям, не имеющим отношения к компьютерам. TransPhone обратилась за помощью в компанию, специализирующуюся на проектировании взаимодействия.
Мы считали, что практически уже создали пользовательский интерфейс, однако ему не помешала бы некоторая доводка. На первом же собрании проектировщики взаимодействия много раз повторили, что понятия не имеют, что мы в действительности пытаемся создать или для кого мы пытаемся это создать. Мы посчитали, что они поверхностно смотрят на проблему, которая на самом деле была довольно серьезной. Собрание закончилось тем, что проектировщики попросили нас более точно определить цели и задачи. У нас появилось ощущение, что эти проектировщики ни малейшего представления не имеют о том, чего мы пытаемся достичь.
После этого мы создали улучшенный прототип для демонстрации потенциальным партнерам, однако устройство TransPhone попросту не вызвало у них восторга. Мы продолжали считать, что демонстрация просто недостаточно убедительна. TransPhone прекратила свое существование через несколько недель после создания второго прототипа.
Вспоминая то, первое собрание с участием проектировщиков взаимодействий, я отчетливо понимаю, что главную нашу проблему они обнаружили в первые же несколько минут: какова была наша цель, для кого мы все это делали? Никто и никогда не дал адекватного ответа на этот вопрос. Задайся мы сразу этим вопросом, возможно, случилось бы одно из двух: найдя ответ, мы получили бы шансы на успех либо, не найдя ответ, минимизировали потери инвестора.
Каков урок этой истории? Проектирование продукта является важнейшей составляющей жизненного цикла предприятия. Наша неспособность разрешить фундаментальные вопросы проектирования и желание вместо этого устремиться вперед, к разработке и продажам, в конечном итоге оказались для компании роковыми. Теперь-то понятно, что, не сумев создать представления того, что мы пытались делать, мы должны были вернуться к исходным целям своего предприятия. Думаю, это, скорее всего, привело бы к созданию иного, более простого продукта. Вместо этого мы продолжали добавлять прибамбасы, вероятно, еще сильнее маскируя возможную полезность продукта.
Подобно ребятам из General Magic, Джим на горьком опыте убедился, что, классная технология и раскаленный докрасна рынок не способны поднять тяжелый груз плохо продуманного кода. Недостаточно перебросить мост между технологией и потребностью. Кто-то еще должен сделать так, чтобы люди захотели ходить по этому мосту.
История наших технологий относится преимущественно к индустриальному веку, поэтому проблемы и решения, присущие ей, близки современному человеку. Сила сопротивления между людьми и механическими устройствами существует, но в определенных рамках. В информационную эру нашу жизнь заполонили компьютеры, все больше продуктов, содержащих микросхемы, и мы обнаруживаем, что между людьми и устройствами возникает когнитивное сопротивление, с которым мы не готовы бороться. Наши инженерные таланты высокосовершенны, но подводят нас в решении проблемы когнитивного сопротивления. За многие годы разработчики программного обеспечения определенно выросли как профессиональны, однако их способность создавать мощные и приятные программы остается такой же слабой, как и прежде.
Я считаю, что наша неспособность решить проблему инженерными методами доказывает невозможность ее решения таким способом. Более того, осмелюсь утверждать, что инженерные методы как раз и являются одной из причин возникновения, этой проблемы. Просить инженеров исправить ситуацию – все равно, что просить лису защитить курятник.
Глава 7
Ноmo Logicus
С большой долей иронии я называю программистов хомо логикус. Вид хомо логикус слегка – но достаточно ощутимо – отличается от вида хомо сапиенс, человека разумного. Из собственных наблюдений я почерпнул четыре фундаментальных отличия образа мысли и действия разработчиков программ от обычных людей. Об этих отличиях и пойдет речь в данной главе. Программисты пожертвуют простотой ради контроля. Обменяют успех на понимание. Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. И, наконец, ведут себя грубо и прямолинейно, как быки.
Авиационный тестЧтобы подчеркнуть различие между видами, я применяю забавную лакмусовую бумажку – «Авиационный тест». Чтобы пройти тест, достаточно представить, что вы идете по посадочному коридору авиалайнера. Вступив на борт, вы должны выбрать – пойти налево в кабину или же направо в салон.
В кабине пилота целый калейдоскоп сложных органов управления и счетчиков, на всех поверхностях располагаются датчики, ручки и тумблеры. Справа же, в салоне, полная противоположность – мягкие округлые формы, успокаивающие бежевые оттенки.
Если повернуть налево, в кабину, вам придется в совершенстве овладеть сложными техническими материями. Придется узнать, зачем нужен каждый из приборов. За понимание всего этого нагромождения вы получаете ощущение определенного контроля над ситуацией и ответственность за посадку в нужном месте.
Свернув направо, в салон, вы отказываетесь от какого-либо влияния на полет. За отказ от контроля вы получаете возможность расслабиться, зная, что попадете в нужное место, и при этом самой сложной операцией будет включение и выключение лампы для чтения.
Авиационный тест четко делит человеческую расу на две категории: свернувшие налево стремятся контролировать ситуацию и понимать, как работает технология, а свернувшие направо стремятся упростить свои размышления и испытывать уверенность в успешности полета. Программисты – хомо логикус – всегда выбирают поворот налево. Пользователи хомо сапиенс – всегда выбирают поворот направо.
Психология программистовПоскольку наша цель есть создание продуктов, основанных на программном обеспечении, мощных и приятных для пользователей, понимание психологии пользователя может показаться естественным условием. Это, разумеется, верно, но мешает уловить более важное, но далеко не столь очевидное обстоятельство. Найти решение и реализовать решение – два совершенно разных действия. Я бы предпочел иметь в руках недостаточно хорошо спроектированный продукт, чем спецификацию великолепного проекта, пылящуюся на полке. Чтобы наши толком спроектированные продукты попали в руки пользователей, необходимо выполнить еще более важное требование: понять психологию создателей продукта, программистов.
Ничего не изменится, пока мы не начнем влиять на разработчиков программного обеспечения. Даже если программисты соглашаются с тем, что к пользователям следует относиться лучше (а обычно они соглашаются), это не означает, что они сделают все необходимое, чтобы достичь озвученной цели. Вы не заставите их изменить подход простыми просьбами. Чтобы получить работающее решение, мы должны проникнуть в способ их мышления, понять, как можно мотивировать этих людей на создание взаимодействия, удобного для пользователя. Разумеется, проектировщик взаимодействия должен разбираться в психологии, причем не только в психологии пользователей, но и в психологии разработчиков программ.
Смысл изложенного прост: программисты отличаются от обычных людей. Стереотипы их поведения вот уже много лет являются поводом для шуток: неловкость в общении, карманные предохранители1818
Речь идет о пакетиках, носимых в нагрудных карманах и предохраняющих рубашку от порчи в случае, если потечет ручка. Такие предохранители стали одним из символов культуры «ботаников» в начале второй половины XX века. – Прим. перев.
[Закрыть], педантичность. Это лишь поверхностные признаки, их легко заметить и высмеять. По-настоящему существенные отличия не только гораздо тоньше, они способствуют более заметному увеличению когнитивного сопротивления в создаваемых программистами интерактивных продуктах.
Многие обозреватели компьютерной индустрии приложили усилия, чтобы определить эти отличия. Роберт Кринджели (Robert Cringely) называет программистов «смердящими богами», подразумевая одновременное высокомерное отношение к окружающим и личное отношение к гигиене.
Другой проницательный наблюдатель и талантливый автор – По Бронсон (Ро Bronson). Он обращал свое зоркое око и острый ум к миру высоких технологий. Пародируя Стивена Кови (Steven Covey), он создал список «Семь привычек крутых инженеров». Эти определения невероятно точны, хотя и гиперболичны.
Программисты пожертвуют простотой ради контроля1. Они щедры в своем эгоизме.
2. Слепота улучшает их зрение.
3. Они кусают не только руку кормящего, но еще и собственные руки.
4. Они готовы приложить любые усилия, чтобы сохранить впечатление, будто их не заботит собственный имидж.
5. Они чинят то, что не сломано, до тех пор, пока это не сломается.
6. «Не я дал неверный ответ, а вы задали не тот вопрос».
7. Считают отсутствие критики комплиментом.
Хомо логикус желает контролировать то, что его интересует, а интересуют его сложные, детерминированные системы. Люди тоже сложны, но их поведение нелогично и труднопредсказуемо, они не ведут себя, как механизмы. Лучшие механизмы – это цифровые механизмы, поскольку они самые сложные, самые изощренные, и программист без труда может их модифицировать.
С точки зрения программиста контроль над людьми менее привлекателен. В своем романе «The First $20 Million Is Always the Hardest»1919
Po Bronson «The First $20 Million Is Always The Hardest», Avon Books, New York, 1997.
[Закрыть] (Тяжелее всего даются первые двадцать миллионов долларов) По Бронсон (Ро Bronson) заставил программистов устраивать розыгрыши над людьми, чтобы показать свою власть, однако программистам намного больше нравится повелевать компьютерами.
За контроль всегда приходится платить – дополнительными усилиями и увеличением сложности. Большинству людей по плечу разумные усилия, однако, программистов от большинства обычных людей отличает готовность и способность овладевать крайне сложными вещами. Понимать сложные системы, составленные из многочисленных взаимодействующих факторов, управлять такими системами – вот часть работы программиста, приносящая ему удовлетворение. Пилотирование самолета – увлечение для программистов2020
Ладно, сознаюсь: я пилот. В 1979 году типичный программист-фанатик Гари Килдалл взял меня на борт своего Piper Archer. Этот короткий полет посадил меня на иглу авиаполетов. Компьютерный программист во мне любит всю эту бессмысленную сложность.
[Закрыть]. Панель управления в кабине самолета просто забита индикаторами, ручками и рычагами, однако программисты преуспевают в общении со столь устрашающе сложными объектами. Для хомо логикус это веселое и увлекательное занятие, несмотря на необходимость (благодаря ей!) многие месяцы кропотливо учиться. Хомо сапиенс предпочитает лететь в пассажирском салоне.
Для хомо логикус контроль – цель, тогда как сложность – просто цена, которую они готовы платить за достижение цели. Для нормальных людей цель – это простота, и отказ от контроля – цена, которую они готовы платить. В продуктах, основанных на программном обеспечении, контролем являются функции. К примеру, в Windows 95 функция «Поиск файла» дает мне серьезный контроль над ходом работы. Я могу указать, в каких областях диска следует выполнять поиск, тип искомого файла, искать ли файл по имени или по содержимому и еще целый ряд параметров. С точки зрения программиста все это просто замечательно. Затратив дополнительные усилия и приобретя определенное понимание предмета, он получает возможность искать быстрее и эффективнее. Напротив, с точки зрения пользователя все не так радужно, поскольку ему приходится указывать область поиска, указывать тип искомого файла и еще метод поиска.
Хомо сапиенс с радостью принесли бы в жертву лишнюю минуту компьютерного времени, если бы знали, что не придется изучать, как работает функция поиска. Для них каждый параметр поиска – дополнительная возможность сделать что-нибудь не так. Вероятность ошибки и отрицательных результатов поиска возрастает по мере увеличения гибкости. Они бы с радостью принесли в жертву всю эту ненужную сложность, контроль и понимание процесса, чтобы упростить себе работу.
