Текст книги "Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса"

После собеседования я пошел к Дону и сказал, что не уверен насчет смелых заявлений Ричарда. Дон ответил, что Бертран Серле, начальник Скотта Форсталла, работал с Ричардом в NeXT и очень хорошо о нем отзывается. На Дона собеседование произвело впечатление, и он хотел взять Уильямсона на работу. Но друг уважал мои сомнения и предложил мне позвонить Ричарду по телефону и поговорить еще.

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

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

– А как долго вы, ребята, работаете над этим проектом с браузером? – спросил Ричард.

Судя по его тону, наши усилия его не впечатлили.

– Шесть недель, – ответил Дон.

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

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

Обустройство не заняло у Ричарда много времени. Через два дня он позвал нас к себе посмотреть демоверсию. Что?! Демоверсию?

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

Уильямсон объяснил, что перед нами Konqueror, один из браузеров с открытым исходным кодом, о котором мы рассказали ему пару дней назад. Konqueror был разработан в проекте KDE – сообществе программистов, чьи цели были схожи с проектом GNOME. KDE также представлял собой полнофункциональную компьютерную среду, похожую на Mac и Windows, систему, построенную вокруг свободного программного ядра Linux.

Ричард рассказал, что он загрузил KDE и поставил себе простую цель: добиться работающего на Mac кода так быстро, как только возможно, чтобы он мог оценить потенциал веб-браузера Konqueror. Поскольку KDE работает на Linux, а не на Mac OS X, Ричарду пришлось, как он сказал, сделать оболочку – дополнительное программное обеспечение, которое заставляло Konqueror «думать», что он работает на компьютере с Linux, а потом «убеждало» компьютер, что браузер – это программа, сделанная под Macintosh. Внесу ясность: написать оболочку чрезвычайно сложно. Понимать, что эта проблема разрешима, было потрясно. Всего за два дня у нас была рабочая оболочка, так что уверенность Ричарда в своих силах оказалась небезосновательной. Да что там, это был высший пилотаж программирования.

Видя наше изумление, Уильямсон сказал нам, что были две хитрости, с помощью которых он заставил свою демоверсию работать. Во-первых, он использовал графическую подсистему Linux X Windows вместо графической системы Apple, оригинальной для Mac OS X. Во-вторых, он запустил всю систему KDE, а не только веб-браузер Konqueror. Если для вас эти слова могут звучать как техническая абракадабра, то для нас они ею не были. Чем дальше Ричард описывал свою работу, тем больше мы с Доном понимали, как эти хитрости позволили ему быстро воспользоваться кодом Konqueror.

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

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

Мы с Доном шесть недель работали над созданием веб-браузера для Macintosh, но у нас все еще не было работающего кода и никаких вариантов его сделать. За очень маленький отрезок этого времени Ричард загрузил веб-браузер из Linux и приспособил Konqueror так, что его можно было загружать на Mac. Его демоверсия браузера работала, она могла загружать веб-страницы, она не «падала» и хорошо себя показывала. Мы с Доном были восхищены. Если бы Ричард еще и повторил свои движения коленчатого вала, думаю, я бы упал в обморок.

Как же Уильямсон всего этого добился? Мы с Доном были опытными программистами, и Дон многие годы занимался разработкой браузеров в Netscape, тем не менее демоверсия Ричарда сразила нас наповал.

Можно ли лучше оценить его достижение, измерить его качественно и количественно? Возникает искушение процитировать легендарное высказывание и назвать Ричарда «10х программистом» – суперпродуктивным гением, который может приносить намного больше пользы, чем простые смертные⁹.

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

