1. Демонстрация

«Бзззззз!»

Я посмотрел на свой iPhone. Последние полчаса я нервно вертел его в руках. Наконец я получил сообщение, которого ждал.

«В любую минуту», – гласило оно.

«ОК», – написал я в ответ.

Я сидел, подавшись вперед, упершись локтями в колени, неудобно устроившись на кожаном стуле, вполне удобном в обычной ситуации. Это был один из стульев, расставленных на официальном месте встреч около лифтов на втором этаже штаб-квартиры Apple, в здании Infinite Loop 2, Купертино, штат Калифорния. Получив сообщение, я поднялся со стула, опустил iPhone в карман и прошел несколько шагов по тихому коридору, пока не оказался около конференц-зала под названием «Дипломатия». Когда дверь откроется, меня пригласят внутрь, чтобы я мог показать свою программу Стиву Джобсу.

Был конец лета 2009 года, и я делал прототипы программного обеспечения для новой продукции – пока еще не имеющего названия планшетного компьютера. Чуть больше двух лет назад компания Apple представила миру iPhone, который практически сразу стал лидером на рынке и за один день получил признание специалистов в сфере IT. Теперь такие люди, как я, программисты iOS, сможем поучаствовать в создании достойного преемника.

С 2005 года я также работал и над iPhone. После всех превратностей судьбы, которые я подробно опишу в главе 6 «Дерби с клавиатурой», мне поручили писать программное обеспечение для клавиатуры iPhone, особое внимание уделив функции автоисправления – коду, который меняет ваше «письмо без очепяток» на «письмо без опечаток».

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

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

Мою задачу еще больше осложняла вездесущая секретность Apple. В проекте Purple^[5] – кодовое название для разработки iPhone – каждая деталь имела конфиденциальную защиту с уровнями доступа. Очень немногим людям выпал шанс увидеть или попробовать программное обеспечение Purple до того, как Стив объявил о нем на широко освещенной в СМИ презентации в январе 2007 года, поэтому не могло быть и речи о том, чтобы моя работа по клавиатуре развивалась как настоящий научный проект, и о том, чтобы провести для нее широкие испытания. До того, как весь мир увидел ее, я получил отзывы о функции автоисправления всего от нескольких десятков человек. Ясное дело, что мы нервничали.

Пока я стоял в коридоре около «Дипломатии», у меня не было времени размышлять о том, сколько нервов я потратил во время разработки клавиатуры iPhone. Я больше думал о стрессе, который испытывал прямо сейчас, – мне предстояла демонстрация своих достижений перед Стивом. Этот новый планшет, который много месяцев спустя Apple представит как iPad, использовал ту же операционную систему, что и iPhone, но у него был экран побольше. Из-за этого с клавиатурой возник целый ряд новых проблем, и я был готов представить свое решение одной из них. Такие демонстрации лежали в основе процесса разработки программного обеспечения в Apple. Далее в этой книге я еще не раз буду говорить о подобных показах.

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

Похоже, клавиатура работала хорошо, и это сыграло мне на руку. Меня пригласили на встречу со Стивом только после того, как автокоррекция заработала и я как бы зарекомендовал себя. Мне не говорили об этом прямо, это показывает, как непросто пересечься со знаменитым CEO Apple.

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

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

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

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

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

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

Анри занимал в компании должность, где ежедневно взаимодействовал и с высшим руководством, например со Стивом, и с отдельными программистами, такими как я. Он руководил командой разработчиков, ответственных за стандартные приложения для iPhone: сообщения, почту, календарь и веб-браузер Safari, а также за пакеты программного обеспечения, которые Apple разрабатывала для программистов со всего мира, писавших приложения и размещавших их в AppStore^[7]. Стив поручил Анри сообщать решения, которые принимались во время этих презентаций, и тот выполнял эту работу со своей фирменной самоуверенностью, сочетавшейся с отсутствием самоуважения. Ламиро носил бороду, которую коротко стриг, и за двадцать лет в Apple черных волос в ней стало куда меньше, чем седины. Он был французом, говорил с сильным акцентом – иногда я мог понять, что он говорит, только из контекста – и произносил многие английские слова довольно замысловато. Больше всего мне нравилось слово build (компилировать). В устах Анри этот общеупотребительный программистский термин превращался в bweeld.

Анри снова стал моим начальником всего несколько недель назад. Я говорю «снова», потому что я уже был в его подчинении сколько-то лет назад, еще до проекта iPhone, когда мы оба исполняли другие роли. Однажды я увидел, насколько спокойным может оставаться Анри в стрессовой ситуации – я тогда здорово испытал его терпение, но эту историю я расскажу потом.

В последующие годы я видел, как он снова и снова проявляет хладнокровие. Перед демонстрацией программы Стиву я знал, что Анри сохранит самообладание и улыбку, несмотря на все напряжение. Ламиро выполнял роль посредника между командой программистов и придирчивыми руководителями компании. Он удалял ругательства из текстов с требованиями начальства и только потом передавал их кодерам. Он мог сказать мне: «Я слышал, Стив нашел небольшой баг», а на самом деле сообщение, которое он получил выглядело как-то так: «****** [проклятая] кнопка CAPS LOCK в сегодняшней сборке не работает! Разве не вы, люди, тестируете эту ****** [проклятую] клавиатуру?!» В то же время Анри с вниманием относился к деталям и умел их донести, мне нравилась его способность сохранять уверенность в том, что все в итоге заработает. Он, казалось, знал, что, если в такие моменты давить на меня сильнее, то это не поможет исправить ошибку быстрее, но я брошу все и займусь ею. По-своему Анри играл роль, возникшую из-за особенностей поведения нашего напоминающего ураган CEO. Он был источником хладнокровия, которое не давало нам сгорать из-за взрывного характера Стива.

– Заходи, – сказал Анри, улыбаясь и открывая дверь пошире, чтобы я мог зайти. Я сделал несколько шагов. Глубокий вдох. Демоверсия была готова или, по крайней мере, я так думал. Посмотрев направо на входе в конференц-зал, я увидел Стива. Он говорил по телефону.

– Да, звучит неплохо, – сказал Стив, откидываясь в офисном кресле и глядя в потолок через очки в круглой оправе. К уху его был прижат iPhone, рукава черной водолазки закатаны до середины предплечья, ноги сложены, штанины джинсов приподнялись до лодыжек, открывая несколько дюймов темных носков над серыми кроссовками New Balance. Его униформа. Джобс не выглядел слабым из-за болезни, и в тот момент все его внимание было сосредоточено на телефонном звонке. Секунду-другую я был в замешательстве, но быстро понял, что должен тихо стоять здесь и не делать ничего, чтобы привлечь к себе внимание. Нужно было еще подождать.

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

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

Еще раз оглядевшись, я почувствовал себя так же, как и всегда в «Дипломатии». Выглядела эта обветшалая комната, совсем не так, как помещение компании, где дизайн – это самое важное.

На дальнем от меня столе стоял только iMac. На стене над компьютером кто-то немного криво повесил постер без рамки с Mac OS X^[8] Jaguar, версия 10.2. Потрепанный вид плаката ничего и не говорил о долгом сроке службы – он был выпущен несколько лет назад, – но его, безусловно, выдавала напечатанная шрифтом с засечками, словно покрытая пятнистым мехом «Х». С того времени этот логотип «Х» несколько раз поменяли, он стал серо-стальным и готическим, без засечек. Так что постер выглядел довольно старым. Что же до столов, то они не представляли собой вообще ничего особенного. И это не та красивая мебель из светлого дерева, что стоит в розничных магазинах Apple, как можно было бы подумать. Нет, это были простые, серые, рабочие столы со столешницами из огнеупорной пластмассы. Стандартная офисная мебель. Стену слева от меня от пола до потолка закрывали белые доски с пятнами от маркеров, следы которых стирали небрежно и не полностью. Также там был диван. Не слишком чистый. Садясь на него, вы проваливались в подушки, как на видавшем виды диване в доме студенческого братства. В той половине комнаты, которая находилось за спинкой дивана, была пара пуфов-груш, сиротливо лежащих в углу – наследство от предыдущей эпохи в Кремниевой долине. В целом конференц-зал «Дипломатия» представлял собой запущенный рабочий кабинет. Он был важным помещением, которое часто использовалось для демонстраций CEO, но никак не центром притяжения.

Разглядывание комнаты позволило мне убить минуту или две, но не было никаких признаков того, что Стив скоро закончит телефонный разговор. Я начал чувствовать себя неуютно, потому что был единственным человеком, который стоял в комнате – после того, как Анри сел, на диване больше не осталось свободного места, а Стив занимал единственное кресло. Мне ничего не оставалось, кроме как стоять, пока Джобс не закончит разговаривать. В какой-то момент я посмотрел на Анри, и он в ответ слегка приподнял брови и пожал плечами, давая понять, что и понятия не имеет, как долго Стив будет разговаривать. Я не мог понять, почему Анри пригласил меня внутрь, если шеф был занят, но, опять же, момент совсем не располагал к лишним вопросам.

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

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

Положение самого Скотта было более надежным. Его отношения со Стивом оставались прочными, а их партнерство началось еще во времена NeXT, компьютерной компании, которую Джобс основал после того, как его уволили из Apple в 1985 году. С тех пор как Apple поглотил NeXT в 1996-м, Стив и Скотт тесно сотрудничали по вопросам разработки программного обеспечения.

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

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

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

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

По другую сторону от Скотта сидел Грег Кристи, один из руководителей высшего звена, постоянный глава команды пользовательского интерфейса (Human Interface) – разработчиков программного обеспечения, ответственных за то, как выглядят и используются iOS и Mac, а также за концепции, на основе которых работают эти системы. В разговорах мы сокращали название этой группы до двух букв, и как лидер команды HI Грег привнес многообразие и глубину в дизайн наших приложений и пользовательских интерфейсов. Грег был типичным жителем Нью-Йорка, дымил сигарами и носил фланелевые рубашки. У него были энциклопедические знания по истории информационных технологий, он был умельцем-самоучкой в работе с аналоговым и цифровым оборудованием, а еще он имел мощное чутье – он будто знал, как нужно делать ПО, которое понравится людям. Пару лет назад Грег дал мне очень хороший совет во время разработки клавиатуры iPhone. Когда я зашел в тупик, не надеясь из него выбраться, он уверенно бросил мне вызов: чтобы решить проблему, вокруг да около которой я ходил, нужно сделать каждую клавишу меньше, чем подушечка пальца, и разработать необходимые улучшения для моего кода автокоррекции. Грег часто давал понять: чтобы сделать наши продукты простыми и удобными в использовании, простые варианты в разработке не годятся. Но он никогда не был легким в общении. В его «капканы» попадали те, кто халтурил и «лепил отмазки» насчет работы. Попытаешься протащить мимо него неряшливо состряпанную демоверсию программы? Тут же попадешь в клыкастую пасть этого ревизора, и Грег сомкнет челюсти с громким щелчком. Он не был самым популярным человеком в компании. Тем не менее к тем, кто разделял его высокие стандарты и его отвращение к лени и оправданиям, он был всегда справедлив и поддерживал их.

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

Я посмотрел на сидящих на диване – явно не я один пытался делать вид, будто не слушаю разговор Стива. Вся ситуация начала казаться каким-то сюрреализмом, фантастикой. Я снова посмотрел на стол для демонстраций за спиной у Джобса. IРad, само собой, был на месте, но теперь я сам себя спрашивал, а заряжена ли у него батарея. И не превратится ли вся эта ситуация в кошмар? Работа по демоверсии клавиатуры началась примерно месяц назад – вскоре после того, как я получил повышение и стал главным инженером программного обеспечения iPhone.

Моя новая работа не имела ограничений по времени. Ожидалось, что я буду находить, создавать и продвигать проекты, которые могли бы сделать наше программное обеспечение лучше. Когда я попытался понять, что именно это значит, моим вторым домом стала студия команды HI. Однажды я зашел туда, чтобы навестить Баса. Как и всегда, он придумал нечто крутое.

Для создания презентаций Бас пользовался Adobe Director – пакетом программного обеспечения, который уже тогда, в 2009-м, считался пережитком канувшей в Лету эпохи. Создатели мультимедиа широко использовали Director в 1990-е годы для контента, годящегося как для CD-ROM дистрибуции, так и для инфоматов, стоящих в торговых центрах, подсказывающих, где находится обувной магазин или фуд-корт. Flash^[9], интернет и мобильные вычисления сделали Director старомодным, но Бас по-прежнему им пользовался, во многом из-за того, что был знатоком языка программирования Lingo, на котором работало это программное обеспечение. Оно давало Ордингу возможность создавать полностью интерактивные презентации, которые, на первый взгляд, выглядели совсем как экран макбука или iPhone, хотя представляли собой всего лишь картинки и анимацию, соединенные несколькими строчками кода на Lingo. Его демоверсии не были «настоящим» программным обеспечением, которое мы могли бы поставлять клиентам, однако Director позволял Басу быстро создавать прототипы, дающие правильное ощущение того, как что станет работать в реальности.

Я смотрел через плечо Баса, когда он запускал свое последнее творение в Director. На экране его Mac я увидел что-то вроде растянутой клавиатуры iPhone. Фон, кнопки клавиш, цвет букв – все было то же самое, но по форме раскладка казалась явно больше в ширину, чем в высоту. Бас сказал мне, что предлагает такой дизайн клавиатуры iPad. Он сделал эту демоверсию, чтобы проверить различные варианты. По краям клавиатуры Бас разместил ряд экранных кнопок настройки, и, когда он нажимал на кнопки или передвигал бегунки, фон, клавиши, буквы на демонстрационной клавиатуре менялись. Он делал кнопки больше или меньше. Он переключался между светлыми буквами на темных клавишах и темными буквами на светлых. Он менял размеры пробела, убирал кнопку, возвращал кнопку, и, когда они увеличивались или исчезали, остальные клавиши меняли форму, чтобы заполнить пустое место. Каждый вариант сопровождался тщательно разработанной анимацией, подчеркивающей изменения. Показывая мне все свои варианты, Бас кратко объяснял, чем обоснован каждый из них и почему он может быть удобным. Помимо великолепной анимации, которая аккуратно указывала на отличия разных версий, самое большое впечатление на меня произвели соотношение ширины и высоты клавиатуры и ее форма в целом. Его предложение по сенсорной клавиатуре iPad больше напоминало клавиатуру настольного компьютера или ноутбука, чем тот дизайн, который мы использовали для iPhone. Клавиши со знаками препинания и Shift находились на своих обычных местах. Наверху был ряд с цифрами и присутствовали давно привычные пары: «!» и «1», «@» над «2» и т. д.

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

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

Пока я сидел и смотрел то на экран прототипа iPad, то на клавиатуру Mac, у меня появилась идея. Я взял iPad, перевернул его горизонтально и поднял над клавиатурой. Я заметил, что длинная сторона экрана практически той же длины, что и верхний ряд букв. Это позволяло мне разместить десять букв из ряда QWERTYUIOP и подогнать их под длину экрана iPad. Места для цифр над верхним рядом букв не оставалось, но, скорее всего, получилось бы не так уж и плохо, ведь в результате выходил дизайн, как у клавиатуры iPhone, однако на экране iPad буквы могли быть почти такими же большими, как на макбуке. Это противоречило подходу Баса, который ужал полную раскладку клавиатуры до размера экрана iPad.

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

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

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

Вероятно, я также мог бы воспроизвести и ступенчатое расположение рядов. Если я смогу скопировать всю геометрию клавиатуры в целом, может быть, для пользователей Mac набирать текст на iPad будет удобнее и привычнее.

Для того чтобы сделать эту работу по дизайну как можно точнее, мне нужно было сделать кое-какие измерения. Была нужна линейка. Вроде ничего такого у меня не было, но я все равно начал рыться в ящиках стола и нашел пару старых микросхем ОЗУ, несколько канцелярских кнопок и коллекцию прототипов iPhone. Линейки не было. Я спросил нескольких коллег, чьи кабинеты находились в моем коридоре, но все они только с недоумением смотрели на меня и разводили руками: да что вообще может захотеть измерить программист? Я проверил запасы в кладовке с офисными принадлежностями. Там обнаружилось практически бесконечное разнообразие зажимов и скрепок для бумаги, но линейки не нашлось. Затем я вспомнил, что на бульваре Стивенс-Крик в Купертино, примерно в миле от офиса есть магазин «Таргет»^[10].

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

Вернувшись в офис компании Apple со своими двумя новыми игрушками – кхм, инструментами! – я начал измерять клавиатуру настольного компьютера и его клавиши, клавиатуру и клавиши ноутбука, экран и клавиши iPhone и экран iPad. Я хотел создать собственную базу данных по этим элементам клавиатуры, повозиться с ними, почувствовать эти объекты и установить свои отношения с каждым из них. Я записал размеры и углы всего. Я сделал несколько зарисовок в Adobe Illustrator, я накладывал изображение одного на изображение другого и раздумывал, что же делать. Я начал писать код, который был нужен, чтобы ввести обе новые клавиатуры в эксплуатацию. Для дизайна Баса с большим количеством клавиш я мог точно скопировать их со своего ноутбука, исключив ряд функциональных клавиш сверху. Для моего дизайна касательно доступных клавиш я мог взять за образец клавиатуру iPhone, но я переместил Delete и добавил еще один Shift. Я придумал еще несколько деталей и потратил пару дней, чтобы написать код программы. Принимая во внимание, что в iOS уже имелась кнопка с изображением глобуса для переключениямежду языками, я менял две свои клавиатуры так, как будто они были раскладками на разных языках. Моя демоверсия была готова. Я пошел показать ее Басу.

Он ответил добродушным смешком, который значил, что ему нравится. У Баса также было предложение. Ему не нравилось нажимать клавишу с глобусом, чтобы переключаться между этими новыми раскладками. В конце концов, мы же не меняли при этом языки. Он сказал, что мы должны добавить новую клавишу Zoom для переключения раскладок рядом с пробелом. Нажимаешь ее один раз, и появляются более крупные кнопки. Нажимаешь еще – и видишь больше кнопок. Бас сказал, что сделает анимацию для такого увеличения. Я подумал, что это звучит очень круто, и вернулся за стол, чтобы добавить эту клавишу.

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

С нашей демоверсией клавиатуры iPad все произошло необычно. Мы на одном дыхании проскочили предпоказ, во многом благодаря тому, что Бас рассказывал о программном обеспечении, используя разработанную им анимацию.

Если нажать на кнопку Zoom в нашей демоверсии iPad, то клавиатура, на которую вы смотрите (скажем, моя), тут же менялась на другую (Баса). Это было очень похоже на то, как в презентациях в Keynote или Power Point происходит переключение от слайда к слайду по щелчку мыши. Изображение одной клавиатуры исчезало и появлялось другое. Бас добавил в свою анимацию масштабирование: клавиши исчезающей клавиатуры меняли размер, чтобы совпадать с той, которая появлялась. А еще он настроил время анимации так, чтобы она начиналась медленно и ускорялась так, чтобы оставлять приятное ощущение после окончания анимации. Эти эффекты были едва уловимыми. Хотя анимация длилась долю секунды, Бас все равно сделал так, чтобы она считывалась. При виде всего этого начинало казаться, что в процессе клавиатура очень сильно меняется. Это было не так. С инженерной точки зрения, отсутствие сложных изменений имело большое значение – простота дизайна означала, что я могу написать код для этой анимации всего за пару часов. Волшебным выглядел весь эффект в целом. Анимация не смотрелась как переключение между двумя слайдами презентации. Нажатие на кнопку Zoom заставляло чувствовать, что перед вами только что была одна клавиатура, которая тут же превратилась в другую.

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

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

– Да, все это звучит отлично, – сказал Стив, и его голос нарушил почти полную тишину. – Хорошо, я вам перезвоню.

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

– До свидания, – попрощался Стив.

Он убрал iPhone от уха и на секунду сфокусировал взгляд на экране, нажимая на красную кнопку отбоя. После этого он засунул телефон в передний карман джинсов, выпрямился на кресле и медленно перевел взгляд на меня.

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

Скотт встал и перешел за спинку кресла Стива.

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

Стив все еще смотрел на меня. Продолжая показывать свою демоверсию с того места, на котором остановился Скотт, я заговорил:

– Да, есть два дизайна. В одном больше клавиш, как на клавиатуре ноутбука, а в другом клавиши больше по размеру, как на увеличенном iPhone. Мы думаем о том, чтобы предложить оба варианта. Нажмите на кнопку Zoom, чтобы попробовать обе версии.

Тут Стив медленно повернул стул к столу. Он опустил глаза. Перед ним лежал горизонтально развернутый iPad, кнопка «Домой» находилась справа от экрана. Была запущена одна из первых опытных версий приложения iPad Notes. В пустом документе мигал курсор. Внизу экрана была видна раскладка Баса с бо́льшим количеством клавиш. Она выглядела в точности как клавиатура ноутбука, только меньше обычной. Стив медленно скользил взглядом по экрану iPad, рассматривая все, что я сделал, причем не только прямо, но и будто стараясь ухватить все даже периферическим зрением.

Еще несколько затянувшихся мгновений – и он коснулся клавиши Zoom, запустив красиво оформленную анимацию, которую сделал Бас для переключения клавиатуры на мой дизайн с крупными кнопками. Никакой реакции, никакого намека на то, что он думает. Стив вел себя как опытный игрок в покер с крупными ставками, впервые рассматривающий карты в своей раздаче. Теперь экран выглядел по-другому. Джобс снова начал его разглядывать. Он потратил целых тридцать секунд, чтобы изучить каждую деталь того, что было на экране. Удовлетворившись увиденным, он снова нажал клавишу Zoom, возвращая раскладку с бо́льшим количеством клавиш. Теперь iPad выглядел в точности так же, как в начале показа. Стив снова изучил его, по-прежнему не выдавая никаких своих размышлений или чувств. Он еще раз коснулся клавиши Zoom, меняя раскладку, быстро осмотрел ее, чтобы удостовериться, что видел оба варианта дизайна – все, что ему предлагали. И перевел взгляд прямо на меня.

– Нам нужна только одна из них, верно?

Не совсем то, чего я ожидал. Кажется, у меня в горле пересохло. Стив все еще смотрел на меня и поэтому, слегка пожав плечами, я выдавил из себя:

– Дааа… хм… Я полагаю, так.

Стив еще немного посмотрел на меня и спросил:

– А какой вариант, по-вашему, мы должны выбрать?

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

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

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

Стив продолжал смотреть на меня, будто обдумывая мой ответ. Он так и не перевел взгляд на кого-либо или что-либо в комнате. Джобс полностью погрузился в происходящее. Он весь был здесь, серьезно обдумывая применение моей идеи для следующей крупной разработки Apple. Это даже пугало. Несколько секунд он думал о том, что я только что сказал, и о том, что он видел на экране iPad. Затем Стив вынес свой вердикт:

– Хорошо, пусть будет с крупными клавишами.

Это было то самое. Оракул Apple заговорил, его пророчество о программном обеспечении было изречено, и Джобс сопроводил это едва заметным кивком. Показ был закончен. Грег, Анри и Бас встали с кушетки и произнесли несколько ободряющих слов вроде «Хорошая работа» или «Прекрасная презентация».

Сегодня я уже получил столько зрительного контакта, сколько мне, интроверту, хватит на несколько дней вперед, так что я опустил взгляд и просто смотрел в пол.

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

– Спасибо.

Над входом в храм Дельфийского оракула висела табличка с надписью «Познай самого себя» – напоминание пришедшим, о том, что ответы в действительности могут быть внутри самого человека. Покидая «Дипломатию», я чувствовал удовлетворение от того, что в одну секунду сам нашел, что сказать Стиву по поводу своей программы.

Это было мое первое впечатление после презентации, и с тех пор я много раз возвращался мыслями к этой встрече.

Стив проверял меня, когда спросил мое мнение. Посмотрев демоверсию, он захотел узнать прямо там, могу ли я сделать программное обеспечение лучше. Если бы я не дал правильного ответа, он обратился бы к другим находившимся в комнате людям. Они заработали свои места, постоянно проходя через подобные проверки, как и каждая деталь программного обеспечения iPhone, и делали свою работу еще лучше. Если я хотел продолжать показывать свои работы в «Дипломатии» – а я хотел, и за время моей работы в Apple действительно демонстрировал Стиву программы еще несколько раз, – то, чтобы меня приглашали снова, мне следовало вносить существенный вклад в обсуждения.

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

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

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

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

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

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

Решить предстояло не только, достойна ли работа одобрения. Когда Скотт выбрал меня (а не только мою программу), чтобы я показал Стиву, это было его способом сказать, что мое слово значит столько же, сколько и моя работа. Он расширял сформировавшийся круг очень осторожно. Из того, что я знал, Стив судил о Форсталле еще и по тому, кого он набирает. Такое иерархическое ограничение доступа к CEO не слишком отличалось от того, что происходило в других крупных компаниях, но способ, которым можно получить допуск на совещания высокого уровня в Apple, зависел не столько от должности, сколько от ваших способностей. На первых этапах, когда я передавал мои прототипы клавиатуры iPhone Анри, чтобы он показал их Стиву на презентации без меня, мне было трудно принять, что моя программа имеет значение для компании, а мое присутствие на ее обсуждении – нет.

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

Благодаря сотрудничеству с Басом моя демоверсия была лучше стандартных. У нас был солидный проект, основанный на трех компонентах: две раскладки клавиатуры плюс способ переключаться между ними – кнопка и анимация. На показе у Стива, несмотря на наши усилия, мы столкнулись с его корректировками. Ему явно что-то понравилось, но он посчитал демоверсию слишком сложной, поэтому разгрузил программу. Эта деконструкция не была обычным делом, но целиком вписывалась в характер Джобса.

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

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

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

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

