Участник:Caesarion/Мои черновики/Психбольница в руках пациентов

Это мой черновик страницы ‘Психбольница в руках пациентов’. Чтобы стать полноценной страницей, необходимо поработать над оформлением и удалить лишние цитаты. Вы можете помочь мне и «Викицитатнику»: редактируйте здесь или переносите цитаты непосредственно на Психбольница в руках пациентов. Если вы считаете, что какое-то высказывание не должно (или наоборот: обязательно должно) войти в конечную версию, напишить об этом под ним. Но не удаляйте цитаты отсюда.

Цитаты

Предисловие

Пол Саффо (Paul Saffo), директор Института Будущего

Спасайся, кто может - началось вторжение компьютеров.

…Все мы пациенты технопсихушки, которую сами же создали.

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

Введение

«Алан, это называется главами».

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

Всех деловых людей можно разделить на две категории: на тех, кто овладеет высокими технологиями, и тех, кто скоро покинет деловую арену.

Кто-то сказал: «Человеку свойственно ошибаться, но чтобы провалить дело капитально, необходим компьютер».

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

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

Повторюсь, чтобы решить проблему, ее следует сначала разобрать на составляющие. Я ищу решения, а не козлов отпущения.

Дрюкер утверждает: «Самая нужная вам информация - информация об окружающем мире, и этой информации у вас нет».

Новая-преновая линия такова, что нам суждено пока оставаться со старой-престарой экономикой.

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

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

Разумеется, такой подход требует мышления, с которым не знакомы деловые люди XXI века. Им следует не снижать затраты на создание каждого объекта в отдельности, но повышать затраты на создание всех объектов в совокупности. Это сущность новой экономики, и именно об этом говорил Питер Дрюкер.

По иронии судьбы лучший способ увеличить прибыльность в информационную эру состоит в том, чтобы больше тратить.

Мой первый наставник, Дэн Хоакин (Dan Joaquin), любил повторять, что правильный обратный вариант старой истины «получаешь то, за что платишь» звучит так: «не получаешь того, за что не платишь». Действия без планирования всегда чреваты риском потратить слишком много. Фокус в том, чтобы потратить нужное количество денег, и он требует значительных познаний в управлении созданием программного обеспечения.

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

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

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

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

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

На мой взгляд, существует два типа руководителей: инженеры и запуганные инженерами. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно испорчена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у деловых людей и программистов нет общих инструментов и общих целей. Человек разумный делегирует человеческие проблемы хомо логикус, не осознавая, что решение могло бы оказаться намного более приятным в случае применения - на исполнительном уровне - уместных финансовых и организационных моделей.

Часть I. Компьютерная безграмотность

Глава 1. Загадки века информации

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

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

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

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

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

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

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

Индустрия высоких технологий по недосмотру поставила во главу программистов и инженеров, поэтому доминирует их сложная в применении инженерная культура.

Мы позволили пациентам завладеть психбольницей.

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

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

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

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

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

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

…Интерактивные продукты должны проектироваться проектировщиками взаимодействия (interaction designers), а не разработчиками программного обеспечения (software engineers).

…Правила инженерных наук к людям не применимы.

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

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

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

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

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

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

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

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

Танцующие медведи уже везде.

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

…Компьютеры - это сложно.

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

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

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

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

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

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

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

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

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

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

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

Часть II. Масштабные издержки

Глава 3. Пустая трата денег

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

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

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

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

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

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

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

Один зрелый и опытный руководящий работник (в прошлом маркетолог) однажды спросил меня в тоне самозабвенной риторики: «Как может кто-то утверждать, что знает, чего хочет пользователь?» Поразительный вопрос. Каждый бизнесмен полагает, что знает это. Ценность большинства деловых людей как раз в их «предположениях» относительно потребностей покупателя. Да, такие предположения наверняка разойдутся с потребностями некоторых пользователей, но отсутствие предположений означает, что результат не понравится никому.

Говорят, Сталин расчищал минные поля, посылая на них штрафные батальоны. Эффективно такое решение? Да. Рационально, гуманно, жизнеспособно, привлекательно? Нет.

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

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

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

Дороже разработки ПО обходится только разработка плохого ПО

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

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

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

Ценность прототипа в знаниях, приобретенных в процесс е его создания, а совсем не в коде. Мудрый разработчик Фредерик Брукс говорит: «Планируйте выбросить одну версию». Так или иначе, вы ее выбросите, так почему не запланировать это событие с самого начала?

Гонки на яхтах и пристрастие к наркотикам в долгосрочной перспективе обходятся дешевле, чем неконтролируемое создание программного обеспечения.

Глава 4. Танцующий медведь

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

Билл Гейтс однажды заметил, с нетипичным для него цинизмом, как сделать программу дружелюбной к пользователю: изготовить печать и поставить на каждой коробке штамп «USER FRIENDLY» (Дружелюбна к пользователю). Компьютерная индустрия взяла его метод на вооружение.

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

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

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