Имеют ли эти ограничения отношение к развитию информационных технологий? В классической книге по разработке программного обеспечения «Мифический человеко-месяц»¹⁰, вышедшей в 1975 году, Фредерик Брукс говорит, что имеют. Рассказывая о том, чему он научился, будучи руководителем проекта по созданию операционной системы мейнфреймов OS/360 в 1960-е годы в IBM, Брукс делится наблюдением: «Если задачу нельзя разбить на части, поскольку существуют ограничения на последовательность выполнения этапов, то увеличение затрат не оказывает влияния на график. Чтобы родить ребенка, требуется девять месяцев, независимо от того, сколько женщин привлечено к решению данной задачи»¹¹.

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

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

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

Чем можно объяснить такое отличие? Поначалу может сложиться впечатление, что многое держится на ловкости Ричарда как программиста, на его созданной программными средствами оболочке. Тем не менее его усилия по работе с Konqueror очень напоминают мои попытки обуздать Mozilla. Возможно, он просто был куда лучшим программистом, чем я, и без его таланта в разработке кода не было бы и этой истории.

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

Он начал с того, что расспросил нас о том, какой анализ браузеров мы провели до его прихода в компанию, и, услышав об этом, быстро сбросил со счетов нашу идею с Mozilla, поскольку этот браузер едва ли нам подходил. Так он показал, что уверен в себе, и не стал заискивать перед руководителем с многолетним опытом в технической области, где Уильямсон был новичком. Далее Ричард сумел добиться результата в самые короткие возможные сроки. Он загрузил проект с открытым исходным кодом, который выглядел многообещающим, – исходник Konqueror из KDE, браузер, который мог стать основой для нашей долговременной работы. Пытаясь заставить этот код работать на Macintosh, Уильямсон решил сделать наиболее близкую к реальности версию браузера, которую только возможно было создать за короткий срок. Он выделил три функции: загрузка страниц, переход по ссылкам и возвращение на предыдущую страницу. Он посчитал, что уже это может стать достаточно веским подтверждением концепции. Затем Ричард применил свои хитрости для упрощения задачи, и после стало понятно, чего у нас пока не будет: на время пришлось отказаться от идеального отображения шрифтов, а также от полной интеграции с оригинальной графической системой Macintosh, равно как и от использования минимального количества исходного кода KDE. Уильямсон рассудил, что все эти недоделки хотя и имеют значение, но не могут существенно преуменьшить значение от появления браузера, отображающего веб-страницы. Он решил свести воедино все эти составные части в одну демоверсию, которая показала бы потенциал Konqueror. Наконец, затем он проработал технические детали и таким образом разработал оболочку, поскольку оставалось только одно препятствие, мешающее реализации его плана. Его мышление дополнило техническую смекалку.

А вот мы с Доном вцепились в то, что Mozilla каким-то образом оправдает ожидания. Я пытался заставить эту громадину с открытым исходным кодом скомпилироваться на Macintosh, нисколько не думая, что же будет после этого. У меня не было никаких достойных планов, целей, списка того, чем можно пренебречь, жесткого графика или технических задумок.

Эту разницу в мышлении более всего подчеркивают отличия в наших результатах. Не то чтобы мы с Доном так держались за привычный образ действий. Просто наш подход к работе в Apple оставался тем же, которого мы придерживались в Eazel, где мы никогда и понятия не имели, на правильном ли мы пути к созданию великолепного сервиса для настольных компьютеров плюс облачного сервиса. У этого была очень простая причина: у нас никогда не было возможности опробовать наше программное обеспечение как единое целое, пока у компании не кончились деньги и она не избавилась от большей части сотрудников. В Eazel мы и представить себе не могли ничего, хоть отдаленно напоминающего быстрые, ориентированные на выполнение схемы, которые только что показал нам Ричард.

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

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

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

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

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

