Мудрый руководитель Питер Дрюкер (Peter Drucker) в свои девяносто два года, большую часть которых он провел, наблюдая и направляя руководителей, смотрит на эту проблему со своей, уникальной точки зрения. В недавнем интервью журналу «CIO» он упомянул о наивном оптимизме руководителей в пятидесятые и шестидесятые годы, когда компьютеры только пробились в деловой мир. Эти руководители думали, что компьютеры «окажут огромное воздействие на способы ведения бизнеса», но Дрюкер говорит, что «произошло совсем не это. Очень немногие руководители задавали вопрос: "Какая информация мне требуется, чтобы выполнять эту работу?"» Цифровые машины дали руководителям небывалые объемы данных, но лишь немногие поинтересовались, подходят ли эти данные для управления корпорацией. Образ существования бизнеса менялся очень быстро, однако менеджмент при этом не менялся. Дрюкер атакует наши устаревшие бухгалтерские системы, рожденные в эпоху меркантилизма, повзрослевшие в век пара и стали и угасающие на пороге XXI века, эры информации. Дрюкер утверждает: «Самая нужная вам информация – информация об окружающем мире, и этой информации у вас нет».
В последние несколько лет XX века, по мере раздувания мыльного пузыря доткомов, целые цистерны чернил уходили на рекламу, твердившую, что в Интернете существует «новая экономика». Знатоки утверждали, что продажа вещей в Паутине, где магазины строят из страниц, а не из кирпичей, принципиально отличается от привычных стилей бизнеса и что «старую экономику» уже не оживить. Разумеется, почти все компании новой экономики мертвы, финансисты, поддержавшие их, пережили шок, а эксперты, пропагандировавшие новую экономику, теперь заявляют, что это была пустая мечта. Новая-преновая линия такова, что нам суждено пока оставаться со старой-престарой экономикой.
На мой взгляд, существует два типа руководителей: инженеры и запуганные инженерами. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно испорчена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов
Можно провести аналогию со здоровенным медведем, которого человек выводит на цепи на городскую площадь и за скромные пожертвования заставляет танцевать. Горожане собираются поглазеть на диковинку – на то, как массивный, громоздкий зверь неуклюже переступает с лапы на лапу. Танцует медведь просто ужасно, но чудо не в том, что он танцует хорошо, а в том, что вообще танцует .
Специалистам в области программного обеспечения только и остается, что чувствовать себя комфортно, сталкиваясь с продуктами, имеющими высокое когнитивное сопротивление. Они гордятся своей способностью работать, несмотря на превратности судьбы.
Обыкновенные люди, являющиеся новичками в использовании этих продуктов, не имеют специальных знаний, позволяющих судить, можно ли избавиться от когнитивного сопротивления. Вместо этого они полагаются на подсказки компьютерных «ботаников», которые пожимают плечами и говорят, что «надо быть компьютерно грамотным», чтобы использовать продукты, основанные на программном обеспечении. Программисты валят всю вину на технологии, объясняя пользователям, что сложность взаимодействия – неотъемлемое свойство компьютеров, и она неизбежна.
Это неправда. Сложных взаимодействий вполне можно избежать.
Когнитивное сопротивление порождается не технологиями, а людьми, которые ими владеют.
Танцующие медведи уже везде.
Она сказала, что мобильные телефоны – это «мокрые собаки». Когда я спросил ее, как следует понимать эту метафору, она пояснила: «Нужно очень и очень сильно любить мокрую собаку, чтобы повсюду таскать ее за собой».
Легко представить, как вспотевший, утомленный альпинист потягивает Gatorade и, улыбаясь, произносит: «Последний участок был совершенно отвесный, пару раз я чуть не сорвался. Мышцы просто звенели от напряжения». Ему нравится , когда это тяжело! Чем тяжелее, тем лучше! Потому-то он и занимается этим!
Компьютеры вдохновляют людей тем же образом, потому что предлагают такие же крутые, беспощадные испытания. И если вы не в идеальной форме, компьютер оставит вас хныкать в придорожной пыли. Легко представить утомленного программиста, который потягивает колу, ухмыляется и говорит: «Да, подпрограмма поиска приводила к сбою, но только когда размер кучи превышал 64 килобайта, потому что в противном случае кэш не использовался. С большим трудом обнаружил!» Он получает удовольствие !
На другом полюсе находятся уцелевшие. Они нередко понимают: что-то в корне неправильно, но не могут сказать, что именно. Они плохо понимают в компьютерах и взаимодействиях, но понимают, что существует проблема. Они знают, что такое сложно и что такое легко , и очень хорошо понимают, что компьютеры – это сложно .
В восьмидесятые и девяностые годы Ройял Фаррос был вице-президентом небольшой, но влиятельной компании Т/Maker, где руководил разработкой. Вот его слова:
«Многие из нас устанавливали сроки сдачи заведомо невозможные, причем настолько, что делали верным одно из следствий закона Паркинсона: «Для завершения проекта требуется в два раза больше времени, чем было отведено». Я твердо верил, что если выделить под проект шесть месяцев, он займет год. Так что если необходимо было получить что-то через два года, следовало требовать сдачи через год. Тупое принуждение, конечно, но оно всегда срабатывало».
Когда предприниматель от программного обеспечения Риджели Эверс работал в Intuit над созданием QuickBooks, он столкнулся с той же проблемой.
«Выпуск первой версии QuickBooks должен был занять девять месяцев. Мы правильно оценили, что начальное развитие будет длиться столько же, сколько длится беременность, но все-таки ошиблись: у нас ушло почти два с половиной года – срок беременности слона».
«Мы ни при чем. Мы реализовали все возможности, перечисленные руководством»
«идеальный продукт для университетской среды. В 1987 году мы продали в этом сегменте больше копий WriteNow, чем Microsoft продала копий Word. Однако мы не смогли удерживать лидерство, потому что рассердили своих самых преданных поклонников на этом рынке, не добавив самую нужную для них функцию: концевые сноски. Пытаясь успеть к сроку, мы не смогли включить ее в спецификацию. Мы успели к сроку, но потеряли целый сегмент рынка».
Для нашего зациклившегося на функциях мира мысль, наверное, непривычная – вы не достигнете своих целей, используя набор функций, как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
Один зрелый и опытный руководящий работник (в прошлом маркетолог) однажды спросил меня в тоне самозабвенной риторики: «Как может кто-то утверждать, что знает, чего хочет пользователь?» Поразительный вопрос. Каждый бизнесмен полагает, что знает это.
Если программа раздражает пользователей и сложна в применении, люди станут избегать работы с ней.
Если проектирование не предшествует программированию, вряд ли оно окажет какое-либо влияние. Один руководитель сказал мне: «Наши люди уже пишут код, и я не собираюсь их останавливать». Эти ковбои думают: «Пока мы будем лететь к земле, я успею сшить парашют». Отважное заявление, однако, мне не довелось видеть ему подтверждения.
Самая дорогая программа – та, что будет запущена только один раз. Самая дешевая – та, что будет запущена десять миллиардов раз.
По моему наблюдению, от продукта можно добиться только тех свойств, которые были учтены заранее
Инвесторы не устают повторять: «У нас не так много денег, чтобы тратить их на продукт, который мы не сможем продать, поэтому мы должны изучить покупателей, прежде чем начнем проект». И при этом руководители разработки, похоже, неизменно верят в то, что у нас не так много времени и денег, чтобы тратить их на проектирование взаимодействия. Мы можем проектировать до бесконечности, и деньги закончатся прежде, чем мы успеем сделать продукт». Поэтому в конечном итоге они создают новые и новые продукты, вместо того чтобы совершенствовать уже имеющиеся – пока не закончатся деньги…
Человек, не владеющий методами проектирования взаимодействия, стремится к созданию продукта, пользователем которого является сам, и программисты, разумеется, тоже попадают в эту ловушку. Любая группа людей, соотносящая будущий продукт с собой, будет бесконечно долго тянуть резину, пытаясь придти к общему мнению по вопросам проектирования, потому что ее участники не имеют единого понятия о пользователях продукта.
Найдя решение главной проблемы, вы делаете главной проблемой следующую по списку
какова была наша цель, для кого мы все это делали? Никто и никогда не дал адекватного ответа на этот вопрос
С большой долей иронии я называю программистов хомо логикус. Вид хомо логикус слегка – но достаточно ощутимо – отличается от вида хомо сапиенс, человека разумного. Из собственных наблюдений я почерпнул четыре фундаментальных отличия образа мысли и действия разработчиков программ от обычных людей. Об этих отличиях и пойдет речь в данной главе. Программисты пожертвуют простотой ради контроля. Обменяют успех на понимание. Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. И, наконец, ведут себя грубо и прямолинейно, как быки.
Чтобы подчеркнуть различие между видами, я применяю забавную лакмусовую бумажку – «Авиационный тест». Чтобы пройти тест, достаточно представить, что вы идете по посадочному коридору авиалайнера. Вступив на борт, вы должны выбрать – пойти налево в кабину или же направо в салон.
В кабине пилота целый калейдоскоп сложных органов управления и счетчиков, на всех поверхностях располагаются датчики, ручки и тумблеры. Справа же, в салоне, полная противоположность – мягкие округлые формы, успокаивающие бежевые оттенки.
Если повернуть налево, в кабину, вам придется в совершенстве овладеть сложными техническими материями. Придется узнать, зачем нужен каждый из приборов. За понимание всего этого нагромождения вы получаете ощущение определенного контроля над ситуацией и ответственность за посадку в нужном месте.
Свернув направо, в салон, вы отказываетесь от какого-либо влияния на полет. За отказ от контроля вы получаете возможность расслабиться, зная, что попадете в нужное место, и при этом самой сложной операцией будет включение и выключение лампы для чтения.
Авиационный тест четко делит человеческую расу на две категории: свернувшие налево стремятся контролировать ситуацию и понимать, как работает технология, а свернувшие направо стремятся упростить свои размышления и испытывать уверенность в успешности полета. Программисты – хомо логикус – всегда выбирают поворот налево. Пользователи хомо сапиенс – всегда выбирают поворот направо.
Даже если программисты соглашаются с тем, что к пользователям следует относиться лучше (а обычно они соглашаются), это не означает, что они сделают все необходимое, чтобы достичь озвученной цели.
«Семь привычек крутых инженеров». Эти определения невероятно точны, хотя и гиперболичны.
1. Они щедры в своем эгоизме.
2. Слепота улучшает их зрение.
3. Они кусают не только руку кормящего, но еще и собственные руки.
4. Они готовы приложить любые усилия, чтобы сохранить впечатление, будто их не заботит собственный имидж.
5. Они чинят то, что не сломано, до тех пор, пока это не сломается.
6. «Не я дал неверный ответ, а вы задали не тот вопрос».
7. Считают отсутствие критики комплиментом.
Три человека приговорены к казни: священник, адвокат, инженер. Первым на эшафот вступает священник. Палач дергает за рычаг, открывающий люк, но ничего не происходит. Священник заявляет, что это божественное вмешательство, и требует, чтобы его освободили, что и происходит. Выводят адвоката. Палач дергает за рычаг, и снова осечка. Адвокат заявляет, что еще одна попытка будет расценена как повторное привлечение к ответственности за то же преступление, и требует, чтобы его отпустили, – что и происходит. Наступает очередь инженера, который приступает к внимательному изучению механизма Три человека приговорены к казни: священник, адвокат, инженер. Первым на эшафот вступает священник. Палач дергает за рычаг, открывающий люк, но ничего не происходит. Священник заявляет, что это божественное вмешательство, и требует, чтобы его освободили, что и происходит. Выводят адвоката. Палач дергает за рычаг, и снова осечка. Адвокат заявляет, что еще одна попытка будет расценена как повторное привлечение к ответственности за то же преступление, и требует, чтобы его отпустили, – что и происходит. Наступает очередь инженера, который приступает к внимательному изучению механизма
Тот факт, что граничные условия могут наступать лишь раз в 79 лет ежедневного применения программы, программиста совершенно не утешает. Что если этот Раз наступит завтра?
В недавнем субботнем приложении к «Таймс» мне довелось прочесть занимательную историю американской пары, после выхода на пенсию уехавшей жить в Мексику. Они купили участок в предместье крупного города и наняли архитектора-американца для проектирования дома своей мечты. Затем они наняли мексиканского подрядчика и передали ему чертежи. В ходе строительства они с изумлением обнаружили, что получается совсем не тот дом, который описал архитектор.
Чертежи указывали, что на фасаде дома должно быть четыре окна, произведенные конкретным изготовителем, и приводили даже точный идентификационный номер товара. Владельцы дома обнаружили, что на фасаде три окна, совершенно иных по виду и размерам. На их расспросы мексиканский строитель пожал плечами и сказал: «Это ведь окна. В плане указано, что окна на этой стороне. В чем проблема?»
Копирование атрибутов успеха вместо его причины – ошибка распространенная. Это все равно что увидеть револьверы генерала Джорджа Паттона, украшенные перламутровыми рукоятями, и прийти к ошибочному выводу, что можно стать хорошим стратегом, только если носишь изысканное личное оружие
Пример: Sagent Technology, поставщик систем управления данными для рынка корпоративных вычислений. В этой компании главным специалистом в области баз данных является Влад Горелик (Vlad Gorelik), о компетентности которого в программировании ходят легенды. Непосредственно он общается лишь с теми клиентами, которые способны трепаться о «сегментации запросов», «распределении задач» и «кубах данных» с той же степенью увлеченности. И не удивительно, что Влад считает типичного пользователя Sagent Information Studio бывалым специалистом по базам данных.
Напротив, Алиса Блэр (Alice Blair), менеджер компании по Information Studio, проводит львиную долю времени в разговорах с потенциальными покупателями продукта. Она объясняет этим людям, что может продукт, каковы его базовые функции. Как следствие, Алиса считает, что в пользовательской аудитории много тех, кто не знаком с продуктом, и тех, кто обладает лишь базовыми навыками работы с компьютером. Неудивительно, что, по ее мнению, большинству клиентов требуется поддержка.
Кендал Косби (Kendall Cosby) работает в службе технической поддержке Sagent. Он не общается с экспертами и новичками. В основном ему приходится работать с конечными пользователями среднего уровня. Поскольку продукт применяется для поддержки принятия решений, Кендал находится в постоянном контакте с финансовыми и рыночными аналитиками, которые мало что знают о компьютерах и базах данных, но в своей работе зависят от возможности обращаться к хранилищам данных и анализировать тенденции в продажах. Собеседники Кендала не очень хорошо разбираются в компьютерах, и ему хотелось бы, чтобы продукт скрывал сложную функциональность или не содержал таковой вовсе. Из всех троих наиболее точным видением клиента обладает Кендал, однако именно Влад и Алиса имеют больше возможностей влиять на архитектуру продукта, поскольку занимают соответствующие должности.
использовала шоколад. Подкуп действовал настолько хорошо, что однажды руководитель группы, пав на колени, публично извинялся передо мной, что забыл уведомить об изменениях в продукте. (Да, свое угощение он все равно получил.) В одной компании пристрастившийся к шоколаду инженер рассказывал мне обо всех изменениях, внесенных его коллегами, чтобы получить и их шоколад. До открытия такого способа подкупа я потратила массу времени сверхурочно, пытаясь выяснить, каким образом изменился продукт. Подкуп же позволил сократить сверхурочную работу раза в два.
Чтобы сделать человека жестоким, не нужны утонченные инструменты, достаточно взгляда или пинка. Нас делает жестокими не технология. Обесчеловечивают технологи, а точнее говоря – процессы, применяемые технологами для создания обесчеловечивающих продуктов.
Роберт Лутц (Robert Lutz), руководитель компании Chrysler, говорит, что 80% участников фокус-группы возненавидели новый пикап Dodge Ram. Но после выхода на рынок машина стала бестселлером, потому что остальные 20% в нее влюбились. Любовь людей к продукту, пусть даже этих людей не очень много, – вот ключ к успеху.
Чтобы сделать каждый персонаж более реальным для участников проекта, я люблю дополнять имена портретами, прикреплять к каждому персонажу изображение. Как правило, я покупаю изображения в ceтевых фотобиблиотеках, но мне случалось работать и с быстрыми набросками. Можете вырезать изображения из журналов, если угодно.
Четко обозначенный, полностью развитый персонаж становится мощным инструментом. До тех пор, пока пользователь не имеет четкого определения, программист может воображать, будто пользователем является он сам. Четко определенный персонаж – это ключ к подавлению склонности разработчика искажать характеристики пользователей. Задолго до написания первой строки кода качественно определенный персонаж становится невероятно эффективным средством для проектирования взаимодействия.
Даже на стадии прототипа в интерфейсе уже была красивая трехмерная графика, высокохудожественные пиктограммы, а также метафорическая тема карты-глобуса – все атрибуты хорошего, но пустого интерфейса. Мы называем это «раскраской трупа».
Сущность качественного проектирования взаимодействия заключается в изобретении таких взаимодействий, которые помогут пользователям достигать практических целей, не препятствуя достижению личных целей
Известная человеческая черта, и Тед здесь не исключение, – реагировать на компьютеры эмоционально (более подробно чуть позже в этой главе). Взаимодействуя с продуктом, человек естественным образом наделяет этот продукт человеческими качествами. Тед готов вложить дополнительные усилия в настройку своего телевизора, поскольку чувствует, что телевизор приложил усилия, чтобы доставить ему, Теду, удовольствие. Это я и называю принципом соразмерности усилий. Люди готовы постараться, решая задачи, потому что воспринимают это, как честный обмен между равными сторонами. Иначе говоря, пользователь готов приложить дополнительные усилия, потому что ожидает получить за эти усилия дополнительное вознаграждение.
Психологи, изучающие рабочую обстановку, применяют термин «гигиенические факторы», которые Сол Геллерман (Saul W. Gellerman)1 определяет как «элементы, обязательные для эффективной мотивации, но не способные мотивировать самостоятельно». Освещение в вашем офисе – гигиенический фактор. Вы ведь не ходите на работу только потому, что там хорошее освещение, но если бы освещения не было, вы не ходили бы туда вовсе.Я адаптировал этот термин, заменив факторы целями: «гигиенические цели». Я их определяю как цели, необходимые для эффективной работы, но сами по себе не мотивирующие.
Человеческий мозг считает компьютеры не столько неодушевленными предметами, сколько предметами, поведение которых схоже с человеческим, поэтому мы бессознательно относимся к ним, как к другим людям, хотя и «считаем, что это неразумно». Иначе говоря, у людей есть особые инстинкты, подсказывающие, как надо вести себя рядом с другими разумными существами, и как только произвольный объект демонстрирует достаточно серьезное когнитивное сопротивление, эти инстинкты включаются, и мы реагируем так, будто имеем дело с другим разумным человеческим существом. Эта реакция бессознательна и неизбежна, она присуща каждому человеку.
Обычно самые мощные инструменты позволяют нам понять, представить личности наших пользователей, вжиться в них. Одну умозрительную модель мы применяем постоянно – она называется «вечные середняки». Большинство пользователей – не новички и не эксперты, они просто вечные середняки. Помните Рупака, Шэннон, Декстера и Роберто из главы 9, где речь шла об уровне подготовленности? Квалификации этих людей совершенно различны, но все четверо являются вечными середняками.
Какое-то минимальное время любой пользователь продукта проводит в статусе новичка, но никто надолго в этом статусе не задерживается. Просто потому, что никто не любит быть новичком, ни у кого нет такой цели. Людям не нравится собственная некомпетентность, а новички некомпетентны по определению. И напротив, обучение и совершенствование – естественный, увлекательный, приносящий удовольствие процесс, поэтому новички очень быстро превращаются в середняков.
В пределах компании руководство, отделы продаж и маркетинга постоянно расхваливают продукт клиентам, журналистам, партнерам, инвесторам, то есть людям, с продуктом не знакомым. Эти профессионалы вынуждены постоянно контактировать с начинающими, поэтому их видение пользовательской аудитории искажено и определяется именно этой проблемной группой
Программисты – короли практичности. Прагматизм практически лишает их терпимости к фантазиям. Но эта сила может стать и слабостью, поскольку случается, что практичный подход не позволяет решить задачу.
независимо от того, насколько интерфейс классный, чем его меньше, тем лучше.
Однажды нас посетил менеджер продукта из одной крупной компании, чтобы проконсультироваться по поводу перепроектирования продукта. В интерфейсе будет примерно десяток диалоговых окон, сказал он. Мы описали ему наш процесс, а затем дали оценку работы. Если мне не изменяет память, цифра составила $60000. «Возмутительно! – воскликнул тогда менеджер. – Это же $5000 за экран!» У меня не хватило духу сказать ему, что мы, вероятно, сократим количество диалогов до одного или двух, и тогда цена, если ее исчислять таким методом, станет гораздо выше. Он просто не понял, о чем речь. Платить за проектирование, исчисляя стоимость в экранах, все равно, что платить официанту за количество подходов к столику. Лучший официант меньше бегает, а лучший проектировщик всегда создает менее развесистые интерфейсы.
Большинство действительно новаторских прорывов сложны в разработке и вполне очевидны задним числом. Невероятно сложно увидеть прорыв в проектировании. Можно получить подготовку, пройти обучение, потратить многие часы на изучение задачи, но не найти ответа. Затем приходит человек со стороны, указывает на ключевую концепцию, и тут же вся головоломка складывается в полноценное изображение с естественной очевидностью, присущей колесу. Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно. Ученый-компьютерщик Алан Карп говорит: «Практически все мои патентные заявки были отвергнуты как "очевидные"».
На мой взгляд, юзабилити-методы похожи на наждачную бумагу. Если вы делаете стул, наждачная бумага может сделать его более гладким. Если вы делаете стол, наждачная бумага и его сделает более гладким. Но никакая шлифовка не позволяет превратить стол в стул.
Один коллега из крупной компании, разрабатывающей программное обеспечение, провел классический юзабилити-тест, одновременно выявивший сильные и слабые места такого предварительного тестирования. Он хотел определить эффективность строки состояния внизу окна программы. Он предложил участникам выполнить безобидное задание при помощи электронной таблицы. Каждые пять минут в строке состояния появлялось сообщение: «К вашему креслу снизу приклеена банкнота в $50. Возьмите ее!» За целый день тестирования ни один из более чем десяти участников не попытался взять купюру.
Едва ли не самым ценным вкладом тестирования является присутствие программистов, когда они из-за полупрозрачного зеркала вынуждены наблюдать, как пользователи сражаются с их программами. Программисты испытывают шок и крайнее недоверие, они ругаются: «Вы тестируете каких-то недоумков!» Юзабилити-тестирование – меткий камень в огород упрямых разработчиков программного обеспечения, который показывает им, что проблема действительно существует. Оно может послужить той же цели и в случае с руководителями.
Стратегия Мiсrоsоft основана на изморе. Говоря военным языком, враг может быть равен вам в умении сражаться (и даже превосходить вас), но, обладая огромным численным перевесом, вы можете просто обмениваться жертвами, пока у противника не закончатся войсковые соединения; в терминах производства программного обеспечения это означает: выбрасывайте на рынок некачественный продукт, пусть даже это танцующий медведь, а затем слушайте жалобы и стоны своих клиентов. Доводите до ума то, что им не нравится, и выпускайте обновленную версию. После трех или четырех версий открытые очаги болезней пользователей потухнут, а качество достигнет какого-то приемлемого минимума, поддерживаемого широкой функциональностью, после чего расти уже не будет. Итеративный подход не позволяет создавать замечательные продукты. WTF???
Впечатляющий коммерческий успех Мiсrоsоft плох тем, что многие не столь крупные компании пытаются повторить ее успех, действуя такими же методами. В долгосрочной перспективе подобная стратегия часто заканчивается плачевно, что показал пример Netscape, однако она продолжает традицию надругательства над конечными пользователями.
Существует большая разница между тем, чтобы выслушивать клиентов, и тем, чтобы за ними следовать. Выслушивать разумно. Подразумевается, что вы накладываете свой собственный фильтр на услышанное. Следовать требованиям клиента – плохо. То есть просто делать все то, что говорит клиент. Уже не вы играете с огнем, огонь играет с вами.
Если к вам в офис придет клиент и предложит $100000, чтобы вы выбросили свою систему бухгалтерского учета или подожгли ящики с бумагами, сделаете ли вы это?
Одна из моих любимых бизнес-аксиом – «если этого нет на бумаге, значит, это не существует» – в мире проектирования программного обеспечения верна, как нигде. Если что-то не записано, более чем вероятно, что это будет неправильно истолковано или опущено. Дело в том, что мотивация программистов очень сильно расходится с мотивацией пользователей. Недостаточно исключить диалоговое окно из описания, проектировщик обязан явным образом указать, где программист не должен по собственной инициативе добавлять лишнее окно.
Программистам нравятся диалоговые окна. Они считают, что оказывают пользователю услугу, добавляя в свободные минуты пару дополнительных диалоговых окон. А пользователи эти окна ненавидят, потому что диалоги их изматывают и снижают производительность.
Некачественный продукт в красивой и красочной упаковке – продукт по-прежнему некачественный.
Если за качество продукта отвечает каждый, это означает, что за качество продукта не отвечает никто.
Если человек получает ответственность за качество продукта и соразмерные полномочия, то он может принять на себя эту ношу независимо от своего опыта. Если взять подходящего человека и дать ему полную власть над качеством и поведением продукта, вы получите продукт намного, намного лучший, чем если этого не сделать. Проблема не в людях, но в процессе
Проектирование взаимодействия делает продукт привлекательным, награждая уникальным рыночным преимуществом – преданностью покупателей. Если покупателя осчастливил ваш продукт, этот человек надолго останется клиентом вашей компании и вашего брэнда. Если же ваш продукт – очередной танцующий медведь, клиенты будут оглядываться в поисках более простых и дружелюбных альтернатив.
Создание правильного продукта – всегда итеративный процесс. Чтобы добиться точности в деталях, требуется несколько попыток. Проектирование взаимодействия позволяет значительно уменьшить количество итераций. Выпуск каждой новой версии продукта сопряжен с огромными затратами, поэтому, уменьшая количество версий с четырех до двух, вы экономите массу денег и времени.
Десять лет назад консультант по розничным продажам Сеймур Меррин (Seymour Merrin) сказал, что нам проще было убедить покупателей, что программами легко пользоваться, чем сделать так, чтобы программами было легко пользоваться. Высказывание Меррина было циничным, однако он также выражал удивление, что нам сошла с рук столь наглая ложь. Сегодня его слова все еще справедливы, но рост высоких технологий не оставляет возможности и дальше выезжать на одном цинизме – нам требуется настоящее решение.
Время от времени у потребителей появляются призрачные надежды, что следующая волна технологии, скажем, распознавание голоса, сделает программные продукты простыми в применении. Надеяться на это наивно и неумно. Мне грустно видеть, как апологеты грубо подыгрывают таким надеждам.
любую форму, какая будет угодна авторам. Они не создают простые в применении программы не потому, что это невозможно, а потому, что не умеют. Чтобы не признавать этот неудобный факт, они заявляют, что лучше сделать просто невозможно «по техническим причинам». Пользователи компьютеров, программистами не являющиеся, вынуждены соглашаться со специалистами и страдать, или же не соглашаться со специалистами и – вот именно – все равно страдать. Не будучи специалистами, они не способны предлагать собственные решения, поэтому к ним относятся, как к бесполезным нытикам.
Штат Детройт производил гигантские хромированные прожорливые автомобили и лицемерно утверждал: «Мы даем потребителям то, что им нужно». Во время нефтяного кризиса семидесятых японцы вышли на рынок с экономичными небольшими автомобилями и нанесли Детройту удар, который не забудется никогда. Сегодня автомобильная индустрия Америки проявляет гораздо большее уважение к желаниям потребителя и уже не осмеливается утверждать, что все знает лучше
потребители способны отличить хорошую вещь от плохой, если им дадут ее увидеть
Двадцать лет назад в бизнесе программирования считалось нормальным, что разработчики самостоятельно тестировали свой код. Более того, программист мог естественным образом предполагать, что только он сам способен достаточно надежно протестировать собственный код, только он сам может знать обо всех слабых местах и пыльных углах, куда следует заглянуть.
Удивительно, но факт: в те времена все знали, что программисты, хотя им и приходилось заниматься тестированием, как один ненавидели это занятие и сожалели о потраченном на него времени и силах. Однако программисты выполняли работу по тестированию, поскольку честно верили в свою роль в процессе, как и в необходимость агрессивного тестирования.
В последние два десятилетия все в этой индустрии постепенно осознали, что эту часть работы могут выполнять подразделения профессиональных тестеров, освобождая от нее программистов. Поначалу программисты отнеслись к идее скептически, но затем оценили ее. Тестерам же, к нескончаемому удивлению большинства программистов, действительно нравилось тестирование.
Моя машина заставляет меня думать, что я идиот!
Пользователи не знают, чего хотят, а когда знают, то каждый хочет своего. Пусть лучше читают руководства и изучают программы
людям необходимо видеть картину в целом
Истинная выгода от хорошо спроектированного продукта или услуги – бесконечная преданность, которую такой продукт пробуждает в ваших клиентах.
Ларри Кили (Larry Keeley) из Doblin Group создал занимательную концептуальную модель трех важнейших качеств в бизнесе высоких технологий. Кили называет первое качество потенциалом – его источником служат инженеры. Они спрашивают: «На что мы способны? Что возможно?» Инженеры должны знать, что можно создать и чего создать нельзя. Продукт не может стать успешным, если его невозможно создать и заставить работать.
Второе качество Кили называет жизнеспособностью – это вклад деловых людей. Они спрашивают: «Что окажется жизнеспособным? Что мы сможем продать?» Деловые люди должны знать, что можно и чего нельзя создать и прибыльно продать. Продукт не может стать успешным, если не может поддержать растущую компанию.
Эти две стороны зависят одна от другой, но их разнящиеся цели создают структурный изъян отношений. Симбиоз столь же нестабилен, как табурет на двух ножках. И здесь на сцене появляется третье качество, предложенное Кили, которое играет роль третьей ножки табурета.
Третье качество Кили называет привлекательностью, и за эту составляющую отвечают проектировщики. Они должны спрашивать: «Что привлечет людей? Чего они хотят?» Проектировщики должны знать, что сделает людей счастливыми и даст им удовлетворение. Продукт не может иметь долгосрочного успеха, если не дает удовлетворения и ощущения могущества людям, для которых он предназначен.
Привлекательность легко перепутать с потребностью, но это кардинально различные свойства. Меня привлекает возможность провести полтора месяца на Бермудских островах, но мне это не нужно. Если у меня желчные камни, то я нуждаюсь в операционном лечении, но меня это не привлекает. Риэлтор Салли нуждается в том, чтобы продать четыре дома в этом году. А возможность обеспечить четыре семьи счастьем и уютом ее привлекает. Она нуждается в МLS-программе, позволяющей опубликовать предложения своих услуг в многочисленных каталогах, но если эта программа будет заставлять ее чувствовать себя глупой, то она ее не привлечет.
Программисты затрачивают столь много времени и энергии на изучение программного обеспечения, что для инженера казалось непостижимым, как пользователи могут не желать тратить время на изучение плодов его труда. Он с готовностью принимал версию, что источником проблемы является его компания, но полностью отрицал свою роль в создании этой проблемы. Он винил продавцов за то, что они не помогают покупателям изучить продукт. Он был готов работать, чтобы решить проблему, скажем, путем создания новых обучающих материалов, однако совершенно не считал возможными даже намеки на его собственное участие в сложившемся положении продукта.
«…четыре базовых принципа, составляющих правила вежливых взаимодействий, это качество, количество, значимость и ясность».
Вот мой список элементов, повышающих качество взаимодействия, как для людей, так и для высокотехнологичных, основанных на программном обеспечении продуктов, насыщенных когнитивным сопротивлением:
Вежливая программа интересуется мной
Вежливая программа относится ко мне уважительно
Вежливая программа обходительна
Вежливая программа ведет себя разумно
Вежливая программа предвидит мои потребности
Вежливая программа отзывчива
Вежливая программа не склонна делиться своими личными проблемами
Вежливая программа в курсе происходящего
Вежливая программа проницательна
Вежливая программа уверена в себе
Вежливая программа всегда сосредоточенна
Вежливая программа покладиста
Вежливая программа дает мгновенное удовлетворение
Вежливой программе можно доверять
Найдя решение главной проблемы, вы делаете главной проблемой следующую по списку
какова была наша цель, для кого мы все это делали? Никто и никогда не дал адекватного ответа на этот вопрос
С большой долей иронии я называю программистов хомо логикус. Вид хомо логикус слегка – но достаточно ощутимо – отличается от вида хомо сапиенс, человека разумного. Из собственных наблюдений я почерпнул четыре фундаментальных отличия образа мысли и действия разработчиков программ от обычных людей. Об этих отличиях и пойдет речь в данной главе. Программисты пожертвуют простотой ради контроля. Обменяют успех на понимание. Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. И, наконец, ведут себя грубо и прямолинейно, как быки.
Чтобы подчеркнуть различие между видами, я применяю забавную лакмусовую бумажку – «Авиационный тест». Чтобы пройти тест, достаточно представить, что вы идете по посадочному коридору авиалайнера. Вступив на борт, вы должны выбрать – пойти налево в кабину или же направо в салон.
В кабине пилота целый калейдоскоп сложных органов управления и счетчиков, на всех поверхностях располагаются датчики, ручки и тумблеры. Справа же, в салоне, полная противоположность – мягкие округлые формы, успокаивающие бежевые оттенки.
Если повернуть налево, в кабину, вам придется в совершенстве овладеть сложными техническими материями. Придется узнать, зачем нужен каждый из приборов. За понимание всего этого нагромождения вы получаете ощущение определенного контроля над ситуацией и ответственность за посадку в нужном месте.
Свернув направо, в салон, вы отказываетесь от какого-либо влияния на полет. За отказ от контроля вы получаете возможность расслабиться, зная, что попадете в нужное место, и при этом самой сложной операцией будет включение и выключение лампы для чтения.
Авиационный тест четко делит человеческую расу на две категории: свернувшие налево стремятся контролировать ситуацию и понимать, как работает технология, а свернувшие направо стремятся упростить свои размышления и испытывать уверенность в успешности полета. Программисты – хомо логикус – всегда выбирают поворот налево. Пользователи хомо сапиенс – всегда выбирают поворот направо.
Даже если программисты соглашаются с тем, что к пользователям следует относиться лучше (а обычно они соглашаются), это не означает, что они сделают все необходимое, чтобы достичь озвученной цели.
«Семь привычек крутых инженеров». Эти определения невероятно точны, хотя и гиперболичны.
1. Они щедры в своем эгоизме.
2. Слепота улучшает их зрение.
3. Они кусают не только руку кормящего, но еще и собственные руки.
4. Они готовы приложить любые усилия, чтобы сохранить впечатление, будто их не заботит собственный имидж.
5. Они чинят то, что не сломано, до тех пор, пока это не сломается.
6. «Не я дал неверный ответ, а вы задали не тот вопрос».
7. Считают отсутствие критики комплиментом.
Три человека приговорены к казни: священник, адвокат, инженер. Первым на эшафот вступает священник. Палач дергает за рычаг, открывающий люк, но ничего не происходит. Священник заявляет, что это божественное вмешательство, и требует, чтобы его освободили, что и происходит. Выводят адвоката. Палач дергает за рычаг, и снова осечка. Адвокат заявляет, что еще одна попытка будет расценена как повторное привлечение к ответственности за то же преступление, и требует, чтобы его отпустили, – что и происходит. Наступает очередь инженера, который приступает к внимательному изучению механизма Три человека приговорены к казни: священник, адвокат, инженер. Первым на эшафот вступает священник. Палач дергает за рычаг, открывающий люк, но ничего не происходит. Священник заявляет, что это божественное вмешательство, и требует, чтобы его освободили, что и происходит. Выводят адвоката. Палач дергает за рычаг, и снова осечка. Адвокат заявляет, что еще одна попытка будет расценена как повторное привлечение к ответственности за то же преступление, и требует, чтобы его отпустили, – что и происходит. Наступает очередь инженера, который приступает к внимательному изучению механизма
Тот факт, что граничные условия могут наступать лишь раз в 79 лет ежедневного применения программы, программиста совершенно не утешает. Что если этот Раз наступит завтра?
В недавнем субботнем приложении к «Таймс» мне довелось прочесть занимательную историю американской пары, после выхода на пенсию уехавшей жить в Мексику. Они купили участок в предместье крупного города и наняли архитектора-американца для проектирования дома своей мечты. Затем они наняли мексиканского подрядчика и передали ему чертежи. В ходе строительства они с изумлением обнаружили, что получается совсем не тот дом, который описал архитектор.
Чертежи указывали, что на фасаде дома должно быть четыре окна, произведенные конкретным изготовителем, и приводили даже точный идентификационный номер товара. Владельцы дома обнаружили, что на фасаде три окна, совершенно иных по виду и размерам. На их расспросы мексиканский строитель пожал плечами и сказал: «Это ведь окна. В плане указано, что окна на этой стороне. В чем проблема?»
Копирование атрибутов успеха вместо его причины – ошибка распространенная. Это все равно что увидеть револьверы генерала Джорджа Паттона, украшенные перламутровыми рукоятями, и прийти к ошибочному выводу, что можно стать хорошим стратегом, только если носишь изысканное личное оружие
Пример: Sagent Technology, поставщик систем управления данными для рынка корпоративных вычислений. В этой компании главным специалистом в области баз данных является Влад Горелик (Vlad Gorelik), о компетентности которого в программировании ходят легенды. Непосредственно он общается лишь с теми клиентами, которые способны трепаться о «сегментации запросов», «распределении задач» и «кубах данных» с той же степенью увлеченности. И не удивительно, что Влад считает типичного пользователя Sagent Information Studio бывалым специалистом по базам данных.
Напротив, Алиса Блэр (Alice Blair), менеджер компании по Information Studio, проводит львиную долю времени в разговорах с потенциальными покупателями продукта. Она объясняет этим людям, что может продукт, каковы его базовые функции. Как следствие, Алиса считает, что в пользовательской аудитории много тех, кто не знаком с продуктом, и тех, кто обладает лишь базовыми навыками работы с компьютером. Неудивительно, что, по ее мнению, большинству клиентов требуется поддержка.
Кендал Косби (Kendall Cosby) работает в службе технической поддержке Sagent. Он не общается с экспертами и новичками. В основном ему приходится работать с конечными пользователями среднего уровня. Поскольку продукт применяется для поддержки принятия решений, Кендал находится в постоянном контакте с финансовыми и рыночными аналитиками, которые мало что знают о компьютерах и базах данных, но в своей работе зависят от возможности обращаться к хранилищам данных и анализировать тенденции в продажах. Собеседники Кендала не очень хорошо разбираются в компьютерах, и ему хотелось бы, чтобы продукт скрывал сложную функциональность или не содержал таковой вовсе. Из всех троих наиболее точным видением клиента обладает Кендал, однако именно Влад и Алиса имеют больше возможностей влиять на архитектуру продукта, поскольку занимают соответствующие должности.
использовала шоколад. Подкуп действовал настолько хорошо, что однажды руководитель группы, пав на колени, публично извинялся передо мной, что забыл уведомить об изменениях в продукте. (Да, свое угощение он все равно получил.) В одной компании пристрастившийся к шоколаду инженер рассказывал мне обо всех изменениях, внесенных его коллегами, чтобы получить и их шоколад. До открытия такого способа подкупа я потратила массу времени сверхурочно, пытаясь выяснить, каким образом изменился продукт. Подкуп же позволил сократить сверхурочную работу раза в два.
Чтобы сделать человека жестоким, не нужны утонченные инструменты, достаточно взгляда или пинка. Нас делает жестокими не технология. Обесчеловечивают технологи, а точнее говоря – процессы, применяемые технологами для создания обесчеловечивающих продуктов.
Роберт Лутц (Robert Lutz), руководитель компании Chrysler, говорит, что 80% участников фокус-группы возненавидели новый пикап Dodge Ram. Но после выхода на рынок машина стала бестселлером, потому что остальные 20% в нее влюбились. Любовь людей к продукту, пусть даже этих людей не очень много, – вот ключ к успеху.
Чтобы сделать каждый персонаж более реальным для участников проекта, я люблю дополнять имена портретами, прикреплять к каждому персонажу изображение. Как правило, я покупаю изображения в ceтевых фотобиблиотеках, но мне случалось работать и с быстрыми набросками. Можете вырезать изображения из журналов, если угодно.
Четко обозначенный, полностью развитый персонаж становится мощным инструментом. До тех пор, пока пользователь не имеет четкого определения, программист может воображать, будто пользователем является он сам. Четко определенный персонаж – это ключ к подавлению склонности разработчика искажать характеристики пользователей. Задолго до написания первой строки кода качественно определенный персонаж становится невероятно эффективным средством для проектирования взаимодействия.
Даже на стадии прототипа в интерфейсе уже была красивая трехмерная графика, высокохудожественные пиктограммы, а также метафорическая тема карты-глобуса – все атрибуты хорошего, но пустого интерфейса. Мы называем это «раскраской трупа».
Сущность качественного проектирования взаимодействия заключается в изобретении таких взаимодействий, которые помогут пользователям достигать практических целей, не препятствуя достижению личных целей
Известная человеческая черта, и Тед здесь не исключение, – реагировать на компьютеры эмоционально (более подробно чуть позже в этой главе). Взаимодействуя с продуктом, человек естественным образом наделяет этот продукт человеческими качествами. Тед готов вложить дополнительные усилия в настройку своего телевизора, поскольку чувствует, что телевизор приложил усилия, чтобы доставить ему, Теду, удовольствие. Это я и называю принципом соразмерности усилий. Люди готовы постараться, решая задачи, потому что воспринимают это, как честный обмен между равными сторонами. Иначе говоря, пользователь готов приложить дополнительные усилия, потому что ожидает получить за эти усилия дополнительное вознаграждение.
Психологи, изучающие рабочую обстановку, применяют термин «гигиенические факторы», которые Сол Геллерман (Saul W. Gellerman)1 определяет как «элементы, обязательные для эффективной мотивации, но не способные мотивировать самостоятельно». Освещение в вашем офисе – гигиенический фактор. Вы ведь не ходите на работу только потому, что там хорошее освещение, но если бы освещения не было, вы не ходили бы туда вовсе.Я адаптировал этот термин, заменив факторы целями: «гигиенические цели». Я их определяю как цели, необходимые для эффективной работы, но сами по себе не мотивирующие.
Человеческий мозг считает компьютеры не столько неодушевленными предметами, сколько предметами, поведение которых схоже с человеческим, поэтому мы бессознательно относимся к ним, как к другим людям, хотя и «считаем, что это неразумно». Иначе говоря, у людей есть особые инстинкты, подсказывающие, как надо вести себя рядом с другими разумными существами, и как только произвольный объект демонстрирует достаточно серьезное когнитивное сопротивление, эти инстинкты включаются, и мы реагируем так, будто имеем дело с другим разумным человеческим существом. Эта реакция бессознательна и неизбежна, она присуща каждому человеку.
Обычно самые мощные инструменты позволяют нам понять, представить личности наших пользователей, вжиться в них. Одну умозрительную модель мы применяем постоянно – она называется «вечные середняки». Большинство пользователей – не новички и не эксперты, они просто вечные середняки. Помните Рупака, Шэннон, Декстера и Роберто из главы 9, где речь шла об уровне подготовленности? Квалификации этих людей совершенно различны, но все четверо являются вечными середняками.
Какое-то минимальное время любой пользователь продукта проводит в статусе новичка, но никто надолго в этом статусе не задерживается. Просто потому, что никто не любит быть новичком, ни у кого нет такой цели. Людям не нравится собственная некомпетентность, а новички некомпетентны по определению. И напротив, обучение и совершенствование – естественный, увлекательный, приносящий удовольствие процесс, поэтому новички очень быстро превращаются в середняков.
В пределах компании руководство, отделы продаж и маркетинга постоянно расхваливают продукт клиентам, журналистам, партнерам, инвесторам, то есть людям, с продуктом не знакомым. Эти профессионалы вынуждены постоянно контактировать с начинающими, поэтому их видение пользовательской аудитории искажено и определяется именно этой проблемной группой
Программисты – короли практичности. Прагматизм практически лишает их терпимости к фантазиям. Но эта сила может стать и слабостью, поскольку случается, что практичный подход не позволяет решить задачу.
независимо от того, насколько интерфейс классный, чем его меньше, тем лучше.
Однажды нас посетил менеджер продукта из одной крупной компании, чтобы проконсультироваться по поводу перепроектирования продукта. В интерфейсе будет примерно десяток диалоговых окон, сказал он. Мы описали ему наш процесс, а затем дали оценку работы. Если мне не изменяет память, цифра составила $60000. «Возмутительно! – воскликнул тогда менеджер. – Это же $5000 за экран!» У меня не хватило духу сказать ему, что мы, вероятно, сократим количество диалогов до одного или двух, и тогда цена, если ее исчислять таким методом, станет гораздо выше. Он просто не понял, о чем речь. Платить за проектирование, исчисляя стоимость в экранах, все равно, что платить официанту за количество подходов к столику. Лучший официант меньше бегает, а лучший проектировщик всегда создает менее развесистые интерфейсы.
Большинство действительно новаторских прорывов сложны в разработке и вполне очевидны задним числом. Невероятно сложно увидеть прорыв в проектировании. Можно получить подготовку, пройти обучение, потратить многие часы на изучение задачи, но не найти ответа. Затем приходит человек со стороны, указывает на ключевую концепцию, и тут же вся головоломка складывается в полноценное изображение с естественной очевидностью, присущей колесу. Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно. Ученый-компьютерщик Алан Карп говорит: «Практически все мои патентные заявки были отвергнуты как "очевидные"».
На мой взгляд, юзабилити-методы похожи на наждачную бумагу. Если вы делаете стул, наждачная бумага может сделать его более гладким. Если вы делаете стол, наждачная бумага и его сделает более гладким. Но никакая шлифовка не позволяет превратить стол в стул.
Один коллега из крупной компании, разрабатывающей программное обеспечение, провел классический юзабилити-тест, одновременно выявивший сильные и слабые места такого предварительного тестирования. Он хотел определить эффективность строки состояния внизу окна программы. Он предложил участникам выполнить безобидное задание при помощи электронной таблицы. Каждые пять минут в строке состояния появлялось сообщение: «К вашему креслу снизу приклеена банкнота в $50. Возьмите ее!» За целый день тестирования ни один из более чем десяти участников не попытался взять купюру.
Едва ли не самым ценным вкладом тестирования является присутствие программистов, когда они из-за полупрозрачного зеркала вынуждены наблюдать, как пользователи сражаются с их программами. Программисты испытывают шок и крайнее недоверие, они ругаются: «Вы тестируете каких-то недоумков!» Юзабилити-тестирование – меткий камень в огород упрямых разработчиков программного обеспечения, который показывает им, что проблема действительно существует. Оно может послужить той же цели и в случае с руководителями.
Стратегия Мiсrоsоft основана на изморе. Говоря военным языком, враг может быть равен вам в умении сражаться (и даже превосходить вас), но, обладая огромным численным перевесом, вы можете просто обмениваться жертвами, пока у противника не закончатся войсковые соединения; в терминах производства программного обеспечения это означает: выбрасывайте на рынок некачественный продукт, пусть даже это танцующий медведь, а затем слушайте жалобы и стоны своих клиентов. Доводите до ума то, что им не нравится, и выпускайте обновленную версию. После трех или четырех версий открытые очаги болезней пользователей потухнут, а качество достигнет какого-то приемлемого минимума, поддерживаемого широкой функциональностью, после чего расти уже не будет. Итеративный подход не позволяет создавать замечательные продукты. WTF???
Впечатляющий коммерческий успех Мiсrоsоft плох тем, что многие не столь крупные компании пытаются повторить ее успех, действуя такими же методами. В долгосрочной перспективе подобная стратегия часто заканчивается плачевно, что показал пример Netscape, однако она продолжает традицию надругательства над конечными пользователями.
Существует большая разница между тем, чтобы выслушивать клиентов, и тем, чтобы за ними следовать. Выслушивать разумно. Подразумевается, что вы накладываете свой собственный фильтр на услышанное. Следовать требованиям клиента – плохо. То есть просто делать все то, что говорит клиент. Уже не вы играете с огнем, огонь играет с вами.
Если к вам в офис придет клиент и предложит $100000, чтобы вы выбросили свою систему бухгалтерского учета или подожгли ящики с бумагами, сделаете ли вы это?
Одна из моих любимых бизнес-аксиом – «если этого нет на бумаге, значит, это не существует» – в мире проектирования программного обеспечения верна, как нигде. Если что-то не записано, более чем вероятно, что это будет неправильно истолковано или опущено. Дело в том, что мотивация программистов очень сильно расходится с мотивацией пользователей. Недостаточно исключить диалоговое окно из описания, проектировщик обязан явным образом указать, где программист не должен по собственной инициативе добавлять лишнее окно.
Программистам нравятся диалоговые окна. Они считают, что оказывают пользователю услугу, добавляя в свободные минуты пару дополнительных диалоговых окон. А пользователи эти окна ненавидят, потому что диалоги их изматывают и снижают производительность.
Некачественный продукт в красивой и красочной упаковке – продукт по-прежнему некачественный.
Если за качество продукта отвечает каждый, это означает, что за качество продукта не отвечает никто.
Если человек получает ответственность за качество продукта и соразмерные полномочия, то он может принять на себя эту ношу независимо от своего опыта. Если взять подходящего человека и дать ему полную власть над качеством и поведением продукта, вы получите продукт намного, намного лучший, чем если этого не сделать. Проблема не в людях, но в процессе
Проектирование взаимодействия делает продукт привлекательным, награждая уникальным рыночным преимуществом – преданностью покупателей. Если покупателя осчастливил ваш продукт, этот человек надолго останется клиентом вашей компании и вашего брэнда. Если же ваш продукт – очередной танцующий медведь, клиенты будут оглядываться в поисках более простых и дружелюбных альтернатив.
Создание правильного продукта – всегда итеративный процесс. Чтобы добиться точности в деталях, требуется несколько попыток. Проектирование взаимодействия позволяет значительно уменьшить количество итераций. Выпуск каждой новой версии продукта сопряжен с огромными затратами, поэтому, уменьшая количество версий с четырех до двух, вы экономите массу денег и времени.
Десять лет назад консультант по розничным продажам Сеймур Меррин (Seymour Merrin) сказал, что нам проще было убедить покупателей, что программами легко пользоваться, чем сделать так, чтобы программами было легко пользоваться. Высказывание Меррина было циничным, однако он также выражал удивление, что нам сошла с рук столь наглая ложь. Сегодня его слова все еще справедливы, но рост высоких технологий не оставляет возможности и дальше выезжать на одном цинизме – нам требуется настоящее решение.
Время от времени у потребителей появляются призрачные надежды, что следующая волна технологии, скажем, распознавание голоса, сделает программные продукты простыми в применении. Надеяться на это наивно и неумно. Мне грустно видеть, как апологеты грубо подыгрывают таким надеждам.
любую форму, какая будет угодна авторам. Они не создают простые в применении программы не потому, что это невозможно, а потому, что не умеют. Чтобы не признавать этот неудобный факт, они заявляют, что лучше сделать просто невозможно «по техническим причинам». Пользователи компьютеров, программистами не являющиеся, вынуждены соглашаться со специалистами и страдать, или же не соглашаться со специалистами и – вот именно – все равно страдать. Не будучи специалистами, они не способны предлагать собственные решения, поэтому к ним относятся, как к бесполезным нытикам.
Штат Детройт производил гигантские хромированные прожорливые автомобили и лицемерно утверждал: «Мы даем потребителям то, что им нужно». Во время нефтяного кризиса семидесятых японцы вышли на рынок с экономичными небольшими автомобилями и нанесли Детройту удар, который не забудется никогда. Сегодня автомобильная индустрия Америки проявляет гораздо большее уважение к желаниям потребителя и уже не осмеливается утверждать, что все знает лучше
потребители способны отличить хорошую вещь от плохой, если им дадут ее увидеть
Двадцать лет назад в бизнесе программирования считалось нормальным, что разработчики самостоятельно тестировали свой код. Более того, программист мог естественным образом предполагать, что только он сам способен достаточно надежно протестировать собственный код, только он сам может знать обо всех слабых местах и пыльных углах, куда следует заглянуть.
Удивительно, но факт: в те времена все знали, что программисты, хотя им и приходилось заниматься тестированием, как один ненавидели это занятие и сожалели о потраченном на него времени и силах. Однако программисты выполняли работу по тестированию, поскольку честно верили в свою роль в процессе, как и в необходимость агрессивного тестирования.
В последние два десятилетия все в этой индустрии постепенно осознали, что эту часть работы могут выполнять подразделения профессиональных тестеров, освобождая от нее программистов. Поначалу программисты отнеслись к идее скептически, но затем оценили ее. Тестерам же, к нескончаемому удивлению большинства программистов, действительно нравилось тестирование.
Моя машина заставляет меня думать, что я идиот!
Пользователи не знают, чего хотят, а когда знают, то каждый хочет своего. Пусть лучше читают руководства и изучают программы
людям необходимо видеть картину в целом
Истинная выгода от хорошо спроектированного продукта или услуги – бесконечная преданность, которую такой продукт пробуждает в ваших клиентах.
Ларри Кили (Larry Keeley) из Doblin Group создал занимательную концептуальную модель трех важнейших качеств в бизнесе высоких технологий. Кили называет первое качество потенциалом – его источником служат инженеры. Они спрашивают: «На что мы способны? Что возможно?» Инженеры должны знать, что можно создать и чего создать нельзя. Продукт не может стать успешным, если его невозможно создать и заставить работать.
Второе качество Кили называет жизнеспособностью – это вклад деловых людей. Они спрашивают: «Что окажется жизнеспособным? Что мы сможем продать?» Деловые люди должны знать, что можно и чего нельзя создать и прибыльно продать. Продукт не может стать успешным, если не может поддержать растущую компанию.
Эти две стороны зависят одна от другой, но их разнящиеся цели создают структурный изъян отношений. Симбиоз столь же нестабилен, как табурет на двух ножках. И здесь на сцене появляется третье качество, предложенное Кили, которое играет роль третьей ножки табурета.
Третье качество Кили называет привлекательностью, и за эту составляющую отвечают проектировщики. Они должны спрашивать: «Что привлечет людей? Чего они хотят?» Проектировщики должны знать, что сделает людей счастливыми и даст им удовлетворение. Продукт не может иметь долгосрочного успеха, если не дает удовлетворения и ощущения могущества людям, для которых он предназначен.
Привлекательность легко перепутать с потребностью, но это кардинально различные свойства. Меня привлекает возможность провести полтора месяца на Бермудских островах, но мне это не нужно. Если у меня желчные камни, то я нуждаюсь в операционном лечении, но меня это не привлекает. Риэлтор Салли нуждается в том, чтобы продать четыре дома в этом году. А возможность обеспечить четыре семьи счастьем и уютом ее привлекает. Она нуждается в МLS-программе, позволяющей опубликовать предложения своих услуг в многочисленных каталогах, но если эта программа будет заставлять ее чувствовать себя глупой, то она ее не привлечет.
Программисты затрачивают столь много времени и энергии на изучение программного обеспечения, что для инженера казалось непостижимым, как пользователи могут не желать тратить время на изучение плодов его труда. Он с готовностью принимал версию, что источником проблемы является его компания, но полностью отрицал свою роль в создании этой проблемы. Он винил продавцов за то, что они не помогают покупателям изучить продукт. Он был готов работать, чтобы решить проблему, скажем, путем создания новых обучающих материалов, однако совершенно не считал возможными даже намеки на его собственное участие в сложившемся положении продукта.
«…четыре базовых принципа, составляющих правила вежливых взаимодействий, это качество, количество, значимость и ясность».
Вот мой список элементов, повышающих качество взаимодействия, как для людей, так и для высокотехнологичных, основанных на программном обеспечении продуктов, насыщенных когнитивным сопротивлением:
Вежливая программа интересуется мной
Вежливая программа относится ко мне уважительно
Вежливая программа обходительна
Вежливая программа ведет себя разумно
Вежливая программа предвидит мои потребности
Вежливая программа отзывчива
Вежливая программа не склонна делиться своими личными проблемами
Вежливая программа в курсе происходящего
Вежливая программа проницательна
Вежливая программа уверена в себе
Вежливая программа всегда сосредоточенна
Вежливая программа покладиста
Вежливая программа дает мгновенное удовлетворение
Вежливой программе можно доверять
Комментариев нет:
Отправить комментарий