Все очень логично и совершенно неправильно.

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

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

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

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

Глава 5. Нелояльность клиентов

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

Привлекательность легко перепутать с потребностью, но это кардинально различные свойства. Меня привлекает возможность провести полтора месяца на Бермудских островах, но мне это не нужно. Если у меня желчные камни, то я нуждаюсь в операционном лечении, но меня это не привлекает. Риэлтор Салли нуждается в том, чтобы продать четыре дома в этом году. А возможность обеспечить четыре семьи счастьем и уютом ее привлекает. Она нуждается в МLS-программе, позволяющей опубликовать предложения своих услуг в многочисленных каталогах, но если эта программа будет заставлять ее чувствовать себя глупой, то она ее не привлечет.

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

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

…Удовлетворение потребностей не является жизненно важной составляющей успеха на рынке.

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

Часть III. Как есть суп вилкой

Глава 6. Психбольница в руках пациентов

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

Кажется совершенно естественным, что проектированием занимается команда инженеров, однако именно это и есть причина проблем.

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

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

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

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

Глава 7. Ноmo Logicus

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

Найти решение и реализовать решение - два совершенно разных действия.

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

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

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

Глава 8. Отмирающая культура

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

Знаменитый идеолог UNIX Эрик Реймонд (Eric Raymond) говорит: «Хорошие программисты знают, что писать, великие - что надо использовать повторно».

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

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

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

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

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

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

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

Изумительно, но простой и очевидный факт, что компьютеры сегодня намного мощнее, дешевле и быстрее, чем всего несколько лет назад, не осознан до конца практиками разработки программ. Поэтому большинство приложений не слишком усердны в обслуживании пользователей. Наоборот, приложения встают стеной на защиту центрального процессора из-за ошибочного тезиса, гласящего, что он перегружен работой. В результате программные продукты перегружают работой пользователей. Идеолог проектирования Билл Могридж (Вill Moggridge) так говорит об этом подходе: «Будь добр к микросхемам и жесток к пользователю».

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

Часть IV. Проектирование взаимодействия - выгодный бизнес

Глава 9. Проектирование для удовольствия

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

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

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

Реальные пользователи не эластичны.

Программисты создали выразительную систему, описывающую конструирование программного обеспечения. Хорошие программисты не бросаются глупыми обобщениями на тему различных компьютеров и систем. Программист никогда не скажет: «Это будет хорошо работать на компьютере». На каком компьютере? На какой модели? Под управлением какой операционной системы? С какими периферийными устройствами? Точно так же проектировщику никогда не следует расплывчато говорить о программах, будто они «спроектированы для пользователя» или «дружелюбны к пользователю». Такие слова обычно призваны оправдать навязывание собственных интересов.

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

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

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

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

В интересах точного определения персонажей необходимо определить средние показатели. Средний пользователь никогда не бывает математически средним. У среднего человека в моем населенном пункте 2,3 ребенка, но ни у одного жителя города не может быть такого количества Детей. Более полезным представителем мог быть стать Сэмюэл, отец двоих детей, или Уэллс, у которого трое детей. Сэмюэл полезен, потому что он личность. Да, гипотетическая, но обладающая точными характеристиками. Родитель, имеющий 2,3 ребенка, не может существовать, как раз из-за этого невозможного среднего показателя.

Усредненные персонажи уничтожают преимущества конкретности точных. Великая сила персонажей именно в их точности и конкретике. Обобщенные данные сводят эту силу на нет.

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

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

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

Проектирование для покупателя - распространенная ошибка в компьютерном бизнесе.

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

Выполнить качественное проектирование и не выразить его в терминах персонажей - не очень мудрое решение. Слишком уж легко скатиться обратно к разговорам о «пользователе» и утратить с таким трудом приобретенный фокус на конкретных архетипах пользователей.

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

Глава 10. Проектирование ради результата

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

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

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

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

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

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

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

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

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

Обратите внимание, что отсутствие препятствий в достижении личных целей важнее мгновенного достижения всех практических целей.

ЛИЧНЫЕ ЦЕЛИ Не чувствовать себя глупо Не совершать ошибок Выполнить адекватный объем работы Развлечься (или хотя бы не страдать от скуки)

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

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

КОРПОРАТИВНЫЕ ЦЕЛИ Увеличить прибыль Увеличить рыночную долю Победить конкурентов Нанять больше сотрудников Предложить новые продукты и услуги Выпустить акции компании в свободное обращение

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

Практическая цель удовлетворения требований клиента соединяет корпоративную цель (более высокие прибыли) с личной целью пользователя (работать продуктивно).

ПРАКТИЧЕСКИЕ ЦЕЛИ Избегать собраний Удовлетворять требованиям клиента Сохранять информацию о заказах клиента Создавать математические модели бизнеса

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

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