Стив использовал показы демоверсий, чтобы понять, отвечают ли предложенные функции такому стандарту практичности и доступности. Когда он сказал мне убрать одну из раскладок в моей демоверсии клавиатуры, это потянуло за собой много других изменений, которые сделали всё еще проще. Это означало, что мы также уберем анимацию Баса. Мы могли убрать и кнопку Zoom. Мы избавлялись и от возможной путаницы по поводу того, какую клавиатуру показывать в разных ситуациях. Например, должно ли программное обеспечение помнить, что вы используете клавиатуру с крупными клавишами в приложении «Заметки», а клавиатуру с бо́льшим количеством кнопок – в электронной почте? И должен ли выбор клавиатуры сохраняться в определенных ситуациях и только в них, но ни в каких других? Эти вопросы выносились на обсуждение, и это хорошо, потому что на них могло не быть простых ответов. Стив считал, что лучший способ отвечать на подобные трудные вопросы – это не попадать в ситуации, которые требуют их задавать.

Фирменная твердость Стива пропитывала Apple. Он окружал себя такими людьми, как Скотт, Грег, Анри и Бас отчасти потому, что они могли принимать правильные решения без долгих раздумий. Когда Стив задал мне вопрос, это было проверкой моей решительности и того, могу ли я сделать свою демоверсию лучше, чем она уже была. Никто в комнате не присоединился к разговору, потому что Джобс явно смотрел на меня, и лучшим способом ответить было высказать свое мнение. Я сделал это, и он закрыл вопрос с моей разработкой.

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

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

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

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

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

2. Магический кристалл

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

Эта презентация «магического кристалла» имела место в технологической среде начала 2000-х годов, в то время, когда все еще продолжался резкий подъем активности стартапов, основная часть деятельности которых была связана с интернетом. Microsoft была всеми признанным лидером компьютерной индустрии, браузер Netscape считался самой крутой новой технологией, а Apple оставалась аутсайдером.

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

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

В 1983 году Столлман начал проект GNU в защиту бесплатного программного обеспечения¹ и написал Универсальную общественную лицензию (General Public License, GPL), чтобы продвигать свой проект. Столлман называет GPL «копилефтом» – словом, противоположным понятию «копирайт»^[11], и, вместо того чтобы ограничивать права пользователей программного обеспечения, GPL расширяет их, гарантируя, что каждый может получить бесплатный доступ к исходному коду, а также изучить его, изменить, использовать как есть или сделать основой своего проекта. Это на самом деле выглядит как свобода, но у GPL есть свои хитрости. Если вы пишете софт, основанный на коде, покрываемом GPL, вы также должны публиковать свое программное обеспечение под GPL. Ожидалось, что это создаст замкнутый круг, постоянно поддерживаемый усилиями каждого кодера на благо всех, богатых и бедных, новичков и компьютерных фанатов, программистов и пользователей.

Если вы не работаете в индустрии программного обеспечения, то Ричард Столлман для вас, скорее всего, просто какой-то влиятельный человек, о котором вы никогда не слышали. За несколько десятков лет свободное ПО распространилось во всей сфере высоких технологий. GPL привела к разработке операционной системы Linux, которая является главным программным обеспечением для смартфонов с системой Android, в центрах обработки и передачи данных Google, Amazon, Twitter и Facebook и на большинстве крупных сетевых серверов разного рода. Интернета таким, каким мы его знаем, не было бы без длительного влияния идей Столлмана и всего того бесплатного софта, появившегося благодаря этим идеям. Скорее всего, не существовало бы поисковых серверов, потоковой передачи музыки и YouTube. Мы обходились бы без Википедии. Без чатов. Без социальных сетей. Без смартфонов. Мир был бы совсем другим.

Моя жизнь тоже могла бы быть другой. До того как прийти в Apple, я работал в стартапе под названием Eazel. Нашей целью было создание удобных в работе систем Linux, пригодных для ежедневного использования на компьютере, – свободного программного обеспечения, которое стало бы альтернативой для Apple Macintosh и Microsoft Windows. Компанией руководили программисты, работавшие с первыми Macintosh в 1980-х годах. Среди них были Бад Триббл, первый менеджер по программному обеспечению Mac, и Энди Херцфельд, маг и волшебник в области программирования, чей графический пользовательский интерфейс помог компьютерам Mac выделиться из ряда обычных для того времени персональных компьютеров с текстовым режимом. Эти ребята были моими героями, и я пришел в компанию, чтобы работать с ними. Именно благодаря элегантности и простоте программного обеспечения Macintosh я и захотел стать программистом².

Вдохновителем Eazel был Энди, на его видение работы компании во многом повлияло движение за свободное ПО – Энди разделял идеализм Столлмана – и его идея разработки менеджеров файлов и иконок сделали бы Linux достойным соперником более известных операционных систем Windows и Macintosh. Энди назвал эту программу Nautilus, и она должна была помогать пользователям Eazel находить файлы, читать электронную почту, запускать такие программы, как текстовые редакторы и электронные таблицы, и, возможно, даже делать крутые вещи, например вести учет цифровых фотографий. С помощью Nautilus Eazel внесла свою лепту в проект GNOME – не слишком тесное сообщество разработчиков свободного программного обеспечения, участники которого, как отдельные программисты, так и компании, должны были создать остальное ПО для операционной системы, которую мы пытались сделать все вместе.

Чтобы стать частью GNOME, Nautilus должен был иметь лицензию GPL. Это было важным фактором для Eazel как коммерческой компании. Если люди смогут скачивать Nautilus бесплатно, когда мы его закончим, то фирме надо найти другие пути зарабатывания денег. Неудивительно, что они были связаны с созданием закрытого программного обеспечения, которое Eazel могла бы продавать: ряд тогда еще только зарождающихся облачных сервисов, включающих в себя автоматическое обновление ПО и хранение файлов онлайн. Эти облачные центры должны были размещаться в центре обработки и передачи данных Eazel, и бесплатными они не были. Идея состояла в том, чтобы интегрировать Nautilus с этими сервисами и использовать бесплатный софт как приманку, чтобы люди пользовались платными услугами Eazel. Рвение к продажам через интернет, энтузиазм по поводу Linux и свободного ПО, изобилие средств, вложенных в новое предприятие, и связь наших основателей с Macintosh – это сочетание заставило меня думать, что Eazel может стать новой крутой компанией.

Если у нас и в самом деле был шанс, то мы упустили его. Мы так и не достигли ни одной из высоких целей. Главным неверным шагом среди множества шагов, которые мы сделали, было то, что мы не смогли сделать наше программное обеспечение единым продуктом, а не несколькими отдельным проектами. Мы так и не сумели соединить его части в целое. Ничего не работало гладко. В нашей, из-за чего программы часто переставали работать при попытке их обновить. Код, который мы написали, чтобы связать Nautilus с облачными сервисами, не работал вообще. У команды Nautilus постоянно были проблемы из-за координации с GNOME. В сообществе свободного ПО была крайне слабая организация, а желания получить прибыль не было. Его члены не разделяли наше стремление заработать деньги и не старались согласовывать свои действия с нашим расписанием выхода продуктов. Из-за всего этого у нас постоянно что-то задерживалось и опаздывало.

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

У Дона была неформальная манера общения и аналогичный подход к выбору одежды, появившиеся после его участия в Code Rush – документальном фильме, выпущенном компанией PBS³. В нем рассказывалось о «войнах браузеров» – борьбе между компаниями Netscape и Microsoft за контроль над зарождающимся интернет-серфингом.

Когда в 1990-е годы все больше и больше людей открывали для себя Всемирную паутину, в Microsoft начали опасаться, что многие пользователи сменят свои технические предпочтения, и влияние, как и деньги, перейдут к Netscape – компании, которая создала самый популярный веб-браузер.

Microsoft сделала свой ход, выпустив собственный браузер Internet Explorer в составе операционной системы Windows, стоявшей тогда на 90 % персональных компьютеров. В Microsoft ожидали, что этот шаг отрежет для Netscape любую возможность заработать на привлекательности и доступности своего браузера, поскольку очень немногие люди будут искать что-то еще, если на их компьютерах сразу будет стоять Internet Explorer.

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

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

Как показала история, это не сработало. И хотя Netscape не выжила как самостоятельная компания, она выпустила открытую версию кода своего браузера, получившего впоследствии новое название – Mozilla. Браузер получил путевку в жизнь во многом благодаря усилиям Дона, моего нового коллеги по Eazel. Мелтон был ответственен за то, чтобы вычистить все ругательства из исходного кода до того, как он увидел свет.

Непечатная лексика была препятствием, от которого Netscape нужно было избавиться в рамках инициативы с открытым исходником, которая должна была позволить заглянуть во внутреннюю рабочую обстановку разработчиков программного обеспечения. Даже сейчас, когда я пишу эти строки, программисты – это в основном молодые люди, всего несколько лет проучившиеся в колледже, умники заливающие в себя кофеиновые напитки, чтобы выдержать долгие часы за клавиатурой и уложиться в зачастую очень жесткое расписание. Правда, в начале 2000-х годов эта тенденция проявлялась еще сильнее. Когда человек устает, а времени ему не хватает, проявляется его настоящий характер, юношеский пыл перекрывает всё, и споры – технические или другого рода – становятся видны в коде ПО. Используя горбатый регистр^[12], программисты часто соединяют несколько слов в одно, и показательным примером ненормативной лексики в коде исходника может служить следующая фраза:

cleanUpBobsSh_tStormHeIsAF_kingTurdBlossom;^[13]

Боясь, что такие грубые ругательства могут поставить под вопрос популярность их программного обеспечения, когда будет опубликован исходный код, руководство Netscape постановило: все ругательства из программ убрать. Чистка кода была грандиозной задачей. Заниматься ею поручили Дону, и, как он говорил, он был для этого чертовски подходящим парнем. Он и сам был тем еще матерщинником. Мелтон нашел и вычистил всю нецензурную лексику, но открытый исходник не сильно помог Netscape в войне браузеров. Компания проиграла.

Поскольку стало понятно, что поражение неизбежно, Дон решил поискать другую работу. К тому времени, когда он пришел в Eazel, отставание от графика разработки не было нашей единственной проблемой. С деньгами тоже было плохо. Eazel нечего было продавать, а финансирование иссякало. Наши руководители были заняты попытками найти новые источники средств, и какое-то время состав сотрудников обновлялся каждые несколько недель. Потом стало тихо. Даже слишком тихо.

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

Мы с Доном остались без работы, но стали друзьями и, когда не слонялись по Кремниевой долине с ее полями для гольфа, то искали себе новую работу. Вскоре мы услышали, что Apple набирает сотрудников. Компьютерная компания в Купертино провела ярмарку вакансий для бывших работников Eazel. Я взял пару визиток у менеджеров Apple и собирался написать им. Но у Дона, который всегда лучше меня давил на нужные рычаги, была другая идея. Следующее, о чем я узнал, – у меня будет собеседование со Скоттом Форсталлом, который в то время был директором Platform Experience в Apple. В те дни, когда не было iPod и iPhone, этот отдел отвечал за пользовательский интерфейс Macintosh, за такие приложения, как Finder и Почта, а также за пакеты программ, которые использовали сторонние разработчики, чтобы создавать собственные программы для Mac.

Приехав на собеседование в кампус Apple, я увидел Скотта, сидящего за столом в дальнем углу офиса. Когда я вошел, он повернулся и наклонился вперед на стуле, как профессиональный борец в ожидании начала следующего раунда. Во время знакомства я сидел, буквально прижавшись коленями к его коленям. Заблаговременно побеспокоившись о том, чтобы показать на собеседовании свои навыки, я принес домашнюю заготовку – свой последний проект ПО, написанный, когда я уже потерял работу. Это была головоломка-пазл, которая запускалась на Mac OS X, новой операционной системе Apple.

Скотт попробовал мое приложение, и, кажется, оно ему понравилось. Он засыпал меня вопросами по поводу этой программы, причем вопросы летели со скоростью молодого Мухаммеда Али^[14], проводящего серию ударов левой.

– Как вы разработали алгоритм создания новых частей пазла?

– Как вы сделали, чтобы ваша анимация шла так гладко?

– Использовали ли вы среду разработки Cocoa или Carbon или обе в какой-то комбинации?

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

Пару дней спустя мы с Доном поехали в магазин компьютерной литературы в Саннивейле – он сказал, что хочет взять там одну книгу. Я пытался заставить его рассказать, как прошло собеседование в Apple, и узнать, не говорили ли ему что-нибудь о моем разговоре со Скоттом, но Дон хранил молчание. Когда мы вышли из магазина и сели в машину, Дон вручил мне экземпляр третьего издания подробного руководства по JavaScript с красиво нарисованным носорогом на обложке⁶.

– Что ты думаешь по поводу того, чтобы сделать браузер для Apple? – спросил он. – Интересно ли тебе?

Еще бы меня это не интересовало!

Но подождите минутку, разве в Mac OS X нет веб-браузера? Да есть же! Это Microsoft Internet Explorer. По соглашению между Apple и Microsoft, Internet Explorer был включен в базовую поставку системы четыре года назад. Стив Джобс объявил об этом соглашении в августе 1997 года, в тот самый день, когда он пригласил Билла Гейтса присутствовать по видеотрансляции на своем выступлении на выставке-конференции Macworld Expo в Бостоне⁷. Именно в тот день Гейтс обязался поддержать Apple, обеспечив на пять лет поставки Office for Mac, вложив в Apple 150 миллионов долларов и согласившись предоставить Internet Explorer как веб-браузер по умолчанию для Apple Macintosh. Если не принимать во внимание злосчастное шестиметровое изображение Билла Гейтса, возвышающегося над конференц-залом Mac как Большой Брат, сделка была чрезвычайно удачной для Apple. Это был знак поддержки и одобрения, хотя многие предсказывали, что компанию ждет неминуемый крах. Несколькими месяцами ранее журнал Wired опубликовал на обложке знаменитое изображение разноцветного логотипа Apple, опутанного колючей проволокой. Ниже было только одно слово: «Молитесь»⁸.

К лету 2001 года Apple встала на ноги, ее поддерживали на плаву конкурентоспособность Mac OS X, успех iMac и (тайные) надежды на iPod, который был выпущен четыре месяца спустя.

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

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

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

Когда мы в семь часов утра встречались в кафе в кампусе, чтобы выпить кофе, мы «пробегались» по основным подсистемам веб-браузера: контент (текст и графика), стили (шрифты, цвета и положение) и скрипты (динамическое поведение, например проверка формы до того, как вы запустите ее). Дон рассказывал о длинном списке аббревиатур существующих стандартов, описывающих соответствующие технические элементы: гипертекстовый высокоуровневый язык разметки (Hypertext Markup Language, HTML), каскадные таблицы стилей (Cascading Style Sheets, CSS) и язык программирования JavaScript. Также он рассказывал, как эти отдельные части программного обеспечения сочетаются друг с другом, чтобы получались сложные веб-страницы.

Пока я слушал и учился, мне начинало казаться, что создание браузера – это задание, которое не по зубам двум людям, особенно после того, как Дон упомянул большие команды, которые работали в Netscape. Без сомнения, то же самое было и в Microsoft. А мы были командой из двух человек. Как мы могли с ними тягаться?

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

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

В самом деле, когда я скачал Mozilla из интернета, моим первым впечатлением от исходного кода были его размеры – около полутора миллионов строк. Я никогда раньше не участвовал в проекте, который составлял хотя бы четверть от этого количества. Если код Mozilla распечатать по тридцать строк на страницу, он составил бы пятьдесят тысяч страниц. Только представьте, что вам предстоит прочитать такую пачку книг, а затем сдать экзамен, где могут спросить про любую произвольно выбранную строку.

В любом случае работу нужно было делать, и я решил, что лучше начну с изучения. Я собрался взглянуть на программное обеспечение поближе, но немедленно налетел на препятствие. Mozilla не «билдилась» на Mac OS X. Это означает, что, хотя у меня был весь программный исходный код для этого браузера, при попытках превратить его в приложение, которое работало бы на операционной системе Apple трехмесячной давности, ничего не получалось. Очевидно, никто, знакомый с Mozilla, никогда не пытался этого сделать. Ничтожная доля Mac на рынке работала против нас. В поисках решения я прошерстил интернет, но ничего полезного не нашел. Поскольку наш проект был секретным, я не мог разместить свои вопросы на онлайн-форумах, как это часто делают программисты, и даже не мог спросить кого-нибудь из коллег в Apple. После нескольких дней безуспешных попыток сделать сборку я признал, что зашел в тупик.

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

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

Мы с Доном устроили совещание. Он сказал, что собирается уехать на неделю в отпуск, который планировал еще до того, как мы начали работать в Apple. Он хотел, чтобы я за эту неделю полностью погрузился в попытки скомпилировать Mozilla под Mac OS X.

И я погрузился. Я педантично делал заметки. Я проводил долгие часы один на один с кодом. Когда Дон вернулся в офис, я передал ему документ, озаглавленный «Компилирование Lizard. Пятьдесят шагов, чтобы запустить Mozilla на Mac OS X».

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

Хорошая новость состояла в том, что все эти шаги работали… Ну, в какой-то мере. Следуя указаниям, мне удалось воспроизвести ярлык программы веб-браузера на своем рабочем столе. Плохая новость состояла в том, что это приложение-Франкенштейн не оживало. Когда я кликал мышью по иконке, Mozilla запускался, но не загружал веб-страницы. Что бы я ни пытался сделать, браузер неизбежно «падал». Пытаясь понять, что не так, я безнадежно запутался в миллионе с лишним строчек исходного кода.

Занимаясь всеми этими исследованиями браузеров, мы одновременно пытались нанять в команду других людей. Мы получили одобрение на то, чтобы взять еще пару программистов, и еще до официального объявления Apple о вакансии начали поиски. Дон знал нескольких человек из Netscape, имеющих опыт в создании браузеров, мы знали нескольких отличных программистов из Eazel, которые все еще не приняли решения по поводу новой работы, и еще мы получили пару заявок от кандидатов внутри компании. Мы столкнулись и с новой трудностью: как убедить людей, у которых есть другие хорошие варианты, согласиться на работу в проекте, о котором мы не можем им рассказать. Дон делал это подмигивая и одновременно заверяя кандидата в том, что его зовут в «большое дело». Все нам отказывали. Те, у кого был опыт работы в Netscape, понимали намек Дона, и никто не хотел никоим образом участвовать в создании еще одного браузера. После недавних мучений с Mozilla я понимал, почему они ведут себя именно так.

В разгар моей борьбы с Mozilla я познакомился с новым кандидатом. Ричард Уильямсон начал с того, что заявил, будто знает, как быстро добиться результата. С британским акцентом, смягченным двумя десятками лет проживания в Соединенных Штатах, он рассказал о себе. В подростковом возрасте он основал собственную компанию по разработке ПО, пару лет занимался смартфонами, затем сделал паузу в учебе, проработав год в NeXT, компании, которой руководил Стив Джобс после увольнения из Apple. Вернувшись после окончания учебы в NeXT, Уильямсон иногда получал приказы от самого Джобса – например, Стив посылал его в Японию на переговоры с клиентом о создании дополнительной сетевой карты для компьютеров NeXT. Переговоры Ричард провел успешно.

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

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

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

После собеседования я пошел к Дону и сказал, что не уверен насчет смелых заявлений Ричарда. Дон ответил, что Бертран Серле, начальник Скотта Форсталла, работал с Ричардом в 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, и мы решили, что это может быть ответом на вопрос, который мы искали. Это магия Кремниевой долины в ее лучшем проявлении.

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

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

3. Черный прямоугольник

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

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

Пока все устанавливалось, я смотрел на стоящие передо мной два компьютера: персональный компьютер с Linux и Macintosh. На моем столе их разделяло всего несколько сантиметров, но в плане ПО они были гораздо дальше друг от друга. Хотя можно проследить общее происхождение Linux и Mac OS X, восходящее к UNIX, операционной системе, созданной как исследовательский проект в лаборатории Bell в 1969 году, обе системы сильно отдалились от своей предшественницы. Со временем Linux и Mac стали напоминать две местности, в которых говорили на одном языке, но с разными диалектами. Linux говорил «трейлер», а Mac – «фура». Если говорить о таких приложениях, как веб-браузеры, то между ними едва ли существовала совместимость, но, если копнуть глубже, на уровне алгоритмов, с которыми работают программисты, сходство двух систем проявлялось сильнее. В них была общая техническая грамматика, обе системы позволяли компилировать и запускать программы, написанные на C++, языке программирования, который разработчики Konqueror использовали для написания исходного кода. Но даже при этом Linux и Mac использовали разные словари и идиомы программирования для написания программ на C++, особенно когда речь шла о графических пользовательских интерфейсах. В конечном счете мы не могли просто скопировать код с одного компьютера на другой. Если мы хотели использовать Konqueror как основу для нашего проекта веб-браузера, мы должны были залатать все подобные терминологические и технические отличия в исходном коде Konqueror под Linux и заменить оболочку Ричарда прочным фундаментом программного обеспечения. Адаптация кода, написанного для одной операционной системы, так, чтобы он работал на другой, настолько распространена, что у программистов даже есть специальное слово для описания этой задачи – портирование. Поскольку на выходе нам нужно было получить браузер стандарта Apple, исходный код которого должен был работать так, будто он изначально был написан для Mac (хотя это было не так), нам в самом деле предстояла большая работа по портированию.

Для того чтобы выделить код браузера из системы KDE, мне не потребовалось много времени. Программное обеспечение было организовано очень аккуратно, и Konqueror обитал, в основном, в двух директориях: KHTML и KJS.

После того, как я отделил код, я дал компьютеру задание подсчитать общее количество строк в этих двух директориях. Это должно было дать нам примерное представление о том, какой объем портирования нас ждет. Поскольку портирование могло потребоваться для каждой строчки кода, то, чем меньше их будет, тем лучше. Увидев результат, я улыбнулся, а когда я сообщил о нем Дону и Ричарду, они тоже расплылись в улыбке. В Konqueror было чуть больше 120 000 строк, и он составлял менее одной десятой размера Mozilla¹². Сначала мы просто не могли поверить, что между двумя массивами исходного кода со схожими функциями может быть такая разница.

Дон объяснил, почему так произошло. Руководители проекта Mozilla разрабатывали систему, которая, как они надеялись, превратит их программное обеспечение в компоненты, соединяющиеся друг с другом, как кубики LEGO. Тем не менее такая схема требовала большого количества дополнительного стереотипного кода: программисты должны были сделать что-то вроде заполнения кучи форм, чтобы регистрировать новый код при повторном запуске системы, и эта волокита поглотила браузер. Теперь мы видели результат применения этого инженерного решения – размер кода Mozilla соотносился с кодом Konqueror как 10 к 1. Очевидно, работа с этими составляющими вышла из-под контроля. Mozilla оказался раздутым, громоздким и ненадежным.

Команда Konqueror использовала противоположный подход. Их код был аккуратным и без излишеств. Они превыше всего ставили лаконичность. Их стиль в программировании больше всего напоминал Хемингуэя, а вот Mozilla – Фолкнера.

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

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

Через несколько дней выяснилось, что наши руководители приятно удивлены, как мы и надеялись.

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

После получения их одобрения нужно было разработать стратегию портирования 120 000 строк кода Konqueror на Macintosh. Чтобы понять, какую сложную программистскую задачу нам предстояло попытаться решить, потребуется некоторое знание жаргона разработчиков.

Когда я хочу, чтобы компьютер выполнил какую-то работу, я пишу точные инструкции, используя один из языков программирования, например, C++ – тот язык, который разработчики KDE использовали для создания Konqueror.

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

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

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

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

Эта система не идеальна, поскольку в схеме перекрестных ссылок могут быть ошибки. Например, если я нахожусь в середине приготовления яиц «Бенедикт» и пытаюсь найти ссылку на голландский соус на странице 123, я могу открыть кулинарную книгу на 132 странице, и нужного мне рецепта там не будет.

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

Когда я делаю похожую ошибку в программе, компилятор выдает мне сообщение об ошибке. Обычно такие сообщения бывают краткими и точными: «expected expression, line 3, column 5» («ожидается выражение в строке 3, колонке 5»). Это может оказаться и ошибкой при наборе, и простой логической ошибкой. Такое сообщение напоминает шеф-повара на суматошной кухне, который бросает один взгляд через плечо помощника, готовящего тарелку яиц «Бенедикт», и выносит приговор: «Голландский соус слишком густой!» Оба этих сообщения констатируют ошибку, и, хотя в них нет четких инструкций решения проблемы, они чрезвычайно полезны.

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

Получив «добро» от начальства, мы с Ричардом и Доном собрались, чтобы разработать нашу стратегию портирования.

Прежде всего мы должны были вернуться к демоверсии Ричарда и разобраться со всеми трудными местами, которые он в ней обошел. Чтобы сделать это, нам предстояло скопировать исходный код Konqueror на Macintosh и скомпилировать его. Затем нужно было все проверить и выловить ошибки, чтобы в результате код браузера выглядел как написанный для системы Mac.

Также, поскольку Konqueror относился к свободному ПО, нам приходилось подчиняться лицензии Столлмана, которую авторы прикрепили к своемусофту. Наше руководство хотело опубликовать исходный код части программного обеспечения, но по большей части он должен был быть закрытым и проприетарным^[15]. Причина проста: Mac OS X была продуктом, который приносил Apple прибыль. В эру iPhone компания начала публиковать бесплатные обновления программного обеспечения, но во времена, о которых идет речь, операционная система Macintosh в Соединенных Штатах стоила 129 долларов для одного компьютера¹³. Когда мы продумывали нашу стратегию разработки веб-браузера, руководство предпочитало не «свободное, как свобода слова» и не «бесплатное, как бесплатное пиво» ПО, а «хорошо спрятанное, как деньги».

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

Дон обожал занудствовать по поводу деталей лицензий свободного ПО. За время работы в Netscape и Eazel он подробно изучил эту тему и любил чесать языком, обсуждая достоинства, недостатки и положения различных лицензий. Он явно получал удовольствие, объясняя хитросплетения стандартной общественной лицензии ограниченного применения исходного кода Konqueror. Эти положения гласили, что если мы включаем Konqueror в «кулинарную книгу» Macintosh как отдельную главу, используя его код только с помощью перекрестных ссылок, и открыто публикуем любые изменения, которые делаем, чтобы рецепт Konqueror «получался вкусным» на Macintosh, мы работаем в соответствии с лицензией свободного программного обеспечения Столлмана.

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

