Алан Купер - Психбольница в руках пациентов

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

Коллективная психология хомо логикус порождает общую для разработчиков программного обеспечения культуру. Общепринятый способ создания продуктов, основанных на программном обеспечении, поразительно схож для фотокамер и автомобилей, для банков и военно-морских сил. Именно поэтому столь различные продукты, как фотоаппараты, автомобили Porsche, банкоматы и крейсеры Aegis ведут себя столь одинаковым, узнаваемым, компьютерным образом.

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

Это подчеркивает другой ключевой аспект культуры разработки программного обеспечения. Эта культура, построенная на особенной природе программистов, получает поддержку со стороны руководителей, многие из которых, что скрывать, – бывшие программисты. Джефф Безос говорит, что самый громкий голос в защиту интерфейса 2-Click (в два щелчка) принадлежал менеджеру этого продукта!

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

Трудно переоценить роль и значение культуры разработки программного обеспечения. Изучая эту, наиболее типичную компанию, занимающуюся разработкой ПО, Фред Муди (Fred Moody) в своей книге «I Sing the Body Electronic» 22 22 Fred Moody «I Sing the Body Electronic», 1995, Viking, New York. (Электронное тело пою) показывает, насколько глубоко укоренилась в индустрии программирования культура нердов. Этот писатель и журналист, пишущий на околокомпьютерные темы, провел год в стенах Microsoft, наблюдая за созданием нового мультимедийного продукта, названного в итоге «Explorapedia». Муди получил свободный доступ в Microsoft, и его книга рисует откровенную картину жизни и культуры ведущей компании индустрии. Если вы не поняли этого по продуктам Microsoft, то эта фирма глубоко чтит программирование, но не осознает или почти не осознает потребность в проектировании взаимодействия. Эта книга содержит захватывающее исследование процессов, происходящих в культуре программирования.

Во вступлении Муди готовит почву:

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