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

Силу и влияние культуры разработки ПО переоценить трудно. В 1995 году Фред Муди написал книгу I Sing the Body Electronic ^[20] («Электронное тело пою»), посвященную 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 «Психбольница в руках пациентов», ситуация прямо противоположная – все указывало на успех, а в итоге продукт провалился. Руководители ищут причины провала и неудачи вовсе не там, где следует это делать, поэтому не видят закономерность и ложно относят результат на волю случая. Вся эта ситуация чем-то похожа на историю с врачами в девятнадцатом веке – тогда еще не знали, что малярию разносит анофелес – малярийный комар, и считали источником болезни другие факторы, в частности, что болезнь переносится по вечернему воздуху и поражает людей случайным образом, а единственный способ противостоять этой смертельной напасти – надеяться на удачу. Позже, когда была установлена верная причинно-следственная связь возникновения заболевания, его удалось быстро победить.

Культурная изоляция

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

Приведу пример компании Sagent Technology, занимающейся поставками систем управления данными для корпоративных вычислений. Главным экспертом по базам данных в этой компании является Влад Горелик – легендарный программист с невероятно высокими компетенциями. С ним лично доводится пообщаться только тем клиентам, которые способны вести столь же увлеченные беседы о «сегментировании запросов», «декомпозиции задач» и «кубических моделях представления данных», как и он. Оттого вовсе не вызывает удивления, что, по мнению Влада, обычный пользователь Sagent Information Studio глубоко информирован в области баз данных.

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

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

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

Кровный интерес

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

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

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

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

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

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

* * *

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

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

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

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

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

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

* * *

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

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

Книга Пола Глена^[21] являет собой невыразимо точный анализ, обличающий образ мышления и поведения программистов. Если вы желаете лучше понимать программистов и их культуру, непременно прочитайте эту книгу.

Ограниченное мышление

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

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

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

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

Всего каких-то 20–30 лет назад компьютеры обладали такой незначительной производительностью и при этом стоили так дорого, что любая здравая идея ограничивалась малой мощностью головного компьютера. В те времена приоритетным направлением компьютерных наук была разработка технологий, способных уменьшить нагрузку на ограниченные вычислительные ресурсы. Так, для снижения нагрузки применялись такие специально спроектированные технологии, как реляционные базы данных, таблица символов ASCII, файловые системы и язык программирования BASIC. Для программного обеспечения тех лет характерно стремление к высокой производительности в ущерб всем прочим соображениям, в том числе легкости в использовании программы. Однако не стоит забывать, что единожды написанный код обладает поистине природной жизнестойкостью, а потому большая часть этого старого кода, созданного для слабых компьютеров, сегодня лежит в основе программ для современных, высокопроизводительных систем.