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

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

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

В высшей степени точный и разоблачающий анализ образа мыслей и поведения программистов приводит в своей книге Пол Глен (Paul Glen)23. Искренне советую прочитать ее всем, кто хочет глубже изучить программистов и их культуру.

Дефицитный образ мыслей

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

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

За последнее десятилетие невероятный прогресс в области компьютерной техники сделал обычным явлением мощнейшие настольные компьютеры по доступным ценам. Любой студент и любая домохозяйка могут обладать мощью, которой в 1974 году позавидовал бы центр обработки данных компании General Motors. И при всем том для создания программ сегодня в большинстве случаев применяются инструменты, технологии, методы и умонастроения, основанные на дефицитном мышлении. Разработчики привыкли задаваться вопросом: «Уложимся ли? Будет ли реакция достаточно быстрой? Какую некритичную функциональность мы можем исключить, чтобы сделать программу более эффективной?» Из рассмотрения исключаются вопросы, имеющие большее отношение к делу: «Поймет ли пользователь? Можем ли мы представить информацию в осмысленном виде? Подходит ли этот набор инструкций для целей пользователя? Какая информация является для пользователя первоочередной?»

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

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

Обесчеловечивает процесс, а не технология

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

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

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

Часть IV

Проектирование взаимодействия – выгодный бизнес

Глава 9

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