Я был где-то посередине.

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

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

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

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

Чтобы эта схема с изъятием страниц работала, мы должны были, перенося Konqueror на Mac, тщательно изучить каждую разрушенную перекрестную ссылку в каждом рецепте. Если подходящий эквивалент уже существует в программном обеспечении Apple – например, общие вычислительные ресурсы, такие как цвета или шрифты, – мы можем переназначить для них перекрестные ссылки. Если эквивалента нет – скажем, для системы, создающей закладки веб-страниц, – нам нужно написать новые рецепты с чистого листа. Мы предполагали, что переделки коснутся как Konqueror, так и Mac, чтобы блюдо вышло таким, как надо.

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

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

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

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

АКТ I. СЦЕНА XXXVI.

Кампус компании Apple Infinite Loop, Купертино. Кабинет Кена.

Кен сидит за столом. Его руки лежат на клавиатуре. Он печатает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 200: use of undeclared identifier "protocol"

(ошибка в строке 200: использование необъявленного идентификатора «протокол»)

Кен ищет соответствующий идентификатор для «протокол». Печатает его.

КЕН: Вот тебе, компилятор! Я определил «протокол». Пожалуйста, попробуй еще раз!

Кен снова вбивает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 201: use of undeclared identifier "host"

(ошибка в строке 201: использование необъявленного идентификатора «хост»)

Кен ищет соответствующий идентификатор для «хост». Печатает его.

КЕН: Надо же, я забыл определить идентификатор «хост»! Ну вот он! Попробуем еще раз.

Кен опять вбивает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 201: use of undeclared identifier "port"

(ошибка в строке 201: использование необъявленного идентификатора «порт»)

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

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

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

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

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

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

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

Я набрал URL-адрес: http://www.yahoo.com. Как обычно, отчет FIXME заполнялся строка за строкой, но браузер не падал. Прошло несколько секунд, а потом браузер кое-что сделал. Он показал мне картинку.

Я закрыл приложение и попробовал снова. Я опять загрузил домашнюю страницу Yahoo. Отчет FIXME заполнился, браузер не упал, снова та же короткая пауза… и тот же черный прямоугольник!

Я выбежал в коридор, чтобы позвать Дона. Когда мы вернулись, я закрыл приложение, снова открыл и загрузил главную страницу Yahoo. Во время паузы мы затаили дыхание… и опять увидели все тот же черный прямоугольник! Браузер наконец что-то сделал!

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

Мы тыкали пальцами в экран и вопили. Я попытался снова загрузить страницу. Браузер опять сработал… еще один черный прямоугольник! Это действительно случилось!

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

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

Во всей моей карьере в Apple было всего два момента, когда я был готов кричать «Эврика!», и это был один из них. Я жалел, что с нами нет Ричарда, чтобы разделить радость этого мгновения. Его демоверсия показала потенциал Konqueror, а встреча с черным прямоугольником была следующим большим шагом. Она показывала, что стратегия портирования действительно работает, и стала на пути превращения демоверсии в продукт.

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

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

Эдисону тоже приходилось сражаться с техникой, например, искать материал для нити накаливания, который мог бы гореть ярко и долго. Мне очень нравится, как причудливо описываются эти поиски в книге 1910 года под названием «История великих открытий».

Однажды вечером [Эдисон] размышлял над проблемой и, сам того не осознавая, крутил в руках кусочек ламповой сажи [красителя, изготавливающегося из копоти], смешанной со смолой, которую он использовал при создании телефона. Не думая о том, что он делает, Эдисон скатал эту смесь сажи и смолы в нить. Тут он посмотрел на то, что у него получилось, и в голову ученому пришла мысль: «А почему бы не пропустить электрический ток через этот углеродный материал?» Он попробовал, и в результате получилась яркая вспышка…

Затем Эдисон решил найти лучший вариант углеродного материала для своих целей. Он покрывал углем бумагу и различные породы дерева – да и любые материалы, все, из чего можно было сделать углеродную нить. Он пробовал даже использовать японский веер из бамбука, и обнаружил, что это волокно светится лучше, чем что-либо еще. Потом он начал искать лучший вид бамбука. Ученый узнал, что существует 2000 разновидностей этого растения. Он должен был заполучить все образцы. Эдисон отправлял людей по всему миру в разные места, где рос бамбук. Одному из них пришлось преодолеть 48 тысяч миль и повстречаться по дороге с дикими животными. Наконец, в Японии нашелся бамбук, который был лучше других сортов. Поиск материала для углеродной нити обошелся примерно в 100 000 долларов¹⁴.

В этой короткой истории есть все. Озарение! Отважные люди! Огромные расстояния! Столкновения с дикими животными! Громадные суммы денег! Даже автор истории великих открытий носил имя, подходящее для рассказчика, – Элмер Элсуорт Бернс.

Конечно, настоящая история создания лампочки гораздо сложнее, и, думаю, мы с вполне обоснованно можем спросить, действительно ли Эдисон крутил в руках кусочек ламповой сажи и смолы, а затем ему пришла в голову потрясающая идея пропустить электрический ток через получившуюся у него нить, напоминающую провод. Как Стивен Джонсон пишет в своей книге «Откуда берутся хорошие идеи»^[16]: «Народная молва утверждает, что Эдисон является изобретателем лампы накаливания, но, на самом деле она появилась в результате сложной системы взаимодействий между Эдисоном и его соперниками… Эдисон опирался на разработки, по крайней мере, полдюжины других изобретателей, предшествующих ему. Среди них были Джозеф Суон и Уильям Сойер»¹⁵.

Эдисон не сам выдумал идею электрического освещения, а уголь использовался в исследованиях материалов для нитей накаливания ламп задолго до того, как Эдисон выяснил, что он ему подходит. Джозеф Суон активно экспериментировал с углем. Тем не менее предшественники Эдисона не смогли создать применимую на практике лампу накаливания, а он смог. Почему? Чтобы это объяснить, надо рассказать, что Эдисон понимал освещение как сложную, создающую и распределяющую электричество систему, о его достижениях как изобретателя, способности умело использовать свою репутацию для получения финансирования исследований и о том, что он собирался учредить и возглавить одну из первых ориентированных на продукт исследовательских лабораторий – организацию, которая бы эффективно управляла работой других¹⁶.

Все это имело значение, но я думаю, что весь успех Эдисона строился на внимании к деталям. Давайте обратимся к тому, как ученый описывает свой подход к основе собственных новаторских исследований. В частности, как он решал такие проблемы, как поиск лучшего материала для лампы накаливания: «Ни одно из моих изобретений не было случайным. Я видел перспективную потребность и проводил опыт за опытом, чтобы прийти к ней. Гений – это один процент вдохновения и девяносто девять процентов тяжелого труда»¹⁷.

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

Как инженера меня интересуют конкретные цифры, приведенные Эдисоном. Соотношение 1 к 99 между вдохновением и тяжелым трудом выглядит огромным. Так ли это на самом деле? История разработки нашего браузера для Apple позволяет проверить это утверждение. Источником вдохновения для нас послужила демоверсия Ричарда. С этого момента мы с Ричардом и Доном принялись за дело. Мы напряженно работали до момента встречи с черным прямоугольником. Вот приблизительная разбивка затраченного нами времени.

На первый взгляд, это соотношение 1:75 показывает, что Эдисон, возможно, переоценивал количество затраченных усилий примерно на 25 процентов, и это серьезная ошибка. Тем не менее в своем заявлении об 1 к 99 Эдисон говорил о состоявшихся изобретениях. Как я уже упоминал, встреча с черным прямоугольником была важной вехой в нашем проекте, но потребовался еще год, чтобы закончить работу. Вспомните, что означал черный прямоугольник, – это был первый раз, когда наш новый код браузера сделал хоть что-то, кроме отказа отвечать, а не упал или выдал кучу отчетов FIXME. И даже в тот момент мы все еще находились на одном из ранних этапов разработки программы. Впереди были многие месяцы до того, как мы решили, что у нас получился конечный продукт, при этом мы уже потратили к тому времени семьдесят пять частей тяжелого труда на одну часть вдохновения. С этой точки зрения, Эдисон значительно недооценил соотношение.

Сомневаюсь, что Эдисон действительно считал свое соотношение 1:99 физическим законом или универсальной константой. Но даже если так, то опыт научил его кое-чему относительно изобретений: главное здесь – напряженный труд.

И все же, если вернуться к отрывку из Бернса, то смола и ламповая сажа в руках занимают в рассказе то же место, что и поиск по всему миру материала для лампы накаливания. Если принимать на веру соотношение Эдисона 1:99, то Бернс в своей книге сильно преувеличивает роль вдохновения, и, возможно, именно поэтому Эдисон говорил о необходимости приложить усилия, чтобы перейти от идеи к изобретению.

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

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

Представьте себе, где бы мы были через несколько недель после показа демоверсии Ричарда, если бы не разработали стратегию портирования и начали над ней работать. Мы добились бы не больше, чем я и Дон за первые шесть недель исследований, пока в Apple не пришел Ричард. Мы никуда не пришли бы, и нам нечего было бы показать. Демоверсия Ричарда вряд ли была бы чем-то бо́льшим, чем программистская диковинка, если бы мы втроем не стиснули зубы и не заставили себя работать без передышки, вспоминая все поговорки о труде, которые знали, когда компилировали код, исправляли перекрестные ссылки по одной за раз, изучали множество примечаний FIXME и в итоге дождались встречи с черным прямоугольником.

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

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

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

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

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

4. Одно простое правило

Работу по запуску проекта мы начинали втроем. Через несколько месяцев мы наняли еще несколько человек, и нас стало девять – маленькая команда, создающая браузер, постепенно идущая к цели.

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

В Apple мы всегда старались поставлять с устройствами лучшие программные продукты, и, помимо скорости, нам нужно было создать браузер со всеобъемлющим набором функций. Первыми в списке стояли удобное управление закладками и четко организованный в соответствии с современными требованиями пользовательский интерфейс. Тем не менее команда сосредоточилась на скорости. Эта трудная задача дала нам цель. Наш чат, работавший по протоколу Internet Relay Chat (IRC), гудел от технических вопросов, комментариев по последним проблемам, идей для воплощения в жизнь, предложений по изменению кода. По меньшей мере четверо или пятеро из нас каждый день собирались за обедом, и мы вместе, как небольшой отряд, шли в Caffe Macs, пересекая кампус в Купертино через зеленую лужайку между Infinite Loop 2 и Infinite Loop 4. Мы шли плотной группой, чтобы каждый из нас мог слышать любой возникший заумный разговор. Я завел традицию ждать за столиком и не начинать есть, пока все не подойдут со своими заказами из кафетерия, и добродушно стыдил остальных, чтобы они делали то же самое – без слов, просто посмотрев искоса, опустив подбородок и слегка приподняв бровь. Начинали есть мы все вместе. Мы не были семьей, но были сплоченной командой.

Мы были такой моделью сотрудничества в стиле Apple – маленькой группой, упорно работавшей над одной задачей – созданием быстрого браузера.

Вдобавок мы хорошо понимали, что такая замена одной программы на другую может оказаться деликатным делом. Когда Apple начнет поставлять новый браузер с Mac по умолчанию, никому бы из нас не хотелось, чтобы пользователи начали задаваться вопросом: а точно ли этот новый браузер удобнее и лучше предыдущего? Стив считал, что высокоскоростной новый браузер Apple будет лучшим способом заставить людей забыть об Internet Explorer, и эта замена их обрадует.

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

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

Исправление ошибок, которые не позволяли просматривать сайты и не давали программе корректно работать, занимало много времени, но, принимая во внимание указание Стива ускорить браузер, мы постоянно размышляли о том, как это сделать.

Дон был тем, кто придумал, как мы можем заставить код работать быстрее. Однажды, через месяц или два после встречи с черным прямоугольником, он позвал меня к себе в кабинет и попросил написать тестовую программу, чтобы измерить скорость браузера. Он задумал автоматизированный инструмент, который будет запускать наше приложение и отдавать ему команду загрузить несколько страниц, одну за другой, в быстрой последовательности. В течение следующих нескольких дней я писал этот код. Я назвал программу «Тест загрузки страницы» (Page Load Test), но вскоре мы начали называть ее PLT.

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

Дон выбирал каждую из сорока страниц в этом списке так, чтобы устроить нашему коду самое суровое испытание, какое только возможно. Он брал страницы, перегруженные текстом, как сайт Yahoo, и страницы, перегруженные графикой, как сайт Disney. В этом списке были и некоторые из самых посещаемых сайтов в сети. Некоторые – такие, как Amazon, Google и Ebay, – вы знаете и сейчас. Другие почти забыты, как Real Networks, Webcrawler и iVillage. Вместе они покрывали все важные характеристики загрузки и отображения веб-страницы, чтобы обнаружить любые слабые места браузера.

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

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

До PLT процесс редактирования в основном был сосредоточен на добавлении новых функций, исправлении ошибок и веб-стандартах гипертекстовых информационных ресурсов – насколько хорошо браузер делает то, что ему положено делать. Все эти показатели были качественными. А PLT проверяла скорость, это был количественный тест, который давал независимую оценку каждому изменению кода, которое мы делали. Теперь точность и скорость шли рука об руку. Дон постановил, что, если мы всегда принимаем во внимание PLT и отклоняем любые изменения кода, замедляющие его, могут произойти только две вещи. Либо скорость браузера останется прежней… либо он станет быстрее. Чтобы подчеркнуть эту хитроумную логику, Дон постукивал указательным пальцем по виску. С того дня, когда PLT будет закончена, заявлял он, наш браузер будет становиться быстрее, потому что перестанет замедляться. Это был его коан.

Запуск PLT на новом коде стал нашим повседневным ритуалом, который мы иногда повторяли каждый час. Я часто использовал программу, чтобы проверить два похожих куска кода с небольшими отличиями, и определить, какой из них быстрее. Когда мы меняли код, то удачей считалось, если с новым кодом браузер работал так же быстро, как и без него. Большинство правок кода никак не сказывались на производительности, но некоторые ее неминуемо меняли. Пока изменение было в сторону ускорения, все было в порядке.

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

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

Из правила скорости PLT не могло быть исключений – Дон не допустил бы этого. Если важный кусок нового кода вызывал замедление, здесь явно был подвох. Поиск средств от снижения скорости – это тернистый путь оптимизации программного обеспечения, и этот термин требует некоторого разъяснения.

Даже среди программистов не так уж много знаменитых ученых в области теории вычислительных машин и систем, но Дональд Кнут по праву является одним из них. Он написал книгу «Искусство программирования» (англ. The Art of Computer Programming) – одну из основополагающих работ в компьютерных науках, многотомное руководство, над которым Кнут с самоотверженностью средневекового монаха-отшельника продолжает работать с 1962 года¹⁸. Он тщательно проводит исследования, пишет с чрезвычайной осторожностью и снабжает свои выпуски такими подзаголовками, как «Введение в комбинаторные алгоритмы и Булевы функции, побитовые решения и методы», «Двоичные диаграммы решений» и «Формирование всех деревьев – история комбинаторной генерации». Для разработчиков программного обеспечения, которые воспринимают свою работу всерьез, Кнут является непревзойденным мастером своего дела. Вот что он говорит об оптимизации:

Программисты тратят огромное количество времени на размышления или беспокойство о скорости работы некритичных частей своих программ, и эти попытки добиться эффективности на самом деле оказывают большое отрицательное воздействие, если говорить о поиске ошибок и поддержании рабочего состояния. Мы должны забывать о низкой эффективности, скажем, в 97 % случаев: преждевременная оптимизация – корень всех проблем¹⁹. (Выделение автора.)

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

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

Приведем пример. Если я приглашу вас к себе на кухню и попрошу:

• Вытащить баночку горчицы из холодильника.

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

• Пойти в супермаркет и купить баночку горчицы.

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

Как это связано с оптимизацией? Вот ряд инструкций для следующего кухонного задания:

• Вытащить все из моего холодильника.

• Расставить предметы на стойке.

А вот попытка оптимизации:

• Вытащить все из моего холодильника.

• Расставить предметы на стойке.

• Сделать как можно меньше подходов.

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

Верно ли это? Эта попытка оптимизации поднимает несколько вопросов. Если переносить продукты большими охапками, это может быть быстрее… но действительно ли это так? Если я пытаюсь сгрести и подхватить большое количество банок с горчицей и майонезом, пакетов с молоком, пачек масла и пластиковый контейнер с остатками жареной свинины со вчерашнего вечера, то могу уронить что-нибудь, пытаясь перенести все за один раз. Это ошибка, верно? Если я пролью или разобью что-либо, не придется ли мне тратить время на то, чтобы все отмыть и отчистить, прежде чем задание можно будет считать выполненным? Если я вернусь к инструкции «Сделать как можно меньше подходов», чтобы поразмыслить о том, что же это все-таки значит, я приду к выводу, что моя цель – все-таки уменьшить количество походов между холодильником и стойкой, но верно ли я думаю? Не знаю. Это просто моя лучшая догадка. У меня нет достаточного понимания ситуации в целом, чтобы быть полностью уверенным в конечной цели задания.

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

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

В программировании существует традиционная точка зрения, что «преждевременность», о которой говорит Кнут, каким-то образом связана с расписанием проекта.

Как правило, программисты сначала делают так, чтобы код работал корректно, а к ускорению переходят, когда бо́льшая часть его ошибок исправлена. Это обычное дело – сначала отладить работу всех функций и только потом заниматься оптимизацией производительности.

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

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

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

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

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

С приближением даты выхода проекта отделу маркетинга Apple предстояло выбрать официальное название для нашего браузера. За месяц до объявления о нашем приложении на весь мир, которое планировалось сделать на выставке-конференции Macworld Expo в Сан-Франциско в начале 2003 года, мы все еще называли его или веб-браузером, или «Александром». Последнее, более позднее название, дали проекту в честь великого македонского царя, знаменитого завоевателя. Мы считали, что очень здорово придумали, но в качестве продуктового наименования Apple такое название не годилось. Скотт Форсталл и отдел маркетинга попросили команду, делавшую браузер, предложить идеи для официального имени, но я был так сосредоточен на доведении до совершенства кода, что названия предлагал без всякого энтузиазма и теперь даже не могу их вспомнить.

У Стива Джобса было несколько идей, и, впервые услышав их, я поморщился. Вначале ему нравилось Thunder (гром), но вскоре Стив решил, что Freedom (свобода) гораздо лучше. Мне оба названия показались ужасными. Я просто и представить не мог, как говорю людям: «Я работаю на Freedom», как будто я какой-то полупомешанный фанат супергероев из комиксов.

Тем, кто в конце концов придумал подходящее название, был Скотт. Safari – оно подходило к той же тематике путешествий по всему миру, что и у других известных браузеров Navigator, Explorer, Konqueror. При этом оно не было подражанием. Оно звучало свежо. Дону название тоже пришлось по душе, и, что куда важнее, оно понравилось Стиву.

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

Выпуск Safari был моим первым релизом в Apple, что само по себе щекотало нервы. А потом еще и Дон сказал мне, что острые ощущения нам обеспечены. Он должен был побывать на последней репетиции выступления Стива Джобса в Москоне-центре^[17] в Сан-Франциско и пригласил меня присоединиться. Это не стоило воспринимать как незапланированный отпуск – мы отправлялись туда, чтобы исправлять неполадки.

Интуитивный план Дона состоял в том, что если на репетиции во время демонстрации Safari Стив найдет какие-то глюки, то Дон будет там, чтобы сказать: «Есть, сэр! Мы все починим прямо сейчас!» А затем мы с ним принялись бы выяснять, что не так, пока Большой Босс, в высшей степени возбужденный, стоит и ждет, глядя на нас.

В последующие годы я многое узнал о том, как Стив готовился к таким пользующимся всеобщим вниманием презентациям. За три или четыре недели до доклада Джобс начинал репетиции своей речи по частям на какой-нибудь площадке в Apple. Чаще всего это происходило в Таун-холле – зале на территории кампуса Infinite Loop. Он медленно день за днем выстраивал шоу, делая его таким, каким хотел видеть. Это был один из главных секретов Стива как ведущего. Он тренировался. Много. Он снова и снова проходил по материалу, пока не доводил презентацию до совершенства и знал ее слово в слово.

Выйдя на сцену в Москоне-центре, Стив репетировал способом, который был для меня новым, и, однажды увидев его методику, я решил, что она настолько мне подходит, что с тех пор всегда использовал ее для собственной подготовки к презентациям. Когда Стив рассказывал о слайде, он полностью превращался в публичного персонажа. Тон его голоса, поза, жесты – все было таким, как будто он выступал перед полным залом. Пока его все устраивало, он продолжал в том же духе. При необходимости он останавливался, выходил из образа, понижал голос и задавал вопросы руководителям подразделений, сидевшим в первом ряду, таким, как Фил Шиллер, старший вице-президент по маркетингу в Apple. Джобс интересовался, что они думают о той или иной фигуре речи или считают ли, что информация изложена гладко. Получив обратную связь, Стив делал продуманную паузу на секунду или две, входил в образ и снова становился публичным персонажем. Если фраза по-прежнему не звучала как надо, он останавливался и пробовал снова. Иногда он занимался этим три или четыре часа, каждый раз четко разделяя попытки, как дубли на съемках фильма. Джобс никогда не забывал и не путал текст – к тому времени его презентация уже была отполирована, – но он старался улучшить каждый слайд и каждую фразу настолько, насколько это возможно.

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

Свой доклад Джобс начал с рассказа о последних новостях, заострив внимание на кампании Switcher – популярной в то время маркетинговой уловке Apple, придуманной для того, чтобы люди покупали Mac взамен компьютера с Windows. В ту эпоху, до iPod/iPhone/iPad, Apple все еще оставалась Apple Computer – компанией, выпускающей персональные компьютеры и пытающейся за счет шумной рекламы привлечь потребителей и поднять свои позиции на рынке. Частью стратегии повышения продаж было открытие два года назад первого магазина Apple Store – точки розничной торговли, которая должна была предоставить улучшенное обслуживание клиентов и повысить продажи Mac. Когда все это начиналось в 2001 году, аналитики отрасли глумились над попытками Apple торговать в розницу, и даже старые руководители высшего звена, такие как бывший финансовый директор компании Джозеф Грациано, предполагали: «Проблема Apple состоит в том, что компания все еще считает, что путь к росту – это подавать икру, когда мир вполне счастлив, питаясь сыром и крекерами»²⁰. Теперь, почти через два года после открытия первого магазина, Стив был готов заявить, что потребность в икре вполне себе осталась. Чтобы подкрепить историю успеха розничных продаж конкретными цифрами, он сообщил о 148 миллионах долларов выручки Apple Store за предпраздничный квартал²¹.

Сделав это, Стив был готов завершить первую часть презентации. Он сказал:

– Это новости о розничных магазинах Apple. Мы счастливы как никогда, и я думаю, мы одержали победу над критиками, пророчившими нам скорое поражение, когда мы открывали первые магазины.

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

Вместо этого Стив сказал:

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

И он переключился на следующий, недавно добавленный слайд.

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

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

В одну секунду сверхсекретный проект, над которым мы работали полтора года, стал достоянием общественности. Также Стив заявил, что Safari не просто загружает веб-страницы быстрее, чем Internet Explorer… Он делает это в три раза быстрее.

Показав ярлык браузера, Джобс переключился на следующий слайд. На нем было единственное слово: «Почему?» Стив ощущал необходимость объяснить, почему Apple сделала собственный браузер, и его объяснение было связано со скоростью. Кто-то мог бы подумать, что разрекламированная производительность Safari была просто маркетинговым ходом, вишенкой на торте, появившейся задним числом, качеством браузера, которое по воле случая оказалось очень хорошим.

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

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

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

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

Такие комментарии мало что объясняют и ничего не предсказывают.

Тем не менее слова и действия могут быть связаны и в спорте, и, когда так бывает, эта связь говорит сама за себя, как это произошло в футболе с карьерой главного тренера Винса Ломбарди.

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

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

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

– Джентльмены, – сказал он, – нам многое предстоит. Мы будем делать все совсем по-другому, не так, как раньше… [Мы] будем безжалостно и непреклонно стремиться к совершенству, зная наверняка, что оно недостижимо, но в этой гонке за совершенством мы достигнем превосходства²³.

Он остановился и оглядел всех, переводя взгляд с одного игрока на другого. В комнате стояла тишина.

– Я нисколько не заинтересован в том, чтобы вы были просто хорошими игроками, – сказал он с напором, поразившим их всех.

Во время перерыва Старр пошел к телефону, чтобы позвонить жене в Алабаму:

– Дорогая, мы, кажется, скоро победим! Этот парень говорил о совершенстве!²⁴

Конечно, любой тренер может провести небольшое мотивационное собрание, но за полной энтузиазма улыбкой Ломбарди вскоре последовало четкое описание конкретных вещей, в которых команда будет совершенствоваться. Одна комбинация. Одна-единственная победная комбинация. Собрав своих игроков, Ломбарди сказал: «Джентльмены, для нас это самая важная комбинация. Это комбинация, которую мы должны сделать. Это комбинация, которую мы сделаем. Это комбинация, которую мы будем повторять снова, снова и снова»²⁵.

Эту комбинацию Ломбарди в подробностях описывает в фильме «Наука и искусство американского футбола»²⁶. Это замечательное малобюджетное учебное видео в стиле шестидесятых начинается с клипов из игровых эпизодов под военную музыку. Их сменяет студийная съемка Ломбарди, щербатого мужчины в очках, в белой рубашке и темном галстуке, коротко подстриженного и держащего перед собой футбольный мяч, чтобы его по ошибке не приняли за страхового агента. Он, немного запинаясь, с бруклинским акцентом рассказывает о квинтэссенции своего напряженного поиска совершенства – Power Sweep^[18].

