Файл: Алан Купер Психбольница в руках пациентов.pdf

121
Если посмотреть со стороны, последние несколько месяцев были похожи на старую эксцентричную комедию или мыльную оперу, только без всякой романтики. Тоже по- своему ценный опыт. Конечно, смотри на дело только так, история не стоила бы столь подробного рассказа. Но во мне говорит сильное чувство. Думаю, долг чести требует прекратить впустую тратить жизнь людей на столь бесполезные предприятия.
В книге «About Face» ты писал о том, как важно перестать тратить время пользователя. От всего сердца соглашаюсь. Но это лишь вершина айсберга. Время пользователя можно потратить только тогда, когда продукт, достигший рынка, начинают покупать. Многие проекты закрываются прежде, чем разработчики успеют создать продукт, а результатом многих становятся продукты, не находящие покупателей.
Инженерам из числа знакомых мне далеко не безразлична судьба их продуктов. Однако когда проект закрывают или продукт получается неудачным из-за отсутствия проектирования, то это означает, пустую трату их энергии. А в мире не так уж много квалифицированных кадров, чтобы впустую тратить их время. Долг чести, о котором я говорю, призывает не просто «перестать впустую, тратить время пользователей, но перестать впустую, тратить время и жизни всех людей, включая программистов.
Было очень больно оказаться Кассандрой в роли наблюдателя - предсказывать мрачную судьбу и, находясь в роли наблюдателя, смотреть, как мимо проплывают возможности ей воспрепятствовать. Я пришел к заключению, что обучение методом проб и ошибок оказывает воздействие настолько сильное, что прошедший такое обучение человек становится глухим для доводов, основанных на фактах и цифрах.
Хочу подчеркнуть, что опыт Скотта вполне типичен. Вот история другого коллеги из нашей области, Джона Ривлина (John Rivlin). Джон управляет небольшой, но очень успешной компанией в Пало-Альто, специализирующейся на проектировании и разработке программного обеспечения. Он прислал мне свою историю:
Мы всегда тщательно проектировали продукты, прежде чем начинать разработку, и данный конкретный случай - не исключение. Мы начали проект с создания пятнадцатистраничной спецификации, описывающей взаимодействие пользователя с программой, которую мы предлагали написать. Спецификация включала и общие проектные положения, что дало нам возможность выйти за пределы начального описания «в одно предложение». Это важно, поскольку мы работаем исходя из фиксированной стоимости разработки и идем на определенный риск.

122
Руководитель разработки нашего клиента, управляющий проектом, поддержал идею написания спецификации, и мы согласовали фиксированную цену. После этого готовую спецификацию передали боссу руководителя разработки, техническому директору. Вот какой ответ мы получили от него: «Зачем вы потратили так много времени на спецификацию? Вы потратили серьезную часть проектного бюджета. Мы не занимаемся спецификациями. Мы просто берем и делаем работу». При дальнейшем разбирательстве выяснилось, что представления технического директора о функциональности существенно отличались от представлений руководителя разработки. Несоответствие выявилось лишь благодаря «бесполезной спецификации, однако и этот факт не убедил его в пользе проектирования программного обеспечения. И это технический директор технологической компании, акции которой находятся в свободном обращении, а ежегодные прибыли превышают сто миллионов долларов. Вот уж, воистину, психбольницей управляют пациенты.
Страх перед проектированием, живущий во многих руководителях разработки, иррационален, но часто базируется на вполне реальном личном опыте. В прошлом, в поисках более совершенных продуктов, руководители просили программистов проектировать взаимодействие, и результаты оказывались плачевными. Человек, не владеющий методами проектирования взаимодействия, стремится к созданию продукта, пользователем которого является сам, и программисты, разумеется, тоже попадают в эту ловушку. Любая группа людей, соотносящая будущий продукт с собой, будет бесконечно долго тянуть резину, пытаясь придти к общему мнению по вопросам проектирования, потому что ее участники не имеют единого понятия о пользователях продукта.
Компьютеры против людей
Программное обеспечение больше похоже на мост, чем на здание. Про граммы работают на высокотехнологичных микропроцессорах, а управляют ими и используют их простые смертные. Осваивая новые технологии и восхищаясь ими, мы упускаем из виду огромную разницу между компьютерами и людьми, эти компьютеры использующими.
К примеру, мы считаем, что раз у компьютеров есть память, она должна быть похожа на человеческую. Это совершенно не так. Память компьютера работает иначе.

