Если у них нет хлеба, пусть едят пирожные — КиберПедия 

Автоматическое растормаживание колес: Тормозные устройства колес предназначены для уменьше­ния длины пробега и улучшения маневрирования ВС при...

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

Если у них нет хлеба, пусть едят пирожные

2021-06-02 17
Если у них нет хлеба, пусть едят пирожные 0.00 из 5.00 0 оценок
Заказать работу

Местом моего проживания и работы является Кремниевая долина, штат Калифорния. Практически все, кого я знаю здесь, задействованы в индустрии высоких технологий. Все мы обеспеченны, высокообразованны, обладаем географической и социальной мобильностью, и еще мы прекрасно владеем компьютерами, мобильными телефонами, DVD-плеерами, банкоматами и любыми другими программными продуктами и устройствами на их основе, широко представленными на пестром рынке для среднего класса. За ланчем в Crescent Park Grill или Spago я слышу разговоры посетителей за соседними столиками, в которых они непременно обсуждают что-нибудь с клиент-серверной архитектурой или нечто веб-ориентированное. Это чудесное место для жизни, но очень оторванное от того, чем живет большинство людей в этой стране, если не сказать, мире. Здесь, в Долине, наши представления о пригодности высокотехнологичных продуктов легко подвергаются искажению. Мы забываем, как в действительности сложны наши продукты для использования.

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

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

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

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

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

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

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

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

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

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

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

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

Как изменить процесс

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

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

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

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

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

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

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

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

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

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

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

* * *

В 1998 году в еженедельном издании Business Week [40] была напечатана статья, в которой колумнист Стивен Вилдстром затронул тему недовольных пользователей компьютеров. Отклики читателей выражали на удивление полярные мнения, их было так много и они отличались таким накалом страстей, что Стивен Вилдстром резюмировал ситуацию следующим образом:

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

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

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

А в самом деле – вам есть что на это ответить?

Примечания

1

Считая от 2006 года, когда была издана книга. – Примеч. ред.

 

2

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

 

3

Честер Уильям Нимиц, главнокомандующий Тихоокеанским флотом США во время Второй мировой войны. – Примеч. пер.

 

4

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

 

5

«Об интерфейсе», первое издание вышло в 1995 году, в 2003 году вышло второе издание, почти полностью переработанное. – Примеч. ред.

 

6

Меня постоянно пытаются убедить, что эта функция очень нужна женщинам, так как якобы может помочь избежать преступных нападений на неосвещенных парковках, но каждый раз я слышал это от технического специалиста мужского пола, которому эта кнопка никогда бы не пригодилась. К моему великому удивлению, не так давно я увидел в Wall Street Journal заметку о реальном случае применения этой кнопки с надписью Panic. Одна семья отдыхала в кемпинге в Йосемитском национальном парке, когда к их автомобилю, где были заперты съестные припасы, подошел дикий медведь и начал царапать его, пытаясь забраться внутрь. Тогда мать семейства нажала эту кнопку, и взвывшая сирена в итоге заставила медведя сбежать. В таком случае, вероятно, эту кнопку стоило бы назвать «Средство для отпугивания медведей».

 

7

Специалист по юзабилити (usability professional) – это не то же самое, что проектировщик взаимодействия (interaction designer). Подробно различия рассмотрены в главе 12 «В отчаянном поиске юзабилити».

 

8

Если быть точнее, мы утверждали, что хотим «сделать процесс объединения компьютеров на базе Intel/Windows таким же простым, как объединение компьютеров Macintosh». В те времена было до смешного просто сделать сеть из компьютеров Mac с помощью AppleTalk. И совсем не так просто сделать это с компьютерами Wintel, даже в настоящее время.

 

9

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

 

10

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

 

11

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

 

12

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

 

13

Как описывает Джеффри Мур в своей потрясающей книге Crossing the Chasm («Преодоление пропасти»), новые опции помогут привлечь только узкий круг ранних почитателей вашего продукта, но не более того.

 

14

Мишель Куин (Michelle Quinn), Vanishing Act («Фокус с исчезновением»), выпуск San Jose Mercury News West Magazine от 15 марта 1998 года.

 

15

Gerald Weinberg, The Secrets of Consulting: A Guide to Giving & Getting Advice Successfully («Секреты консультирования: как с успехом давать и принимать советы»), Dorset House, 1985.

 

16

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

 

17

Po Bronson «The First $20 Million Is Always The Hardest», Avon Books, New York, 1997.

 

18

Ладно, стоит признать: я пилот частного самолета. Гари Килдалл – программист и настоящий фанат своего дела – в 1979 году позволил мне полетать с ним на его Piper Archer. После этого кратковременного полета я буквально «подсел» на это занятие. Программист внутри меня обожает всю эту сложность, доведенную до абсурда.

 

19

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

 

20

Fred Moody, I Sing the Body Electronic, 1995, Viking, New York.

 

21

Paul Glen «Leading Geeks: How to Manage and Lead the People Who Deliver Technology», 2003, John Wiley & Sons, New York.

 

22

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

 

23

Фургон Конестога – крытый конный фургон, который использовался переселенцами из долины Конестога, штат Пенсильвания. – Примеч. ред.

 

24

Saul W. Gellerman «Motivation and Productivity», Amacom, New York, 1963.

 

25

Byron Reevs, Clifford Nass, The Media Equation; How People Treat Computers, Television, and New Media Like Real and Places, Cambrige University Press, 1996.

 

26

Steven Pinker, How the Mind Works, W. W. Norton & Company, 1997. Я очень люблю эту прекрасную, увлекательную книгу, написанную весьма компетентно. Довольно интересное чтение, раскрывающее глаза на многие факторы.

 

27

Игры являются примечательным исключением из этого правила. Многие игры просто не были бы такими увлекательными, если бы некоторые факты не были скрытыми, процессы неясными, а цели – размытыми.

 

28

Robert X. Cringely, Accidental Empires, How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can’t Get a Date, Addison-Wesley, 1991.

 

29

На самом деле полный набор содержал больше персонажей, но самыми яркими оказались Бетси и Эрни.

 

30

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

 

31

Edward de Bono, Lateral Thinking, Creativity Step by Step («Латеральное мышление: Учебник творческого мышления»), 1970, Harper & Row, Publishers, New York.

 

32

Конечно, время и стремительное снижение цены на кремний значительным образом изменило конъюнктуру рынка сканеров. Данная информация актуальна на январь 1997 года.

 

33

«Частный детектив Магнум» – американский детективный телесериал 1980 года.

 

34

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

 

35

Pee Wee Herman – комический псевдоним американского комедийного актера Пола Рубенса.

 

36

В своей книге под названием About Face («Алан Купер об интерфейсе») я привожу порядка 50 мощнейших аксиом проектирования. Это пример одной из них.

 

37

Это был конкурс в рамках отраслевой конференции COMDEX, он назывался Windows World Open и спонсировался такими компаниями, как Microsoft, Computerworld и Ziff-Davis Events. На тот момент конкурс проводился уже в седьмой раз.

 

38

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

 

39

David Maister «Managing the Professional Service Firm», 1997, Free Press, New York.

 

40

Stephen H. Wildstrom, «They’re Mad as Hell Out There», Business Week, October 19, 1998.

 


[1] Считая от 2006 года, когда была издана книга. – Примеч. ред.

 


Поделиться с друзьями:

Наброски и зарисовки растений, плодов, цветов: Освоить конструктивное построение структуры дерева через зарисовки отдельных деревьев, группы деревьев...

Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰)...

Состав сооружений: решетки и песколовки: Решетки – это первое устройство в схеме очистных сооружений. Они представляют...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.208 с.