И последний претендент на трон проектирования взаимодействия – сама технология. Microsoft, в частности, усиленно навязывает эту ложную панацею. Например, Мiсrоsоft утверждает, что интерфейсы упростятся, как только разовьются технологии распознавания голоса и рукописного ввода. Уверен, что это глупость. Каждая новая технология всего лишь добавляет возможностей для приведения пользователей в отчаяние – при помощи систем более быстрых и более мощных.

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

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

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

В 1986 году компания Мiсrоsоft поторопилась на рынок с первой версией Windows, которая была столь смехотворна, что заслуженно стала предметом шуток. Шесть месяцев спустя Мiсrоsоft выпустила версию 1.03 и исправила некоторые дефекты. Годом позже Microsoft выпустила версию 1.1, а затем версию 2.043. На каждом этапе развития продукта разработчики пытались разрешить проблемы, созданные в предыдущей версии. Наконец, четыре года спустя после выпуска первой версии, Мiсrоsоft представила Windows 3.0, и все перестали смеяться. Мало какие компании в этой индустрии имеют такое упорство и финансовые возможности, позволяющие выдержать четыре года публичного унижения и добиться, наконец, приемлемого результата. При этом все наблюдают, как лидер де-факто слепо спотыкается практически до победного конца, после чего делают очевидный вывод о том, что именно так и нужно действовать.

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

Стратегия Мiсrоsоft основана на изморе. Говоря военным языком, враг может быть равен вам в умении сражаться (и даже превосходить вас), но, обладая огромным численным перевесом, вы можете просто обмениваться жертвами, пока у противника не закончатся войсковые соединения; в терминах производства программного обеспечения это означает: выбрасывайте на рынок некачественный продукт, пусть даже это танцующий медведь, а затем слушайте жалобы и стоны своих клиентов. Доводите до ума то, что им не нравится, и выпускайте обновленную версию. После трех или четырех версий открытые очаги болезней пользователей потухнут, а качество достигнет какого-то приемлемого минимума, поддерживаемого широкой функциональностью, после чего расти уже не будет. Итеративный подход не позволяет создавать замечательные продукты.

Стратегия измора не просто дорого обходится и заставляет тратить уйму времени, она омерзительна, потому что негуманна по отношению к пользователям компьютерных технологий. К несчастью, эта стратегия неплохо служит Мiсrоsоft. Компания не устает выпускать сырые, непродуманные, плохо сконструированные и спроектированные продукты на потеху индустрии и осмеяние наблюдателей, как пристрастных, так и беспристрастных. Однако пока специалисты отпускают язвительные замечания, Мiсrоsоft продолжает поддерживать свои первые попытки вторыми, третьими, четвертыми, пятыми, наконец, одиннадцатыми версиями. Такие продукты, как Windows, ActiveX, Word, Access, Windows NT и многие другие, в конечном итоге стали гигантами соответствующих рыночных ниш.

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

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

Игрока, применяющего стратегию истощения, вполне можно победить, но только не подобным подходом. В конце концов, независимо от уровня вашей компании, денег у Microsoft больше. Следует наносить массированные удары по слабому месту Microsoft, а именно в области процесса разработки, ставящего программирование перед проектированием взаимодействия. Мiсrоsоft дважды ущербна в том смысле, что многие люди в компании занимают должность «проектировщика» и выполняют функции, связанные с проектированием. Как показывают выдержки из книги Фреда Муди (см. главу 8 «Отмирающая культура»), культура Мiсrоsoft уже привязалась к неэффективному «проектированию постфактум». Любая компания, готовая заниматься реальным проектированием взаимодействия, сможет побить Мiсrоsоft.

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