Когда компания Google достигла международного уровня, мы быстро поняли, что большинству инженеров, живущих в Калифорнии, не хватает навыков, необходимых для перевода веб-страниц на другие языки. Стремясь решить данную проблему традиционным способом, мы могли бы нанять профессиональных переводчиков и потеряли бы много времени и денег. Однако мы поступили иначе, предложив выполнить эту работу нашим пользователям. Мы опубликовали все свои тексты и попросили добровольцев перевести их на местный язык. Они справились – и справились просто фантастически. Похожее случилось, когда команде, ответственной за гео-продукты, была поставлена задача сделать карту мира. Они обнаружили, что многих мест просто не существовало на карте, и создали сервис Map Maker, позволявший любому желающему внести свой вклад в Google Maps. Живете на улице, которая не отображается в картах? Не проблема: просто нарисуйте эту улицу, и мы ее добавим (разумеется, после того как убедимся, что она действительно существует там, где вы сказали). Таким образом было создано новое сообщество картографов среди рядовых горожан, которые сделали так, чтобы карты целых городов оказались на расстоянии клика от наших пользователей. Например, всего за два месяца они нанесли на карту пакистанские дороги протяженностью более 25 тысяч километров.
Вскоре после того как мы пришли в Google, команда топ-менеджеров организовала выездное мероприятие, где мы обсуждали открытие большего количества офисов по всему миру. Когда Эрик спросил Ларри, сколько менеджеров, по его мнению, должно быть в компании, Ларри ответил: «Миллион». Он не шутил, но также и не имел в виду, будто в компании должен быть миллион сотрудников (по крайней мере, мы не думаем, что он имел в виду именно это). Сегодня разработчики по всему миру постоянно работают с Android, Google App Engine, Google APIs, Google Web Toolkit, а также с инструментами с открытым исходным кодом, в которые Google внес свою лепту. Все они не являются сотрудниками Google, но если бы мы считали и их, то, вероятнее всего, общее количество людей, использующих инструменты Google или создающих крутые штуки на наших платформах, исчислялось бы миллионами. Таким образом мы могли бы достичь цели, поставленной Ларри, и в этом случае он поставил бы цель в десять раз масштабнее – 10 миллионов.
Отгружайте и итерируйте
Итак, у нас есть точное количество ресурсов, припасенных для новых озарений, мы одели «намордник» авторитарным менеджерам, дали волю своей гениальности и вышли за рамки узкого мышления, чтобы отовсюду черпать идеи. Инновации льются потоком, блестящие мысли бьют ключом. Бóльшая их часть умирает еще до того, как увидит свет, но несколько драгоценных – хороши настолько, чтобы достичь Земли обетованной. Вы публикуете в блоге пост, даете зеленый свет и открываете шампанское, собираясь отпраздновать это со своей командой.
Затем вы возвращаетесь к работе, потому что если вы все сделали как полагается, продукт еще не готов. Вольтер писал: «Лучшее – враг хорошего»[208]. Стив Джобс сказал команде, работавшей над созданием Macintosh, что «настоящие художники отгружают»[209]. Новые идеи никогда не могут быть идеальными с самого начала, и у вас нет времени ждать, пока они таковыми станут. Создайте продукт, отгрузите его, понаблюдайте, как он работает, разработайте и внедрите усовершенствования и снова отправьте его потребителю. Отгружайте и итерируйте. Компании, выполняющие эти процессы быстрее всех, побеждают.
Когда мы запускали свой флагманский продукт AdWords, у нас возник спор по поводу того, должны ли рекламные объявления публиковаться сразу, минуя внутренний контроль. В компании многие полагали, что это приведет к появлению некачественной рекламы и спаму. Но также были и те, кто считал, что, если бы рекламодатели имели возможность сразу наблюдать за своими объявлениями в действии, они смогли бы намного быстрее собирать данные об эффективности рекламы и улучшать ее. Они доказывали: более быстрый цикл обработки объявлений приведет к более высокому, а не низкому качеству. Мы остановили свой выбор на минимальном внутреннем контроле, использовав таким образом подход «Отгружай и итерируй».
Данный подход применим ко многим сферам. Легче всего его реализовать на практике в нашем мире – мире программного обеспечения, где продуктом являются не физические товары, а биты и байты, доставляемые в цифровой форме. Но с новыми технологиями, такими как 3D печать, и возможностью моделировать немало вещей онлайн стоимость экспериментирования во многих сферах упала, иногда настолько резко, что процессы отгрузки и итерации в большинстве случаев стали доступнее.
Самая сложная часть в «отгрузке и итерировании» – это итерирование. Сплотить команду с целью отгрузить новый продукт довольно просто, но намного сложнее сделать так, чтобы они остались и выполнили сложную работу по улучшению продукта. Одной из эффективных форм мотивации, к которой мы пришли, стали негативные отзывы. Мы часто использовали критику, чтобы стимулировать сотрудников к итерированию своих продуктов, начиная от записки Ларри «Эта реклама – отстой» и заканчивая негативными отзывами, которые Марисса размещала на стене перед своим кабинетом, а затем анализировала со своими продакт-менеджерами и инженерами. И здесь есть тонкая грань, которую мы не всегда улавливали. Правильная критика мотивирует, но слишком много критики имеет совершенно противоположный эффект.
Модель «отгрузки и итерирования» работает не всегда. После запуска некоторые продукты изменятся в лучшую сторону и будут набирать обороты, в то время как остальные зачахнут. Дело в том, что к моменту выхода продукта на рынок в него уже вложено существенное количество ресурсов и эмоций, способных помешать принятию правильных решений. Пренебрежение невозместимыми издержками – это главный урок, который следует усвоить, потому что в модели «отгрузки и итерирования» задача руководителя должна заключаться в том, чтобы «накормить» победителей и «морить голодом» проигравших, независимо от предшествующих вложений. Продукты, изменяющиеся в лучшую сторону и набирающие обороты, следует поощрять бóльшим количеством ресурсов, нежели продукты, которые застаиваются.
Чтобы решить, какие усилия увенчаются успехом, а какие – нет, используйте данные. Так оно всегда и было, но особенность Эпохи Интернета в том, насколько быстро вы получаете данные и сколько их у вас. Ключевой фактор при выборе победителей заключается в решении, какие данные использовать, и установке системы таким образом, чтобы эти данные можно было извлечь и проанализировать быстро. Полученная информация заглушит ложное представление о невозместимых издержках – противоречащую здравому смыслу склонность большинства людей рассматривать количество ресурсов, инвестированных в проект, как одну из причин продолжать в него инвестировать («Мы уже инвестировали миллионы, мы не можем остановиться сейчас»)[210].
Зачастую люди склонны «кормить» проигравших в надежде, что это сделает их победителями. Когда Джонатан руководил продуктами в [email protected], на портале компании Excite.com существовало немало разделов, таких как новости, недвижимость, спорт, финансы и так далее. Каждый из них сражался за клики на главной странице, и когда трафик какого-либо раздела падал, руководство Excite пыталось исправить ситуацию, перемещая его в лучшее место на странице. «Эй, финансы, ваш трафик в этом квартале упал, и вы отстаете от плана. Не беда – мы поместим вас на самый верх страницы». В Excite использовали данные с целью определить, какие области контента проигрывали, но вместо того чтобы морить эти разделы голодом и постараться усовершенствовать их, они кормили их, заселяя в более выгодные «апартаменты». Вспоминая об этом сегодня, мы понимаем, что слоган Excite не был в достаточной степени сфокусирован на их пользователях – он привлекал внимание пользователей к худшим продуктам, что способствовало достижению мнимых целей. И данная проблема, как оказалось, никого не волновала.
На практике «отгружать и итерировать» означает, что давление со стороны маркетинга и PR при запуске должны быть минимальными. Если вы занимаетесь ресторанным бизнесом, вы называете это «открытием в тестовом режиме». Когда вы выталкиваете птенцов из гнезда, не давайте им спасательный жилет или даже парашют – позвольте им лететь самостоятельно. (Примечание: это метафора.) Инвестируйте только тогда, когда увидите какой-то подъем с их стороны. Прекрасный пример тому – Google Chrome. Он был запущен в 2008 году с минимумом помпезности и практически без маркетингового бюджета, но самостоятельно набрал колоссальные обороты лишь за счет своего превосходства. Позже, с течением времени, когда у браузера появилось более 70 миллионов пользователей, руководство приняло решение подлить масла в огонь и утвердить маркетинговую push-стратегию (включая даже рекламу по телевидению). Но пока продукт не оправдал свое звание лидера, мы его не «кормили».
Внесем ясность: модель «отгрузки и итерирования» не означает, что у вас есть право отправлять потребителям некачественные продукты в надежде затем улучшить их. На самом деле Джонатан часто предостерегал свою команду от запуска некачественных продуктов в расчете на то, что пользователей привлечет бренд компании. Продукты должны быть крутыми, но ограничивать их функциональность при запуске – это нормально. Вначале лучше отказаться от важных маркетинговых и PR-ресурсов, так как вероятность того, что потребители испытают разочарование от хорошо разрекламированного продукта, намного выше, чем от того, что был запущен без лишнего шума. Позже вы можете расширить функционал, добавив новые функции и подкорректировав существующие. Как писал гуглерам Эрик в феврале 2006 года: «У вас должен быть план для вау-функции вскоре после запуска». Благодаря такому подходу пользователи привыкли к высокому качеству продуктов, а если какой-то функционал ограничен, они знают, что его расширят вскоре после запуска.
Применять модель «отгрузки и итерирования» легко, когда ваш продукт полностью цифровой (программное обеспечение, СМИ) и затраты на производство физических товаров минимальны. Нам легко «отгрузить» новую функцию в поисковую систему Google и подкорректировать ее, основываясь на данных об использовании; производителю автомобилей или микросхем намного сложнее проделать то же самое. Но зачастую существуют другие способы использования охвата и силы Интернета для того, чтобы собирать важные данные пользователя. Например, «отгружайте» эскизы и прототипы или создавайте программное обеспечение, которое позволит использовать ваш продукт виртуально. Придумайте способ, дающий людям возможность испытать ваше творение, и, вооружившись данными, старайтесь усовершенствовать его.
Проигрывайте красиво
Антиподом рассказа об «отгрузке и итерировании» Chrome является история проекта Google Wave, запущенного с помпой в 2009 году. Wave является настоящим воплощением инновации. Он был творением небольшой команды инженеров из нашего сиднейского офиса, которые использовали 20 % своего времени на то, чтобы проработать вопрос «Какой была бы электронная почта, если бы ее изобрели сегодня?». В конечном итоге они придумали очень интересный прототип, который просто ошеломил руководство высшего звена. Мы дали добро на продолжение работы над проектом (хотя она, скорее всего, продолжалась бы и без нашего разрешения), в результате чего были созданы платформа и протоколы, обеспечивающие людей новым способом коммуникации в Эпоху Интернета.
Wave стал настоящим технологическим чудом, и тем не менее проект с треском провалился. Мы запустили его в 2009 году, но он не пользовался успехом у пользователей. Команда Wave «отгружала» и итерировала как ненормальная, но базовый контингент пользователей не достигал достаточной численности. Через год после запуска мы объявили о закрытии Wave. Пресса просто разгромила нас, назвав Wave оглушительным промахом и огромным провалом.
Они были правы: Wave был огромным провалом. Проект потерпел неудачу довольно быстро: мы не вливали в него приличных денег после такого неприличного результата. Он потерпел неудачу – и никто не был пригвожден к позорному столбу. Никто из команды Wave не потерял свою работу: на самом деле, после закрытия проекта большинство из них поднялись по карьерной лестнице в Google как раз благодаря своей работе над тем, что расширило границы возможного. В конце концов, Wave потерпел неудачу, но оставил после себя ценные технологии: элементы его платформы были перенесены на Google+ и Gmail. Как проигравший, Wave проиграл красиво.
Для того чтобы создавать инновации, вам нужно научиться правильно проигрывать. Учитесь на своих ошибках: любой неудачный проект должен быть источником технических, пользовательских и маркетинговых инсайтов, которые могут оказаться полезными для следующей попытки. Трансформируйте идеи, не уничтожайте их: большинство великих мировых инноваций начались с совершенно другой сферы применения, поэтому, когда вы сворачиваете проект, внимательно изучите его компоненты с целью понять, как их можно применить в другом месте. Как говорит Ларри, если вы достаточно масштабно мыслите, очень сложно потерпеть полную неудачу. Практически всегда вы способны найти в ней нечто очень ценное. И не осуждайте команду, которая потерпела неудачу: убедитесь в том, что эти сотрудники получили хорошие должности внутри компании. Следующие новаторы увидят, наказываете ли вы проигравших. Не нужно хвалить за провал, но все же это своего рода почетный знак. По крайней мере, они старались.
Задача руководства заключается не в минимизации рисков или предотвращении неудач, а в создании среды, достаточно устойчивой, чтобы принимать возможные риски и мириться с неизбежными ошибками. Писатель и профессор Нассим Талеб пишет о создании систем, которые являются «антихрупкими»: они не просто переживают неудачи и внешние потрясения, но и становятся сильнее благодаря этому[211]. Не поймите нас неправильно: провал не является целью. Но если вы измеряете жизнеспособность вашей инновационной среды, вам необходимо учитывать как достижения, так и неудачи, стремясь добиться большей «антихрупкости». Автор комиксов «Дилберт» Скотт Адамс говорит: «Полезно относиться к неудаче как к дороге, а не стене»[212]. Ходжа Насреддин, мудрый глупец и суфист из XIII века, выступает в поддержку следующей идеи: «Правильные суждения берутся из опыта; опыт берется из неправильных суждений»[213].
Продолжительность провала является, возможно, самым коварным для правильного понимания элементом. Хороший провал – это быстрый провал: как только вы видите, что проект не станет успешным, вам хочется как можно скорее перекрыть ему кислород, стремясь избежать дальнейшей траты ресурсов и альтернативных издержек (тем умным креативщикам, что работают над обреченным проектом, лучше было бы поручить работу над потенциально успешным проектом). Но одним из признаков инновационной компании является то, что она дает хорошим идеям много времени на рост. Такие проекты, как беспилотные автомобили или Google Fiber, который обеспечит людей широкополосным доступом в Интернет с пропускной способностью в 1 Гбит/с (что примерно в 100 раз быстрее, чем есть у среднестатистического американца сейчас), имеют потенциал стать очень прибыльными, но это займет много времени. Как подчеркивает Джефф Безос: «Путем расширения горизонта планирования вы сможете включиться в проекты, в которые иным способом никогда не попадете. В Amazon мы любим работать от пяти до семи лет. Мы хотим сажать семена, давать им вырасти, и в этом мы настойчивы. Мы настойчивы в подходах и гибки в деталях»[214].
Итак, проигрывайте быстро, но расширяйте горизонт планирования. Ха! Как такое возможно? (Вот видите, мы же говорили, что это коварная часть.) Секрет в том, чтобы итерировать быстро и установить систему показателей, которая будет помогать вам оценивать, приближаетесь ли вы к успеху с каждой итерацией. Незначительные провалы вполне ожидаемы и допустимы, так как они зачастую могут внести ясность и показать правильный путь для перехода к следующим этапам. Но когда провалы становятся серьезнее и вы не видите явного пути к успеху (или, как говорят Регина Дуган и Кайгам Габриель, когда достижение успеха требует «множества чудес подряд»[215]), то, возможно, пришла пора свернуть проект.
Дело не в деньгах
Хотя мы считаем, что выдающихся сотрудников следует необычайно поощрять за их необычайные успехи, мы не платим людям за успешные проекты в рамках «20 % времени». Дэн Ратнер мог получить очень щедрое вознаграждение за свой вклад в работу трансформационной команды Street View, но ему не выплатили ни цента непосредственно за его работу над трайками[216]. У нас не предусмотрено никакого материального стимулирования за проекты в рамках «20 %» по одной простой причине: нам это не нужно. Возможно, прозвучит банально, но вознаграждение уже заключается в самой работе. Несколько исследований показали, что внешние поощрения не стимулируют креативность, а, по факту, только мешают ей, превращая дерзкий проект, приносящий внутреннее удовлетворение, – в рутинное зарабатывание денег[217].
Наш любимый пример того, как проекты «20 % времени» могут сами по себе быть источником поощрения, связан с событиями августа 2005 года, когда ураган Катрина разрушил побережье Мексиканского залива. К тому моменту сервис Google Earth функционировал в течение всего восьми недель, и команда, работавшая над нашими гео-продуктами (Maps и Earth), была совсем небольшой и очень перегруженной. Но когда случился ураган, они засучили рукава и запустили более восьми тысяч актуальных снимков со спутника (из национального управления океанических и атмосферных исследований – NOAA), которые показывали масштабы бедствия на фотографиях улиц и окрестностей в высоком разрешении. Это помогло спасателям, с большим трудом ориентировавшимся из-за того, что бóльшая часть указателей и уличного освещения были повреждены ураганом. Данные снимки также помогли организациям, доставлявшим гуманитарную помощь, а позже – и выжившим, которые не знали, могли ли они вернуться в свои дома.