Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов
 Скачать 7.24 Mb.
|
|
Глава 10. Проектирование ради результата Целеориентированное проектирование начинается с создания персонажей и определения их целей. В предыдущей главе я подробно рассказало персонажах. В этой главе речь пойдет о целях. Я покажу, как определять цели и применять их на практике, в качестве мощного средства проектирования. Персонажи и цели неразделимы, они - как разные стороны одной медали. Персонаж существует, потому что у него есть цели, а цели существуют, чтобы придавать смысл персонажу. Мы решаем задачи, чтобы достичь целей До того как цифровая эра познакомила нас с когнитивным сопротивлением, дизайн (проектирование) был понятием в основном художественным, и мнение одного человека о качестве дизайна продукта было ничем не хуже мнений других людей. Когнитивное сопротивление приходит вместе с взаимодействием, а взаимодействие необходимо лишь в присутствии намерения, цели. В этом новом свете природа дизайна изменилась. Художественная составляющая никоим образом не исчезла. Она лишь попала в тень более серьезной потребности - достижения целей пользователя. Таким образом, в современном проектировании воспринимаемое качество - уже не спорный вопрос, а свойство, которое можно подвергать системному анализу. Иначе говоря, в ярком свете пользовательских целей мы можем достаточно просто определить, какой дизайн будет соответствовать намерениям, независимо от чьего-либо мнения или, если уж об этом зашла речь, эстетических качеств. Слова «качественное проектирование взаимодействию» обретают смысл лишь в контексте разговора о человеке, непосредственно участвующем. Во взаимодействиях и имеющем при этом определенные намерения. Намерения не существуют без людей. Эти элементы неразделимы. Именно поэтому ключевыми составляющими нашего процесса 192 проектирования являются цели и персонажи - намерения и люди. Более того, наиболее важными целями считаются личные цели интересующие одного конкретного человека. С вашим продуктом взаимодействует реально существующий человек, а вовсе не абстрактная корпорация, поэтому личные цели людей вы обязаны ставить выше целей корпорации. Ваши пользователи будут изо всех сил стараться достигнуть целей бизнеса, но лишь после того, как достигнут собственных. Самая важная личная цель - сохранить достоинство, не почувствовать себя глупо. Сущность качественного проектирования взаимодействия заключается в изобретении таких взаимодействий, которые помогут пользователям достигать практических целей, не препятствуя достижению личных целей. Задачи не являются целями Цели - не то же самое, что задачи. Цель - это конечное состояние, тогда как задача - переходный процесс, необходимый для достижения цели. Очень важно различать задачи и цели, ведь их так легко спутать. Если моя цель - побездельничать в гамаке, почитывая воскресную газету, то придется мне сначала подстричь лужайку. Моя задача – подстричь газон, тогда как моя цель - отдых. Если бы я мог нанять кого-то для стрижки газона, то достиг бы цели, не прикасаясь к газонокосилке. Различать задачи и цели просто. Задачи меняются вместе с технологией, тогда как цели обладают приятной особенностью - они очень стабильны. Например, в путешествии из Сент-Луиса в Сан-Франциско мои цели скорость, удобство, безопасность. Направляясь в Калифорнию на золотые прииски где-нибудь в 1850 году, я путешествовал бы в своем новом, высокотехнологичном фургоне Конестога 1 . В интересах безопасности я взял бы с собой ружье «винчестер». Направляясь из Сент- Луиса в Caн-Франциско в 1999 году, я путешествую в новом, высокотехнологичном Боинге-777. В интересах безопасности «винчестер» имеет смысл оставить дома. Мои цели остались неизменными, однако задачи изменились вместе с технологиями настолько, что стали прямо противоположными. 1 Конестога (Conestoga) – местность в Пенсильвании, где были созданы фургоны такого типа. – Прим. перев. 193 Противопоставление целей и задач встречается сплошь и рядом. Если президент желает, чтобы за океаном наступил мир, он посылает пехотинцев, вооруженных автоматами, самолетами, бомбами. Его задача - война. Его цель - мир. Когда адвокат корпорации желает избежать конфликта с коллегой, то вступает в прения о положениях контракта. Цель адвоката согласие, а задача - спор. Цель - стабильная сущность. Задачи преходящи. Вот одна из причин, по которой проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда. Программисты занимаются проектированием, ориентированным на задачи Очень многие разработчики начинают проектирование с вопроса: «Каковы задачи?». Такой подход дает возможность сделать работу, но не позволяет даже приблизиться к наилучшему решению, а также совершенно не удовлетворяет пользователя. Проектирование, ориентированное на задачи вместо целей, - вот одна из основных причин раздражающего и неэффективного взаимодействия. Вопрос «каковы цели пользователя?» позволяет нам смотреть через незамутненное стекло и создавать более качественный и уместный дизайн. Компьютерное программирование, если добраться до сути, - это создание подробных пошаговых описаний процедур. Процедура есть рецепт решения задачи. Хорошие программисты по необходимости имеют Процедурный взгляд на вещи, взгляд, ориентированный на решение задач. В конечном итоге для достижения целей пользователя задачи необходимо решать, однако существуют различные акценты и различные последовательности выполнения задач. Лишь некоторые из последовательности удовлетворяют личным целям пользователя. 194 Проектирование, ориентированное на цели Когда для решения поставленных проблем проектировщики взаимодействия анализируют цели, они обычно находят совсем иные, более подходящие решения. Цель Дженнифер, офис-менеджера небольшой компании, - сделать так, чтобы дела в офисе шли гладко. Разумеется, она не хочет ни чувствовать себя глупо, ни совершать ошибки. Сэтой целью она должна обеспечить бесперебойную работу компьютерной сети. Требуется, во-первых, правильно настроить сеть, во-вторых, наблюдать за работой сети и, в-третьих, периодически изменять конфигурацию сети для поддержания максимальной производительности. В представлении Дженнифер ее работа состоит в интеграции всех трех задач для достижения цели - гладкой работы офиса. С точки зрения Дженнифер эти три задачи действительно не существуют обособленно. Она не видит большой разницы между изначальной настройкой сети и последующей сменой конфигурации. А теперь обратимся к Клэнси, разработчику программного обеспечения, перед которым стоит задача создать программу для Дженнифер. В присущем Клэнси представлении хомо логикус программа решает три задачи (имеет три функции) - под каждую задачу будет отведен отдельный программный модуль. Клэнси кажется естественным, что для каждой из функций отведен собственный участок интерфейса. Ведь это логично. Клэнси думает об интерфейсе, содержащем иерархический список системных компонентов в левой части, а в правой части - информацию о выбранном элементе иерархического списка. Такой интерфейс обладает одним преимуществом - он утвержден компанией Microsoft, а потому кажется программистам разумным. Пользователю придется прощелкать множество системных компонентов, чтобы понять, что происходит с системой, однако вся нужная информация ему доступна только по специальному запросу. На сцену выходит Уэйн, проектировщик взаимодействия, которому поручено осчастливить и Дженнифер и Клэнси. Обладая сознанием проектировщика, Уэйн понимает, что программа должна предстать перед Дженнифер в виде, наиболее точно соответствующем ее целям, и при этом содержать всю необходимую функциональность (здесь Дженнифер – ведущий персонаж). Уэйн также знает, что не может требовать от Клэнси усилий по реализации неразумных или технически невозможных интерфейсных решений. 195 Уэйну понятно, что у Дженнифер только одна цель - работа без сбоев, и он проектирует интерфейс, позволяющий Дженнифер с одного взгляда увидеть, что все гладко. Если где-то возникает узкое место, интерфейс четко обозначает эту точку сети наглядным способом, так, что она бросается в глаза, и это позволяет Дженнифер исследовать и разрешить проблему, взаимодействуя непосредственно с экранным представлением той области, где эта проблема возникла. Уэйн знает, что для Дженнифер нет разницы между наблюдением за системой и ее настройкой, поэтому интерфейс должен отражать данные ожидания. Ей приходится взаимодействовать с системой в единственном случае - когда она точно знает, что для этого есть причины. С точки зрения Клэнси, код для отображения производительности компонентов сети и код для настройки этих компонентов - это две различные процедуры. В мышлении, ориентированном на задачи, они не связаны одна с другой. Однако в мышлении, ориентированном на цели, они связаны неразрывно. Дженнифер никогда не займется переконфигурированием, если у нее не будет для этого веской причины, например, может снизиться производительность. Более того, Дженнифер и в процессе переконфигурирования будет внимательно следить за производительностью. Проектирование для удовлетворения целей персонажа пользователя ясно показывает альтернативный подход к предоставлению функциональности. Часто такой подход дает качественно лучшие способы решения прозаических проблем проектирования. Вот некоторые примеры. Целеориентированные телевизионные новости В одном из наших проектов клиент работал над семейством приложений для поддержки процесса создания передачи теленовостей. С точки зрения инженера, мыслящего в терминах задач, такие передачи создаются так же, как строятся мосты - всю передачу делают за один прием. Но мы установили, что у ведущих новостей нет цели «создавать» передачу в течение какого-то времени, у них, скорее, есть цель всегда иметь в наличии передачу, которая со временем только улучшается. Каждая передача новостей - это живое существо, очень гибкое и органичное, всю свою жизнь проводящее во взрослом состоянии. В новостном бизнесе случается всякое, поэтому ведущий всегда желает иметь место для отступления. Его цель - всегда иметь разумную передачу, которую не стыдно 196 выпустить в эфир. Вечерние новости появляются утром в виде полноценной, готовой к передаче в эфир записи. Эта запись длительностью 22 минуты (не считая рекламных вставок) всегда находится в состоянии полной готовности. Под каждое направление новостей отведено определенное время, и в сумме все сюжеты всегда имеют продолжительность 22 минуты. Здесь можно провести аналогию с подстройкой фокуса размытого изображения: границы новостной передачи никогда не меняются, а вот содержимое становится более точным и выдержанным: по мере настройки. Начиная с 10 утра передача готова к выходу в эфир в любой момент, однако лучше всего выйти в эфир приблизительно в 5 часов вечера. Каждая передача состоит из 20-30 сюжетов, переполненных заставками видеоклипами, репортажами и интервью. В течение утра приоритеты сюжетов изменяются, как изменяется порядок показа и отведенное под сюжеты время, отражая взгляды руководителя передачи. В начале второй половины дня внимания могут потребовать последние известия, изменял порядок следования других сюжетов и, вероятно, даже исключая некоторые сюжеты из программы. Корреспонденты и режиссер будут вносить исправления и изменения в сценарий до последней секунды, иногда до самого начала эфира. Разработчики программного обеспечения, рассматривая проблему с точки зрения задач и процедур, создали приложение, позволяющее создавать передачу посюжетно. Что было очень логично, очень разумно, но совершенно неправильно. Передача становилась полноценной только непосредственно перед эфиром, а изменение любого фрагмента разрушало существующую структуру, делая передачу неподходящей для эфира и требуя дополнительной работы над фрагментами. Мы сделали набросок приложения, работа в котором начиналась с готовой к вещанию в вечерние часы передачи теленовостей. Приложение позволяло корреспондентам и режиссеру постоянно вносить изменения, как если бы вся работа выполнялась вручную. Но помимо этого мы задействовали и мощь компьютерных технологий. К примеру, если сюжет в последнюю минуту удалялся из программы, отведенное под него время автоматически отдавалось оставшимся сюжетам по схеме приоритетного распределения. 197 Целеориентированное управление классом В другом проекте нас попросили спроектировать систему управления классами для учителей начальной школы. Разработчики создали модули для проведения тестов, отслеживания успеваемости и доступа к базе данных учебных планов. С точки зрения задач, решение казалось адекватным. Выражаясь метафорически, мы заглянули в глаза учителя, чтобы определить, чего в действительности хочет учитель начальной школы, и получили удивительный ответ. Мы узнали, что учителя чувствуют себя изолированными в классах, они жаждут информации о том, насколько эффективна их деятельность. Чтобы расти в профессиональном плане, учителю необходим способ, позволяющий оценивать собственную успеваемость. Эта простая потребность неочевидна при разборе процесса обучения на составляющие задачи. В тоже время, если исследовать цели, эта человеческая потребность становится очевидна. В своем проекте мы предусмотрели модуль, отслеживающий достижения учителей по семестрам и аудиториям. Этот инструмент позволил учителям получить более осмысленное представление о состоянии дел, что прибавило им уверенности в своей работе. Цели личные и цели практические Выше я утверждал, что сущность качественного проектирования взаимодействия состоит в том, чтобы позволить пользователям достигать практических целей, не отказываясь от целей личных. Хомо логикус и апологеты обычно находят излишним чересчур пристальное внимание к личным целям и стараются этого избегать. Однако различие между двумя видами целей - критическая составляющая успеха. Для примера возьмем моего коллегу Теда. Он только что прислал мне по электронной почте сообщение, в котором жалуется на свой новый телевизор. Много неприятных часов он провел за чтением руководства, потому что иначе не мог настроить многочисленные режимы ящика. Он, предположил, что в телевизоре должен быть экранный диалог, сопровождающий пользователя на каждом шаге настройки и который позволил бы обойтись без чтения руководства. Его решение лучше чтения руководства, но, не будучи проектировщиком, Тед, естественно, подошел к проблеме устаревшим, механическим, образом: сосредоточился на задачах. Экранные диалоги упростили бы задачу настройки режимов, но давайте подойдем к проблеме иначе. Мы взглянем на цели Теда, и это даст нам возможность создать решение, качественно превосходящее то, 198 которое предложил он. Начнем с оценки целей Теда. Здесь всегда предпочтительно начинать с главного. Очевидно, нам известно, что Тед желает смотреть телевизор. Он только что заплатил уйму денег за новый ящик, поэтому так же очевидно, что он желает воспользоваться преимуществами новых суп ер возможностей этого телевизора. Эти практические цели непосредственно связаны с задачей настройки нового телевизора. Но мы не должны ни на секунду забывать, что Тед - человек, а значит, обладает выраженными личными предпочтениями, которые можно назвать целями. Тед не хочет, - чтобы новая вещь его унижала, он не хочет, чтобы из него делали идиота. Тед не хочет совершать ошибки. Ему нужно чувство достигнутого результата, и чем скорее, тем лучше. Он хочет развлечься. Эти личные цели жизненно важны. С точки зрения проектировщика взаимодействия они важнее, чем практические цели еда. Тед жаловался не на то, что не может смотреть новый телевизор, и не на то, что слишком много заплатил, и не на то, что не может воспользоваться новыми супервозможностями. Он жаловался потом, что телевизор заставил его чувствовать себя глупо. Конечно, Тед выразился иначе, ведь сама фраза «ящик делает из меня идиота» заставляет человека чувствовать себя глупо, но очевидно, что смысл письма был именно такой. Взаимодействуя с телевизором, он случайно делал ошибки. После подключения телевизора у него ушел час, чтобы получить хоть сколько-нибудь удовлетворительный результат. Процесс настройки режимов вряд ли можно назвать развлекательным. Взаимодействие, присущее продукту, соответствовало практическим целям Теда, но шло вразрез с его наиболее важными личными целями. Особые качества, сделавшие новый телевизор Теда классическим примером высокотехнологичного танцующего медведя, заключены не в способе достижения практических целей владельца, но в том, как продукт не смог удовлетворить его личные цели. Как бы мы спроектировали новый интерфейс для телевизора, вооруженные информацией о святости личных целей Теда? Во-первых, чтобы владелец быстро почувствовал, что он чего-то достиг, мы должны гарантировать, что телевизор будет хорошо работать сразу после включения. Ненужно, чтобы работали сразу все возможности, но какие-то должны работать, причем хорошо. Очевидно, этот первый тест на удовольствие невозможно пройти при помощи процесса настройки режимов. 199 Разработчики программного обеспечения относятся ко всем режимам одинаково, а потому валят их в одну кучу. Однако мы можем с легкостью предположить, какими должны быть первичные настройки, что позволит телевизору выполнять базовые функции, а пользователю даст отсрочку в знакомстве с прочими, более сложными возможностями продукта. Необходимо вытаскивать параметры из кучи. Это не техническая задача, а простая перестановка приоритетов в проектировании. Наш проект телевизора подпадает под определение успешного: Тед может вынуть телевизор из коробки, воткнуть его в розетку и сразу же довольно расслабиться в своем кресле, переключая каналы. Большинство практических целей достигнуто, а личным целям при этом ничто не вредит. Обратите внимание, что отсутствие препятствий в достижении личных целей важнее мгновенного достижения всех практических целей. Это различие также иллюстрирует дополнительные идеи проектирования взаимодействия и обеспечения функциями. Решение должно обеспечить Теду способы достижения всех его практических целей, но проектирование взаимодействия должно четко показать ему, как он может выполнить свои личные задачи. |