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

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

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

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

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

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

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

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

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

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

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