В фильме Ломбарди по меньшей мере полчаса говорит об одной этой комбинации, указывая на доске на буквы «икс» и «о», описывая свое понимание концепции, направления, варианты, указания тренера по этой жесткой тактике. При ней квотербек передает мяч бегущему, который затем некоторое время двигается вдоль линии скримиджа^[19], давая возможность обоим гардам^[20] оказаться на его фланге. Затем соперников блокируют, и команда переходит в атаку, продвигаясь вперед, на территорию противника, к линии его ворот. Через несколько минут этой кинолекции, в деталях объясняющей его любимый атакующий стиль игры, Ломбарди начинает переполнять энтузиазм. Он забывает о своем смущении перед камерой и принимает позу, характерную для атакующего игрока, чтобы движениями всего тела показать правильную технику блокирования.

Мы и подумать бы не могли, что можно так долго рассказывать об одной комбинации, при этом, возможно, этот фильм еще и сократили. Известный тренер и комментатор Джон Мэдден рассказывал, как побывал на тренерском семинаре, где Ломбарди говорил о Power Sweep и только о Power Sweep в течение восьми часов²⁷.

От упражнения к упражнению, от тренировки к тренировке, от игры к игре, от сезона к сезону «Пэкерс» доводили до совершенства и полировали Power Sweep Ломбарди. Противники знали, что в игре будет использована эта комбинация, но не могли ее остановить. Похоже, пытаясь опровергнуть высказывание Сунь Цзы о том, что «война – это путь обмана», Ломбарди строил свои победы на открыто брошенном вызове. Чтобы победить «Пэкерс», нужно справиться с Power Sweep.

За первый год пребывания Ломбарди в должности тренера без всяких изменений в составе «Пэкерс» выиграли семь игр и проиграли пять. На следующий год они приняли участие в чемпионском матче NFL, но проиграли. За следующие семь лет команда пять раз становилась чемпионом, в том числе победила в двух Супербоулах. Шаг за шагом, год за годом «Пэкерс» из аутсайдеров превращались в лучших, а потом и в легенд, и все это строилось на одной, ничем не выдающейся игровой комбинации, которая когда-то была нарисована мелом на доске, а потом раз за разом утонченно разыгрывалась на поле.

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

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

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

Когда я протягиваю мостик от своей технической работы до тренерских достижений Винса Ломбарди, я вижу в его подходе к футболу то же стремление к ясности и совершенству, какое было у нас во время работы с продуктами для Apple. Со своим искренним упором на Power Sweep и успехом, которого «Пэкерс» добились в результате, Винс Ломбарди был Стивом Джобсом среди футбольных тренеров. Ломбарди связал свои слова и действия команды во время игры, сосредоточившись на одной атакующей комбинации, а в Apple мы, сделав акцент на том, чтобы не замедлять браузер, связали наши слова и действия при разработке программного обеспечения, сосредоточившись на одном простом правиле.

5. Самая трудная задача

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

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

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

Я не могу винить Дарена в том, что он хотел эту работу. Разумеется, у него вполне хватало для нее квалификации, но я все равно был огорчен – так огорчен, что даже собирался уйти из Apple в Google.

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

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

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

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

Это мне подходило. Я действительно не хотел уходить из Apple. Мне нравилась направленность компании на то, чтобы разрабатывать крутые продукты, и я хотел делать их и дальше. Демонстрация полного доверия Скотта значила больше, чем то, что именно он сказал, и это повлияло на мое решение остаться. Я ощутил, что пока я работаю с ним и могу обратиться к нему в случае необходимости, со мной все будет в порядке.

Несколько недель спустя Скотт, как и обещал, вызвал меня в свой кабинет. Разговор он начал с рассказа о развитии электронной почты: со времен своего появления она распространялась исключительно как текстовая среда. Веб-сервисы электронной почты, такие как Hotmail, быстро становились популярными, и пользователи Mac получали все больше и больше электронных писем с прикрепленными веб-страницами. От вездесущих социальных сетей, например Facebook, нас еще отделяло целое десятилетие, и в то время электронная почта была лучшим способом поделиться цифровым контентом. Компании использовали ее, чтобы рассылать рекламные брошюры, спамеры – чтобы направлять таргетированную рекламу в массы, а простым пользователям она была нужна, чтобы составлять семейные альбомы фотографий из отпуска, используя такие приложения, как Apple iPhoto.

Скотт сказал, что становится все больше и больше таких «наполненных» сообщений, в которых используются веб-технологии для оформления текста и вставки картинок. Проблема, по его словам, была в том, что приложение электронной почты в Mac не позволяло редактировать такие сообщения и отвечать на них. Скотт уже придумал ее решение. Он предложил, чтобы мы использовали WebKit – ядро программного кода нашего браузера, – чтобы улучшить возможности электронной почты на Mac. Техническая трудность состояла в том, что мы как пользователи просматриваем сеть. Мы не редактируем страницы, а просто читаем их, если не считать заполнение форм в интернет-магазинах. Чтобы заставить этот план работать, Форсталл хотел от меня такой доработки и адаптации нашего кода, чтобы люди могли обращаться со всей веб-страницей в электронном письме, как с документом текстового редактора, изменяя текст и картинки привычным способом, печатая новый текст, выделяя абзацы мышкой, удаляя их клавиатурой, вырезая, копируя, вставляя и так далее. Скотт объяснил, что мы пожинаем дивиденды от наших вложений в Safari и WebKit, поскольку теперь сами можем принимать решения по поводу новых особенностей веб-приложений, которые мы хотели бы видеть в будущих продуктах Mac. Редактирование страниц для электронной почты было именно такой технологией. Скотт спросил меня, заинтересован ли я в работе над ней.

Я никогда не работал с текстовыми редакторами, но не хотел разочаровывать Скотта, поэтому кивнул и сказал:

– Ну… да.

Скотт принял это за восторженное утверждение и поднажал, чтобы закончить дело. Он сослался на одержимость Стива электронной почтой: наш CEO еще несколько лет после возвращения в Apple продолжал писать электронные письма на компьютере NeXT, потому что считал, что его бывшая компания производила великолепное программное обеспечение.

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

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

Этот разговор был иллюстрацией важного аспекта того, как происходила разработка программного обеспечения Apple: такие руководители, как Скотт, предлагали возможности принять участие в проектах таким программистам, как я. И он был прав, когда предполагал, что у нас немного специалистов, которые в состоянии воплотить редактирование WebKit в реальность. Стив и Скотт хотели новую функцию. Если Apple действительно собиралась предоставить ее клиентам, кто-то должен был подписаться на эту работу и сделать ее.

Впервые с этим выражением «подписаться»^[21] я столкнулся в книге Трейси Киддер «Душа новой машины» (Tracy Kidder. Soul of a New Machine), получившей Пулитцеровскую премию истории о разработке мини-компьютера в Data General Corporation в конце 1970-х годов²⁸. Киддер использовала этот термин, чтобы описать ситуацию, когда один из молодых программистов компании берет на себя личную ответственность за проект. В Apple мы не говорили «я подписываюсь» так официально или недвусмысленно, как это, по словам Киддер, было в Data General, но истории Киддер за многие годы распространились по миру высоких технологий, и многие сотрудники Apple читали эту книгу (я лично читал даже не один раз), поэтому мы все были в курсе, что такое «подписаться», и делали это, хотя и не называли именно так.

Самое близкое выражение, которое было в лексиконе Apple, относилось скорее к менеджерскому жаргону: непосредственная личная ответственность (в разговорах мы называли ее D-R-I)^[22]. Ее брал на себя человек, который делал все, что необходимо, чтобы разработать часть аппаратного или программного обеспечения, какую-то технологию или критически важную вещь. Лично ответственным (DRI) называли человека, который отвечал за проект головой.

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

– Хорошо, Скотт, я сделаю все, что смогу.

Ответ ему понравился.

Вот так я стал ответственным за то, чтобы добавить в WebKit редактирование веб-страниц – технологию, о которой я почти ничего не знал.

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

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

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

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

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

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

Чтобы показать сущность моих проблем, возьмем два правила поведения точки ввода, простое и сложное.

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

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

До того, как я приступил к проекту редактирования в WebKit, я думал, что благодаря этим правилам, все будет работать примерно так, как, в общем, и должна работать обработка текста. И я был уверен, что замечу, если какое-то из этих правил перестанет работать – например, почему выровненный по левому краю текст вдруг стал неровным слева? Да, умом я эти правила не понимал. Теперь, когда мне предстояло превратить функцию WebKit в полноценный текстовый редактор, я больше не мог позволить себе роскошь опираться на интуитивные ощущения при наборе и редактировании электронных писем. Я должен был стать экспертом, знающим все тонкости текстовых редакторов. По этой теме не существует учебников для программистов, поэтому мне приходилось проводить эксперименты, чтобы выяснять, что и как работает. Мне нужно было сжиться с буквой и духом всех этих правил, простых и сложных. Я потратил много времени, прощупывая различные текстовые редакторы: Microsoft Word, Apple Mail и BBEdit – редактор, который я использовал для того, чтобы писать программы. Я проверял, «прокликивал», набирал текст, щелкал мышью. Постепенно я узнал и о других правилах, и о том, как написать код, чтобы обеспечить их выполнение. Сделав это, я попал в тупик.

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

У программистов для подобных проблем есть свое название. Мы позаимствовали его из квантовой механики, от имени Вернера Гейзенберга, который вывел принцип неопределенности. Мои проблемы с курсором назывались «гейзенбагами»^[23]. И их исправление оказалось самой трудной задачей в программировании, с какой мне когда-либо приходилось сталкиваться.

Чтобы дать полное техническое объяснение этих проблем, я сражался с кодом, заставляя его показывать правильный видимый результат. Мне нужно было описать формат веб-страниц HTML (Hypertext Markup Language, язык гипертекстовой разметки), а также понятные лишь посвященным вещи, такие, как древовидные структуры объектной модели документа, алгоритмы обхода бинарного дерева и многое другое. Проведем аналогию. Представьте себе следующую ситуацию.

Клиент приходит в кондитерскую, чтобы для него испекли торт по индивидуальному заказу. Он говорит: «Я хочу торт с надписью: “С днем рождения!”, а ниже – “Том”».

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

«Я хочу торт с надписью с днем рождения а ниже том».

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

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

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

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

Какой-то <b>текст, выделенный жирным шрифтом, какой-то <i>курсив</i></b> и какой-то простой текст.

Какой-то текст, выделенный жирным шрифтом, какой-то курсив и какой-то простой текст.

Вы видите, что, как и при заказе праздничного торта, когда заказчик говорит с продавцом, текст и его стилизованное оформление вы как бы передаете ему одновременно. В HTML не всегда легко отделить разметку от содержания. Данные и метаданные смешиваются. Вот более сложный и реалистичный пример, который я взял со страницы Википедии, где говорится о белоголовом ксенопсарисе²⁹ – маленькой южноамериканской птице. В примере ниже HTML-код представлен рядом с его отображением:

Белоголовый ксенопсарис (лат. Xenopsaris albinucha) – вид воробьинообразных птиц из семейства титировых (Tityridae), который выделен в монотипический род белоголовых ксенопсарисов (Xenopsaris).

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

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

Я зашел в тупик.

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

Дон предложил мне встретиться с двумя коллегами из нашей команды, создававшей браузер: Дареном Адлером и Треем Мэттьюсоном, работающим по временному контракту и помогающим нам улучшить код. Оба были отличными программистами и имели намного больше профессионального опыта, чем я. Когда Дарен приступил к работе над Safari, это было фактически его второе место в Apple. Первый раз он работал в компании еще в 1980-х, когда руководил командой, создававшей архитектуру программного обеспечения для System 7 – достойной упоминания операционной системы в истории Mac. Трей был одним из первых разработчиков AppKit в NeXT, и этот код теперь был частью основы программного обеспечения для разрабатываемых в Apple приложений.

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

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

Дарен и Трей задавали вопросы, и примерно через полчаса они поняли суть моей проблемы с точкой ввода: я проводил слишком много времени, размышляя о данных, и недостаточно думал о визуальном отображении. Я был так занят, пытаясь расшифровать HTML, что не уделил должного внимания тому, чтобы написать код, который гарантировал бы те результаты, которых я пытался добиться.

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

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

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

Когда пришло время поговорить о решении проблемы, коллеги посоветовали мне вычистить код. За многие месяцы борьбы я расставил функции для частных случаев поведения курсора по всему проекту. Дарен и Трей сказали, что это ошибка, но их рекомендация собрать код обратно в один С++ класс, который они предложили назвать VisiblePosition, выглядела как чрезмерная педантичность. Зато в ней содержалось важное техническое «озарение»: когда поведение программного обеспечения становится необъяснимым, добавьте ему организованности. Мой код точки ввода должен быть как пекарь, изучающий правильно заполненную форму заказа, чтобы найти те самые слова, которые нужно написать на торте.

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

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

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

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

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

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

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

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

Тем не менее, если бы Скотт не нашел правильные слова, которые он сказал мне, когда в команде Safari сменилось руководство, я бы мог уйти в Google и не подписался бы на проект редактирования WebKit.

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

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

6. Дерби с клавиатурой

В Apple не отводилось слишком много времени на то, чтобы наслаждаться успехами. Стив Джобс объяснил эту особенность обычаев компании в интервью с ведущим NBC Nightly News Брайаном Уильямсом по случаю открытия Apple Store на Пятой авеню на Манхэттене в 2006 году. Уильямс спросил Стива, каким образом он «вписывается в американскую семью мыслителей и изобретателей». Сначала Джобс попытался уйти от ответа, но после того, как Уильямс надавил, сказал: «Я думаю, если вы делаете что-то, и оно оказывается хорошим, то вы должны сделать что-то еще, настолько же прекрасное, и не откладывать это надолго. Просто начните думать, что будет следующим»³⁰.

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

Закончив с редактированием HTML, я снова отправился на встречу со Скоттом Форсталлом, чтобы поговорить о том, чем мне заняться дальше. Я сказал ему, что меня все еще беспокоит, что два года назад я не получил место руководителя команды Safari и попросил дать мне шанс возглавить какую-нибудь другую команду в его отделе.

В то время существовала открытая вакансия менеджера Sync Services (Сервисы синхронизации) – команды, отвечающей за синхронизацию облачных сервисов Mac и Apple, которые тогда называли. Mac^[24]. Я попросился на это место. Скотт согласился. Не возражал и Анри Ламиро, который в то время подчинялся Скотту и возглавлял группу команд, куда входила и синхронизация.

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

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

– Привет, Кен! Как тебе твоя руководящая работа?

– Привет, Курт! Все хорошо, – соврал я.

Тем не менее я решил, что смогу извлечь из этого короткого разговора какую-то пользу. Я сделал свой ход:

– Ну, теперь, когда я руковожу Sync Services, возможно, мы с тобой могли бы поработать вместе над нашим продвижением.

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

– Кен, мы не продаем синхронизацию. На самом деле мы не считаем ее… ну… ориентированной на клиентов технологией.

Курт выглядел смущенным отчасти из-за своего ответа, а отчасти – из-за моего вопроса. Я немедленно понял, что выражение «не ориентированная на клиентов» было для него синонимом «не важная», по крайней мере, не имеющая значения с точки зрения отдела продвижения.

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

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

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

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

Когда мы с Анри встретились, я сказал ему, что немедленно хочу уйти из команды синхронизации. Я был тверд, как скала. Оглядываясь назад, хочу сказать, что это было несправедливо. Я должен был дать ему какое-то время, обеспечить некий переходный период, но я этого не сделал. Несмотря на это Анри оставался спокойным. Он сказал, что очень удивлен и что ему нужно больше информации для Скотта, чтобы они могли решить, что делать. В тот момент я упомянул о слухах по поводу нового суперсекретного проекта и предложил, что если у меня получится перейти в него, то я могу не уходить из Apple в Google.

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

Очевидно, встречи со Скоттом было не избежать. Я сказал ему, что не хочу работать в команде синхронизации, объяснив это так же, как ранее Анри, хотя уже становилось понятно, что мой подход работает не очень хорошо. Я объяснил, что руководство Sync Services – это не для меня, и, если я собираюсь оставаться в Apple, мне нужно что-то другое. Я извинился. Я сказал, что откажусь от должности и уволюсь по собственному желанию. Тут Скотт велел мне притормозить. С его точки зрения, я получил руководящую работу, о которой сам и просил, а теперь, всего несколько месяцев спустя, прошу о чем-то еще. Я подписался на синхронизацию. «Отписаться» от нее просто так было нельзя. Скотт хотел понять меня и помочь, но не был уверен, что я сам знаю, что мне нужно, и, восстанавливая все это в памяти, думаю, он был прав в своих сомнениях. Он попросил меня подождать с какими-либо решениями, и на этом наша встреча закончилась.

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

Я не колебался.

Потом Анри сказал мне:

– Ну так вот, мы делаем сотовый телефон. Его кодовое название Purple.

Таким образом я стал частью самого большого сверхсекретного проекта компании, возможно, за всю историю Apple. Я одновременно ощутил вину и эйфорию. Если сложить все очки, полученные за работу над Safari и WebKit, то на моем счету был примерно ноль. Если мои отношения со Скоттом оставались, казалось, на прежнем уровне, Анри был настроен более скептически, особенно в начале, и косые взгляды, которые он бросал на меня в течение следующих нескольких недель, говорили о том, что для Анри я не только не заработал очков, а вовсе ушел в минус.

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

Также мы получили бейджи для допуска в помещения команды пользовательского интерфейса (Human Interface, сокращенно – HI). К ней относились разработчики, которые наделяли программное обеспечение Purple жизнью, от общего представления и принципов до анимации и ярлыков программ. Наша же команда программистов отвечала за обеспечение «мускулатуры», добавляя код, алгоритмы и приложения. Вместе мы должны были оживить ПО телефона с сенсорным экраном и наделить его программной индивидуальностью.

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

Теперь мы обитали в своем собственном коридоре тайн.

Я воссоединился с несколькими коллегами, которых знал по проекту Safari, в том числе с Ричардом Уильямсоном, который стал моим руководителем. Ричард отчитывался перед Анри, который тоже оставил команду синхронизации, правда, менее драматичным способом, чем я. После того, как начался проект Purple, Скотт и Анри стали подбирать программистов из разных частей компании. Все мы, в том числе Анри и команда HI, которую возглавлял Грег Кристи, отчитывались перед Скоттом, который, как всегда, был на связи со Стивом Джобсом.

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

Теперь мне предстояло о нем узнать.

Во время моего первого визита в студию HI, чтобы взглянуть на мультитач, Бас Ординг показал мне интерактивную демоверсию, которую он, как всегда, сделал в Adobe Director. На его столе было приспособление, которое мы называли Wallaby, и этот экспериментальный гаджет размером с телефон был тем самым, с помощью которого Бас разрабатывал и проверял свою демоверсию для сенсорного экрана. Wallaby являлся устройством-прототипом с экспериментальными программными средствами. Это был мультисенсорный дисплей, разработанный для того, чтобы приблизительно представлять форму нашего смартфона и обеспечить правильное ощущение при касании экрана. Wallaby связывался с Mac с помощью дополнительной платы и разъемного кабеля примерно в четверть дюйма толщиной. Wallaby представлял собой просто экран. Mac обеспечивал вычислительную мощность, поэтому там и тут подсоединялись различные разъемы. Все эти приспособления обеспечивали аппаратную реализацию для того, чтобы вдохнуть жизнь в экспериментальное программное обеспечение. Бас взял в руки дисплей Wallaby и, нажимая на него и проводя по нему пальцами, показал мне основы системы пользовательского интерфейса сенсорного экрана в стиле Apple. В нем был интуитивно понятный главный экран с расположенными рядами иконками для запуска программ под названием SpringBoard и подвижная схема с инерционной прокруткой, которая игриво подпрыгивала, когда Бас доходил до конца списка³¹. Сегодня все эти вещи хорошо нам знакомы, но в тот день я словно впервые заглянул в будущее технологий персональных гаджетов.

Впечатляющее программное обеспечение, которое показал мне Бас, не могло стать прочным основанием для долгосрочной разработки, поскольку прямого пути от сделанной в Director демоверсии к годному для клиентов продукту не существовало. Нам была нужна инфраструктура ПО, основанная на профессиональном языке программирования, таком, как С++ или Objective-C, и я появился в команде Purple после того, как Стив решил, каким должно быть это основание.

Ричард, который работал над Purple на пару месяцев дольше, ввел меня в курс дела. Он рассказал, что они думали об использовании программной платформы iPod, поскольку она уже работала на карманных устройствах, но не знали наверняка, можно ли будет расширить ее и превратить в более сложную систему для запуска нескольких приложений одновременно. Также они думали о полнофункциональной интегрированной среде разработки AppKit, которую мы использовали, создавая программы для Mac. Эта среда обеспечивала меню, окна и подборку других вещей, необходимых для пользовательского интерфейса, но, опять же, возникал вопрос: можно ли будет заставить ее работать на более ограниченной аппаратной платформе смартфона. Они думали и о WebKit, что означало создание системы пользовательского интерфейса из набора детально проработанных веб-страниц, но здесь существовала проблема с удобством программирования. Также они рассматривали возможность разработки с нуля совершенно новой, основанной на сенсорном вводе, системы пользовательского интерфейса.

Все это делалось параллельно, но через пару недель исследований варианты с AppKit и WebKit были признаны неприменимыми на практике и отброшены.

Этот период напоминал первые дни нашего проекта веб-браузера, когда мы должны были выбрать технологическое направление среди множества вариантов. Но с Purple все было по-другому. Ставки были выше: Джобс ревностно следил за процессом разработки. Purple был новым аппаратным продуктом, имевшим потенциал стать соперником и резко снизить продажи самого крутого в то время продукта Apple – iPod, поэтому шло жесткое соревнование за то, чтобы войти в проект, который может оказаться следующим хитом. Тони Фаделл, старший вице-президент подразделения iPod, хотел, чтобы разработка программного обеспечения для нового телефона шла на его территории. Скотт Форсталл считал, что он сможет сделать лучше, и эти два человека устроили конкурс руководителей за право будущей разработки программного обеспечения Purple.

Скотт оказался сильнее в этой борьбе, поставив Анри и еще пару программистов на разработку платформы, которая взяла бы у Mac так много, как только возможно, но заменила бы AppKit совершенно новой мультисенсорной системой пользовательского интерфейса UIKit. Крошечная команда программистов Анри создала демоверсии инерционной прокрутки и SpringBoard – главных новшеств в пользовательском интерфейсе, которые Бас показал мне на Wallaby, а также одну из первых демоверсий Safari. Все они запускались на устройстве, которое могло поместиться у вас в кармане. Из этих демоверсий Скотт создал перспективную модель, показывающую, что его команда программистов сможет перенести главные программы Mac на смартфон. Стив согласился.

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

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

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

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

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

Наши лидеры – Скотт, Анри, Грег и Ким Воррат, руководитель проекта Purple, основной обязанностью которой было отслеживать сроки выполнения разработки, – всегда наблюдали за тем, как мы продвигаемся вперед. Во время периодических проверок они постоянно задавали себе одни и те же главные вопросы: приближает ли эта демоверсия нас к готовому продукту хоть на малюсенький шаг? Увидели ли мы достаточно положительных изменений за последнее время? На правильном ли пути эта технология или приложение?

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

Примерно в сентябре 2005 года состоялся особенно трудный показ экранной клавиатуры. Хотя Скотт Херц и Уэйн Вестерман, программисты, которые создали эту демоверсию, сделали очень много, готовя смартфон для клиентов – Скотт с нуля разработал SpringBoard, а Уэйн был одним из изобретателей функции мультитач, – эта последняя демонстрация клавиатуры прошла не слишком хорошо. Помню, Скотт Форсталл сидел в офисном кресле, наклонившись вперед, сжимая экран Wallaby в руках и пытаясь воспользоваться клавиатурой.

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

Пару дней спустя нас ждал сюрприз. Анри вызвал всех программистов Purple из их кабинетов. К тому времени нас было человек пятнадцать, и когда мы все собрались в холле, он сделал объявление. Анри сказал нам бросить все, что мы делаем, отставить все текущие дела в сторону, временно остановить работу по Safari, «Почте», SpringBoard, «Заметкам» – по всему. Он сказал, что Скотт нажимает большую фиолетовую кнопку паузы. Он хотел, чтобы каждый прямо сейчас принялся за разработку клавиатуры. Последняя «трудная» демоверсия клавиатуры вызвала опасения у всей управленческой цепочки. Нам было жизненно важно иметь экранную клавиатуру для сенсорных телефонов, и до нас донесли вердикт начальства: прогресс в этом плане шел слишком медленно.

Вспомните то время. Осенью 2005 года, когда мы работали над Purple в атмосфере полной секретности, особый успех на рынке имел смартфон BlackBerry. Его прозвище CrackBerry было намеком на поведение как будто бы зависимых от своего гаджета людей: они постоянно проверяли электронную почту и печатали сообщения на хорошо продуманной аппаратной клавиатуре с малюсенькими клавишами³².

На нашем телефоне Purple аппаратной клавиатуры не было. В лаборатории проектирования промышленного дизайна не было прототипов с чем-то вроде клавиатуры в стиле BlackBerry. Главная идея Purple строилась вокруг большого сенсорного экрана и минимального количества кнопок. Apple сделала ставку на виртуальную клавиатуру. Когда дело доходило до ввода текста, пластиковые клавиши уступали место пикселям на экране. Как команда программистов и компания мы пошли ва-банк. Тем не менее, когда дело дошло до того, чтобы набирать текст на плоском дисплее без тактильных клавиш, мы не могли придумать клавиатуру достаточно быстро.

Анри окинул взглядом свою собравшуюся в холле команду и сказал:

– Начиная с сегодняшнего дня, все вы становитесь разработчиками клавиатуры.

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

