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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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