Общая культура

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

Разработчики программ, принадлежащие к виду Хомо логикус, объединены общей культурой, порожденной их коллективной психологией. Тот общепризнанный способ, каким создаются программные продукты, на удивление одинаков для компаний, выпускающих камеры, для автокомпаний, банков и морфлота, потому такие, казалось бы, разные продукты, как фотоаппарат, автомобили Porsche, банкоматы и крейсеры, оснащенные системой «Иджис», все как один имеют такое узнаваемое, схожее с компьютерами поведение.

Благоговение перед технической подкованностью – также одно из характерных для этой культуры явлений. В результате существования этого явления возникает другой эффект – важность владения техническими навыками проецируется на другие сферы, даже на те, где в таком поклонении нет необходимости, например на проектирование взаимодействия. Тридцать лет назад, когда компьютеры размещали в специальных серверных с окнами (glass houses), к которым имели доступ только специально обученные программисты, проектирование на основании собственных предпочтений разработчиков имело смысл и отвечало требованиям времени. Когда впоследствии компьютеры постепенно стали выходить на потребительский рынок, программисты все еще занимались проектированием, потому что так исторически сложилось. Руководители разработки задаются вопросом: «Зачем мне платить проектировщикам взаимодействия, если я и так уже получаю эту работу от программистов, притом бесплатно?» Вопрос справедлив, только в его основе лежит изначально неверный довод. У этого руководителя не будет никакого проектирования взаимодействия – ни платно, ни бесплатно. Все, что он получит в итоге, – это интерфейс, спроектированный лишь для удовольствия его создателей: людей с особой подготовкой, собственной индивидуальностью и нетипичными склонностями.

Здесь мы можем увидеть еще одну ключевую особенность культуры разработки программ. Несмотря на то что эта культура базируется на специфической природе программистов, их руководители также оказывают на нее существенное влияние, потому что сами, надо сказать, когда-то были программистами. Джефф Безос упомянул, что громче всех «интерфейс в два клика» защищал менеджер по продукту!

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

Культура программирования в компании Microsoft

Силу и влияние культуры разработки ПО переоценить трудно. В 1995 году Фред Муди написал книгу I Sing the Body Electronic («Электронное тело пою»), посвященную Microsoft. Базируясь на исследовании этой типичной компании по разработке программного обеспечения, книга описывает, как глубоко укоренилась в нашем обществе культура «ботаников». Фред Муди – путешествующий писатель и журналист, обозревающий компьютерные темы, провел год в стенах Microsoft, наблюдая за разработкой мультимедийного инновационного продукта, который впоследствии получил название Explorapedia. Муди был предоставлен неограниченный доступ ко всему, что происходило в Microsoft, и его книга рисует нашему взору показательную картину той жизни и культуры, которая существовала внутри ведущей компании в индустрии. Как видно по продуктам Microsoft, программирование глубоко почитается компанией, а вот необходимость в проектировании взаимодействия ею совсем не осознается. Книга представляет собой увлекательное исследование всего, что происходит в культуре программирования.

Вступление книги создает предпосылки для дальнейшего рассказа:

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

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

Эта книга являет собой удивительную летопись того, что методы работы Microsoft нередко бывают спорны, непрофессиональны и оказывают деморализующее воздействие. Увиденное там озадачило и самого Муди, вместе с тем он был уверен, что стал свидетелем чего-то невероятно важного. Что ему сразу бросилось в глаза – так это программисты, правящие бал. И даже в те моменты, когда они не делают этого явно, они все равно влияют на все косвенно, силой своей воли. Муди ни разу не ставит под сомнение свое или чье-либо другое убеждение, следует ли программистам и в самом деле быть у руля, однако он постоянно упоминает сопротивление, разногласия, неприязнь и чувство неудовлетворенности, которые этому сопутствуют:

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

Очевидно, что Фреду довелось стать свидетелем создания пляшущего медведя: тоскливого и сложного в использовании продукта, единственным лучом света в котором были опции, недоступные в каких-либо других продуктах.

Продукт Explorapedia можно назвать классическим примером того, насколько деградировал нормальный процесс разработки. Я не сомневался, что проект оказался провальным. А вот Муди озадачило, что продукт вышел точно в срок и принес прибыль. Последние страницы книги, названные автором как Postmortem, содержат такой текст:

Никогда бы не подумал, что мое знакомство с Microsoft закончится летописанием истории провального проекта. Тем не менее с самого начала и до конца моего пребывания здесь меня не покидало ощущение, что мне преподносят урок, как не надо разрабатывать продукт. С тех пор как все, кто был задействован в проекте Explorapedia, казались такими несчастливыми, злыми и беспрерывно говорили, как они расстроены и разочарованы, я мог сделать только один вывод – что невольно созерцаю надвигающуюся катастрофу. Однако по факту проект Explorapedia был безоговорочно успешен.

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

Безусловно, самым губительным фактором для продукта можно считать его слабую проработанность. Завершая свой рассказ, автор приводит цитату одной из участниц проектирования, Сары Фокс, в тот момент, когда она…