123
Моя память позволяет мне легко распознавать лица друзей, а мой собственный компьютер никогда не узнает даже меня. Мой компьютер хранит миллионы телефонных номеров с идеальной точностью, а я не всегда сразу вспоминаю даже собственный номер.
Чтобы программное обеспечение было мощным и надежным, оно должно создаваться в идеальной гармонии с потребностями кремниевых микросхем. Чтобы программисты работали профессионально, они также должны участвовать в этой гармонии.
Чтобы пользователи были довольны и могли эффективно применять программы, программы следует создавать в гармонии с потребностями человеческой природы.
Проблема, понятно, в том, что человеческие потребности радикальным образом отличаются от потребностей кремниевых микросхем.
Очевидно, что одна часть программы, а именно внутренняя, должна создаваться с применением специальных технических знаний и учетом потребностей компьютеров. И точно так же очевидно, что вторая часть (внешняя) должна создаваться с применением специальных социальных знаний и учетом потребностей людей. Я убежден, что программисты способны справиться с первой задачей, но вторая задача требует участия проектировщиков взаимодействий.
Идеолог компьютерной отрасли Джерри Вайнберг говорит: «Найдя решение главной проблемы, вы делаете главной проблемой следующую по списку»
1
. Многие десятилетия главной проблемой компьютерной отрасли оставалась эффективность.
Компьютеры были, в основном, маленькими, дорогими, медленными и
1
Gerald Weinberg, «The Secrets of Consulting: A Guide to Giving & Getting Advices Successfully» (Секреты консультирования:
Руководство по успешному применению советов), Dorset House, 1985.

124 непроизводительными. Мы обожествляли хакеров, умевших создавать максимально эффективные программы и выжимать всю возможную производительность из дорогих
ЭВМ. По существу, было гораздо дешевле обучать людей общению с непонятными, но производительными компьютерными программами, чем покупать дополнительные компьютеры. Неуклонное и неизбежное падение цен на компьютеры навсегда избавило нас от этой проблемы. Сейчас, оказывается, гораздо дороже обходится адаптация людей к «эффективным» программам, чем создание программ, соответствующих ожиданиям людей.
Решение очевидно: поставить программы на службу пользователям. Однако на пути такого решения встает культура, которую мы столь заботливо создавали последние сорок лет, культура, обожествляющая хакеров, стоящих у руля. Сообщество разработчиков программного обеспечения в целом готово включить проектирование взаимодействия в процесс разработки. «Конечно, - говорят они, - проектируйте сколько угодно, только дайте сначала продукт закончить. К сожалению, проектирование взаимодействия должно предшествовать строительству, поэтому открытость программиста проектированию совершенно бесполезна. Точно так же оператор бетономешалки может сказать плотникам, что они смогут начать создавать каркас, как только он закончит заливать бетон.
Учим собак быть кошками
В качестве отступного разработчики программного обеспечения всегда выражают готовность изучать проектирование. Меня постоянно просят «научить проектировать. Я приветствую такую открытость, но не верю в эффективность такого подхода. Любой разработчик программного обеспечения, достаточно квалифицированный, чтобы называться профессионалом, слишком погружен в буквальную и детерминированную сущность кремниевой логики. Слишком сильно погружен, чтобы достичь параллельно схожей эффективности в иррациональном, непредсказуемом, переполненном эмоциями мире людей. Я не хочу сказать, что программист неспособен стать проектировщиком, я лишь пытаюсь сказать, что практически невозможно делать то и другое хорошо одновременно.
Каждый разработчик программного обеспечения считает себя не таким, как все, считает, что способен делать и то и другое. Как ясно показала судьба General Magic, это

