Smart Reading - Ключевые идеи книги: Психбольница в руках пациентов. Алан Купер

Оригинальное название:

The Inmates are Running the Asylum

Автор:

Алан Купер

Тема:

Менеджмент

Правовую поддержку обеспечивает юридическая фирма AllMediaLaw

www.allmedialaw.ru

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

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

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

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

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

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

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

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

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

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

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

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

Когнитивное сопротивление ПО разделяет людей на тех, кто мирится [2] Продвинутые пользователи – это просто техноэнтузиасты, сумевшие подавить лучшие свои инстинкты, чтобы стать полезными потребителями продукции с высоким когнитивным сопротивлением. с их сложностью в обмен на возможности, которые они дают, и тех, кому трудности использования доставляют удовольствие. Такие люди склонны оправдывать сложность программ и не считают нужным упрощать взаимодействие с ними. Можно условно назвать эти две категории людей «уцелевшими» и «апологетами».

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

В индустрии разработки программ облик и поведение продуктов определяют [3] Программисты «проектировали» этот продукт по ходу написания кода. Примерно так бобер «проектирует» свою плотину во время ее строительства. программисты. Программисты пишут код (инструкции) для компьютера, а не для пользователя, а потребности компьютера и пользователя противоречивы.

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