Слушая Анри, я задавался вопросом, не было ли это последней, отчаянной попыткой вернуть разработку клавиатуры в правильную колею? Что, если мы не сможем? Тогда проект Purple отменят? Анри ничего такого не говорил, но он и не должен был этого делать. За все годы моей работы в Apple еще никогда не было такого, чтобы команда проекта из пятнадцати человек решала одну-единственную проблему.

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

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

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

– Твои клавиатуры – как у всех, и они не работают. Все делают клавиши слишком маленькими, и по ним трудно попасть пальцем, – сказал он. – Кнопки должны быть больше.

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

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

Ричард сделал прототипы, чтобы проверить эту идею. Я ответил своим собственным, который назвал «клавиатура Blob»³³.

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

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

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

Вы жмете, жмете и жмете. Напротив, прототипы клавиатуры Purple в стиле Ричарда (с несколькими буквами на одной клавише) требовали от пользователя думать над каждой буквой. На моей клавиатуре Blob для того, чтобы напечатать простое слово bank, требовалась последовательность из самых разных жестов.

• «Свайпнуть» влево на клавише abc.

• Стукнуть по клавише abc.

• Стукнуть по клавише nyz.

• «Свайпнуть» вправо на клавише ejk.

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

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

1. С большими клавишами легче набирать текст. Ричард был прав.

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

3. На клавиши нужно только нажимать. Постоянно выбирать различные жесты для каждой буквы слишком сложно.

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

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

Чтобы напечатать слово light, вы нажмете клавиши со следующими буквами:

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

Единственная проблема состояла в том, что я и понятия не имел, как сделать словарь. В таких случаях очень здорово работать в Apple. У компании есть огромный каталог прошлых проектов, исследований и ресурсов. Я порылся в нем. Я поскреб по дальним углам давно забытых директорий с программным обеспечением, запасенным в архивах Apple. Я собирал информацию из различных источников и составил примитивный список английских слов.

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

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

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

Когда Скотт пришел в день показа, чтобы посмотреть клавиатуры, все программисты команды собрались в главном конференц-зале проекта Purple, который назывался «Между». Напротив него находились еще две комнаты: «Молот» и «Наковальня»^[25]. Прошел примерно месяц с того времени, когда в этом же коридоре Анри объявил о конкурсе, и все приложили серьезные усилия, но было совершенно не очевидно, вышли ли мы из кризиса с клавиатурой.

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

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

– Ну, это все.

– Нет! – выпалил я.

Это походило на крик больше, чем мне хотелось бы, но всплеск адреналина опередил мой разум. Скотт повернулся ко мне. Чувствуя стук крови у себя в ушах, я объяснил, что у меня есть клавиатура для демонстрации, но мне потребуется несколько секунд, чтобы изменить настройки компьютера, к которому был подключен прототип Wallaby. Скотт отодвинул стул, чтобы я мог подойти к Mac и запустить свою демоверсию, и через несколько мгновений я снова передал ему Wallaby.

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

Скотт слегка наклонил голову в знак согласия, переключился на то, что происходит на экране Wallaby, и, глядя через его плечо, я увидел, что он нажал пять клавиш, чтобы напечатать свое имя: as zxc op rt rt. Он набирал быстро и, подняв глаза, увидел, что имя написано правильно. Он несколько раз нажал delete и попробовал еще раз. После тык-тык-тык-тык-тык он снова увидел:

Удовлетворенный этим, он нажал еще несколько клавиш:

yui as space nm yui space nm as nm qwe

Он поднял взгляд и увидел целое предложение:

Сделано это было даже проще, чем кажется из описания. Скотт повернулся ко мне и сказал:

– Это потрясающе!

Все в комнате на секунду замолчали, затем на меня посыпались вопросы Скотта:

– Почему на каждой клавише расположено несколько букв?

– Как программное обеспечение узнает, какую именно букву я хочу?

– Как оно понимает, какое слово я имею в виду?

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

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

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

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

Я как раз придумал, что будет дальше.

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

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

Нам нужны были точные и конкретные демоверсии, чтобы вести работу, поскольку даже простую идею трудно обсуждать конструктивно без образца, который иллюстрировал бы ее. Вот пример.

Подумайте о милом щеночке. Представьте его себе мысленно. Если нужно, можете даже закрыть глаза. Сделайте этот образ настолько подробным, насколько можете. Не торопитесь. МИЛЫЙ ЩЕНОЧЕК.

У вас получилось? У меня тоже, и у меня вышло хорошо. На самом деле, думаю, мой щенок милее вашего.

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

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

Я сделаю проще. Вот фотографии двух милых щенков.

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

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

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

Делать демоверсии трудно. Для этого нужно перестать беспокоиться по поводу траты времени и сил на что-то, в чем ты вовсе не уверен. В Apple мы должны были раскрыть идею и продемонстрировать ее острому глазу внимательных коллег, которые никогда не боялись критиковать. Психологическое напряжение растет от того, что ты знаешь: большинство демоверсий – да почти все они! – растворяются в абсолюте (и здесь я имею в виду, что они не имеют никаких перспектив).

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

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

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

Мы буквально должны были демонстрировать свои идеи. Мы не могли просто рассказать о них. От нас требовалось показать их.

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

Моя победа в дерби с клавиатурой Purple была как встреча с черным прямоугольником. Она определила направление для дальнейшей работы, и, как ни странно, клавиши на моей клавиатуре выглядели как маленькие инопланетные обелиски, опрокинутые на бок.

7. QWERTY

Если у вас когда-нибудь был iPhone, то вы знаете, что клавиатура, которую я представил на дерби, выглядит и работает совсем не так, как та, что оказалась в устройстве, попавшем в руки к клиентам. Как же это произошло?

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

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

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

Однажды компания сделала продукт, который не имел успеха именно из-за плохого метода ввода текста. Это был Newton – карманный персональный компьютер, который Apple создала в 1990-е годы. Это изделие было прорывным с точки зрения идеи и формы, но его погубили проблемы с распознаванием рукописного текста³⁴.

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

Из тех, кто был в проекте Purple, нескольким людям – в том числе и Грегу Кристи – довелось работать над Newton, и все они прекрасно знали, почему карманный компьютер Apple «не взлетел». Для них моя клавиатура выглядела как нечто, из-за чего история может повториться. Каждый баг, который обнаруживался в моей работе по клавиатуре, заставлял кого-то вспоминать Newton. Так что я быстро привык, что в презентации о самом потенциально рискованном для Purple ПО, которую Анри регулярно делал для Скотта, клавиатура появлялась на первом слайде, выше всех.

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

Никто из нас не знал, как должна работать экранная клавиатура. Я постоянно задавался вопросом, а хороши ли те решения, которые кажутся хорошими мне. Я не знал.

Набор текста на маленьком куске стекла был совершенно новым опытом.

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

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

Когда Скотт привел Фила в конференц-зал, я уже их ждал. Это была моя первая встреча с мистером Шиллером, и я волновался. Я настроил все так, как было несколько дней назад, но к этому времени я уже сделал несколько изменений в пользовательском интерфейсе клавиатуры. Скотт представил меня. Фил кратко и вежливо поздоровался, – похоже, он хотел перейти сразу к делу.

Он взял Wallaby и нажал несколько раз. Я не видел, что он печатает. Фил спросил меня, почему на каждую клавишу я поместил по несколько букв. Он был доволен, но прямолинеен. Кажется, Шиллер решил, что моя клавиатура выглядит странно и что это требует объяснений.

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

Фил не был доволен и сказал об этом. На этом все и кончилось. Я был удивлен, что все произошло так быстро. Презентация завершилась буквально за две минуты.

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

Пару дней спустя мы со Скоттом повторили показ демоверсии Тони Фаделлу, руководителю подразделения iPod. Раньше я никогда не встречался с Тони, но я и не должен был знать его, учитывая его занятость. Подойдя к столу в конференц-зале, где лежал прототип телефона с моей клавиатурой, он едва на нее взглянул. Не задал он и никаких вопросов. Тони попробовал мое программное обеспечение, но смог напечатать всего пару слов. Показ демоверсии получился еще короче, чем с Филом, и через минуту они со Скоттом уже ушли вместе на закрытое совещание, оставив меня в конференц-зале одного, убирать Mac, Wallaby и соединяющие их провода.

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

У меня не было ощущения, будто я подвел Скотта. Во время показа программы руководителям серьезных ошибок в ней не было. Пытаясь «переварить» обратную связь и решить, что делать дальше, я вспомнил появление черного прямоугольника во время работы над Safari. Этот прорыв не означал окончание работы, он предвещал начало. Взбудораженные тем, что наш браузер впервые отобразил небольшую частичку веб-страницы, мы понимали, что означает это историческое для проекта событие. Я начал воспринимать свою победу в дерби с клавиатурой подобным же образом, как успешное прослушивание, а не как проходящий с аншлагами концерт.

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

Шли недели, я делал демоверсии одну за другой, пробуя новые идеи, чтобы улучшить впечатления от набора текста. Я добавлял слова в словарь. Я экспериментировал с отображением предлагаемого слова на клавише «пробел». (Это была дополнительная подсказка: программа вставит это слово, если вы нажмете пробел.) Поскольку кабинет Ричарда Уильямсона был рядом с моим, я часто заглядывал к нему, звал его в свой кабинет и предлагал взять Wallaby, чтобы он мог опробовать мои последние идеи. Он всегда давал на них конкретные отзывы. Больше слов в словаре – хорошо. Подсказка слова на клавише «пробел» – не очень хорошо.

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

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

Эта схема хорошо работает для обычных слов, и чем больше их я вводил в словарь, тем лучше он работал.

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

С необычными словами была такая же проблема. Что, если вы хотите специально написать какую-нибудь белиберду? Это случается гораздо чаще, чем вы можете подумать. Каждый год 19 сентября проводится Международный день пиратов³⁵. В этот веселый праздник люди чаще всего хотят написать одно слово: Arrrrr! Конечно. А как вы его будете писать правильно: Arr? Arrrr? Aarrrr? Aarrrrr? Для того, чтобы люди могли легко и удобно печатать, как пираты, мне нужно было добавить все варианты этого Arr! в словарь, поскольку сама «сообразить» клавиатура не могла. У нее не было никаких встроенных знаний по английскому языку. Она не могла приходить к умозаключениям или составлять себе представление о каких-то вещах. Клавиатура могла предложить слово, только если оно точно совпадало с тем, что было внесено в словарь.

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

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

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

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

Но, прежде чем я успел придумать, как набирать личные имена или пиратские крики, возникла более серьезная проблема. Используя мою клавиатуру в течение нескольких месяцев после дерби, коллеги по проекту Purple обнаружили, что они путаются, когда набирают слова по буквам. Что-то нарушало обычные процессы мышления и набора. Сотрудники рассказывали, как они начинают печатать слово, а где-то посередине теряют нить мысли. Я и понятия не имел, в чем состоит проблема или почему это, кажется, чаще случается с моей клавиатурой, чем с клавиатурой настольного компьютера или ноутбука. Когда возникало такое замешательство из-за экранной клавиатуры, лучше всего было остановиться, стереть наполовину написанное слово и начать набирать его сначала. Когда стало ясно, как часто моим коллегам приходится прибегать к этому методу, я перестал волноваться о том, как напечатать Теему или Arrrrr! Мне надо было разобраться, что запутывало людей. Проведя небольшое расследование, я выяснил что происходит.

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

Вот пример. Я начинаю печатать слово aluminum (алюминий), но тут что-то отвлекает меня на секунду – скажем, коллега приглашает выпить кофе. Предположим, до того, как меня отвлекли, я ввел пять букв. Когда я снова сосредоточился и вернулся к набору, я должен спросить себя: «Где я остановился? Какая буква будет следующей?» Надеясь получить подсказку, я смотрю на строку с предложениями – узкий прямоугольник, расположенный непосредственно над клавиатурой, где отображаются возможные варианты из словаря. Программа предлагает мне слово slimy (слизистый).

Это ничем не поможет, но slimy – это действительно самое подходящее слово из словаря для первых пяти клавиш, которые я должен был нажать, чтобы набрать слово aluminum. Это не было ошибкой программы. Мало того, клавиатура не давала подсказки о том, какую клавишу мне нужно нажать следующей, чтобы получить нужное слово. Возможно, я хотел продолжить набирать слово aluminum, но было трудно сообразить, какую букву я должен написать на том месте, где прервался. Какая буква является шестой в слове aluminum? Это на удивление трудный вопрос, и при том, что клавиатура предлагала неправильное слово, проще было стереть все, что есть, и начать заново. Я хотел aluminum, но получил slimy. Техническая трагикомедия.

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

• Мы не можем вводить необычные личные имена, такие как Теему.

• Мы не можем вводить необычные слова, такие как Arrrrr!

• Мы теряемся во время набора текста – проблема «А где я остановился?»

Каждый день мои коллеги по команде обновляли программное обеспечение клавиатуры, загружая его на свои прототипы Wallaby и пробуя в деле. В сфере высоких технологий есть специальный термин для ежедневного использования и оценки вашего собственного продукта, находящегося в стадии разработки – dogfooding («пробовать собачью еду»). Мне самому это слово никогда не нравилось, и оно не соответствовало вкусам Apple. Корм для питомцев – это не то, что обычно воспринимается как апофеоз разработки программного обеспечения. В команде Purple мы пытались сделать для людей отменные продукты, и, хотя внутри компании иногда говорили о «собачьей еде», в официальных ситуациях мы чаще употребляли словосочетание living on («пожить»), чтобы описать процесс использования нами находящегося в разработке ПО, как будто оно было реальным продуктом.

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

В начале 2006 года, примерно через три месяца после дерби с клавиатурой, десяток человек из нашего проекта собрались в переговорной «Между», чтобы отчитаться об успехах перед Скоттом Форсталлом и еще несколькими программистами и менеджерами. Был там и Грег Кристи, а также несколько разработчиков из команды HI. Скотт опробовал находящиеся в разработке функции программного обеспечения Purple. Держа Wallaby в руке, он набирал текст. Мы не занимались именно клавиатурой, но тут Скотт запутался, печатая слово средней длины national.

Нажав четыре клавиши nm as rt yui, Скотт поднял глаза и увидел в строке подсказки Mary. Его это несколько выбило из колеи, но он оправился достаточно быстро, чтобы нажать следующую клавишу op. Но, снова посмотрев в строку подсказки, Форсталл увидел Mario. Теперь он был полностью дезориентирован. Он и понятия не имел, куда нажимать дальше. Скотт вляпался в проблему «А где я остановился?» Он сказал о том, как чувствовал себя, когда единственным способом, чтобы набрать слово, которое он хотел, было остановиться, все стереть и начать заново. Другие, конечно, его поддержали. Я уже слышал подобные отзывы. Теперь, когда мы собрались вместе, мы начали штурмовать эту проблему всей группой.

Я вышел к белой доске и нарисовал схемы, где было показано, как при наборе слова national могло получиться Mary и Mario. Я объяснил, почему это имеет смысл. Ранее я рассказывал о двух других главных проблемах, возникших в победившем в дерби дизайне. Я упоминал, что в то время, как Mary и Mario были досадными препятствиями на пути к тому, чтобы набрать national, написать менее распространенные имена, такие, как Теему, может вообще оказаться невозможным, поскольку их нет в словаре. Я изложил свои соображения: мы никогда не сможем добавить в словарь имена всех людей в мире. Также я упомянул о трудности с тем, чтобы набрать Arrrr! и о том, что мы никогда не сможем добавить в словарь всю важную околесицу, которую люди могут захотеть напечатать.

Описав эти проблемы, я вернулся к обзору четырех основных концепций, которые легли в основу работы моей клавиатуры.

1. Крупные клавиши, на которых расположено по несколько букв.

2. Раскладка QWERTY.

3. Все используемые жесты – это касание.

4. Словарь, обеспечивающий активное содействие.

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

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

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

– Ооооо, да кончай же, Кен! Неужели ты не можешь просто разместить по одной букве на каждой клавише?

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

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

– Да, возможно, кое-что я смогу сделать, – ответил я Грегу.

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

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

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

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

Еще одно отличие появилось благодаря идее, которая пришла мне в голову, когда я стоял у белой доски в конференц-зале. На концептуальном уровне она была связана с тем, чтобы создать клавиатуру как средство, с помощью которого люди будут сообщать устройству свои намерения, и сконструировать программное обеспечение так, чтобы оно могло понимать эти намерения. Это важный принцип для пользовательских интерфейсов сенсорных экранов, и я еще вернусь к обсуждению этой идеи в следующей главе. Чтобы извлечь выгоду из предложения Грега разместить по одной букве на каждой кнопке, у меня появилась идея: печатающий человек и код автоисправления не должны воспринимать клавиатуру одинаково. А на победившей в дерби клавиатуре было именно так: группировка букв на клавишах была одинаковой как для того, кто печатает, так и для программного обеспечения. Например, буквы QWE всегда были вместе. В новой раскладке, на которую вдохновил меня Грег, каждая буква располагалась на отдельной клавише, сама по себе, но если речь шла о коде автоисправления, то приобретала новый набор соседей. Скажем, буква F больше не была заперта в наборе DF. Для того, кто набирает текст, была точно определенная клавиша F, но для кода автоисправления F была частью настраиваемой группы FDGRTC, где F находится в центре, а соседи – справа и слева, вверху и внизу. С точки зрения автоисправления, клавиши на самом деле стали больше, хотя человеку, который набирает текст, они визуально казались меньше.

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

Для человека, который набирает текст, клавиши на клавиатуре, расположенной слева, уменьшились в размере по сравнению с победившей в дерби клавиатурой. Программа автоисправления воспринимает клавишу F как гораздо более крупную, поскольку нажатие в области D, G, R, T или C может привести к автоматическому исправлению на F, но может закончиться и выбором одной из этих букв. С точки зрения автоисправления, все клавиши увеличились подобным образом, и их пересечение показано на примере соседних с F букв. Программе автоисправления предстоит решить, какую именно из этих букв вы имели в виду

Это стало еще одним важным этапом в разработке клавиатуры и решением для всех моих давнишних проблем. Клавиши, на каждой из которых было по одной букве, позволяли избежать проблем с вводом имен и необычных слов. Поскольку вы можете нацелиться на отдельную букву, вы свободно можете написать что угодно. Даже если вам и придется быть более осторожными, вы можете печатать медленнее и обращать больше внимания на буквы, когда они подсвечиваются на экране^[26]. Если вы будете следить за этим и всегда нажимать на правильную клавишу, то сможете написать все, что угодно, даже те слова, которых нет в словаре. Еще лучше было то, что переход к расположению букв по одной на клавишу решал проблему «А где я остановился?» Поскольку я всегда отображал конкретную последовательность нажатых клавиш, вы могли посмотреть на них и понять, где прервались. Если вас прервут при наборе слова aluminum, вы больше не увидите slimy.

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

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

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

Когда я перешел от этого автоматического подбора слов на придуманную Грегом раскладку QWERTY, у которой на каждой клавише было по одной букве, после нажатия пробела появлялись именно те знаки, которые вы ввели, те, которые подсвечивались, когда вы их нажимали. Предложения из словаря оставались видимыми в специальной строке, а лучшее из них находилось слева. То, что вы напечатали, появлялось справа. Тем не менее, чтобы воспользоваться предложением из словаря, требовалось коснуться слова в строке предложений, а не нажать пробел. В конце набора слова вам приходилось останавливаться, поднимать глаза на буквы, которые вы на самом деле напечатали, нажимать пробел, если все правильно, или нажимать слово, чтобы изменить набранное на то, что предлагает помощник. Это изменение модели взаимодействия казалось правильным: я словно возвращал все права на управление тому, кто набирает текст. Если вы хотите написать: Arrrrr! то можете это сделать легко и просто. В этом и была суть идеи размещения по одной букве на каждую клавишу. Если вы нажимаете на пробел, то получаете именно те буквы, которые набрали.

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

Как и раньше, я каждый день продолжал обсуждать клавиатуру с Ричардом Уильямсоном, и мы начали говорить об уничтожении этих «лежачих полицейских». В первую очередь, мы подумали о том, чтобы значительно улучшить словарные подсказки. Обычная схема набора стала такой: набрать слово, нажать на подсказку, чтобы получить лучший вариант из словаря, набрать слово, нажатьна подсказку и т. д. Снова, снова и снова. Мы подумали, что, возможно, нужно изменить порядок: нажатие пробела должно было стать для программы сигналом, чтобы сделать выбор. Что если клавиатура будет автоматически вводить лучший вариант из словаря, когда вы нажмете пробел, это придаст ей сходства с победившим в дерби вариантом. Это означало, что вам, возможно, придется нажать на слово в строке предложений, если нужно не то, что предлагает словарь. Однако в процессе обсуждения нам стало ясно, что это правильная идея, потому что тогда вам придется нажимать на подсказку, только если вы хотите напечатать Arrrrr! или другое редкое слово. Также мы опасались, что клавиатура будет часто предлагать не те слова, которые вы пишете, то есть слово, появившееся после нажатия пробела, не будет соответствовать именно тем клавишам, которые вы нажимали. Не станет ли это проблемой? Мы не знали, но думали, что такой способ поможет решить заминку со скоростью. Ричард предложил мне попробовать, и ради интереса я согласился.

Он ушел из моего кабинета, я написал код, и через полчаса у меня была новая демоверсия клавиатуры QWERTY, которая автоматически подставляла лучший вариант из словаря при нажатии на пробел.

Я снова позвал Ричарда к себе. Он взял Wallaby с моего стола, чтобы попробовать, решает ли нововведение проблему со скоростью набора. Ричард опустил голову и начал быстро стучать по сенсорному экрану. Он печатал большими пальцами так быстро, как только мог. Он печатал, печатал, печатал. Он не делал пауз и не поднимал голову, чтобы посмотреть, как у него получается. Он доверял программе. Закончив длинное предложение, он поставил точку, а потом посмотрел, что у него вышло.

Все в точности, как он собирался написать. Ричард внимательно посмотрел на текст еще раз, тщательно изучая каждое слово. Он хотел удостовериться, что видит действительно безошибочно набранный текст. Он показал экран мне. Взглянув друг на друга, мы расхохотались. Мы не могли поверить своим глазам: словарь отлично сумел все исправить! Ричард только что печатал на Wallaby быстрее, чем кто-либо еще до этого.

Подождите… подождите… секундочку! На какой-то момент мы засомневались. Было ли это на самом деле? А может быть, Ричард просто очень аккуратно печатал?

Нет. На подсоединенном к Wallaby Mac сохранился лог-файл, и он показывал, что в действительности Ричард печатал ужасно неточно, это была совершенная чепуха, словно речь пьянчуги, который никак не может пройти тест на алкогольное опьянение в письменной форме:

Tge quixk brpwm foz jimprd ivrr rhe kazy.

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

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

За все время моей работы в Apple появление черного прямоугольника было одним из двух моментов, когда мне хотелось крикнуть: «Эврика!» Тот эпизод, о котором я только что рассказал, был вторым. За эти годы я сделал много демо, но та, из-за которой мы смеялись, была лучшей. Реакция Ричарда, веселый смех, головокружение, охватившее нас обоих в момент открытия нового программного обеспечения, которое, возможно, означало огромный шаг в правильном направлении. То, что надо внести эти изменения в нашу клавиатуру, мы решили легко и быстро.

Много месяцев спустя, когда мы уже представили наш новый смартфон публике, но еще не начали продавать клиентам, те из нас, кто состоял в команде разработки ПО, стали использовать последние прототипы как обычные телефоны. Однажды ко мне зашел Нитин Ганатра, еще один администратор программного обеспечения проекта Purple, отчитывающийся перед Анри. Он был равен по рангу Ричарду и отвечал за такие приложения, как SpringBoard и «Почта». Нитин зашел, чтобы задать какой-то обычный рабочий вопрос, ничего срочного, и, входя, он держал в руке шоколадный батончик. Мы поговорили примерно минуту, а потом разговор перешел на набор текста. Нитин вытащил телефон из кармана. Держа прототип в левой руке, он вывел на экран последнюю на тот момент версию моей клавиатуры – прямого потомка кода демоверсии, которая заставила нас смеяться. Нитин начал печатать. Он даже не потрудился убрать свой батончик и положился на мой улучшенный код автоисправления, используя при наборе только средний палец на правой руке и большой на левой. Надорванная обертка шоколадки шуршала при каждом движении. Затем Ганатра повернул ко мне экран, чтобы я мог увидеть идеально набранный текст. Я уже забыл, что именно он написал, помню только его одобрительный кивок.

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

Может ли это действительно воплотиться в реальность? Внесет ли автоисправление в это вклад? Неужели мы с нашей клавиатурой наконец были на правильном пути?

А что насчет раскладки QWERTY? Была ли она правильным выбором? Возможно, вы знаете, что название QWERTY – это акроним, образованный первыми буквами в верхнем ряду слева на клавиатурах для многих языков, использующих латиницу, и то, что мы в конце концов взяли эту самую популярную раскладку для наших смартфонов³⁶, не было заранее принятым решением. Как я уже говорил, в процессе разработки прототипов мы пришли к QWERTY достаточно поздно. Сначала мы рассматривали много других вариантов. Тем не менее мы вернулись к наиболее популярному дизайну клавиатуры.

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

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

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

Это подводит к следующему вопросу: а что такое хороший вкус? На этот счет у меня есть собственное мнение, о котором я расскажу вкратце, но также я прекрасно понимаю, что я не первый поднял эту тему. Иммануил Кант много писал о вкусе, но его «Критика способности суждения» не является практическим руководством по разработке продукта. Если один из моих коллег усомнится в раскладке QWERTY для клавиатуры Purple из-за вкуса, цитата из труда немецкого философа не поможет: «Само суждение вкуса не постулирует согласия каждого (ибо это доступно только логическому общему суждению, поскольку оно способно привести для этого основания), оно только предполагает в каждом это согласие как частный случай, подтверждения которого оно ожидает не от понятий, а от согласия других»^[29].

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

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

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

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

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

Не всегда просто думать об идеях или объектах и принимать активное участие в здоровом и продуктивном творческом процессе, пока вы не в состоянии объяснить, почему именно они вам нравятся или не нравятся. Это требует вдумчивой вовлеченности.

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