125 попросту не так. Разработку в General Magic возглавляли Билл Аткинсон (Bill Atkinson) и
Энди Герцфельд (Andy Herzfeld), в прошлом ведущие разработчики программного обеспечения для Apple Macintosh и, вероятно, два наиболее изобретательных и одаренных творца из числа программистов. Их совместное программирование проектирование для Macintosh превратилось в успех в 1984 году (хотя в проектирование пользовательского интерфейса существенный вклад внес Джеф Раскин (Jef Raskin), в программировании участия не принимавший). Однако за последующие четырнадцать лет вещи достаточно сильно изменились, и старые методы перестали быть применимыми. В начале 1993 года я брал интервью у Энди Герцфельда в штаб-квартире разработки
General Magic, которая являлась одновременно и его жильем в Пало-Альто. Там он изложил мне свою философию проектирования программных продуктов. Я изумленно слушал его, понимая, насколько малы его шансы на успех. История признала выдающийся талант Энди.
Несомненно, что продукт, задуманный General Magic, был востребован, и таковым остается поныне. Несомненно, что технология в продукте применялась великолепная.
Несомненно, что способность Марка Пората находить стратегических партнеров и заключать сделки мало кому удастся превзойти. Несомненно, что компания имела хорошую родословную и хорошее финансирование. Что же тогда уничтожило компанию? Я считаю главной причиной проектирование взаимодействия, а точнее - его отсутствие. Несмотря на звездную генеалогию и вселяющие трепет таланты, продукт
General Magic был сконструирован, а не спроектирован.
Принятый в отрасли образ мышления не дает места столь очевидным выводам, как видно из статьи о General Magic. Чаша ответственности за провал продукта в статье склоняется, похоже, к высокомерию и честолюбию Пората, однако в Кремниевой Долине нет ни одного президента, у которого имеется недостаток таких проявлений собственного эго. Эти качества навряд ли могут быть причиной провала компании.
Наша высокотехнологическая культура настолько замкнута в себе, что мы слабо осознаем собственные провалы и слабые места. Невозможно стать успешным журналистом в этой области, не будучи компьютерным фанатиком - апологетом, поэтому журналисты сваливают вину за провалы на наши личные качества, недоброжелательность фортуны и форс-мажорные обстоятельства.
* * *

126
Разработка программного обеспечения не является самостоятельной профессией, такой как юриспруденция, архитектура или медицина, поэтому названия должностей в нашей отрасли весьма ненадежны. Некоторые мои друзья, высокопрофессиональные программисты, называют себя проектировщиками программного обеспечения».
Самоназвание, вне всякого сомнения, заслуженное, но не совсем верное. Скажем, Энди
Герцфельд с готовностью отзывается на прозвище «проектировщик».
Многие программисты считают себя талантливыми проектировщиками. Вообще говоря, это действительно так во многих случаях, но существует огромная разница между проектированием функциональности и проектированием для людей.
Даже если программистов сложно оправдать в плане проектирования, они, по крайней мере, стараются удерживать проекты от окончательного расползания». Завидев узурпатора, они стараются не допускать к рулю безответственных людей. Большинство программистов очень ответственны, они часто считают сторонних консультантов, маркетологов и руководителей вздорными и некомпетентными личностями.
Программисты чувствуют чепуху за версту, и всего после пары случаев, когда маркетологи или руководители требуют изменений, улучшающих интерфейс» и оказывающихся в итоге неэффективными, у программистов возникают защитные барьеры против такого вмешательства. Изменения могут быть к лучшему или к худшему, но в любом случае программисты вынуждены делать дополнительную работу. Каждое изменение снижает качество кода, поскольку неизбежно оставляет швы и рубцы, Если кто-то заявляет, что программой станет легче пользоваться, и достаточно лишь поместить каждую кнопку «ОК» в правый верхний угол диалогового окна, опыт и мудрость программиста подсказывают ему, что это пустая трата времени - его времени. И он прав в своей бдительности.
После нескольких напрасных погонь за недостижимыми целями они начинают относиться к поступающим извне рекомендациям по проектированию как к обычным советам. Они словно строители, которым пришлось разрушить слишком много непродуманных стен и которые теперь смотрят на чертежи с предубеждением и зарекаются воспринимать их всерьез.
* * *
Разработчики программного обеспечения рисуют на досках диаграммы, изображая пользовательский интерфейс и код для работы с данными в виде отдельных

