АкушерствоАнатомияАнестезиологияВакцинопрофилактикаВалеологияВетеринарияГигиенаЗаболеванияИммунологияКардиологияНеврологияНефрологияОнкологияОториноларингологияОфтальмологияПаразитологияПедиатрияПервая помощьПсихиатрияПульмонологияРеанимацияРевматологияСтоматологияТерапияТоксикологияТравматологияУрологияФармакологияФармацевтикаФизиотерапияФтизиатрияХирургияЭндокринологияЭпидемиология

Мотивы создания этой книги

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

Совершив такое открытие, я начал понимать, почему программные продукты настолько плохи с точки зрения пользователя. В 1995 году я написал книгу^[5] о том, что узнал, и она оказала существенное влияние на разработку некоторых из программ.

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

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

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

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

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

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

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

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

Глава 2
Когнитивное сопротивление

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

Дата добавления: 2015-02-05 | Просмотры: 712 | Нарушение авторских прав