Прошлое – это вечный и не иссякающий источник. Именно здесь мы возвращаемся к словам Канта, говорящим, что философия играет важную роль в творческой работе. Я могу использовать Канта, но только если я знаю о нем и только до той степени, до какой я усвоил то, что он сказал. Важно, какое значение это имеет для меня. То же самое относится и к любым творческим достижениям: и к картинам Фриды Кало, и к блюзу преподобного Гэри Дэвиса, и к теории Чарльза Дарвина, и к философии Лао Цзы, и к идеям об оптимизации программного обеспечения Дональда Кнута, и к вере и обрядам древних греков, идущих к Дельфийскому оракулу. Когда я изучаю прошлое, я выбираю, на что опереться, чтобы решить, что мне нравится. И иногда этот созданный в прошлом каталог непосредственных откликов на предыдущие работы очень естественно отражается в моей сегодняшней работе.

Как все это связано с QWERTY? Эта раскладка клавиатуры является частью нашего культурного наследия, пусть даже и не такого возвышенного, как философские рассуждения Канта о вкусе. Куда более важно то, что давняя популярность QWERTY означает, что люди привыкли к ней. Вспомните мою демоверсию, которую я показал Ричарду. Поскольку он знал, где находятся клавиши на клавиатуре QWERTY, он смог прийти в мой кабинет, взять Wallaby и набрать те слова, которые хотел, совершенно не задумываясь. За несколько десятилетий QWERTY отпечаталась в мускульной памяти Ричарда. Он подсознательно знал, как печатать. Его ментальная карта QWERTY легко перешла от печати десятью пальцами на полноразмерной клавиатуре к набору большими пальцами на сенсорном экране. На мой взгляд, если брать точку зрения разработчика продукта, я не мог предложить Ричарду ничего лучше, чем использовать те навыки, которые, как я знал, у него уже есть. С его точки зрения пользователя, другое расположение клавиш не было бы так легко использовать без подготовки.

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

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

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

Прежде чем я перейду к обсуждению третьей составляющей вкуса, я хочу упомянуть одну характеристику, которая, кажется, ускользнула из моего общего определения вкуса, – понятие красоты. Я пропустил ее не случайно. Создание программного обеспечения и продуктов, которые выглядели бы красивыми визуально, имеет собственные пределы. Однажды Стив Джобс сказал: «Дизайн – это то, как он работает». Это мое самое любимое высказывание из всех, что я от него слышал. Полностью суждение, с помощью которого Стив в интервью 2003 года для «Нью-Йорк Таймс» втолковывал другим свою точку зрения и где обсуждался iPod, было таким:

Большинство людей делают ошибку, считая, что дизайн – это то, как он [продукт] выглядит. Люди думают об этой внешней оболочке, полагают, что разработчикам вручают эту коробочку и говорят: «Пусть она выглядит привлекательно!» Мы иначе смотрим на дизайн. Дизайн – это не то, как продукт выглядит и воспринимается. Дизайн – это то, как он работает³⁸.

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

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

Если бы в результате какой-то мировой катастрофы все накопленные научные знания оказались уничтоженными и к грядущим поколениям живых существ перешла только одна фраза, то какое утверждение, составленное из наименьшего количества слов, принесло бы больше всего информации? Я считаю, что это – атомная гипотеза… все тела состоят из атомов… В одной этой фразе, как вы убедитесь, содержится невероятное количество информации о мире, стоит лишь приложить к ней немного воображения и чуть соображения³⁹.

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

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

Итак, является ли клавиатура QWERTY привлекательным и всеобъемлющим целым? Соблюдается ли в ней равновесие и достаточно ли она приятна? Работает ли этот дизайн? Ответ на эти вопросы дали прошедшие годы. Клавиатура QWERTY с автоисправлением не «утопила» iPhone, как это сделало с Newton распознавание рукописного ввода. Все было наоборот.

Теперь печатать двумя большими пальцами на экране сенсорного телефона – это норма. Это то, что по умолчанию есть в любом мобильном устройстве.

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

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

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

8. Конвергенция

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

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

И тут – оба-на! Гадостный сюрприз, который преподнесло мне автоисправление во время презентации, бросил корабль моей программы на острые скалы.

Через несколько дней после того, как Ричард впервые набрал текст с неожиданной точностью, которая стала возможной только благодаря включенному автоисправлению, я пришел в кабинет к Анри Ламиро, чтобы дать Скотту Форсталлу попробовать поработать с новым программным обеспечением. Я установил свою демо, присоединил Wallaby к Mac, стоящему на боковом столе рядом с рабочим местом Анри. Пришел Скотт, сел, взял Wallaby и набрал какой-то текст. Я смотрел через его плечо, когда он писал первые слова. Форсталл был под впечатлением. Пока что все шло хорошо. Я использовал эту возможность, чтобы привести ему свои аргументы в пользу постоянно включенного автоисправления. Я сказал, что именно так мы сможем обеспечить отличный набор текста на Purple, что это решает все проблемы, от которых страдала победившая в дерби клавиатура, и поможет нам избежать печальной участи Newton с распознаванием рукописного ввода.

Слушая меня, Скотт уловил упоминание о Newton и решил повеселиться, вспомнив превратившийся в культовый комикс «Дунсбери».

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

Я хорошо разбирался в связанном с Newton фольклоре и точно знал, что Скотт хотел написать. Он хотел egg freckles («яйца в крапинку»), но этого не получил. Моя клавиатура завалила тест.

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

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

Вскоре я обнаружил проблему. Скотт не смог набрать egg freckles, потому что две ошибки в работе словаря наложились одна на другую.

Первая была багом в метаданных, которые я приписал к каждому слову в словаре. Их я называл значением частоты использования. Она измеряла популярность слова в обычном тексте. Для того, чтобы постоянно включенное автоисправление работало хорошо, нужно было, чтобы код помогал людям набирать самые распространенные в английском языке слова: the, and, have, from, will и так далее. Программное обеспечение должно было знать, какие слова встречаются чаще других – например, люди с большей вероятностью напишут good (хороший), а не goof (оплошность). Отсюда следует, что значение частоты использования для good выше, чем для goof. Артикль the имеет самую высокую частоту использования, поскольку является самым распространенным словом в английском языке. Как редактор словаря я должен был оценить каждое слово с точки зрения частоты использования и присвоить более популярным словам более высокие значения, чем у менее употребительных. Также клавиатура помогала с повседневными словами, такими как egg (яйцо), которое входит в несколько тысяч самых употребительных английских слов (вместе со словом bacon – бекон). На самом деле, программа должна была помочь Скотту написать слово egg, и она бы помогла, но возникла одна проблема: значение частоты использования слова было по ошибке занижено так сильно, что значение достаточно редкого и не слишком приличного слова eff (совокупление) оказалось выше. Это был просто глюк в моей базе данных словаря, и мое расследование кончилось, как только я понял, что значение частоты использования выставлено неверно. Я вздохнул, исправил значение для egg и несколько раз пробормотал eff себе под нос, пока этим занимался.

Что же насчет freckles (крапинки)? Этого слова вообще в словаре не было. Я не мог этого объяснить. Когда клавиатура увидела freckles и не смогла найти совпадающую с ним словарную статью, мой код решил, что это слово не является английским. Поэтому код автоисправления заменил написанное Скоттом на то, что нашлось в словаре: grackles (гракл), распространенная североамериканская птица, Quiscalus quiscula.

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

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

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

Демоверсия eff grackles подчеркнула важность качества данных. Во время показа программы Скотту с моими алгоритмами все было в порядке. Ошибка скрывалась в словаре. Чтобы исправить ее, я должен был удостовериться, что все употребляемые в повседневной жизни слова, такие как egg, имеют правильную частоту использования. Мне пришлось тщательно присваивать значения словам с похожим написанием, особенно тем, в которых буквы находятся рядом в раскладке QWERTY, например tune (мелодия) и time (время). Поскольку отсутствующие слова, такие как freckles, могли привести к глупым ошибкам, я также проверил словарь на то, чтобы в него входили все несколько тысяч самых распространенных английских слов.

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

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

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

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

Если вы хотели написать слово cold (холодный), но напечатали colf, вы можете представить себе, как четвертый рычажок «переключается» на другую букву, чтобы получилось желаемое слово. Основная идея, стоящая за автоисправлением, – это поиск лучшей комбинации букв с учетом нажатых клавиш и оценка букв, находящихся по соседству с ними. Поскольку в раскладке QWERTY D находится около F, программа может автоматически исправить colf на cold.

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

• Распределить нажатые клавиши в ряд переключений с соседними буквами.

• Прокрутить рычажки, чтобы проверить каждую комбинацию букв.

• Отметить в словаре слова, найденные при прокручивании рычажков.

• Предложить найденное слово с самым высоким значением частоты использования.

Первоначально я разработал этот алгоритм для моей победившей в дерби клавиатуры, и он хорошо себя показал, когда на каждую клавишу приходилось по несколько букв. Также он был хорошим решением, когда все мы в команде Purple только начинали осваивать печать на сенсорном экране. Месяцы спустя, когда клавиатура QWERTY с одной буквой на каждой клавише заменила прошлую и все стали делать гораздо больше ошибок в каждом слове, поскольку клавиши значительно уменьшились, простого подхода с переключателями было уже недостаточно. Он мог надежно заменить одну неверную букву в широко употребительном слове, как в моем примере с colf и cold, но гораздо хуже показывал себя, если вы печатали что-то вроде vild, так как не мог понять, что вы хотели написать – cold, bold (жирный) или vile (подлый). У меня не было хороших идей, как ответить на этот вопрос, а также хороших идей по улучшению моего кода «велосипедного замка». Я отправился на поиски помощи.

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

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

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

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

В конце концов, эти технические разговоры больше вдохновили меня, чем напрямую повлияли на мои алгоритмы. Честно говоря, бо́льшая часть подобной математики была мне недоступна. У меня нет инженерной подготовки – на самом деле, в колледже я не взял ни одного математического курса. Если когда-либо и был какой-то довод в пользу того, чтобы продолжать изучение этого предмета после окончания старшей школы (ведь никто не говорил мне, что математика может мне понадобиться), то это был как раз он. Я пытался прыгнуть выше своей головы.

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

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

Я предположил, что, если я хочу нажать клавишу G, но палец попадает налево и нажимает на F, с большей вероятностью я имею в виду G или F, а не H. Другими словами, если я попадаю по клавише, в которую не целился, то та, которую я намеревался нажать, скорее всего, будет следующей ближайшей к ней. Я встроил направление этих пропусков в свой алгоритм.

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

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

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

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

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

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

Я представил, насколько мне надо «подвинуть» каждую из точек на рисунке схемы набора, чтобы она выглядела в точности так же, как идеальный образец из словаря. Для каждого сравнения схем я добавил все «сдвиги». Самым близким совпадением было то, которое требовало меньше всего подвижек. К счастью для меня, расчет всех «сдвигов» можно было сделать, опираясь на элементарную школьную математику. Это было как наложение сетки на карту города и подсчет улиц и проспектов, которые мне нужно пройти, чтобы добраться из одного места в другое, – то, что иногда называют манхэттенским расстоянием, или расстоянием городских кварталов^[33].

На рисунке можно увидеть, что идеальная схема для слова blot (пятно) для первых трех букв совпадает со схемой для слова blog, но для последней буквы требуется куда более значительный сдвиг. Степень совпадения со словом blot меньше, чем со словом blog, следовательно, я могу предположить, что, скорее всего, тот, кто набирал текст, имел в виду последнее слово, а не первое

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

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

1. Представить нажатые клавиши как ряд переключений с соседними клавишами.

2. Провернуть рычажки, чтобы проверить все комбинации букв.

3. Отметить словарные слова, появляющиеся при прокручивании рычажков.

4. Рассчитать схему отклонения для каждого найденного слова.

5. Добавить значение частоты использования для каждого найденного слова во взаимодействии со схемой отклонения.

6. Из всех найденных слов предложить одно с самым большим значением с точки зрения частоты использования и схемы отклонения⁴⁰.

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

В то время как алгоритм отклонения от схемы становился все лучше, наверх моего списка дел перемещались другие задачи. Они были связаны с тем, где будет задействована клавиатура: для заполнения однострочных полей в таких приложениях, как «Контакты», и в многострочных текстовых областях таких приложений, как «Заметки». Я писал код для этих пользовательских виджетов, используя как основу свою работу с текстовым редактором WebKit. Пополнение словаря тоже нельзя было полностью отставить в сторону, и я продолжал им заниматься, добавляя новые названия продуктов Apple, например, Xserve, и такие тонкости, как автоматическое добавление апострофа в cant, что превращало слово в can’t.

Я продолжал улучшать клавиатуру, и со временем при печати возникало все меньше и меньше глупых ошибок.

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

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

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

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

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

Испытывали ли мы на себе давление, заставляющее быстрее заполнить подобные пробелы в нашей системе? Да. Я справлялся с ним, контролируя и регулируя свое рабочее время. Если я не уставал, то мог сопротивляться стрессу. По крайней мере, бо́льшую часть времени. Например, однажды, когда у меня с коллегой появились разногласия по поводу решения технической проблемы, связанной с клавиатурой, а в мой код все еще вносились изменения, я сорвался и заорал на него: «Пошел ***** [к черту] из моего кабинета!»

Еще один инцидент произошел с Ким Воррат, которая делала напряженную работу, балансируя между расписанием работ и постоянной оценкой рисков, связанных с нашим продвижением вперед. Однажды вечером Ким разозлилась и так хлопнула дверью своего кабинета, что сломала механизм замка и оказалась запертой внутри. Чем она была так расстроена? Достаточно точный ответ будет такой: ежедневной утомительной работой над Purple. Какая-то незначительная проблема заставила ее взорваться. Скотт Форсталл вызволил Ким из кабинета, сломав дверную ручку алюминиевой бейсбольной битой.

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

Время шло, и к осени 2006 года программное обеспечение Purple перешло на этап конвергенции. Мы все приближались к той системе программного обеспечения, которую Apple будет продавать вместе со своим устройством.

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

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

Ким держала в руках телефон Purple, к которому не были присоединены никакие провода, ведущие к компьютеру Mac. Реальный телефон, предназначенный для промышленного выпуска. Настоящий стеклянный экран, а не пластиковый дисплей Wallaby. Ранее я никогда не видел ничего подобного, а это была не просто модель. Это был работающий телефон. Аппарат был заряжен, и на нем работало все загруженное программное обеспечение. Держа в руках этот прототип последней версии, Ким указала, что есть еще несколько аппаратных компонентов, которые не закончены, и, поскольку они немного больше по объему, чем те части, которые мы будем производить, верхняя и нижняя части телефона не совсем смыкаются в левом нижнем углу. Щель была совсем маленькой, два или три миллиметра. Телефон Purple находился на этапе конвергенции, но она еще не была завершена полностью.

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

Я несколько раз покачал аппарат из стороны в сторону, чтобы насладиться свободой движений без кабеля, подсоединенного к Mac. Опыт использования Wallaby оставлял ощущение привязи к стоящему на столе компьютеру с раскиданными повсюду проводами. Теперь, положив телефон в карман, я впервые ощутил, каково будет им пользоваться.

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

Я хотел такой.

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

Дата объявления о новом продукте уже была внесена в календарь, и мы шли к ней бо́льшую часть предыдущего года. Планы выпуска были согласованы с ходом работ по программному и аппаратному обеспечению. Apple сообщит миру о Purple на конференции Macworld в начале января 2007 года, а первые телефоны должны поступить в продажу в следующем июне.

Это означало, что у меня есть время исправить еще несколько ошибок и добавить в словарь несколько слов до того, как люди коснутся пальцами клавиатуры. Режим секретности сохранялся до последнего момента, и даже когда я шел в Москоне-центр в назначенный день, я по-прежнему не знал, как будет называться Purple. 10 января, на следующий день после презентации флагманского продукта, я отредактировал словарь автокоррекции, добавив в него новое слово – iPhone***.

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

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

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

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

Дон Мелтон часто рассказывал историю о том, как происходила конвергенция в Netscape. Когда компания, где он работал раньше, готовилась выпустить новую версию браузера Navigator, ее сотрудники не ставили себе цели свести количество ошибок к нулю. Руководители программистов Netscape знали, что ни одна сложная программа никогда полностью не будет свободна от ошибок. Вместо этого они стремились к zarro boogs – намеренно искаженному выражению zero bugs (ноль ошибок). Эта фраза в юмористическом ключе выражает признание в том, что проект считается «законченным» к дате выпуска, но в действительности программисты не подошли к недостижимому идеальному коду без ошибок, несмотря на то, что может показывать запрос к базе данных ошибок или график конвергенции⁴¹.

Это соотношение между исправлением ошибок и датами выпуска вызывает вопрос. Если конвергенция была в центре внимания команды Purple в последние несколько месяцев перед объявлением о выходе iPhone, то не объясняют ли методы конвергенции, почему этот телефон оказался так хорош?

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

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

Вскоре я больше расскажу об идеях, которые делают подход компании Apple особенным, но вначале хочу обсудить противоположный случай – привести пример процесса, с помощью которого невозможно добиться присущего iPhone совершенства. Для этого я обращусь к Дугласу Боуману – дизайнеру, в резюме которого работа на Twitter и Wired. Он также начинал в Google в 2006 году, став одним из главных специалистов компании по визуальному проектированию^[34]. Вот как он объяснил свой уход из компании, занимающейся интернет-поиском, после трех лет работы в ней:

Если на самом верху (или около него) не будет человека, полностью понимающего принципы и элементы дизайна, у компании в конце концов не станет обоснований, чтобы принимать связанные с дизайном решения… Если нет убежденности, подкрадываются сомнения. Инстинкты отказывают… Когда в компании полно программистов, принятие решений перекладывается на их плечи. Сведите каждое решение к простой логической проблеме. Уберите всю субъективность и опирайтесь только на данные. Данные говорят в вашу пользу? ОК, запускайте это. Данные говорят об отрицательных результатах? Возвращаемся к чертежным доскам. И эти данные в конце концов становятся опорой для каждого решения…

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

Сорок один оттенок голубого – кажется, это действительно много, но, если они в Google хотят зайти так далеко, почему бы не протестировать сотню оттенков? Или тысячу? Если некоторое количество данных – это хорошо, то чем их больше, тем лучше, правильно? Но Боуман предполагает, что это не так.

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

В Apple нам и в страшном сне не могло такое привидеться. Мы никогда не устраивали А/В-тестов для какого-либо программного обеспечения iPhone. Когда дело доходило до выбора цвета, мы брали один. Мы использовали наш хороший вкус и наши знания о том, как сделать ПО доступным для людей с проблемами зрения, связанными с восприятием цвета, и двигались вперед.

Или мы не так делали? И да, и нет. Мы всегда быстро делали выбор насчет мелких деталей, но всегда могли изменить принятые ранее решения. Мы тратили много времени на крупные вопросы, но никогда – слишком много. Мы всегда заботились о том, чтобы постоянно двигаться вперед. Этот урок я усвоил с первых дней разработки браузера Safari, когда мы с Доном потратили шесть недель на ерунду, а Ричард за два дня сделал демоверсию, которая потрясла нас до глубины души.

Все время двигаться вперед, к цели – вот что было ключевым подходом Apple в разработке ПО.

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

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

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

Это эволюция по Дарвину, и нет ничего удивительного в том, что сам Чарльз Дарвин был однозначно уверен в возможностях и силе влияния поэтапных изменений на череду поколений. Первую главу «Происхождения видов», прежде чем представить свою для того времени радикальную идею естественного отбора, Дарвин начал с длинной дискуссии об искусственном отборе, опираясь на знакомство читателей XIX века с животноводством:

Но когда мы сравниваем ломовую лошадь со скаковой, одногорбого верблюда с двугорбым, различные породы овец, приспособленные либо к засеянным разными культурами полям, либо к горным пастбищам, с шерстью, пригодной у одной породы для одного, у другой – для другого; когда мы сравниваем многочисленные породы собак, полезные для человека в самых разнообразных направлениях… я полагаю, что в этом надо видеть больше, чем простую изменчивость. Мы не можем допустить, чтобы все породы возникли внезапно столь совершенными и полезными, какими мы видим их теперь; действительно, во многих случаях мы знаем, что не такова была их история. Ключ к объяснению этого – способность человека к накопительному отбору: природа доставляет последовательные вариации, человек составляет их в известных, полезных ему направлениях… Это волшебный жезл, при помощи которого он вызывает любые формы жизни, какие пожелает⁴³.

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

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

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

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

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

Мы не тасовали распечатанную техническую документацию или неменяющиеся бумажные эскизы целыми неделями, ожидая гениального прозрения, которое перебросит нас прямиком от придуманной в начале пути концепции к готовому дизайну продукта, и не надеялись, что как-то сможем перескочить через соотношение вдохновения к поту, о котором говорил Томас Эдисон – то соотношение между временем, необходимым, чтобы придумать идею, и количеством тяжелой работы, которая нужна, чтобы превратить идею в нечто реальное. Я хорошо усвоил этот урок, и больше никогда за время своей работы в Apple не проводил неделю за составлением чего-то вроде того документа из пятидесяти шагов «Компилирование Lizard», о котором я рассказывал в главе 2.

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

У нас не было больших, стоящих на переднем крае современных технологий исследовательских отделов, существующих обособленно. Они работали в тесной связке с разработчиками и программистами, вместе создавая и преподнося покупателям реальные продукты. Хорошо известно, как Стив Джобс расформировал в Apple подобную организацию – группу передовых технологий – вскоре после того, как вернул себе управление компанией в 1997 году.

Подобные вредные шаблоны могут не позволить творческому отбору правильно функционировать, поскольку блокируют стабильное накопление положительных изменений во время разработки продукта. Это не всё, чем можно разрушить процесс. Вы можете создавать и выпускать продукты, так никогда и не попробовав творческий отбор, как мы делали с Nautilus и онлайн-сервисами в Eazel. Вы можете проводить показы демоверсий и прерывать их, так и не решив, что делать дальше, – ошибка, которая прерывает цепь критики, обеспечивающей логическую связь одной демоверсии с другой. Вы можете собирать раздутые команды проекта для выполнения заданий, с которым управятся один или два человека – недостаток, ведущий к путанице в коммуникации и ослаблении возможности каждого внести свой вклад. У вас могут быть конфликты в субординации, и вы никогда не сможете принять окончательное решение, которое признавали бы все. Вы можете создавать дизайн, руководствуясь тем, как изделие выглядит, что сейчас в моде или каким-то абстрактным идеалом, а не думать о том, как оно работает. Вы можете использовать А/В-тестирование, чтобы принимать простые решения, как это, очевидно, делали в Google.

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

Каким бы ни было объяснение того, почему мы начали пользоваться творческим отбором, но с каждым успешным делом становилось понятнее, что мы не зря пользуемся этим методом. Добиваясь хороших результатов, мы развивались и улучшали сам процесс. Мы взяли это прямо у Дарвина, переложив его идеи для разработки продуктов.

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

Если я расширю метафору Дарвина, то можно сказать, что творческий отбор дополнялся селекционным давлением^[35], которое мы создавали, чтобы формировать прогресс от одной демоверсии к другой на этапе принятия решения об изменениях. С самого начала у компании Apple всегда был свойственный ей здравый смысл по поводу того, что выбрать, и представление о том, какие идеи являются более убедительными, – это помогало определить условия, при которых процесс творческого отбора раскрывался во всей красе. В следующей главе я более подробно расскажу об этом направлении разработки продуктов в стиле Apple.

9. Пересечение

Когда Стив представлял iPhone, примерно на сорок первой минуте^[36] своего доклада на Macworld 2007, он переключил презентацию на слайд, где был изображен темный логотип компании Apple, за которым всходило солнце, и сказал: «Наступил день, которого я ждал два с половиной года. Каждые несколько лет выходит новый революционный продукт, который меняет всю индустрию»⁴⁵.

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

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

Название этой главы «Пересечение» говорит об идее, которая нам помогла. В ней будет рассказываться о том, как компания Apple ценит навыки и в технических, и в гуманитарных науках.

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

В отличие от творческого отбора, который так никто не называл, мы говорили о том, что «работаем на пересечении». В официальном университете Apple^[37] даже был курс по этой теме – проводимое под руководством ведущего занятие, продолжавшееся половину дня, где обсуждалось соединение технических и гуманитарных наук, трудности работы на пересечении и причины, по которым очень важно не оставлять попыток работать в этой области, поскольку именно эти усилия лежат в основе понимания компанией Apple грандиозного продукта.

Это пересечение не только свободно обсуждалось внутри компании, но – что странно для Apple – споры не прекращались и за пределами кампуса Купертино. Стив Джобс всем сообщил свое мнение по этой теме со сцены, во время презентации первого iPhone.

Причина, по которой Apple может создавать такие продукты, как iPad, состоит в том, что мы всегда стараемся быть на пересечении технических и гуманитарных наук, можем взять из тех и других лучшее. С точки зрения технологии, выпускать невероятные передовые продукты, но в то же время делать их интуитивно понятными, простыми и интересными в использовании так, что они действительно подходят своим владельцам. Не пользователи должны приспосабливаться к ним, а они к пользователям⁴⁶.

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

Эти усилия распространялись повсюду. Я хотел, чтобы клавиатура iPhone щелкала, как клавиши печатной машинки, и в конце концов добился такого звука, постукивая карандашом о край стола. На это меня вдохновила история о том, как Бен Бертт, саунд-дизайнер первой части «Звездных войн»⁴⁸, создал эффект выстрелов бластеров, записав стук молотка, когда мастер крепил провода к радиобашне^[38].

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

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

Когда летом 2005 года я пришел в команду iPhone, программное обеспечение сенсорных устройств было для меня совершенно новой областью. Когда я получил первый Wallaby, мне было в новинку писать программу, запускать ее на Mac и видеть, как графические данные приложения появляются на сенсорном экране прототипа. Я убирал руки с клавиатуры Macintosh, брал Wallaby, нажимал ярлыки, выбирал строчки в прокручиваемых списках и управлял приложениями. Это делали все члены команды Purple, проверяя, каким будет взаимодействие с ПО и изображениями на экране Wallaby при помощи пальцев.

