Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов
 Скачать 7.24 Mb.
|
|
Глава 14. Мощь и удовольствие Чтобы ваш бизнес получил все выгоды от проектирования взаимодействия, эту дисциплину необходимо сделать составной частью процесса разработки. Ее нельзя добавить задним числом. В предыдущей главе я писал, что проектирование необходимо излагать на бумаге, прежде чем начнется создание кода. Однако в кипящем котле разработки продукта программист по-прежнему имеет возможность игнорировать проектировочный документ, независимо от качества документа. Такое развитие событий весьма вероятно в пассивно-агрессивной культуре разработки программного обеспечения, где инженеры считают любые проектировочные вводные не более чем советом, которому можно следовать, если позволяет рабочая нагрузка и есть желание. Следует четко и ясно дать понять всем участника проекта, что проект это чертеж, которому необходимо следовать, а не просто предложение. Если приверженность проектированию не демонстрируется энергично и открыто, разработчики будут предполагать, что лишь на них возложена ответственность за создание успешного продукта. Есть только один способ эффективно передать эту мысль. Высшее руководство компании должно недвусмысленно заявить всем менеджерам по проектированию и разработке, что программисты освобождаются от ответственности. Оно должно дать понять, что за качество продукта отвечает теперь команда проектировщиков, и проектировщики наделяются полномочиями требовать, разумеется, под присмотром руководителей. Программисты вольны импровизировать внутри программы, но любой аспект взаимодействия с пользователем, имеющий четкое определение, должен быть реализован строго по описанию. Описание можно подвергать сомнениям, но нельзя в одностороннем порядке игнорировать или переиначивать. Предписания проектировщиков не следует считать советом, который можно воспринимать частично или видоизменять. На команду проектировщиков возлагается ответственность за все, с чем вступает в контакт пользователь. Не только за программное, но и за аппаратное обеспечение. Следует принимать во внимание и сопутствующие программные модули, такие как программы установки. Это, вероятно, наиболее радикальное требование, выполнение которого необходимо 292 для успешного проектирования, причем такое, которое требует наибольшей культурной адаптации. Позже в этой главе мы обсудим культурные вопросы более подробно. А сейчас рассмотрим пример компании, успешно включившей проектирование в процесс разработки. Пример налаженного проекта Моя студия проектирования недавно завершила работу над одним из самых успешных проектов. Клиент - небольшая компания Sun Healthcare Systems, Inc., создающая программное обеспечение для управления всевозможными аспектами работы учреждений системы здравоохранения. На первых встречах я старательно объяснял заказчику важность персонажей и рассказывал о том, какую роль мы им отводим в процесс е проектирования. К нашему большому удовольствию и удивлению команда SHS восприняла эту концепцию очень благосклонно. На первое проектное совещание они принесли собственный набор из десятка уже определенных персонажей. Нам все же пришлось потратить время на изучение предметной области, чтобы проверить качество персонажей и доработать их, зато полностью исчезла необходимость убеждать разработчиков и маркетологов в применимости персонажей как инструмента. Бизнес SHS приводит эту компанию к тому, что Мишель Борк (Мiсhеl Воurque) из компании Clinidata, расположенной в Монреале, называет«Клиническим водоворотом». Кабинеты врачей попали в число первых объектов компьютеризации в малом бизнесе, однако преобразованию поддалась лишь финансовая часть. Та же сторона, где врач взаимодействует с пациентом, упрямо сопротивлялась пришествию цифровой эры, и остается одним из последних бастионов некомпьютеризованного мира. Усилия SHS в основном направлены на администрирование, но существенная часть задач оказывается прямо в этом водовороте. Мы участвовали в небольших проектах других компаний, работающих в этой области, но в самом центре водоворота мы еще не были. Возможность работать над столь серьезным и сложным проектом нас сильно воодушевила. Воодушевились и в компании SHS, но для начала сообщили нам, что масштабы бизнеса настолько велики, что компания сомневается в нашей способности эти масштабы осилить. SHS считала, что ее бизнес просто слишком велик и сложен для 293 понимания. Для нас это был вызов, и мы приняли его с готовностью. Проект был большой. Мы выделили пять ключевых персонажей. Ни в одном из прошлых проектов не бывало больше трех. Поначалу мы с подозрением отнеслись к такому числу, однако, пересмотрев результаты, поняли, что SHS действительно пытается охватить огромный сегмент рынка здравоохранения. Разумеется, создание программного обеспечения сразу для пяти ключевых персонажей - слишком крупный проект. В SHS это поняли, поэтому продукт проектировался и создавался поэтапно, по одному персонажу на этап. Дэвид Вест (David West), вице-президент по разработке и наш связной в SHS, помимо прочего снискал доверие и уважение других сотрудников этой растущей организации. Маркетологи знают, что он действует в их интересах. Знают это и программисты. Знают, что он суров, но справедлив. Он подобен камню в бурлящих водах разработки. Он верен процессу проектирования, и другие разработчики стали доверять нашей работе, воспринимать ее всерьез, как спецификацию. Когда SHS вступила в контакт с Соорег Interaction Design, ее отдел разработки программ был организован в соответствии с уже имевшимся программным продуктом. А продукт имел два модуля - клинический и финансовый. Проведя исследование и разработав персонажи, мы быстро поняли, почему существующая система не способна удовлетворить медиков. Если даже не учитывать серьезные проблемы взаимодействия, деление между информационными подсистемами (клинической и финансовой) было надуманным. Это порождало лишнюю бумажную работу, которую пользователь был вынужден выполнять, чтобы обойти недостатки системы обработки данных. Каждый пользователь обитал на собственном островке данных, поскольку два модуля системы не были взаимосвязаны. Мы рекомендовали создать объединенную медицинскую карту пациента, содержащую как клиническую, так и финансовую информацию для консолидированной базы данных, а также модульный пользовательский интерфейс, позволяющий каждому персонажу получать доступ к информации, необходимой для решения ее задач. В результате SHS перепроектировала базу данных, лежащую в основе продукта. И что примечательно, реорганизовала сотрудников отдела разработки в соответствии с этой новой архитектурой! Разработчики сформировали две новые группы. Одна из них работала с архитектурой медицинской карты и базой данных, а вторая - с интерфейсами 294 персонажей. Все дальнейшие программные спецификации и документы в SHS будут содержать имена персонажей для четкого определения функций. Программисты SHS поступили мудро, откладывая программирование до завершения работ по проектированию. Дэвид и команда SHS хорошо понимали, что простой программистов обходится недешево, но гораздо дороже обходится заливка бетонной смеси программного кода не там, где требуется. Программисты работали над логикой базы данных, не затрагивающей взаимодействие с пользователем. Кроме того, они разбили проект на несколько фаз, среди которых был и перевод существующей версии продукта на более высокий уровень. Таким образом, программистам было чем заняться, и конфликтов с долгосрочными стратегическими планами не возникало. Для того чтобы гладко синхронизировать нашу работу с работой программистов, мы разделили процесс на несколько крупных частей. Мы договорились, что на начальном этапе проектирования будем уделять внимание лишь двум персонажам из пяти ключевых, а к трем остальным вернемся позже. Опять же, это позволило вести проектирование в опережающем темпе, и в то же время разработчики не сидели без дела. Осознанное проектирование взаимодействия В большинстве компаний проектирование основного продукта или услуги считается важнейшим умением. В мире высокотехнологических продуктов, основанных на программном обеспечении, считается (и ошибочно), что проектирование продукта находится в компетенции инженерного персонала. В действительности акт творения состоит из двух частей: проектирования и программирования. Готовность разрешить проектировщикам взаимодействия работать с важнейшим элементом бизнеса наряду с инженерами требует значительных культурных перемен. В любой компании, независимо от ее специализации, сотрудники знают, что имеют определенные обязанности. Так, в компании, производящей катушки для динамиков, руководитель производства знает, что хотя его задача заключается в покупке лучшего сырья по наинизшей цене, он не сможет подписать контракт с поставщиком, пока не получит одобрение совета компании. Руководитель производства не очень разбирается в юридических вопросах контрактного дела, однако знает, что не стоит создавать 295 трудности своей компании, пренебрегая советом профессионалов в области контрактов и сделок. Даже не разбираясь в контрактном деле, точнее, как раз поэтому, руководитель знает, что необходимо привлечь юриста. Приемщик в грузовом доке, обладая самым низким рангом, знает, что уполномочен расписываться лишь за грузы, доставка которых уже оговорена, но не уполномочен расписываться за иные. Основатель и президент компании, выпускающей катушки, также вполне осознает необходимость участия юристов на всех уровнях. Он не имеет профильного юридического образования, а потому советуется с помощником, прежде чем подписывать какие-либо документы. Ни один из этих людей не обладает специальными знаниями в области юриспруденции, но каждый полностью осознает важность участия юриста. Никто в Компании ничего не подпишет, пока юристы не подтвердят, что это можно сделать. Сама по себе компания осознает необходимость в таком присмотре и даже, временами, вмешательстве. Такое осознание, распространяющееся на всю компанию, верно и для других областей. Когда катушечной компании потребовалось новое производственное здание, она наняла стороннего профессионала, архитектора. Руководитель производства и президент хорошо разбираются в особенностях производственных мощностей, однако знают, что их понимание нюансов конвейерной работы и строительства зданий поверхностно. Никому в этой компании и в голову не придет расширять производство, не посоветовавшись сначала с архитектором. Архитектор переводит потребности пользователей в термины, понятные строителям. То же верно и для рекламы. Руководитель отдела маркетинга не будет просить рабочего описать выгоды продукта для брошюры или для профильного отраслевого журнала. Каждый в компании, независимо от опыта, понимает, что реклама - дело профессионалов, и что специалисты по рекламе могут обеспечить компании отличный пиар. Разумеется, эти специалисты могут быть сотрудниками компании, как могут быть и наняты в рекламном агентстве. Оба варианта хороши. Приведенная аналогия не идеальна. Ни архитектура, ни юридическая консультация для производственной компании не лежат в сфере основного занятия. Однако 296 программирование - это создание продукта, а именно создание продукта, как правило, и считается занятием компании. Учитывая непосредственное влияние продукта на бизнес, можно ожидать, что любая компания будет вдвойне осторожна, чтобы бразды правления не попали в плохие руки, - еще более осторожна, чем в случае с рекламой, архитектурой или приобретением чего-либо. Мы должны сделать так, чтобы в компании поняли: проектирование взаимодействия представляет собой область, требующую профессиональных навыков, и что интерактивные продукты нельзя просто конструировать инженерными способами, их следует еще и проектировать, чтобы добиться успеха на открытом рынке. Польза от перемен В мире программного обеспечения так много апологетов, а их влияние настолько велико, что власть этой касты ослабевает очень медленно. Но эта власть ослабнет обязательно. Для этого достаточно, чтобы люди поняли: технологии не обязательно должны быть бесчеловечными. Чем чаще пользователи будет сталкиваться с программами, не унижающими их человеческое достоинство, тем быстрее они будут терять терпение, встречаясь с иными программами, которые оскорбляют и раздражают их. Они пинками погонят танцующих медведей прочь. Когда пользователей таких продуктов было немного, все они были и непосредственными участниками процесс а, а потому понимали, насколько революционна эта технология. По мере проникновения технологии во все сферы жизни все меньше причастившихся осознают, насколько это достижение велико. Они не готовы простить продукту некачественное взаимодействие только потому, что создание этого продукта отняло много сил. Следование за технологией кажется идеей неплохой, однако результатом обычно становятся утомляющие продукты, более сложные наследники тех, что уже были созданы. Проектирование взаимодействия позволяет вырваться из этого круга и создавать продукты, которые делают то, что никогда раньше не делалось. Проектирование взаимодействия делает продукт привлекательным, награждая уникальным рыночным преимуществом - преданностью покупателей. Если покупателя осчастливил ваш продукт, этот человек надолго останется клиентом вашей компании и вашего брэнда. Если же ваш продукт - очередной танцующий медведь, клиенты будут 297 оглядываться в поисках более простых и дружелюбных альтернатив. Проектирование взаимодействия может сократить затраты времени на разработку продукта. Если вы заранее знаете, что именно следует создавать, то потратите меньше времени на поиски верного пути. Создание правильного продукта - всегда итеративный процесс. Чтобы добиться точности в деталях, требуется несколько попыток. Проектирование взаимодействия позволяет значительно уменьшить количество итераций. Выпуск каждой новой версии продукта сопряжен с огромными затратами, поэтому, уменьшая количество версий с четырех до двух, вы экономите массу денег и времени. Процесс разработки удешевляется, если версий становится меньше и код выбрасывается не в таких количествах. Программисты часто жалуются, что наши проекты требуют создания более сложного кода, и зачастую они правы. Однако в целом размер кода получается обычно меньшим. Стоимость кода не сильно растет с увеличением сложности, однако значительно растет с увеличением объема. Каждую лишнюю строку кода необходимо тестировать, отлаживать и поддерживать. Почему они не едят пирожных? Я живу и работаю в Кремниевой Долине, штат Калифорния. Практически все знакомые мне люди вовлечены в индустрию высоких технологий. Мы все обеспечены, образованны, географически и социально мобильны, замечательно управляемся с компьютерами, сотовыми телефонами, видеомагнитофонами, банкоматами и всеми прочими представителями зверинца продуктов, основанных на программном обеспечении. Когда я обедаю в Crescent Park Grill или Spago, посетители за соседними столиками все время обсуждают клиент-серверные архитектуры и веб-интерфейсы. Восхитительное место для жизни, но оно не дает представления о большинстве жителей этой страны, не говоря уже обо всей планете. Здесь в Долине наши оценки качества высокотехнологических продуктов могут искажаться легко и радикально. Мы забываем, насколько сложно в действительности применять эти продукты. Десять лет назад консультант по розничным продажам Сеймур Меррин (Seymour Merrin) сказал, что нам проще было убедить покупателей, что программами легко пользоваться, чем сделать так, чтобы программами было легко пользоваться. Высказывание Меррина было циничным, однако он также выражал удивление, что нам 298 сошла с рук столь наглая ложь. Сегодня его слова все еще справедливы, но рост высоких технологий не оставляет возможности и дальше выезжать на одном цинизме - нам требуется настоящее решение. Люди знают, что компьютерами очень трудно пользоваться, однако предполагают, что тому есть причины. Большинство считает, что лучше уже и быть не может. Простые пользователи, не вовлеченные в индустрию компьютеров, приходят в крайнее раздражение из-за сложных в применении продуктов, тогда как люди, занятые созданием продуктов, в массе своей удовлетворены состоянием дел. Программистам не кажется, что компьютерами сложно пользоваться, поэтому они готовы терпеть некоторые вещи, пока есть возможность поиграть в технологические игры, создавая новых классных танцующих медведей. Что до остальных из нас, мы получаем программы, соответствующие требованиям, а требовали мы до сих пор очень немного. Разработчики программ засыпают нас штучками, примочками, возможностями, которые нам не нужны, которые мы никогда не применяем, но вынуждены оплачивать. Мы требуем, чтобы программы не сбоили, поэтому программы подвергаются исчерпывающему тестированию и, как следствие, обладают разумной надежностью. Мы требуем новых версий немедленно, и компании выпускают версии с безумной скоростью. Но, не задумываясь о том, что жизнь может стать лучше, мы не требуем, чтобы продукты стали мощными и приятными, поэтому продукты и остаются слабыми, угнетающими. Время от времени у потребителей появляются призрачные надежды, что следующая волна технологии, скажем, распознавание голоса, сделает программные продукты простыми в применении. Надеяться на это наивно и неумно. Мне грустно видеть, как апологеты грубо подыгрывают таким надеждам. Программное обеспечение уместно сравнить с пластилином - оно может принимать любую форму, какая будет угодна авторам. Они не создают простые в применении программы не потому, что это невозможно, а потому, что не умеют. Чтобы не признавать этот неудобный факт, они заявляют, что лучше сделать просто невозможно «по техническим причинам». Пользователи компьютеров, программистами не являющиеся, вынуждены соглашаться со специалистами и страдать, или же не соглашаться со специалистами и - вот именно - все равно страдать. Не будучи специалистами, они не способны предлагать собственные решения, поэтому к ним относятся как к бесполезным 299 нытикам. Штат Детройт производил гигантские хромированные прожорливые автомобили и лицемерно утверждал: «Мы даем потребителям то, что им нужно». Во время нефтяного кризиса семидесятых японцы вышли на рынок с экономичными небольшими автомобилями и нанесли Детройту удар, который не забудется никогда. Сегодня автомобильная индустрия Америки проявляет гораздо большее уважение к желаниям потребителя и уже не осмеливается утверждать, что все знает лучше. Япония захватила позиции на автомобильном рынке, выполнив желания пользователей, о которых те и не подозревали. При этом потребители способны отличить хорошую вещь от плохой, если им дадут ее увидеть. Точно так же высоты в проектировании программного взаимодействия сегодня остаются свободными, они не захвачены никем. Мiсrоsоft уязвима не меньше, чем General Motors в 1974 году. Массовый рынок потребителей, не знакомых с технологическими тонкостями, охотно принимает простые в применении продукты, что и подтверждает взрывной рост среды Web. Люди, привлеченные простотой ее использования, точно так же оценят качественно спроектированные продукты, делающие сложные вещи простыми для пользователей. Потребители, не знакомые с тонкостями технологии и не принадлежащие к анклавам вроде Кремниевой Долины, не будут требовать изменений просто потому, что не могут образовать сплоченную группу. Разумеется, хорошее от плохого они отличают, но только после того, как хорошее и плохое появляется на полках магазинов. Изменения произойдут только тогда, когда люди, принимающие участие в процессе и способные повлиять на ранние стадии развития продуктов, заинтересуются решением этой проблемы. Программисты вовлечены в конфликт интересов, а потому мой призыв адресован апологетам в самом сердце этой индустрии высоких технологий. Современные бизнесмены вовлечены в жизнь этой индустрии, хотят они того или нет. Вряд ли еще остались в мире предприятия, не вставшие на путь внедрения информационных технологий. Ни один из современных нам продуктов, основанных на программном обеспечении, не способен дать мощь и удовольствие от применения людям, не входящим в число одержимых технологией. Инженерное же сообщество просто сообщает, что пользователям придется получить «компьютерное образование». Полагаю, в историю эта |