127 прямоугольников. Однако реальной разницы в кодировании того и другого нет. Это не две стены, одна из которых сложена из гранитных блоков квалифицированным каменщиком, а соседняя - из деревянных досок, сколоченных плотниками и обшитых гипсовыми изоляционными панелями. Совсем нет. В коде, реагирующем на движения мыши, и коде, реорганизующем базу данных глубоко в недрах программы, используются примерно те же операторы, указатели, вызовы методов, Часто внутренний код системы и код для взаимодействия с пользователем пишет один и тот же человек. Он пользуется одним языком, теми же библиотеками, инструментами и методами для решения этих задач. Кто может сказать, где проходит граница между программой для компьютеров и программой для пользователей?
Программисты привыкли рассматривать задачи в рамках функций, так что им совершенно неясно, чем хороша идея взять фрагмент программы, нарушить множество границ функциональности и перенести его на сторону пользователя. Инженерам трудно осознать, чем код на языке С, реализующий взаимодействие с базой данных, разительно отличается от кода на языке С, реализующего взаимодействие с человеком.
* * *
Следующую историю рассказал мой коллега, Джим Гей (Jim Gay). Он показывает, как легко умные инженеры загораются увлекательными и интересными проблемами, вместо того чтобы заниматься решением проблем, действительно того требующих.
Начинающая компания TransPhone решила выйти на рынок электронной коммерции. Основной нашей идеей стало создание простого в применении смартфона как основы для интернет-коммерции. Решающим фактором успеха нашей модели был простой интерфейс, с которым было бы удобно работать людям, не имеющим отношения к компьютерам. TransPhone обратилась за помощью в компанию, специализирующуюся на проектировании взаимодействия.
Мы считали, что практически уже создали пользовательский интерфейс, однако ему не помешала бы некоторая доводка. На первом же собрании проектировщики взаимодействия много раз повторили, что понятия не имеют, что мы в действительности пытаемся создать или для кого мы пытаемся это создать. Мы посчитали, что они поверхностно смотрят на проблему, которая на самом деле была довольно серьезной.
Собрание закончилось тем, что проектировщики попросили нас более точно определить цели и задачи. У нас появилось ощущение, что эти проектировщики ни малейшего

128 представления не имеют о том, чего мы пытаемся достичь.
После этого мы создали улучшенный прототип для демонстрации потенциальным партнерам, однако устройство TransPhone попросту не вызвало у них восторга. Мы продолжали считать, что демонстрация просто недостаточно убедительна. TransPhone прекратила свое существование через несколько недель после создания второго прототипа.
Вспоминая то, первое собрание с участием проектировщиков взаимодействий, я отчетливо понимаю, что главную нашу проблему они обнаружили в первые же несколько минут: какова была наша цель, для кого мы все это делали? Никто и никогда не дал адекватного ответа на этот вопрос. Задайся мы сразу этим вопросом, возможно, случилось бы одно из двух: найдя ответ, мы получили бы шансы на успех либо, не найдя ответ, минимизировали потери инвестора.
Каков урок этой истории? Проектирование продукта является важнейшей составляющей жизненного цикла предприятия. Наша неспособность, разрешить фундаментальные вопросы проектирования и желание вместо этого устремиться вперед к разработке и продажам в конечном итоге оказались для компании роковыми. Теперь-то понятно, что, не сумев создать представления того, что мы пытались делать, мы должны были вернуться к исходным целям своего предприятия. Думаю, это, скорее всего, привело бы к созданию иного, более простого продукта. Вместо этого мы продолжали добавлять прибамбасы, вероятно, еще сильнее маскируя возможную полезность продукта.
Подобно ребятам из General Magic, Джим на горьком опыте убедился, что, классная технология и раскаленный докрасна рынок не способны поднять тяжелый груз плохо продуманного кода. Недостаточно перебросить мост между технологией и потребностью. Кто-то еще должен сделать так, чтобы люди захотели ходить по этому мосту.
История наших технологий относится преимущественно к индустриальному веку, поэтому проблемы и решения, присущие ей, близки современному человеку. Сила сопротивления между людьми и механическими устройствами существует, но в определенных рамках. В информационную эру нашу жизнь заполонили компьютеры, все больше продуктов, содержащих микросхемы, и мы обнаруживаем, что между людьми и устройствами возникает когнитивное сопротивление, с которым мы не готовы бороться.