Все члены команды программистов пытались решить собственные технические проблемы, улучшая такие приложения, как «Почта», Safari, «Заметки» и SpringBoard, и вскоре мы начали задавать друг другу один и тот же «большой» вопрос: насколько крупными мы должны делать объекты на экране, чтобы на них было легко нажимать пальцем? Цели для касания должны быть достаточно маленькими, чтобы на одном экране могло поместиться много полезного контента, но в то же время достаточно большими, чтобы вы с уверенностью могли выбрать то, что хотите. Кроме этого, у нас не было никаких особых соображений о размере экранных объектов.

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

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

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

А вот у Грега Кристи дрожали руки. Эта дрожь была особенно заметна, когда он выходил на улицу покурить. Если кто-то из нас, программистов, давал Грегу слишком маленький ярлык, по которому ему трудно было попасть, он все равно пытался, и когда попытка проваливалась, издавал свой характерный вздох – громкий, долгий, недовольный вздох истинного ньюйоркца, – чтобы выразить свое $#!&% раздражение от того, что не может использовать ту штуку, которую вы ему дали. Грег был в своем праве. Вспомните, Стив Джобс не говорил, что продукты должны расстраивать пользователя, он говорил, что они должны «приспосабливаться к пользователям».

Мы ожидали, что вариативность будет гораздо выше, чем то, что мы видели на примере Скотта и Грега. Их опыт пользования сенсорным экраном на раннем этапе разработки отличался, и это доказало, что одно из самых важных пользовательских взаимодействий с iPhone остается под вопросом: какого размера должен быть ярлык на домашнем экране?

Скотт Херц, один из моих коллег по проекту Purple, вскоре нашел ответ. Он написал приложение и дал попробовать команде. Приложение было небольшим. Оно запускалось, показывая очень крупную кнопку Start. После нажатия на нее экран на мгновение становился пустым, а потом в каком-то его месте появлялся прямоугольник. Нужно было попасть по нему пальцем. Когда вы нажали, независимо от того, попали вы или нет, после еще одной секунды пустоты где-то на экране появлялся еще один прямоугольник. Только он был другого размера: больше или меньше. Попади в коробочку. Попади в коробочку. Попади в коробочку.

Честно говоря, это было весело. Как игра. После двадцати или около того прямоугольников она заканчивалась, и приложение показывало вам ваши очки: как много было попаданий и сколько раз вы промахнулись. За кадром ПО отслеживало размер прямоугольников и их положение. Поскольку было весело играть… ммммм… в серьезную тестовую программу, чтобы собрать чрезвычайно важную информацию о возможности пользоваться сенсорным экраном, приложение Херца быстро разошлось по коридору Purple. В течение нескольких дней мы набрали информацию о размере целей и точности попадания.

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

Игра Скотта дала нам ответ, который мы искали. Ярлыки на домашнем экране первого iPhone являются квадратами со стороной в пятьдесят семь пикселей.

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

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

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

mv paper.txt folder

Чтобы отдать такую команду, вам нужно знать название программы, которая перемещает файлы – именно она скрывается под загадочным сокращением mv, – и помнить: то, что вы хотите переместить, надо указывать первым, а направление – вторым. Такой интерфейс с командной строкой делает работу с компьютером абстрактной, непонятной, интуитивно неощутимой для всех, кроме умников, считающих, что заучивать всю эту китайскую грамоту круто. У всех остальных (правильная) реакция будет такая: «Отвратительно!»

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

Apple не изобрела непосредственное управление – это сделал специалист по теории вычислительных машин и систем Бен Шнейдерман в 1982 году⁴⁹, – но Mac быстро способствовал ее популяризации. Компания с самого начала была в курсе передовых исследований по взаимодействию человека и компьютера, оценила ключевое технологическое решение, создала вокруг него систему и, начиная с января 1984 года, воплотила ее в продукт, который люди могли купить. Macintosh и мышь начали традицию Apple – использовать новые технологии, чтобы решать давние проблемы взаимодействия, и этот подход служил источником вдохновения еще многие годы.

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

Имран Чаудри был одним из первых сторонников мультитача, и именно его вдохновенный замысел позволил превратить эту новую технологию в продукт.

Группа проектирования программного обеспечения в Apple не случайно называлась командой «Человекомашинного интерфейса». В центре внимания находились люди, и больше, чем кто-то, кого я когда-либо знал, Имран верил в то, что продукты должны служить людям. Как и у многих других влиятельных людей в Apple, в работе Имрана во многом отражалась его личность. В нем была плавность, деликатная невозмутимость, которую очень трудно описать, но которую можно было мгновенно заметить при личном общении. Много лет я рассказывал жене об Имране, и, наконец, ей выпал шанс с ним познакомиться на одной из организованных Apple вечеринок в честь нашего ежегодного релиза программного обеспечения. После нее жена сказала: «Да, я вижу, что ты имел в виду, когда говорил об Имране. У него есть харизма».

Харизма. Да, у Имрана она была. Тем не менее, в отличие от Стива Джобса, самого известного и харизматичного человека в истории Apple, Имран никогда не заставлял людей краснеть и не распекал их. Напротив, он всегда говорил очень мягко. В его манере было сближаться с другим человеком. В то время как его тихий голос заставлял прислушиваться, он не имел ничего общего со стеснительностью. На самом деле Имран всегда точно знал, чего хочет, и совершенно недвусмысленно все объяснял, когда речь шла о его целях в разработке наших продуктов.

С самого начала работы над Purple у Имрана было представление о том, как должен действовать мультисенсорный пользовательский интерфейс. Чтобы показать, что он имеет в виду, скажем, группе программистов и дизайнеров Purple, Имран освобождал место на плоской поверхности стола перед ним, затем клал туда один-единственный лист бумаги и вытягивал указательный палец, чтобы коснуться середины листа. Затем он начинал двигать пальцем вместе с бумагой как единым целым, вращая лист по кругу; синхронные движения его пальца и объекта, которым он манипулировал, показывали плавность и чуткость, которых он хотел добиться от пользовательского интерфейса Purple.

– Вот, леди и джентльмены, – говорил он с мягким акцентом, сопровождая свою демонстрацию кивком головы, – так оно должно работать.

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

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

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

1. Имена семи гномов из сказки о Белоснежке.

2. Первые семь простых чисел больше десяти.

3. Семь стран Европы, названия которых начинаются с гласной.

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

Такой тест иллюстрирует концепцию, которую я уже несколько раз упоминал в этой книге: нагрузка памяти. Как известно, наша кратковременная память имеет строгие ограничения, и потребовались десятилетия исследований, чтобы понять границы когнитивных возможностей, изложенные в психологической работе «Магическое число семь плюс-минус два», выпущенной в 1956 году Джорджем А. Миллером⁵⁰, в то время работавшим в Гарвардском университете. Миллер хотел количественно измерить объем кратковременной памяти. Он обнаружил, что одновременно мы можем запомнить где-то около семи пунктов. Это все. Попытки удержать в памяти больше предметов требуют, чтобы мы начали создавать последовательности или, как говорит Миллер, «группы предметов, связанных вместе». Например, у меня нет никаких проблем, чтобы запомнить семь цветов в следующем порядке: красный, белый, синий, голубой, желтый, пурпурный, черный, поскольку первые три – это цвета американского флага, а остальные четыре постоянно используются в офсетной печати. Я легко могу сгруппировать их благодаря своей национальности и знанию типографских процессов. Даже если речь идет о случайной информации, значительно легче запомнить эти девять цифр 984–313–552, чем 847620475, просто благодаря тому, что визуально они разделены на группы с помощью тире. Тем не менее, если мы не можем заполнить ячейки нашего мозга, создав группы, когда на нас валится много информации, мы оказываемся перегружены, и, когда наша кратковременная память переполнена, начинаем делать больше ошибок и приходить к менее точным суждениям. Наша работоспособность быстро падает.

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

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

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

Например, вот снова тест со списками, только теперь его легче будет выполнить. Возьмите лист бумаги, то, чем можно писать, затем выберите одну из трех видоизмененных тем и – вперед!

1. Имена семи любых героев Диснея.

2. Первые семь простых чисел.

3. Любые семь стран Европы.

Конечно, теперь списки легче составить, но пусть вас не вводят в заблуждение придуманные условия теста в книге. Подобные возможности для упрощения всегда существуют при разработке реальных продуктов, и в Apple мы их искали. Пример тому моя история из главы 1. Когда я показал две возможные клавиатуры для iPad – раскладку с большим количеством клавиш, которую сделал Бас, и мою раскладку с более крупными клавишами – Стив Джобс понял, что мы можем исключить выбор, снизить количество пунктов, которые пользователям iPad придется держать в голове, набирая текст, и, таким образом, продукт станет проще в использовании. Только не всегда очевидно, какие именно части системы, если от них освободиться, запустят подлинный эффект «лучше меньше, да лучше».

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

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

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

Когда Скотт попросил меня убрать строку предложений, меня это не рассердило, хотя я больше года напряженно над ней работал. Работая в Apple, мы всегда были рады улучшить опыт пользователей, облегчив нагрузку нашего программного обеспечения^[41].

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

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

Есть еще множество примеров наших попыток соединить технические и гуманитарные науки на этом перекрестке, но в книге не хватит места, чтобы рассказать истории о них всех, поэтому вот еще несколько очень кратких примеров из эпохи Purple.

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

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

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

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

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

Я бы мог продолжать и продолжать, и, если вы хотите почитать невразумительную юридическую терминологию, вы можете это сделать. Я сошлюсь на патент Соединенных Штатов Америки 7479949, который в разговорах с юристами Apple иногда называют «Патент-949», а в других разговорах – «патент на iPhone». Его официальное название: «Устройство с сенсорным экраном, метод и графический пользовательский интерфейс идентификации команд с использованием эвристических правил»⁵¹. Этот документ – официальное заявление Apple о новых свойствах и функциях программного обеспечения первого iPhone. 385 страниц патента заполнены диаграммами, графиками, схемами, примерами реализации и формулой изобретения. Эта подача заявки имела своей целью обеспечить всеохватывающий отчет о мультисенсорном пользовательском интерфейсе, а в его разделах подробно разбираются скучные подробности бесчисленных конкретных взаимодействий. Например, вот короткий отрывок, описывающий, как движения пальцев по сенсорному экрану могут быть интерпретированы в определенных ситуациях.

В некоторых примерах реализации изобретения направление перемещения непосредственно соответствует движению пальца; в других же реализациях, как бы то ни было, направление перемещения отображает направление движения пальца в соответствии с правилом. Например, правило может утверждать, что, если направление движения пальца отклоняется на Y градусов от стандартной оси, то направление перемещения идет вдоль стандартной оси, в ином же случае направление перемещения практически совпадает с направлением движения пальца⁵².

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

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

Алгоритмы производят количественно измеримые результаты, где прогресс можно определить движением в заранее определенном направлении, как в случае, когда мы почти год пытались повысить производительность Safari. Тест загрузки страницы сообщал, как работает наш код и выражал результат в одном числе – среднем времени загрузки страницы.

У нас постоянно была совершенно четкая цель – уменьшить это число. Она никогда не ставилась под вопрос. Чем быстрее, тем лучше.

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

Эвристические правила также могут измеряться или иметь связанное с ними значение – продолжительность анимации или значения красного-зеленого-синего для цвета на экране, но в них нет такой «стрелки улучшения», которая всегда указывает в одном направлении. В отличие от оценочных алгоритмов, по эвристическим правилам труднее принять решение. Например, как быстро должна останавливаться прокрутка списка после того, как вы ее запустили? Мы всегда делали демоверсии, чтобы оценить все возможности. Я часто сидел с разработчиками команды HI, например, Басом или Имраном, чтобы принять предварительные решения по жестам или анимации, затем мы пересматривали эти решения в более крупной группе, а потом вся команда какое-то время пользовалась результатами этих решений. Эту схему мы использовали для того, чтобы разработать эвристические правила для всей системы.

Сколько времени должна занять анимация раскрытия ярлыка приложения, чтобы оно раскрылось на весь экран? Как далеко вы должны провести пальцем по экрану для того, чтобы это касание можно было интерпретировать как свайп? Насколько жест расширения позволяет вам увеличить фотографию в приложении «Фото»? Ответами на все эти вопросы будут числа, возможно, 0,35 секунды для анимации приложения, или 30 пикселей для свайпа, или четырехкратное увеличение для фотографии, но главное тут не в этом. Сами значения ничего не доказывают ни в каком инженерном смысле. Скорее эти цифры представляют собой разумные умолчания^[42], или приятные эффекты, или способ дать людям то, что они имеют в виду, а не то, что они делают. Для обнаружения того, что представляют собой эти вещи и какие из них являются приемлемыми, нужно время, поскольку слово «эвристический» происходит от слова «эврика», которое, конечно же, пришло к нам из греческого и означает «найти». Именно здесь слово «эврика» входит в наш процесс разработки, поскольку хорошие эвристические правила не появляются в виде вспышек озарения, а являются результатом терпеливых поисков. Нам даже не всегда было понятно, что мы уже отыскали нужное эвристическое правило. К окончательному решению мы приходили только с течением времени, после долгого рассмотрения. Эвристические правила работают так. Они субъективны.

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

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

В Apple мы никогда не рассматривали понятие правильного цвета с точки зрения алгоритма. Мы использовали демоверсии, чтобы выбрать цвет и время анимации, и мы полагались на свой вкус. Когда мы искали правильное «движение пальца согласно правилу», как говорится в отрывке, который я взял из «Патента-949», мы принимали субъективное решение. Мы разрабатывали эвристические правила.

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

Например, иногда мы использовали эвристические правила, чтобы регулировать алгоритмы. В программе автоисправления клавиатуры алгоритм отклонения от схемы мог всегда найти наиболее близкое совпадение со словарным словом для любой последовательности букв. Представьте себе, что кто-то набрал oooorr, возможно, чтобы добавить некий нажим к слову or (или), делая выбор между двумя прекрасными вариантами (например, «на десерт мы могли бы съесть по три шарика мороженого с фруктами и орехами иииииили шоколадный слоеный торт»). Как бы то ни было, слова ooooorr нет в словаре, и оно не слишком напоминает слово, которое близко к нему в геометрическом смысле, используемом алгоритмом клавиатуры. Таким словом будет polite (вежливый). Проблема в том, что мы не считаем, что oooorr настолько похоже на polite, чтобы сократить дистанцию между ними. Они не выглядят, как слова, которые сочетаются. Мы не примем переход oooorr → polite так же, как принимаем автоисправление rhe → the или firdt → first. Цель автоисправления – это давать вам то слово, которое вы имели в виду, учитывая то, что вы делали, а не в обязательном порядке искать набранный вами текст по словарю, используя какие-либо заумные расчеты. Разрабатывая код клавиатуры, я обнаружил, что иногда лучше оставить набранные буквы в покое, опираясь на предположение о том, что автор текста действительно имел в виду то, что напечатал. После определенного момента из-за неожиданных автоисправлений программное обеспечение больше путает, чем помогает. Где же этот момент? Я смог его определить только опрашивая людей и затем, опираясь на их отзывы, сделать эвристическое правило точки отсечения, регулирующее, какое вмешательство я могу позволить алгоритму отклонения от схемы и когда ему лучше не вмешиваться. В этом случае, как показал опыт, oooorr лучше оставить в покое.

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

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

Это медленный путь. Как сказал Стив во время презентации iPhone, ему пришлось ждать этого события два с половиной года.

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

На презентации устройства на Macworld, когда Стив впервые продемонстрировал iPhone, моя клавиатура пересеклась с миром.

Когда Стив в своей презентации добрался до того места, где должен был первый раз показать клавиатуру публике вне Apple, мои гордость и надежда сменились страхом и ужасом. Затем в своем рассказе для зрителей Стив назвал мою клавиатуру «феноменальной» и легко набрал текстовое сообщение.

Фух! Честно говоря, Стив поставил лишний перевод строки в конце текста, который ставить не намеревался, но это не так уж важно. Ничего ужасного не случилось, и я почувствовал огромное облегчение. Демонстрация прошла хорошо. Это было круто.

Случилось еще одно пересечение – мое со Стивом. Сразу после презентации iPhone мы с Ричардом Уильямсоном вышли в проход перед сценой вместе со всей командой разработки программного обеспечения Purple. Чтобы подойти туда, нам пришлось пройти около Стива. Он посмотрел на нас, сразу узнал Ричарда и поблагодарил его. Это была моя первая встреча с начальником; хотя он и знал мою работу, но мы не были знакомы. После самой крупной презентации во всей истории Apple я оказался рядом с Большим Боссом, и он посмотрел мимо меня. Это было разочарованием.

Были пересечения iPhone со скептиками. Прошло совсем немного времени после презентации на Macworld, и люди начали говорить о своих сомнениях по поводу нашего продукта. Возможно, ни одно из них не стало так известно, как глумливый комментарий Стива Балмера, который тогда был генеральным директором Microsoft. Его первая реакция, когда он услышал об iPhone, была: «Пятьсот долларов? С контрактом? Это самый дорогой телефон в мире. И он не подходит для бизнес-пользователей, потому что у него даже нет клавиатуры, на нем неудобно работать с почтой»⁵³.

Время показало, что Балмер смеялся зря. Но, как бы то ни было, сразу после объявления об iPhone было приятно получить внеплановое обращение в эфире от еще одного Стива. Это было смешно.

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

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

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

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

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

2. Сотрудничество – работать вместе с другими людьми и стараться объединить сильные стороны каждого, как это было, когда Дарен и Трей помогали мне сделать корректно работающую точку ввода в текстовом редакторе WebKit.

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

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

5. Решительность – делать сложный выбор и не отставать от графика, и ничего не откладывать, как сделал Стив Джобс, когда заставил меня прямо на месте выбрать лучшую раскладку клавиатуры для iPad, а не предлагать два разных дизайна, которые независимо друг от друга разрабатывали мы с Басом.

6. Вкус – развить утонченное ощущение оценочного суждения и добиться приятного и целостного равновесия как тогда, когда мы предложили раскладку QWERTY для iPhone.

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

Есть и еще множество примеров. Ричард вдохновил нас, сделав буквально за пару дней свою первую демоверсию браузера, чтобы показать потенциал кода Konqueror, продемонстрировав потрясающий уровень мастерства. Вопль «Ооооо, да хватит же, Кен!» заставил меня расположить по одной букве на каждой клавише клавиатуры QWERTY, причем это был один из судьбоносных моментов моей карьеры. Постоянные усилия были нужны, чтобы создать словарь для программы автоисправления iPhone, добавить все эти словарные статьи и расставить значения частоты использования для лексикона в несколько десятков тысяч слов. Решения о настройке бесчисленных эвристических правил были приняты благодаря безупречному вкусу таких дизайнеров, как Бас и Имран. Эти решения можно видеть в каждом жесте и взаимодействии с первым iPhone. Умение поставить себя на место другого повлияло на управление функцией «Смахните, чтобы разблокировать» так, что она стала интуитивно понятной даже для детей. Скотт Форсталл дал мне шанс присоединиться к проекту Purple даже после того, как я плохо использовал возможность управлять одной из его команд по разработке программного обеспечения – кризис моей веры в коллективную работу, – потому что понимал, что я хочу участвовать в общем деле, просто мне нужна правильная роль.

Есть кое-что очень важное, что я хотел бы показать этими примерами, потому что вы, возможно, и сами задумались об этом. Некоторые из эпизодов, о которых я говорил, кажутся незначительными. Сколько эмпатии было у Скотта Херца, когда он делал свою игру «Попади в мишень»? Сколько решительности потребовалось Грегу Кристи, чтобы объявить, что мне следует вернуться к раскладке клавиатуры QWERTY, где на каждой клавише находится по одной букве?

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

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

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

Культура, которую мы создали, неотделима от наших продуктов. Исходя из моего опыта, такой тип культурного образования лучше всего работает, если группы и команды остаются небольшими, когда люди в этих командах активно и часто общаются между собой, а не в тех случаях, когда общение случайно и мимолетно. Команды проектов, которые я описал в этой книге, были действительно небольшими. До того, как мы сделали первое бета-объявление о программном обеспечении, в проекте Safari код редактировали десять человек. В «Патенте-949» изобретателями iPhone заявлены двадцать пять человек. Хотя эти два числа показывают разные вещи, они приводят нас к правильной приблизительной оценке. В Apple команды программистов не состояли из сотен и тысяч человек. Здесь на сцену выходила прагматичная философия управления, которая начиналась со Стива и распространялась вниз. Наши руководители хотели отличных результатов, и они создавали связь, так как хотели сотрудничать непосредственно с людьми, делающими свою работу, создающими демоверсии и так далее. Это накладывало ограничение на количество сотрудников. Был также и еще один эффект: то, что группы разработчиков были небольшими, давало ощущение собственного влияния и сплоченности команды. Эти факторы очень важны, особенно если судить по тому, что они часто оказываются вверху списков типов поведения, которые менеджеры слишком больших команд пытаются нарабатывать и поощрять. Эффективная коммуникация была еще одной, часто неуловимой характеристикой, присущей нашим маленьким командам. Пути коммуникации между несколькими членами команды были хорошо отработаны, и эти пути, как дорожная колея, облегчали путешествие в желаемом направлении. Мы всегда пытались достичь своей цели так быстро, как только могли, с минимальными колебаниями и отсрочками.

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

Итак, вот мое восприятие пути Apple, нашего рецепта по изготовлению программного обеспечения для таких продуктов, как Safari, WebKit, iPhone и iPad, мой рассказ о том, как мы делаем грандиозные продукты.

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

Если это высказывание расширить, оно будет выглядеть так:

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

К главе о перекрестках и пересечениях это развернутое объяснение подходит лучше всего. Также оно очень зависит от «мастерства исполнения», как бы сказали в Голливуде, имея в виду, что качество того, что получается в результате, обусловлено тем, как все делается⁵⁴. Так что нет ничего удивительного в том, что это связано с людьми, их рабочими инструментами и тем, что они решают с ними делать.

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

10. В данный момент

29 июня 2007 года был особенным днем, и я решил прогулять работу. Вместо того чтобы с утра пораньше приехать в офис и приступить к своему обычному распорядку – взять кофе, сесть за стол, просмотреть новости, прочитать электронную почту, проверить список ошибок, выданный Radar, начать программировать, – я остался дома и серфил по интернету. Примерно через час я поехал из Саннивейла, где находился мой дом, в центр Пало Альто, примерно в 16 километрах от меня. Пробиваясь через пробки на дороге с частыми остановками на спешащей по утрам Университетской авеню, главной улице Пало Альто, я во все стороны вертел головой, чтобы найти дорогу. Подъехав ближе, я увидел очередь, которая уже растянулась вдоль квартала. Я припарковал машину и пошел посмотреть на толпу. У меня не было какой-то особенной цели, я даже не совсем четко представлял, зачем туда иду – я просто хотел побыть среди людей, которые ждали открытия Apple Store, чтобы купить свой первый iPhone.

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

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

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

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

Мы с Биллом никогда не встречались, но у нас было много общих знакомых. Спросив его о деревянном iPhone, я представился и рассказал, что работал над настоящим телефоном, хотя и не уверен, что это где-то зарегистрировано. В любом случае встреча с Биллом Аткинсоном, одним из создателей Macintosh, одним из моих героев, стоявшим в очереди, чтобы купить свой первый iPhone, была для меня волнующим событием.

Каким-то образом в этот момент я ощутил, что моя миссия выполнена, поэтому сел в машину и поехал в кампус Apple в Купертино. Когда я заходил в коридор Purple, перед своим кабинетом стоял Скотт Форсталл в окружении небольшой группы программистов. Это было необычно, но, как я уже говорил, 29 июня 2007 года был необычным днем. Подойдя ближе, я обнаружил, что Скотт не просто приветствует проходящих мимо людей. Он разливал шампанское. Форсталл передал мне стакан, и мы подняли тост за выход iPhone.

Самым ясным воспоминанием, которое осталось у меня от тех первых дней после начала продаж iPhone, было… облегчение. Я чувствовал его, потому что моя клавиатура работала достаточно хорошо и не «потопила» iPhone, как система распознавания рукописного ввода, погубившая Newton.

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

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

К тому времени, когда мы начали работать над тем, что стало iOS4 (Apple изменила название программного обеспечения iPhone, официально признавая статус операционной системы в компании и ее растущую важность в мире высоких технологий), я получил повышение, стал главным инженером программного обеспечения iPhone (это говорит о том, что Стив решил изменить название где-то на более позднем этапе этого годичного цикла разработки) и вместе с Басом начал работать над клавиатурой iPad, которую мы в конце концов показали Стиву.

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

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

Скотт хотел, чтобы мы выяснили, какими могут быть эти пятипальцевые жесты. Он хотел исследовать более крупный экран iPad, чтобы лучше использовать мультитач для более простой работы с несколькими приложениями. На iOS4 мы сделали несколько улучшений программного обеспечения для запуска нескольких приложений, и Скотт хотел распространить это на iPad. Он поставил мне цель для iOS5: добавить мультисенсорные многозадачные жесты для iPad. Я подписался на эту работу.

Через несколько недель у меня была демо первых вариантов трех многозадачных жестов для iPad.

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

2. Свайп вверх, чтобы показать строку ярлыков с последними используемыми приложениями.

3. Сминающий жест (скранч), чтобы вернуться к домашнему экрану из текущего приложения.

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

После нескольких недель шлифовки и показа демоверсий мы натренировались делать эти жесты. Мы были готовы показать программу Стиву.

Осенью 2010 года я вошел в зал «Дипломатия», готовый продемонстрировать многозадачные жесты для iPad. Стив, Скотт, Грег и Анри уже были в конференц-зале. Как обычно, Стив сидел в офисном кресле. Он был чрезвычайно худым, но я был не уверен, плохо ли он себя чувствовал. Стив, Скотт, Грег и Анри сидели на облезлой кушетке лицом к Джобсу.