…Цели всегда являются результатами.

ЛОЖНЫЕ ЦЕЛИ Экономия памяти Уменьшение потребности в клавиатурном вводе Поддержка работы в броузере Простота в освоении Обеспечение целостности данных Ускорение ввода данных Увеличение скорости исполнения программы Применение супертехнологии или супервозможностей Улучшение внешнего вида Сохранение единообразия интерфейса на различных платформах

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

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

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

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

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

Это принцип соразмерности усилий: если вы нуждаетесь в большем количестве информации, то подождете, пока она будет получена.

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

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

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

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

Неподходящие функции в неподходящих местах - вот клеймо продуктов, основанных на программном обеспечении.

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

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

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

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

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

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

Глава 11. Проектирование для людей

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

Свой инструмент для рассмотрения задач мы называем «сценариями». Сценарий - это сжатое описание способов применения программного продукта персонажем для достижения цели.

Ведь программисты ставят себя на место своих компьютеров. Программисты привычно описывают действия компьютера от первого лица, они говорят: «Я обращаюсь к базе данных, а затем сохраняю записи в буфере». Человек говорит «я», но всю работу на самом деле выполняет компьютер. В роли компьютера человеку проще симпатизировать потребностям машины в процессе написания кода.

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

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

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

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

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

…Панель инструментов - это идиома интерфейса, обеспечивающая доступ к самым востребованным функциям.

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

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

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

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

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

Делать больше при помощи меньшего всегда лучше.

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

Часть V. Возвращаемся на место водителя

Глава 12. В отчаянных поисках эргономики

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

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

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

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

Любой процесс, основанный на наблюдении, должен играть второстепенную роль по отношению к творчеству.

Если вы делаете стул, наждачная бумага может сделать его более гладким. Если вы делаете стол, наждачная бумага и его сделает более гладким. Но никакая шлифовка не позволяет превратить стол в стул.

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

«Проектирование - то, чем программисты занимаются двадцать минут перед тем, как начать писать код».

Как нельзя быть немножко беременной, так нельзя немножко заниматься программированием.

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

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

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

Каждая новая технология всего лишь добавляет возможностей для приведения пользователей в отчаяние – при помощи систем более быстрых и более мощных.

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

Итеративный подход не позволяет создавать замечательные продукты.

Глава 13. Управляемый процесс

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

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

Приняв чек, вы отдаете бразды правления клиенту. У клиента могут быть деньги, однако клиент не обладает двумя важнейшими качествами: 1) он не заботится о ваших интересах и 2) не знает, как проектировать ваш продукт.

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

…Если скрестить проектирование и программирование, получается просто программирование.

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

Разрешить непроектировщикам выкидывать возможности? Все равно, что разрешить пассажиру перерезать провода в самолете.

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

Чтобы сэкономить время, надо потратить время.

…Подготовка позволяет минимизировать длительность стадии производства.

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

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

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

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

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

Одна из моих любимых бизнес-аксиом - «если этого нет на бумаге, значит, это не существует» - в мире проектирования программного обеспечения верна как нигде. Если что-то не записано, более чем вероятно, что это будет неправильно истолковано или опущено.

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

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

…Проектировочный документ должен, это неизбежно, опускать некоторые моменты.

Некачественный продукт в красивой и Красочной упаковке - продукт по-прежнему некачественный.

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

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

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

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

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

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

Чем меньше сложного взаимодействия, тем меньше пространных объяснений.

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

…Точно осознавая, что вы делаете, вы избежите траты сил на то, чего вы точно не собираетесь делать. Ни одна компания не может себе позволить тратить силы на вещи, не относящиеся к делу.

…Написание кода подрывает способность программиста думать о целях пользователя.

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

Проектировщики должны быть кровно заинтересованы в успехе.

Самое важное - принять решение что программированию будет предшествовать проектирование.

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

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

Глава 14. Мощь и удовольствие

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

На команду проектировщиков возлагается ответственность за все, с чем вступает в контакт пользователь. Не только за программное, но и за аппаратное обеспечение. Следует принимать во внимание и сопутствующие программные модули, такие как программы установки.

…Простой программистов обходится недешево, но гораздо дороже обходится заливка бетонной смеси программного кода не там, где требуется.

…Акт творения состоит из двух частей: проектирования и программирования. Готовность разрешить проектировщикам взаимодействия работать с важнейшим элементом бизнеса наряду с инженерами требует значительных культурных перемен.

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

…Технологии не обязательно должны быть бесчеловечными.

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

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

Стоимость кода не сильно растет с увеличением сложности, однако значительно растет с увеличением объема. Каждую лишнюю строку кода необходимо тестировать, отлаживать и поддерживать.

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

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

Разработчики программного обеспечения известны способностью менять свои убеждения.

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

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