…смотрит на книгу издательства Dorling Кindersley, на основе которой была создана Explorapedia. Сара потрясенно осознает, что, исследуя печатную книгу, читатели чувствуют себя гораздо более свободно, чем при изучении ее компьютерной версии. Хотя изначально предполагалось, что компьютер станет великой силой, избавляющей от всяких ограничений бумажного издания. Книга, по словам Сары, содержала иллюстрации, вокруг которых свободно располагался текст, так что читатели могли исследовать страницы не спеша, имея возможность охватить большие объемы информации с одного взгляда. В Explorapedia же они были вынуждены проходить через множество всплывающих окон, идущих одно за другим, где в каждый момент времени можно было видеть только несколько предложений. Ужасный парадокс ситуации оказался в том, что компьютер ограничивал читателя в разы сильнее книги. «Dorling Kindersley сделало все прямо противоположным образом, а мы превратились в некое подобие привратников, ограничивающих доступ к ресурсам».

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

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

Сотрудники Microsoft, которые принимали участие в работе над проектом, остались в таком же неведении, как и Муди. Вот что рассказал Кевин Геммил, старший программист проекта:

Кэролин постоянно твердит, что это «адский проект», а Крэйг беспрестанно повторяет, что он еще никогда не сталкивался ни с чем подобным. А еще Крэйг вечно говорит, что вот тут ошибка и тут ошибка, и вот там мы ошиблись с этой энциклопедией Encarta, и теперь здесь снова все повторяется. И Сара тоже не перестает говорить: «Жизненный цикл этого продукта такой… цикличный». И здесь так с каждым проектом! Мы говорим, что учимся на своих ошибках… и все равно каждый раз снова и снова встреваем в ту же [ненормативная лексика].

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

Даже при обычных обстоятельствах участники той команды испытывали затруднения при общении с Геммилом. Дизайнеров и программистов Microsoft разделяла громадная культурная пропасть. Обычно разработчики просто не могли объяснить дизайнерам даже мельчайшие детали проблемы программирования. И напротив – долгие недели работы дизайнеров над каким-либо аспектом продукта заканчивались тем, что разработчики выносили жесткий вердикт о невозможности реализации указанного.

Несмотря на то что в последние годы наблюдается некоторое улучшение ситуации, два этих противостоящих лагеря все же говорят на разных языках, их взгляды на мир компьютеров с интеллектуальной, культурной, психологической и эстетической точки зрения полярно различаются. Дизайнеры Microsoft имели подход, присущий гуманитариям, а разработчики – математикам и деятелям науки. Разработчики считали себя выше дизайнеров, поскольку полагали, что последние обладают неясным бессистемным мышлением и переменчивыми предпочтениями. Дизайнерам, в свою очередь, казалось, что у разработчиков напрочь отсутствует воображение, а кроме того, они консервативны и имеют тенденцию моментально отклонять все предложения по дизайну, даже не желая попытаться найти решение. А ввиду того что таинства программирования были непостижимы для дизайнеров, те никак не могли оценить, насколько доводы разработчиков справедливы и задуманное действительно не подлежит реализации. «Дизайнеры, – как частенько поговаривал Том Кордри, – это обязательно женщины, они любят поболтать, живут в лофтах, предпочитают вегетарианство и носят в ушах дары природы. Разработчики – непременно мужчины, питаются фастфудом, преимущественно молчаливы и говорят вслух только одно: „Неправда“». Еще он мог бы добавить, что методы разрешения конфликтных ситуаций у разработчиков и дизайнеров также различаются. Разработчики порой склонны вести себя как дети, и, когда им в голову взбредает в шутку обстрелять дверь офиса дизайнеров шариками из игрушечного пистолета, их жертвы спешат пожаловаться супервайзеру. Однако будь на их месте такие же разработчики, они открыли бы ответную стрельбу.

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

К слову, раздраженный ответ «Неправда», упоминаемый Кордри при описании манер разработчиков, прекрасно иллюстрирует одно из «качеств высокоэффективных инженеров» По Бронсона: «Это не я неверно ответил, это вы не так спросили».

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

Со стороны казалось, будто Геммил просто забавляется и подтрунивает над Бьорк, отвечая на ее вопросы, но его поза и поведение, бесспорно, выражали враждебность. Он сидел, напряженно выпрямившись, будто аршин проглотил, раздраженно постукивая по полу одной ногой и барабаня пальцами по столу. Он словно хотел оказаться где угодно, только не здесь. Его отношение к вопросам Бьорк можно было четко отследить по этому стуку об пол ногой и пальцами об стол. Чем о более сложной реализации программной опции шла речь, тем чаще становились проявления раздражения Геммила.

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

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

Однако Microsoft является бесспорно успешной компанией, а это, в свою очередь, влечет удручающий побочный эффект. Многие компании пытаются организовать у себя подобие культуры Microsoft, в надежде стать столь же успешными. Слепое копирование внешних признаков успешности взамен вызвавших успех обстоятельств – заблуждение довольно распространенное. Это как если бы кто-то увидел, что генерал Джордж Паттон носит при себе револьверы с перламутровыми рукоятками, и ошибочно решил, что одного лишь вычурного оружия достаточно, чтобы стать выдающимся стратегом.

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