Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов
 Скачать 7.24 Mb.
|
|
Глава 12. В отчаянных поисках эргономики Взрывное распространение на массовом рынке продуктов, основанных на программном обеспечении, как в области универсальных компьютеров, так и специализированных устройств, преобразовало аудиторию пользователей. В прежние времена это была небольшая группа великодушных обожателей технологии. Сегодня же это огромное множество нетерпеливых, подавленных, не сведущих в технике 254 потребителей. Наверное, каждый" кто связан с разработкой программного обеспечения, да и кто несвязан, наблюдал, как в болезненном раздражении кричат пользователи, и чувствовал потребность чем-то помочь. Многие специалисты пошли вперед, полные решимости исправить ситуацию. У всех замечательная подготовка, у большинства отличная репутация и у многих длинные списки первоклассных клиентов. Вместе же они произвели больше тепла, чем света; их продуктам, основанным на программном обеспечении, не достает самой малости - они не являются объектом желания. Результатом стало замешательство по поводу выбора действенных способов преодоления недовольства пользователей. В этой главе я попытаюсь распутать этот клубок и показать, какую пользу может приносить та или иная специализация, и как это согласуется с целеориентированным проектированием взаимодействия. Последовательность Вероятно, важнейшим аспектом проектирования является последовательность событий в процессе разработки. С первых же дней разработки программного обеспечения последовательность событий была такая: программирование, устранение дефектов, доводка. Сначала программирование, устранение дефектов, доводка. Сначала программист пишет программу, затем в пошаговом режиме проходит ее в поисках непреднамеренных ошибок, внесенных при ее создании. Затем он исправляет эти ошибки, и наконец, программа готова к сдаче. Совершенно естественно, что инженеры воспринимают любую новую дисциплину с большей готовностью, если она не нарушает привычный порядок действий. Существует метод, известный как «юзабилити-тестирование», который вырос до существенных масштабов и заключается в эмпирическом исследовании реальных взаимодействий, пользователей с продуктом. Основная причина широкого признания такого тестирования в бизнесе высоких технологий в том, что оно легко встраивается в существующую последовательность. Юзабилити-тестирование по большей части связано с наличием работоспособной программы, поэтому, разумеется, необходимо ждать, пока программа 255 не будет готова к запуску. Так юзабилити-тестирование проводится параллельно устранению дефектов, что удобно. Программистам удобна такая дополнительная форма тестирования, поскольку она не нарушает существующую последовательность действий. Как я уже говорил, создание кода по отношению к проектированию – все равно что заливка бетонной смеси в строительстве. Независимо от профессионализма проектировщика и применяемых методов, если создание кода уже началось, воздействие проектирования окажется пренебрежительно мало. Фундаментальная предпосылка включения проектирования взаимодействия в процесс разработки про грамм заключена в предшествовании проектирования программированию. Очевидно, что я защищаю целеориентированное проектирование, однако любой системный процесс проектирования, предшествующий программированию, будет эффективнее любого процесса, следующего за программированием. Проектирование взаимодействия до начала программирования означает коренные перемены в процессе разработки программного обеспечения. Естественно, такие перемены затрагивают программистов, и они видят для себя угрозу. До этого они были первыми, а следовательно, и самыми важными. Если другая дисциплина предшествует программированию, означает ли это, что специалисты другой дисциплины более важны? Это не так, и подробности ожидают читателей в следующей главе. Как профессионал, работавший с программным обеспечением, я занимался программированием, изобретением, тестированием, документированием, проектированием, продажей, поставкой и поддержкой. Я могу утверждать, что среди этих задач программирование - задача самая сложная и предъявляющая к исполнителю 256 самые высокие требования. (Я говорю о профессиональном программировании, о создании программ, пригодных для коммерческого распространения. Известно, что сложность программы растет экспоненциально в зависимости от размера кода. В институте почти всем приходится писать небольшие, по сотне-другой строк, программы. И многие пользователи для выполнения своей работы пишут программы примерно такого же размера. Однако общий объем, кода коммерческого приложения легко может превышать пятьдесят тысяч строк, поэтому сложность этих приложений выходит за пределы понимания большинства смертных.) Даже если другие специалисты об этом не догадываются, то у программистов нет сомнений, что их вклад в дело намного больше, чем, чей бы то ни было еще. Миф о непредсказуемости рынка, рассказанный в главе 3 «Пустая трата денег», - еще одна причина, по которой последовательность «программа, тест, доводка» так прочно закрепилась в индустрии. Если мы не можем знать, чего захочет рынок, зачем тратить время на предварительное проектирование взаимодействия? Просто пишем код и выбрасываем на рынок, а там уж видно будет. Кроме того, такой подход избавляет нас от какой - либо ответственности за неудачи. И несмотря на эти все проблемы, жизненно важно, чтобы более думающие люди изменили существующую последовательность, поместив проектирование перед программированием. Юзабилити-тестирование Любой процесс, основанный на наблюдении, должен играть второстепенную роль по отношению к творчеству. Программисты творят дисциплина эргономики молчаливо передает бразды правления программистам, говоря: «Вы создадите это, а затем я протестирую и увижу, насколько хорошо вы справились.» Однако в скоростном мире высоких технологий созданный продукт немедленно выходит на рынок. Тестирование постфактум уже не может сильно повлиять на продукт. На мой взгляд, юзабилити-методы похожи на наждачную бумагу. Если вы делаете стул, наждачная бумага может сделать его более гладким. Если вы делаете стол, наждачная бумага и его сделает более гладким. Но никакая шлифовка не позволяет превратить стол в стул. И тем не менее, мне приходится видеть, как тысячи людей из лучших побуждений прилежно шлифуют столы методами эргономики, пытаясь получить 257 стулья. Юзабилити-тестирование до программирования Нет сомнений, что юзабилити-тестирование до начала программирования возможно, однако природа и ценность процесса в этом случае меняется радикально. Такого рода тестирование сравнимо с чистым исследованием, которое больше подошло бы для университетской среды. Один коллега из крупной компании, разрабатывающей программное обеспечение, провел классический юзабилити-тест, одновременно выявивший сильные и слабые места такого предварительного тестирования. Он хотел определить эффективность строки состояния внизу окна программы. Он предложил участникам выполнить безобидное задание при помощи электронной таблицы. Каждые пять минут в строке состояния появлялось сообщение: «К вашему креслу снизу приклеена банкнота в $50. Возьмите ее!» За целый день тестирования ни один из более чем десяти участников не попытался взять купюру. Осознать, что пользователи не обращают особого внимания на содержание популярной в среде программистов строки состояния, само по себе полезно. Однако это не проливает свет на скрытые проблемы: что есть состояние, заслуживающее внимания пользователя? Следует ли вообще отображать что-либо? В каком месте? Эти проблемы проектирования, как и раньше, остаются нерешенными. Интеграция юзабилити-тестирования в процесс проектирования Профессиональная литература переполнена подробными советами о том, как проводить тесты, но мало кто говорит о возможностях тестирования на стадии, когда продукт еще не существует. На практике необходимо создать и протестировать какую-то видимость программы. Обычно макет принимает форму быстро созданного прототипа или «кукольного театра», созданного из бумажных вырезок или других низкотехнологичных материалов. Вы можете многое узнать, наблюдая за реакцией пользователей на спектакле кукольного театра, однако без предварительного проектирования может оказаться, что тестируется не совсем то, что нужно. Кроме того, присутствие человека, проводящего тестирование, оказывает серьезное влияние на такую форму тестирования: здесь любое слово, кивок и даже взгляд могут исказить результат. Чтобы получить наиболее осмысленные результаты, необходимо провести крайне 258 дорогостоящее сравнительное тестирование - создать две программы и каждую протестировать. И даже в этом случае вы узнаете лишь, что один вариант лучше другого. Вы не узнаете, каких высот можете достичь на практике. Толковое юзабилити-тестирование может выявить неверные предположения проектировщика. Всегда лучше демонстрировать результаты проектирования пользователям и перепроектировать итеративно, чем вообще этого не делать. Некоторые новые технологии, такие как распознавание голоса, настолько плохо изучены, что даже результаты простейшего юзабилити-тестирования могут иметь огромную ценность. Едва ли не самым ценным вкладом тестирования является присутствие программистов, когда они из-за полупрозрачного зеркала вынуждены наблюдать, как пользователи сражаются с их программами. Программисты испытывают шок и крайнее недоверие, они ругаются: «Вы тестируете каких-то недоумков!» Юзабилити- тестирование - меткий камень в огород упрямых разработчиков программного обеспечения, который показывает им, что проблема действительно существует. Оно может послужить той же цели и в случае с руководителями. Перефразируя рекламу зубной пасты, можно сказать, что юзабилити-тестирование представляет собою эффективный способ предотвратить кариес в случае добросовестного следования советам профессионалов и практике целеориентированного проектирования. Главное – помнить, что другие факторы могут оказывать еще алее сильное воздействие. Многопрофильные команды Сопротивление разработчиков программного обеспечения всему, что грозит изменить знакомую последовательность событий процесса разработки, привела к рождению многочисленных извилистых логических построений в сообществе проектировщиков. Широко обсуждается мысль о там, что проектирование должны осуществлять команды, включающие представителей многих дисциплин. Согласно этой гипотезе, команда, включающая представителей пользователей, программистов, менеджеров, маркетологов, специалистов по юзабилити, даст лучшие результаты. Па моему опыту, метод «круглого стола» не эффективен. Цели и заботы участников различаются, а участник, цели которого имеют наибольший вес, часта хуже всегда приспособлен для выражения своих забот. Хуже того, программисты, в любом 259 случае, обладающие абсолютной властью над программными артефактами, неизбежна берут на себя управление командой, обычна с заднего сиденья. Круглый стал не дает желаемых перемен. Подход демократичный, полидисциплинарный, многокультурный, никого не оставляющий за бортом, на не способный исправить ущербную последовательность, продолжающую отравлять взаимодействие. Проектирующие программисты Первыми «добровольцами» в борьбе с проблемами несведущих в технологиях пользователей стали сами программисты. Полная неприспособленность их культуры и инструментов для решения данной задачи не имела никакого значения ввиду отсутствия других кандидатов. Славно случайные свидетели, которым не повезло оказаться поблизости от места катастрофы, программисты получили задание организовать скорую помощь для интерфейсов лишь потому, что занимались родственными вещами. Программисты - ничто без своего энтузиазма, и они гордятся сваей компетенцией, поэтому сложность проектирования взаимодействия привлекла их, и они приложили к решению задачи значительные усилия. Так появилась язвительная шутка: «Проектирование - то, чем программисты занимаются двадцать минут перед тем, как начать писать код». В этой книге я неоднократно показывал, что усилия программистов были обречены с самого начала. Как говорит По Бронсон, они считают отсутствие критики комплиментам, поэтому их оценка собственной производительности невероятно высока, и многие из них продолжают держаться за роль проектировщика взаимодействия. Славно безумные карали, программисты не желают сдавать захваченную территорию, даже если оккупация неприятна, невыгодна, нежеланна и непригодна для защиты. Если вы программируете профессионально, та вы - программист независима от того, чему мажете научить, что протестировать или спроектировать. Как нельзя быть немножко беременной, так нельзя немножко заниматься программированием. Многие разработчики все еще не признают существования серьезной проблемы («просто пользователи должны больше учиться»), но есть и такие, кто отчетливо видит всеобщее разочарование и финансовые убытки от широко продаваемых танцующих медведей. Хорошо, что группа последних растет, как растет и желание большинства 260 компаний – разработчиков обращаться за сторонней помощью. В действительности большинства программистов неплохо справляется с проектированием, а многие из тех, кто не способен это делать, осознают Сваи недостатки и стараются не практиковать проектирование. Огромное «но»: когда программисты проектируют, их усилия практически всегда основываются на уникальной индивидуальности хомо логикус. Конечный результат - сложные в применении и негодные продукты, которые, как правила, нравятся только другим программистам. Откуда вы знаете? Многие специалисты по юзабилити считают, что невозможно понять, насколько удобно взаимодействие, пока не проведено тестирование. Поэтому они постоянно спрашивают: «Откуда вы знаете?» Однако я заметил нечто весьма любопытное. Задавая этот вопрос, они вовсе не играют в адвоката дьявола. Они спрашивают по той простой причине, что не могут опознать качественно спроектированные взаимодействия. По меньшей мере четыре крупные кампании, с которыми мне приходится работать, давно общаются с профессиональными эргономистами. Эти кампании решили вложить средства в юзабилити. Они наняли профессионалов для создания лабораторий, проведения исследований, обнаружения вероятных проблемных областей и выдвижения догадок относительно улучшения эргономики. Программисты прилежно вносили изменения в программы, но мало что изменилось. Разве что программистам приходилось работать намного больше. После нескольких итераций программисты просто сдались, то же самое сделали большинство менеджеров. Они поняли, что процесс очень дорогостоящий и требует больших затрат времени, однако фундаментальную задачу не решает. Проектировщики взаимодействия полагаются на свой опыт, на подготовку и суждения, что позволяет давать точные оценки. Он использует специальные принципы, идиомы и инструменты для каждой ситуации и, наряду с этими средствами, используют еще прочие источники информации. Откуда знает рентгенолог, изучив рентгеновский снимок, что человеку требуется операция? Рентгеновские снимки настолько сложно интерпретировать, что неспециалисты просто не могут себе представить как такое возможно. А подготовленные врачи делают это все время. Откуда судья знает, виновен ли подсудимый? Откуда инвестор знает, что настало время покупать? Эти 261 профессионалы, возможно, делают ошибки время от времени, однако их работа основывается не на догадках. Мне приходилось видеть, как уважаемые специалисты по юзабилити попадают «в молоко». Они разрабатывали изощренные тесты для выделения отдельных реакций пользователей на существующие программы, а затем изучали таблицы с результатами, чтобы обнаружить дефекты интерфейса. Когда их точный научный метод вскрывал проблемную область, они скатывались до дилетантских рассуждений: «Что ж, полагаю, мы можем перенести эту кнопку вот в этот диалог» или «Думаю, если мы добавим здесь кнопку, пользователю будет удобнее». Вполне можно сказать: «Я не знаю», однако попытка угадать ответ обречена на провал. Что еще хуже - вид человека, гадающего с отсутствующим взглядом, вызывает у программистов, людей, кровно заинтересованных в результате, однозначную реакцию. Вас списывают со счетов как шарлатана. Руководства по стилю Сотрудничество дизайнера Шелли Ивенсон (Shelley Evenson) и ученого Джона Райнфранка (John Rheinfrank) в исследовательском центре компании Xerox в Пало-Альто в восьмидесятые годы дало жизнь ряду важных идей в области визуальных коммуникаций. Они создали своеобразный словарь, «язык визуального проектирования» для всех фотокопировальных аппаратов Xerox: зеленый цвет обозначал оригиналы, синий принадлежности, а красный - зоны обслуживания. Схожие нетекстовые подсказки весьма полезны в интерфейсах, обладающих высоким когнитивным сопротивлением. Такие подсказки содержатся в «руководствах по стилю», содержащих примеры и предложения по использованию. Многие разработчики программного обеспечения и их руководители, раздраженные многочисленными проблемами взаимодействия, не отказались бы иметь подобное руководство, описывающее, какой интерфейс должен быть у продукта. Многие корпорации разработали руководства по стилю интерфейсов для всех внутрикорпоративных приложений, а многие поставщики программного обеспечения предлагают подобные руководства сторонним разработчикам, занятым производством совместимых программ. Руководства по стилю могут помочь, но они не решают проблем взаимодействия, с 262 которыми связано целеориентированное проектирование. Эти проблемы решаются в каждом конкретном случае по-своему. Разные приложения нужны пользователям для разных целей, и каждый элемент взаимодействия в продукте должен относиться к чему- то определенному. Общий визуальный язык и последовательные органы управления способны помочь, но только их для решения проблемы будет мало. Конфликт интересов Потребуй Билл Гейтс публично от всех прочих компаний прекратить разработки в области проектирования взаимодействия, эти компании просто прогнали бы его со сцены. Однако документ Microsoft, озаглавленный «Interface Style Guide» (руководство по стилям интерфейсов), требует именно этого и является одним из самых сильных конкурентных преимуществ Мiсrоsоft. Microsoft и Apple продвигают руководства по стилям интерфейсов, превознося их мощь и пользу, и на первый взгляд может показаться, что эти компании являются самым компетентным источником подобной информации. Однако интересы владельцев платформы конфликтуют с интересами разработчиков программного обеспечения. Оба создателя платформ применяют скрытую форму принуждения, пытаясь заставить производителей придерживаться стандарта. Независимый разработчик программного обеспечения, не следующий рекомендациям руководства по стилю, не сможет заявить о «совместимости с платформой», лишая свой продукт важного плюса с точки зрения маркетинга. Таким образом, большинство компаний, создающих пользовательские приложения, готовы следовать рекомендациям разработчика платформы. Требуя, чтобы независимые разработчики следовали описанным принципам, разработчики платформ исподтишка подавляют инновации. Тем временем сами разработчики платформ вольны экспериментировать и давать ход новшествам, сколько пожелают. Они могут без угрызений совести пренебрегать собственными руководствами по стилям. Разумеется, никакие другие компании не нарушают эти руководства столь же часто и откровенно, как сами Microsoft и Apple. Я не выступаю за сожжение руководств по стилю и за хаос в интерфейсах. Просто говорю, что к руководствам следует относиться так, как сенатор относится к лоббисту, а не так, как автомобилист к полиции. 263 Законодатель знает, что лоббист действует из корыстных соображений, он вовсе не третья сторона, не заинтересованная в вопросе. Фокус-группы Многие отрасли обнаружили ценность фокус-групп, позволяющих узнать, что нравится и что не нравится потребителям в различных продуктах. Но какими бы полезными ни были фокус-группы для проникновения в мысли потребителей о самых разнообразных продуктах, для бизнеса программного обеспечения они могут быть источником проблемы. Самая большая сложность состоит в том, что большинство людей, включая и профессиональных пользователей программ, не представляют, что может и чего не может программное обеспечение. Поэтому если участник фокус-группы просит включить какую-то возможность, этот запрос часто носит оттенок недальновидности. Пользователь просит того, что считает вероятным, возможным, разумным. Сознательно потребовать чего-то маловероятного, невозможного, неразумного - значит просто выставить себя дураком, а люди не делают этого добровольно. Насс и Ривз из Стэнфордского университета изучали реакцию людей на компьютеры и получили убедительные свидетельства того, что собственная оценка людей таких реакций ненадежна. Они пишут: «Многие распространенные методы, особенно фокус-группы, основываются на предположении, что люди способны к интроспекции в отношении [интерактивного] опыта. Мы считаем, что такое предположение часто неверно». Ларри Кили говорит, что «пользователи отвергнут новые идеи, если вы их предложите». Поэтому фокус-группы - сомнительный инструмент для создания сколько- нибудь новаторских продуктов. В большинстве продуктов, основанных на программном обеспечении, достаточно передовых решений, чтобы фокус-группы потеряли всякий смысл. Фокус-группы могут быть эффективными для определенных категорий продуктов, однако ошибочно будет доверять им в надежной оценке продуктов с высоким уровнем когнитивного сопротивления. Визуальное проектирование В книге «AboutFace» я показал, почему вовсе не графическая основа графического 264 пользовательского интерфейса (ГПИ) 1 сделала его доминирующей формой взаимодействия с компьютером. Скорее, дело было в жестко ограниченном словаре новых интерфейсов. Эта ограниченность и дала ГПИ (в английском варианте GUI (Graphical User Interface)) такое преимущество перед прежними зелеными экранами. Качественный дизайн может стать хорошим вкладом в качество интерфейса, однако многие игроки отрасли все еще приписывают дизайну ценность, которой он попросту не обладает. Я только что вернулся с конференции COMDEX в Чикаго, где судил конкурс по проектированию и созданию прикладных программ для внутрикорпоративного использования 2 . Одно из первых мест заняла программа управления продажей билетов для ежегодного съезда любителей авиации в Висконсине. Кассовый терминал - сердце системы – преднамеренно был сделан неграфическим. Небольшой текстовый экран был необыкновенно строгий, прямоугольный, эстетически примитивный. Однако программа уверенно вышла в лидеры, поскольку при проектировании пристальное внимание уделялось особым потребностям команды добровольцев, занятых продажей билетов у этих добровольцев была ответственная, но простая работа, причем работу эту надо было выполнять быстро и с минимальной подготовкой. Графические интерфейсы замечательно подходят для информирования руководителей о положении дел в целом, но у пользователей описываемого терминала таких потребностей не было, поскольку каждый следующий клиент из очереди не имел ничего общего со всеми остальными клиентами в очереди. Видеть картину в целом в требования к программе не входило. Простого текстового экрана вполне хватило, чтобы продукт завоевал награду. Об этом уроке забывают многие профессионалы. Одна из характерных особенностей ГПИ заключается в их способности отображать растровую графику. Можно запросто делать программные интерфейсы, насыщенные сочной графикой, как в игре Myst. Поэтому многие дизайнеры и художники с радостью наложат грим из привлекательной растровой графики на лицо вашей программы. Однако графические дизайнеры редко задумываются о сопутствующем взаимодействии. Этот интерфейс - одна из тех бесполезных «красивостей», которые вы получаете вместе с новыми компьютерами, и он - до самой последней копейки - стоит тех денег, 1 В английском варианте GUI (Graphical User Interface). – Примеч. науч. ред. 2 Конкурс проводится уже семь лет и называется Windows World Open. Спонсируется компаниями Microsoft, ComputerWorld и Ziff-Davis Events. 265 которые вы заплатили. Его назначение как-то связано с телефоном или приводом CD- ROM, точно не могу сказать. Интерфейс, несомненно, прекрасен, особенно если вы технофил, влюбленный во всякие примочки, однако способ работы с программой непостижим. Это пример того, что мы называем «росписью по трупам». Программисты взяли интерфейс, не подлежащий использованию из-за фундаментальных дефектов в поведенческом проектировании, и завернули его в привлекательную обложку. Поставщики устройств, похоже, особенно увлечены таким подходом, ведь программа шла в комплекте с моим новым компьютером. Подозреваю, дело в том, что интерфейс метафорически следует представлениям о классном аппаратном обеспечении. Мы часто видим красивые продукты, эстетика которых великолепна, а функциональность или способы взаимодействия неадекватны назначению. Причина не в том, что продукт не проектировался, а в том, что он проектировался дизайнером, а не проектировщиком взаимодействия, имеющим инструменты для борьбы с когнитивным сопротивлением. Промышленный дизайн Другая область, к представителям которой обращаются за экспертизой, это промышленный дизайн. Эта хорошо развитое и сформировавшееся ремесло создания трехмерных объектов, приспособленных для вашего взгляда, вашего тела и особенно для ваших рук. В целом промышленные дизайнеры достигают отличных результатов, и упрекать их можно разве что в недостатках, но не в проступках. Они обучаются созданию кнопок, регуляторов и органов управления, которые легко увидеть, нащупать, применить. Однако они не подготовлены специально ни к разрешению проблем 266 когнитивного сопротивления, ни к сотрудничеству с разработчиками программного обеспечения. Кнопки мгновенно опознаются как таковые (для примера возьмите систему дистанционного замка из главы 2 «Когнитивное сопротивление»), даже на ощупь. Их физическое назначение интуитивно понятно, однако логическое назначение (метаназначение) остается неясным, как прежде. Каждый из пяти пультов на моем кофейном столике в отдельности сделан хорошо, но все вместе они делают мой домашний развлекательный комплекс практически бесполезным. Обладая привлекательным внешним видом, эти пульты бесполезны, если требуется переключить канал или заглушить звук в темноте. Дизайнеры, создавшие эти пульты, удовлетворили требования разработчиков развлекательных систем, но не удовлетворили потребности пользователя в качественном взаимодействии. Легко понять, почему менеджеры продуктов путают промышленный дизайн с проектированием взаимодействия. Промышленные дизайнеры тоже имеют дело с интерфейсом между людьми и продуктами высоких технологий. Они тоже облегчают людям применение высокотехнологичных штуковин. Кнопки можно легко найти и нажать, но это не означает, что пользователь поймет, какую именно кнопку следует нажимать. Это проблема когнитивного сопротивления, а не промышленного дизайна. Классная новая технология И последний претендент на трон проектирования взаимодействия - сама технология. Microsoft, в частности, усиленно навязывает эту ложную панацею. Например, Мiсrоsоft утверждает, что интерфейсы упростятся, как только разовьются технологии распознавания голоса и рукописного ввода. 'Уверен, что это глупость. Каждая новая технология всего лишь добавляет возможностей для приведения пользователей в отчаяние – при помощи систем более быстрых и более мощных. Ключ к более качественному взаимодействию кроется в уменьшении неопределенности между компьютерами и пользователями. Обработка естественных языков никогда не даст такого эффекта, поскольку значения слов в человеческой речи весьма расплывчаты. Наше общение столь часто основано на нюансах, жестах и интонациях, что появившиеся системы распознавания слов еще очень долго не смогут (если вообще смогут) научить компьютеры интерпретировать значения наших фраз. Технология распознавания голоса определенно принесет пользу многим продуктам. 267 Но, полагаю, было бы излишне оптимистично надеяться; что какая-то новая технология сможет просто спасти нас, сделать то, что до сих пор не было сделано. Технология требует проектирования взаимодействия для создания законченных решений для пользователей, независимо от того, какое сочетание технологий используется. Итерации Расхожая истина о разработке программного обеспечения гласит, что добиться качественного взаимодействия можно только поэтапным улучшением. Приверженность юзабилити-тестированию во многих крупных компаниях, в частности в Microsoft, привела к распространению этой идеи. Конечно, итерации - важный элемент качественного проектирования: продолжаем работать, пока не получим правильное решение. Однако многие разработчики поняли идею иначе: плюем на проектирование и просто пересчитываем в темноте все кочки, какие есть на дороге. В 1986 году компания Мiсrоsоft поторопилась на рынок с первой версией Windows, которая была столь смехотворна, что заслуженно стала предметом шуток. Шесть месяцев спустя Мiсrоsоft выпустила версию 1.03 и исправила некоторые дефекты. Годом позже Microsoft выпустила версию 1.1, а затем версию 2.0 1 . На каждом этапе развития продукта разработчики пытались разрешить проблемы, созданные в предыдущей версии. Наконец, четыре года спустя после выпуска первой версии, Мiсrоsоft представила Windows 3.0, и все перестали смеяться. Мало какие компании в этой индустрии имеют такое упорство и финансовые возможности, позволяющие выдержать четыре года публичного унижения и добиться, наконец, приемлемого результата. При этом все наблюдают, как лидер де- факто слепо спотыкается практически до победного конца, после чего делают очевидный вывод о том, что именно так и нужно действовать. Однако создание всех этих промежуточных версий дорого обошлось компании. Если бы Microsoft достигла уровня качества Windows 3.0, пропустив пару промежуточных версий, она сэкономила бы миллионы на разработке и поддержке, при этом заработав дополнительные миллионы на продажах - на более раннем этапе жизни продукта. Позиция, защищающая неизбежность создания многочисленных версий продукта, - весьма дорогостоящее убийство здравого смысла. 1 В нумерации версий продуктов Microsoft совершенно нет логики. Windows 3.0 предшествовали по меньшей мере четыре значительных издания системы. Очевидно, что Windows 3.1 – радикально иной и улучшенной версии, содержащей массу серьезных изменений, следовало дать название Windows 4.0. Уверен, что маркетологи Microsoft дали этой версии номер 3.1 потому, что не хотели терять рыночную нишу, уже завоеванную «третьей версией». 268 Стратегия Мiсrоsоft основана на изморе. Говоря военным языком, враг может быть равен вам в умении сражаться (и даже превосходить вас), но, обладая огромным численным перевесом, вы можете просто обмениваться жертвами, пока у противника не закончатся войсковые соединения в терминах производства программного обеспечения это означает: выбрасывайте на рынок некачественный продукт, пусть даже это танцующий медведь, а затем слушайте жалобы и стоны своих клиентов. Доводите до ума то, что им не нравится, и выпускайте обновленную версию. После трех или четырех версий открытые очаги болезней пользователей потухнут, а качество достигнет какого-то приемлемого минимума, поддерживаемого широкой функциональностью, после чего расти уже не будет. Итеративный подход не позволяет создавать замечательные продукты. Стратегия измора не просто дорого обходится и заставляет тратить уйму времени, она омерзительна, потому что негуманна по отношению к пользователям компьютерных технологий. К несчастью, эта стратегия неплохо служит Мiсrоsоft. Компания не устает выпускать сырые, непродуманные, плохо сконструированные и спроектированные продукты на потеху индустрии и осмеяние наблюдателей, как пристрастных, так и беспристрастных. Однако пока специалисты отпускают язвительные замечания, Мiсrоsоft продолжает поддерживать свои первые попытки вторыми, третьими, четвертыми, пятыми, наконец, одиннадцатыми версиями. Такие продукты, как Windows, ActiveX, Word, Access, Windows NT и многие другие, в конечном итоге стали гигантами соответствующих рыночных ниш. Стратегия измора эффективна, только если применяется компаниями, обладающими железобетонным именем, кучей времени, выдержкой игрока в покер и неисчерпаемыми финансами. До сих пор ни один участник компьютерной индустрии не проявил все эти качества на уровне, соответствующем уровню Мiсrоsоft. Впечатляющий коммерческий успех Мiсrоsоft плох тем, что многие не столь крупные компании пытаются повторить ее успех, действуя такими же методами. В долгосрочной перспективе подобная стратегия часто заканчивается плачевно, что показал пример Netscape, однако она продолжает традицию надругательства над конечными пользователями. Игрока, применяющего стратегию истощения, вполне можно победить, но только не подобным подходом. В конце концов, независимо от уровня вашей компании, денег у 269 Microsoft больше. Следует наносить массированные удары по слабому месту Microsoft, а именно в области процесса разработки, ставящего программирование перед проектированием взаимодействия. Мiсrоsоft дважды ущербна в том смысле, что многие люди в компании занимают должность «проектировщика» и выполняют функции, связанные с проектированием. Как показывают выдержки из книги Фреда Муди (см. главу 8 «Отмирающая культура»), культура Мiсrоsoft уже привязалась к неэффективному «проектированию постфактум». Любая компания, готовая заниматься реальным проектированием взаимодействия, сможет побить Мiсrоsоft. |