Я прикинул, что как только Скотт закончит со своей вступительной речью, я скажу несколько слов, прежде чем перейти к своей программе. Я планировал что-то вроде: «Вот многозадачные жесты, о которых рассказал Скотт. У меня есть три…». Но когда Стив понял, что речь идет о многозадачных жестах для iPad, он прервал Скотта, сказав, что уже думал об этой функции и придумал способ возвращаться из приложения к домашнему экрану. Он показал свою идею, помахав рукой перед лицом, как будто отмахивается от мухи. После пары взмахов жест стал более определенным: Джобс опустил руку, расположив кисть параллельно полу. Затем он отвел пальцы назад, к себе, немного изогнув кисть горстью, а потом сделал быстрый толчок запястьем вперед, как будто пытается отогнать приложение.

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

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

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

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

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

Вскоре Стив заметил еще одну дополнительную деталь, которую я присоединил к жесту из стороны в сторону. Если вы двигали экран в правую или левую сторону, полноэкранное представление приложений скользило к левому или правому краю экрана. В любой отдельно взятый момент на экране были только части двух приложений – того, в котором вы находились, и того, на которое переключались. Разрабатывая эту «ленивую Сюзанну»^[43] для приложений, мы решили, что если вы запускаете приложение, нажав иконку на домашнем экране, то свайп вправо не покажет другое приложение. Поскольку скольжение влево-вправо было предназначено для того, чтобы получить доступ к приложениям, которые использовались недавно, а приложение, только что запущенное с домашнего экрана, было самым последним по определению, в том направлении приложений не могло быть. На попытку сделать именно так меня вдохновил пружинящий отскок, который получается, когда вы добираетесь до конца списка, прокручивая его в iOS. Для жеста из стороны в сторону я сделал «упругую» анимацию – как будто последнее запущенное приложение становилось сделанным из резины, если вы пытаетесь потянуть его вправо. В этом случае приложение забавно растягивалось, а когда вы его отпускали, возвращалось на место со звуком «блоп-блоп-блоп». Для меня этот эффект четко давал понять, что дальше в этом направлении нет никаких приложений.

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

Стиву она, напротив, понравилась. Обнаружив «резиновую» анимацию, он слегка выпрямился на кресле, по-прежнему удерживая iPad на колене, и потянулся к экрану обеими вытянутыми руками, явно указывая всеми десятью пальцами на устройство перед ним.

Не поднимая головы, все еще глядя на экран iPad, Стив высказал свое мнение о «пружинящем» эффекте:

– Эта анимация… это и есть Apple.

Несколько месяцев спустя на одном из моих обычных совещаний с Анри, где мы обсуждали текущую работу по iPad, я сказал ему, что, возможно, было бы хорошо еще раз показать Джобсу мою программу, чтобы снова продемонстрировать многозадачные жесты, поскольку программное обеспечение уже приближалось к своему окончательному виду. Это дало бы еще один шанс получить обратную связь до того, как iOS5 выйдет в свет.

Анри ответил покачиванием головы и сухой фразой:

– Я считаю, что в данный момент мы должны выпустить многозадачные жесты так, как они есть.

Мы закончили разговор несколько минут спустя, и, выходя из кабинета Анри, чтобы отправиться в свой коридор, я снова услышал его слова у себя в голове:

– В данный момент…

И тут до меня дошло. Анри знал: Стив больше не вернется.

Примерно через шесть недель Стив сложил с себя обязанности CEO Apple. А еще через шесть недель его не стало⁵⁵.

Эпилог

Многие годы работа в Apple давала мне финансовую стабильность, одобрение со стороны талантливых коллег и всемирную известность для созданного мной программного обеспечения. Стив Джобс был всецело сосредоточен на создании великолепных продуктов, и его точка зрения вдохновляла меня. Вдруг все становилось на свои места.

В этой книге я много рассказывал об уроках, которые получил в Apple. Самый большой урок, который я усвоил, состоит в том, что группа людей и культура, которую они создают, – это одно и то же. После смерти Стива культура разработки программного обеспечения в Apple начала меняться. С течением времени, уходом старых коллег и появлением новых она изменилась еще сильнее. К тому времени, когда в апреле 2017-го наступил мой последний день в Apple, в компании оставались очень немногие из тех людей, которых я упомянул в этой книге. Больше всего мне не хватало работы с ними, как это было в тех историях, о которых я рассказал. Когда я писал книгу, я чувствовал сильную связь с Apple, ее продуктами и людьми, с которыми работал в последние годы, но пришло время уходить и мне.

За пару недель до того, как я уволился из компании, я работал над последним проектом – выставкой для Музея дизайна в Лондоне. Мы создавали экспозицию об iPhone как часть инсталляции под названием «Калифорния: свобода дизайна», где должно было отразиться влияние Западного побережья Америки, начиная с 1960-х и заканчивая высокими технологиями Кремниевой долины. Мне предстояло оживить мой первый код автоисправления клавиатуры как пример мультисенсорной операционной системы, которую мы изобрели десять лет назад. Я восстановил ПО по нашим архивам исходного кода и запустил его на современной версии iOS, так что дизайнеры Apple могли воспользоваться им, делая в высоком разрешении анимацию клавиатуры для показа в музее. Было приятно взглянуть на этот код и провести с ним несколько часов последний раз перед тем, как я уйду.

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

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

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

Благодарности

Спасибо Тиму Бартлетту из St. Martin’s Press. Вы прочитали эту книгу, потому что он верил в человека, в первый раз в жизни выступившего в роли автора. Благодарю Ким Скотт за ее неизменную поддержку и за то, что она представила меня Тиму. Мои благодарности Алисе Пфайфер из St. Martin’s Press за ее бесконечную готовность помочь, терпение и ответы на все мои вопросы. Спасибо Алану Брэдшоу из St. Martin’s Press за помощь с редактированием формата и стиля, а также за работу корректора. Хотелось бы поблагодарить Ника Дитмора и Бианку Брэмхем за помощь с иллюстрациями, занимающими всю страницу, и Гая Шилда – за то, что он их нарисовал. Выражаю огромную признательность Энди Матюшак и Джули Уитни за то, что они прочитали первые черновики и дали полезные отзывы.

Огромное спасибо моим друзьям и коллегам из Apple. Их слишком много, чтобы перечислить всех поименно, но вы знаете, кто они. Возможно, я и остаюсь интровертом, но могу сказать, что мне нравилось работать с ними. Спасибо, ребята! Благодаря вам в моей жизни произошли некоторые из самых счастливых событий!

Спасибо моей жене Джин. Если говорить о самых счастливых временах, то она всегда со мной, решительно и бесповоротно.

Примечания

1. Free Software Foundation, GNU Operating System. [Online]. Accessed November 12, 2017. На страницах этого веб-сайта рассказывается об истории, философии и лицензиях проекта GNU. https://www.gnu.org

2. Steven Levy, Insanely Great, the Life and Times of Macintosh, the Computer That Changed Everything (New York: Penguin Books, 1994). Macintosh вдохновлял меня с того момента, когда я впервые увидел его в колледже в 1984 году, и, если бы Стивен Леви не написал свою книгу о том, как сотрудники Apple создавали Macintosh, вы сейчас не читали бы эту книгу.

3. David Winton, Code Rush: Full Film. Vimeo. [Online]. PBS Home Video, Winton Dupont Films, April 25, 2000. Accessed November 12, 2017. Одна из моих любимых сцен в этом документальном фильме – это та, где Дон идет через кампус Netscape в тающем вечернем свете. В деле также принимает участие его коллега Тара Хернандес, которая по неизвестной причине несет хоккейную клюшку. Они отправляются искать капризного программиста, обладающего сокровенной крупицей знаний, которые могут исправить те несколько ошибок, все еще остающихся в Netscape и не позволяющих выпустить код браузера. Придя на рабочее место этого программиста, сплошь заставленное пустыми жестянками из-под кока-колы и другим мусором, они обнаруживают, что хозяина нигде поблизости нет. Где же этот парень? Никто не знает. Коллега из соседнего кубикла, который видел таинственного программиста ранее в этот день, от всего сердца присоединяется к заявлениям о скором «конце света». Думаю, это было прекрасное шоу, которое стало одной из легенд Кремниевой долины. https://vimeo.com/8235099

4. Sam Williams, Free as in Freedom: Richard Stallman’s Crusade for Free Software (Sebastopol, CA: O’Reilly & Associates, 2001). https://www.oreilly.com/openbook/freedom/index.html

5. Wikipedia contributors, “Gratis versus Libre,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Gratis_versus_libre&oldid=840748752. Accessed May 14, 2018.

6. David Flanagan, JavaScript: The Definitive Guide, 3rd ed. (Sebastopol, CA: O’Reilly Media, 1998). (Флэнаган Д. «JavaScript: Подробное руководство» – книга, переведенная на русский язык и многократно переиздававшаяся в России – Прим. пер.) В индустрии высоких технологий 1990-х годов книги O’Reilly & Associates были распространены повсеместно. У всех программистов, которых я знал, были эти издания, и все их нежно любили. Хотя я уже многие годы не обращался ко второму изданию Programming Perl («Программирование на Perl»), так называемой верблюжьей книге, я по-прежнему держу ее у себя на столе из-за искренней любви и ностальгии.

7. “Steve Jobs Announces the Microsoft Deal – Macworld Boston” (1997). YouTube: Every Steve Jobs Video. [Online]. Accessed November 12, 2017. Этот доклад был представлен на выставке-конференции Macworld Expo в Бостоне 6 августа 1997 года в конференц-зале Bayside Expo & Executive Conference Center. Перемотайте до 30 минут и 20 секунд, чтобы увидеть Билла Гейтса. https://www.youtube.com/watch?v=almoJa_c_FA

8. James Daly, “101 Ways to Save Apple,” Wired, June 1, 1997. Слово «Молитесь» появилось на обложке журнала, но сама статья была озаглавлена «101 способ спасти Apple». По большей части, советы были плохими или откровенно дурацкими. («#1. Примите это: вы вышли из игры производителей компьютерной аппаратуры. … #24. Заплатите художнику комиксов Скотту Адамсу 10 миллионов долларов, чтобы Дилберт (Скотт Адамс – автор сатирического комикса «Дилберт», где рассказывается об офисной жизни, менеджерах, инженерах, маркетологах, боссах, юристах, и прочих странных людях. – Прим. пер.) влюбился в женщину-ремонтника из Performa». … #73. Переименуйте компанию в Papaya»), но, как выяснилось, в #50 содержалась хитрость: «Дайте Стиву Джобсу столько власти в разработке продуктов, сколько он захочет взять». https://www.wired.com/1997/06/apple-3/

9. “What Makes a 10x Programmer/Software Engineer?” Quora. [Online]. Accessed November 12, 2017. https://www.quora.com/What-makes-a-10x-programmer-software-engineer. “Are You a 10x Programmer? Or Just a Jerk?” The New Stack. [Online]. Accessed November 12, 2017. https://thenewstack.io/10x-programmer-just-jerk/. Мне нравится заголовок. В нем содержится сомнение, которое многие из тех, кто работает в отрасли, ощущают по поводу существования 10х программистов.

10. Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы. (Серия: «Профессионально») = The Mythical Man-Month. Essays on Software Engineering. Anniversary Edition. – СПб.: Символ-плюс, 2000.

11. Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы. (Серия: «Профессионально») = The Mythical Man-Month. Essays on Software Engineering. Anniversary Edition. – Пер. с англ. С. Маковеева. – СПб.: Символ-плюс, 2000, с. 26.

12. WebKit, “Timeline.” [Online]. Accessed November 14, 2017. На память я не жалуюсь, но она недостаточно хороша, чтобы помнить количество строк с той точностью, какую я хотел бы видеть в тексте. Я ссылаюсь на репозиторий проектов с открытым исходным кодом WebKit, чтобы можно было сверить даты, хронологию событий, файлы, имена, комментарии к коммитам и так далее. https://trac.webkit.org

13. Ryan Tate, “Apple Just Ended the Era of Paid Operating Systems,” Wired. [Online]. Accessed October 22, 2013. https://www.wired.com/2013/10/apple-ends-paid-oses/

14. Elmer Ellsworth Burns, The Story of Great Inventions (New York: Harper & Brothers, 1910), pp. 121–124.

15. Steven Johnson, Where Good Ideas Come From: The Natural History of Innovation (New York: Riverhead Books, 2010).

16. Paul Israel, Edison: A Life of Invention (New York: John Wiley & Sons, 1998). Особенно интересен текст на страницах 168, 188 и 217.

17. James Newton, Uncommon Friends: Life with Thomas Edison, Henry Ford, Harvey Firestone, Alexis Carrel & Charles Lindbergh (New York Harcourt, 1987), p. 24. Очевидно, автор Джеймс Ньютон присутствовал, когда Эдисон сделал свое заявление о вдохновении и поте. Тем не менее цитата, которую я привожу, – это часть длинного разговора с репортером, взявшим у Эдисона интервью по случаю его дня рождения в 1929 году, и я сомневаюсь, что у автора с собой был блокнот, чтобы точно записывать то, что говорил ученый. Поэтому действительно ли Эдисон так рассказывал о своем методе работы? Я не знаю, но, кажется, будущие поколения голосуют за положительный ответ на этот вопрос. Использовав эту цитату, я и сам понимаю, что этим подбрасываю еще одно полено в костер.

18. Donald E. Knuth, The Art of Computer Programming (Boston: Addison-Wesley, разные годы издания).

19. Donald Knuth, “Structured Programming with go to Statements,” ACM Computing Surveys 6, no. 4 (1974): 261–301. Мне очень нравится, как знаменитое высказывание Кнута об оптимизации вошло в статью, где оно упоминается как одно из самых знаменитых положений в науке о компьютерах с эпохи «структурного программирования». Это утверждает Э. В. Дейкстра в своей статье “Go To Statement Considered Harmful” («О вреде оператора GOTO»). Эту статью можно найти с помощью любого поисковика, который вы предпочитаете. Я обнаружил ее на http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

20. Cliff Edwards, “Commentary: Sorry, Steve: Here’s Why Apple Stores Won’t Work,” Bloomberg Business Week, May 20, 2001. [Online]. Accessed November 13, 2017. https://www.bloomberg.com/news/articles/2001–05–20/commentary-sorry-steve-heres-why-apple-stores-wont-work

21. “Steve Jobs Introduces 12»–17» PowerBooks, iLife & Safari – Macworld SF” (2003). YouTube: EverySteveJobsVideo. [Online]. Accessed November 13, 2017. Эта речь была произнесена на Macworld Expo в Сан-Франциско 7 января 2003 года в Moscone Convention Center. Промотайте до 3 минут 43 секунд, чтобы послушать, как Стив рассказывает о работе Apple Store. https://www.youtube.com/watch? v=5iOWA2wEFPE

22. David Foster Wallace, String Theory: On Tennis: Five Essays (New York: Little, Brown, 2014). Не является ли мой рассказ о Винсе Ломбарди попыткой пойти вслед за Уоллесом? Да, возможно. Отрывок, о котором я думаю больше всего, – это история Трейси Остин, опубликованная в указанной книге под заглавием “How Tracy Austin Broke My Heart” («Как Трейси Остин разбила мне сердце»). Впервые эта часть увидела свет 30 августа 1992 года в Philadelphia Enquirer. Дежурная бейсбольная фраза, которую я использовал, очень близка к той, которая была у Уоллеса.

23. John Eisenberg, That First Season: How Vince Lombardi Took the Worst Team in the NFL and Set It on the Path to Glory (Boston: Houghton Mifflin Harcourt, 2009), p. 76 (глава 7).

24. Там же.

25. Lombardi. HBO Sports, NFL Films, 2010. Мне не удалось заполучить полную копию этого фильма. Я нашел то, что, по всей видимости, является отрывком из него на YouTube https://www.youtube.com/watch?v=ILrJenuiYF0, и могу только установить происхождение этого клипа из фильма HBO. Я узнал голос Лива Шрайбера, и другие источники подтверждают, что он в самом деле выступал в этом фильме рассказчиком. Вдобавок в еще одном клипе Джерри Крамера он показан в аналогичном окружении, и этот клип является трейлером к фильму, доступному на сайте HBO. Я более или менее уверен, что эта цитата верна. Мне бы очень хотелось посмотреть фильм HBO полностью. Собирая данные для этой книги, я просмотрел множество других ресурсов, посвященных Ломбарди, и эти несколько клипов из вырезанного отрывка были лучшими. В обзоре фильма, сделанном Ричардом Сандомиром в «Нью-Йорк Таймс» от 10 декабря 2010 года под заголовком “The Loud, and Memorable, Voice of Lombardi” («Громкий и запоминающийся голос Ломбарди») говорится, что фильмы NFL стали «главным архивом данных для фильма о Ломбарди как о тренере». Возможно, более целеустремленный поиск точно определит, что эти клипы связаны с фильмами HBO или NFL. Дерзайте!

26. “Vince Lombardi Teaches the Power Sweep Part 1,” YouTube: Football Coaching. [Online]. Accessed November 14, 2017. Мне очень хотелось бы иметь полную копию фильма Винса Ломбарди «Наука и искусство американского футбола». Из ностальгии идеальной была бы шестнадцатимиллиметровая пленка, чтобы смотреть ее в темной комнате, когда в свете проектора видны летающие в воздухе частицы пыли. К сожалению, я смог только найти отрывки из этого фильма на YouTube. Я нашел введение к фильму и частичное описание Power Sweep на https://www.youtube.com/watch?v=uv4CXySXxCk.

27. Lombardi, HBO Sports.

28. Tracy Kidder, The Soul of a New Machine (New York: The Modern Library, 1997), pp. 82–83.

29. Wikipedia contributors, “White-Naped Xenopsaris,” Wikipedia, TheFree Encyclopedia, https://en.wikipedia.org/w/index.php?title=White-naped_xenopsaris&oldid=833595068. Accessed November 14, 2018. Я отредактировал оригинальный код HTML, чтобы сделать его проще.

30. NBC Nightly News with Brian Williams. May 25, 2006. http://www.nbcnews.com/id/12974884/#.Ww3STy-ZP1I Это настолько емкий итог рабочей философии Стива, что после его смерти, когда компания устраивала мемориальное собрание в атриуме четвертого здания Infinite Loop в кампусе Apple в Купертино, для того чтобы показать на экране, выбрали только эти слова.

31. Freddy Anzures and Imran Chaudhri, Graphical user interface for a display screen or portion thereof. U. S. Patent D604,305, filed June 23, 2007, and issued November 17, 2009. Это патент на промышленный образец, описывающий SpringBoard – программу, запускающую приложения с помощью ярлыков на домашнем экране iPhone. http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=D604305; Бас Ординг, непрерывное перемещение изображения, а также перемещение, увеличение и поворот документов на сенсорном экране. U. S. Patent 7,469,381, filed December 14, 2007, and issued December 23, 2008. Это патент, описывающий инерционную прокрутку. http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7469381; Matt Brian, “The Apple Patent Steve Jobs Fought Hard to Protect, and His Connection to Its Inventor,” The Next Web, August 7, 2012. Accessed November 19, 2017. https://thenextweb.com/apple/2012/08/07/the-apple-patent-steve-jobs-fought-hard-to-protect-and-his-connection-with-its-inventor/

32. “Crackberry,” Urban Dictionary. Accessed November 14, 2017. https://www.urbandictionary.com/define.php? term=Crackberry

33. Kenneth Kocienda et al., Keyboards for portable electronic devices. U. S. Patent 7,694,231, filed January 5, 2006, and issued April 6, 2010.

34. Mat Honan, “Remembering the Apple Newton’s Prophetic Failure and Lasting Impact,” Wired, August 5, 2013. https://www.wired.com/2013/08/remembering-the-apple-newtons-prophetic-failure-and-lasting-ideals/. Accessed November 14, 2017.

35. Wikipedia contributors, “International Talk Like a Pirate Day,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=International_Talk_Like_a_Pirate_Day&oldid=831048898. Accessed November 14, 2017.

36. Wikipedia contributors, “QWERTY,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=QWERTY&oldid=842348998. Accessed May 14, 2018.

37. Samantha, Today I Found Out, “The Origin of the Qwerty Keyboard,” January 7, 2012. http://www.todayifoundout.com/index.php/2012/01/the-origin-of-the-qwerty-keyboard/. Accessed May 14, 2018.

38. Цитируется по Rob Walker, “The Guts of a New Machine,” The New York Times Magazine, November 30, 2003. http://www.nytimes.com/2003/11/30/magazine/the-guts-of-a-new-machine.html. Accessed November 14, 2017.

39. Фейнман Р., Лейтон Р., Сэндс М. Фейнмановские лекции по физике. Выпуск 1. Современная наука о природе. Законы механики. Выпуск 2. Пространство. Время. Движение (издание 5). – Эдиториал УРСС, 2004, с. 23.

40. Kenneth Kocienda et al., Method, Device, and Graphical User Interface Providing Word Recommendations for Text Input, U. S. Patent 8,232,973, filed June 30, 2008, and issued July 31, 2012. http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=8232973.

41. Wikipedia contributors, “Bugzilla,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Bugzilla&oldid=841348601. Accessed November 15, 2017.

42. stopdesign, creative outlet of Douglas Bowman, “Goodbye, Google,” March 20, 2009. http://stopdesign.com/archive/2009/03/20/goodbye-google.html. Accessed November 15, 2017.

43. Ч. Дарвин. Происхождение видов путем естественного отбора, или Сохранение благоприятных рас в борьбе за жизнь. – Перевод с шестого издания (Лондон, 1872). – Санкт-Петербург: Наука, 1991, с. 14–15.

44. Wikipedia contributors, “Seagull Manager,” Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/w/index.php?title=Seagull_manager&oldid=838557671. Accessed November 15, 2017. Первоначально источником для этого понятия стала шутка из книги Кена Бланшера «Лидерство и одноминутный менеджер», вышедшей в 1985 году.

45. “Steve Jobs Introduces the Original iPhone at Macworld SF (2007),” YouTube: EverySteveJobsVideo. https://www.youtube.com/watch?v= –3gw1XddJuc. Accessed November 16, 2017. Промотайте до 21 минуты 45 секунд, чтобы услышать, как Стив начинает представлять iPhone. Думаю, смотреть до 41 минуты не стоит, поскольку защищенный авторскими правами контент, который был показан на презентации, не может быть воспроизведен на YouTube.

46. “Steve Jobs Introduces Original iPad – Apple Special Event (2010),” YouTube: EverySteveJobsVideo. https://www.youtube.com/watch?v=_KN-5zmvjAo. Accessed November 16, 2017. Этот доклад был представлен 27 января 2010 года в центре искусств Йерба-Буэна в Сан-Франциско. Чтобы послушать, что Стив говорит о перекрестке, промотайте до 1 часа 30 минут.

47. Robert X. Cringely, Steve Jobs: The Lost Interview. Furnace, Public Broadcasting Service (PBS) (as NerdTV), Oregon Public Broadcasting, John Gau Productions, 2012. Промотайте до 57 минуты, чтобы послушать, что Стив говорит о расположенных с интервалами шрифтах на Macintosh. http://www.magpictures.com/stevejobsthelostinterview/.

48. “Star Wars Blasters Sound Effect. How They Did It,” YouTube: tedmerr. https://www.youtube.com/watch?v=fl0wIdGxfbQ. Accessed November 16, 2017; “The Story Behind the Creation of the Lasergun Sound in Star Wars.” Filmsound.org. http://filmsound.org/starwars/lasergunstory.htm. Accessed November 16, 2017. “Sound Design of Star Wars.” Filmsound.org. http://www.filmsound.org/starwars/.

49. Wikipedia contributors, “Ben Shneiderman,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Ben_Shneiderman&oldid=838578865. Accessed November 16, 2018. Wikipedia contributors, “Direct Manipulation Interface,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Direct_manipulation_interface&oldid=831492190. Accessed November 16, 2017.

50. Wikipedia contributors, “The Magical Number Seven, Plus or Minus Two,” Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=The_Magical_Number_Seven,_Plus_or_Minus_Two&oldid=841444468. Accessed November 16, 2017. George A. Miller, “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information,” Classics in the History of Psychology. http://psychclassics.yorku.ca/Miller/. Accessed November 16, 2017. Статья, размещенная на этом сайте, впервые была опубликована в Psychological Review 63 (1956): 81–97.

51. Steven P. Jobs et al., Touch screen device, method, and graphical user interface for determining commands by applying heuristics. U. S. Patent 7,479,949, filed April 11, 2008, and issued January 20, 2009. http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7479949.

52. Там же. Текст, который я цитирую, находится в колонке 75 и начинается со строки 39.

53. “Ballmer Laughs at iPhone,” YouTube: smugmacgeek. https://www.youtube.com/watch?v=eywi0h_Y5_U. Accessed November 16, 2017

54. Впервые я услышал о «зависимости от мастерства исполнения», когда кинодраматург Филиппа Бойенс описывала свои попытки создать сюжетную линию Сэмуайза Гэмджи в конце «Властелина колец. Две крепости» в The Two Towers, The Appendices, Part Three, The Journey Continues, From Book to Script: Finding the Story. New Line Productions, Inc., 2002. “What does ‘execution dependent’ mean?” johnaugust.com. https://johnaugust.com/2009/what-does-execution-dependent-mean. Accessed November 16, 2017.

55. Apple Newsroom, “Steve Jobs Resigns as CEO of Apple,” August 24, 2011. https://www.apple.com/newsroom/2011/08/24Steve-Jobs-Resigns-as-CEO-of-Apple/. Accessed November 16, 2017. AppleNewsroom, “Letter from Steve Jobs,” August 24, 2011. https://www.apple.com/newsroom/2011/08/24Letter-from-Steve-Jobs/. Accessed November 16, 2017. Apple Newsroom, “Apple Media Advisory,” October 5, 2011. Accessed November 16, 2017.

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

Вернуться