Обучаем собак кошачьим повадкам

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

Каждому разработчику программного обеспечения свойственно считать себя особенным, единственным, кто способен выполнить обе задачи сразу. На самом деле это далеко не так, и печальная судьба General Magic ясно иллюстрирует это. Отдел разработки в General Magic возглавляли Билл Аткинсон и Энди Херцфельд. Оба они когда-то были ведущими разработчиками программного обеспечения для Apple Macintosh и, бесспорно, значительно превосходили многих программистов по уровню своего таланта, креативности и изобретательности. Их совместная работа над проектированием и программированием Macintosh привела к успеху в 1984 году (хотя Джеф Раскин, не участвовавший в программировании, также внес значительный вклад в проектирование). Тем не менее спустя 14 лет после их успеха мир уже не был прежним, и их методы работы уже не подходили. В начале 1993 года я взял интервью у Энди Херцфельда в головном офисе разработки General Magic, который располагался в гостиной дома Энди в Пало-Альто, – тогда он и поведал мне философию его взгляда на проектирование и программирование. Я слушал с удивлением, осознавая, как мала вероятность успеха этой теории. Однако история дала второй шанс проявиться выдающемуся таланту Энди.

Нет никаких сомнений в том, что продукт, который задумали в General Magic, был и до сих пор остается чрезвычайно желанным. Нет никаких сомнений в превосходстве применяемой технологии. Никто не может усомниться в превосходной способности Марка Пората создавать стратегические партнерства и заключать выгодные сделки. И также несомненно то, что компания была основана серьезными людьми с серьезным финансированием. Что же в таком случае привело ее к краху? На мой взгляд, все указывает на проектирование взаимодействия, вернее, на его отсутствие. Невзирая на звездный состав и невероятную одаренность специалистов компании, продукт General Magic появился в результате процесса конструирования, а не проектирования.

Из статьи Мишель Куин о General Magic видно, что сложившийся в отрасли образ мышления попросту пренебрегает очевидными выводами. Автор статьи склоняется в пользу того, чтобы возложить вину за провал продукта на высокомерие и эгоизм Пората, только в Кремниевой долине не найти президента компании, которому не были бы присущи эти качества в непомерном количестве. Высокомерие и эгоизм уж точно не могут привести к провалу компании.

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

* * *

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

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

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

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

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

* * *

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

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

* * *

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

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

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

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

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

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

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

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

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

Ното logicus

С некоторой долей иронии я зову программистов Хомо логикус (Homo logicus): как особый вид, который совсем чуть-чуть, но довольно ощутимо отличается от вида Хомо сапиенс (Homo sapiens), человека разумного. На основании моих личных наблюдений я выделил четыре базовых способа, какими мыслят и действуют разработчики программного обеспечения и которые отличают их от обычных людей, – именно этим отличиям будет в подробностях посвящена данная глава. Программисты готовы с радостью поступиться простотой приложения ради возможности все контролировать. Они променяют успех на понимание. Они фокусируются на всех ситуациях, возможных в реальности, вместо того чтобы учитывать только то, что более вероятно. А еще они ведут себя довольно жестоко.

Самолетный тест

Одна маленькая забавная проверка, которую я называю «самолетный тест», помогает мне безошибочно отличить один вид от другого. Чтобы посмотреть, как она работает, достаточно проделать следующее: представьте, что проходите по посадочному коридору к самолету. Когда вы ступаете на борт, вам нужно выбрать, куда пойти: налево – в кабину для пилотов или направо – в салон для пассажиров.

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

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

 

 

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

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