Одна из моих любимых натурных сцен – это площадка из «Поющих под дождем», мюзикла 1952 года, выпущенного компанией Metro-Goldwyn-Mayer, с Джином Келли и Дебби Рейнольдс в главных ролях. Рассмотрим заглавный танцевальный номер фильма, где Джин Келли после того, как поцеловал Дебби Рейнольдс, желая ей спокойной ночи на крыльце ее дома, с ликованием отбивает чечетку, прыгает, приземляется в воду и кружится под проливным дождем. Эта сцена поставлена на голливудской натурной площадке, изображающей городскую улицу. Сразу после того, как Келли окатил бурный поток воды из водосточной трубы, спускающейся с крыши одного из «зданий», мимо которых он движется в танце, актер минует магазин женских головных уборов La Valle – соблазнительно выглядящую витрину с выставленными в ней модными женскими шляпками. Конечно, этот магазин не был настоящим. Витрина могла быть плоской фанерой, за которой ничего не было, или за дверью «магазина» мог скрываться обычный студийный кабинет, где, возможно, сидел бухгалтер или клерк MGM. Нам это неважно. Мы слишком очарованы танцами и пением. Сравните этот фальшивый магазин шляп с еще одним предметом реквизита, который мы видели раньше, когда Келли запрыгивал на фонарный столб на краю тротуара. В отличие от магазина шляп этот фонарный столб должен быть реальным или, по крайней мере, достаточно реальным, чтобы выдержать вес актера. А что насчет остальных фонарных столбов на площадке? Мы не знаем, но, опять же, нам это не важно. Может быть, они настоящие, а возможно, и нет, но декораторы должны быть уверены в том, что один определенный фонарный столб достаточно прочен, чтобы главный герой фильма запрыгнул на него. Он должен быть хорошо сделан, потому что этого требует танец.

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

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

За годы, которые прошли с тех пор, когда Ричард показал мне свою демоверсию браузера, я перенял манеру его работы.

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

Главное – это, собственно, то, что обведено маркером, и им я уделяю особое внимание, точно так же, как декораторы уделяли внимание фонарному столбу на съемочной площадке. За пределами нарисованных кругов я оставляю менее важные детали, которыми, конечно, когда-нибудь придется заняться, но делать это немедленно нет необходимости. Им я уделяю минимум внимания. Я исключаю их из демоверсии, если могу без них обойтись, как внутреннюю часть того магазина головных уборов. С особой осторожностью я подхожу к тому, что оказывается на границе. Некоторые элементы находятся на воображаемой жирной черте. Это детали, которые требуют некоторого внимания, поскольку они помогают задать тон и развеять сомнения тех, кто будет смотреть демо. Например, если речь об экране параметров настройки приложения или второстепенном элементе пользовательского интерфейса, находящемся в стадии разработки, я могу сделать скриншот экрана с настройками другого приложения вместо того, чтобы делать полный рабочий интерфейс. Это похоже на то, как реквизитор кладет в витрину несколько шляп. Я хочу, чтобы те, кто будет смотреть мою демоверсию, думали, что видят что-то настоящее, хотя оно таковым и не является. Я понимаю, что она не является реальным продуктом, и моя аудитория тоже это понимает, но в процессе разработки создание видимости настоящего продукта очень важно для того, чтобы увидеть, чего же мы в действительности пытаемся добиться. Таким же образом мои коллеги могут начать реагировать и давать отзывы о моей работе, словно демоверсия – это уже продукт.

Эта попытка сделать процесс разработки непрерывным и последовательным предполагает еще одну, последнюю характеристику, которую можно сравнить с работой на съемочной площадке. И площадка, и демоверсия – части какого-то крупного проекта. У каждой своя история. Танцы и пение Джина Келли под дождем выражают его радость от первого поцелуя, это тот момент фильма, когда главные герои показывают нам, что влюбились друг в друга. Это магия Голливуда в своем лучшем проявлении. Демоверсия Ричарда была тем переломным моментом, когда нам показали потенциальные возможности открытого кода Konqueror, и мы решили, что это может быть ответом на вопрос, который мы искали. Это магия Кремниевой долины в ее лучшем проявлении.

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

Всему этому мы научились у Ричарда. Он изменил то, как мы работали.