Войти в систему
Войти с помощью соц. сетей:
Если вы действительно изобретаете что-то новое, то не должны знать, что делаете.
Если вы такой же человек, как и все, то должны испытывать благоговейный трепет перед достижениями человечества, такими как космический полет или появление iPhone, и хотеть возглавить команду, которая способна совершать такие вещи. Как руководитель, вы ждете от своей команды великих и смелых идей, которые изменят вашу компанию, отрасль, а может, и весь мир, но они так и не появляются. Или, возможно, вы сами приходите с идеями в команду, а вам начинают объяснять, почему они не будут работать. Подобные разочарования имеют одну и ту же фундаментальную причину — страх потерпеть неудачу. Это естественно и очень по-человечески — стремиться к успеху и избегать негативных оценок, связанных с неудачей. Однако терпимость к неудачам — как на личном, так и на организационном уровне — является ключом к появлению инноваций. Благоразумные менеджеры нередко препятствуют принятию риска. Создание организации, которая поощряет и вознаграждает постепенное достижение больших целей, повышает шансы на появление успешных инноваций и снижает издержки неизбежных ошибок. В этом заключается суть экспериментирования. В сфере программного обеспечения никогда еще не было так просто и так необходимо создать культуру, способствующую экспериментированию. Посмотрим, почему это так.
В биографии братьев Райт, изданной в 2016 г., Дэвид Маккалоу подробно описывает процесс, благодаря которому два веломеханика из Огайо стали первыми, кто осуществил моторный полет. Братья Райт не могли похвастаться хорошим финансированием в отличие, например, от Сэмюэля Лэнгли, который получил деньги от Военного ведомства на разработку летательного аппарата тяжелее воздуха. Но он тратил больше времени на проведение рекламных пресс-туров, а не на создание прообраза самолета.
Братья Райт выиграли, потому что экспериментировали, причем очень активно. И они были готовы к эффектному провалу, даже когда на кону стояли их собственные жизни.
В своем велосипедном магазине в штате Огайо в 1899 г. они построили прототип летательного аппарата. Следующим летом они отправились в Китти-Хок, штат Северная Каролина, — жалкое, совершенно неблагоустроенное местечко с кусачими мухами, но с сильными ветрами, и попытались взлететь на своей машине. Аппарат разбился. Братья починили его, улучшили конструкцию и снова попытались подняться в воздух. Опять неудачно. Они повторяли этот цикл до тех пор, пока их аппарат полностью не развалился, и только тогда отправились домой на зиму. Опираясь на полученные за сезон данные, они строили следующую версию летательного аппарата, а с наступлением лета возвращались в Китти-Хок для новых испытаний, повторяя весь процесс. В 1903 г. после многочисленных травм, переломов и крушений братья наконец смогли определить комбинацию формы крыла, стабилизаторов, систем управления, мощности двигателя и многого иного, необходимую для обеспечения первого пилотируемого полета. Остальное — история.
Это вдохновляющий пример. Здравый смысл говорил братьям Райт, что пора оставить их затею. Крушения грозили им гибелью, но они продолжали свои попытки, пока наконец не добились успеха. Если братья Райт могли бесконечно продолжать эксперименты до получения успешного результата, то так же можем делать и все мы.
Экспериментирование с программами происходит точно так же, но, к счастью, оно проще, быстрее и не так опасно, как полеты на аппарате тяжелее воздуха. Посмотрите на приложения в своем телефоне. Все они обновляются еженедельно. Многие сайты обновляются ежедневно и даже ежечасно.
Чего вы не замечаете, так это экспериментирования во многих приложениях и сайтах. К новым функциям подключаются всего 0,5% клиентов, чтобы понять, насколько они нравятся им. Если реакция хорошая, компания распространяет действие новой функции на более широкую аудиторию. Если что-то идет не так — происходят сбои или просто новая функция не вызывает симпатий, то компания откатывает ПО назад.
В этом суть экспериментирования. Это также суть революции бережливого стартапа, начатой Эриком Рисом, который написал предисловие к этой книге. Если можно опробовать новшества с низким риском и быстро узнавать о потребностях клиентов, то почему бы этого не сделать?
Быстрое экспериментирование при разработке ПО — самый важный аспект принципа «Создать или умереть». Именно поэтому я описываю его как дарвиновский процесс. Как только одна компания начинает быстро экспериментировать и внедрять инновации, за ней следует вся отрасль. Жесткая борьба за выживание приводит к ускорению всеобщего прогресса. По мере снижения стоимости экспериментов их число растет. Вы получаете кембрийский взрыв — взрывной рост числа инноваций.
Есть такой старый анекдот: женщина постоянно ходит в церковь и молится о выигрыше в лотерею. Она молится неделю за неделей, год за годом. Наконец Бог отвечает: «Так и быть, я пойду тебе навстречу, но для начала ты хотя бы лотерейный билет купи!»
Инновации в чем-то напоминают эту историю: эксперименты — это лотерейные билеты с шансом выиграть прорывную инновацию. Чем больше лотерейных билетов вы купите, тем выше ваши шансы. Однако мне не нравится аналогия с лотерейным билетом, потому что никакое умение не может увеличить шансы на выигрыш. Экспериментируя и внедряя инновации, вы совершенствуетесь по мере наработки практики. Эта глава повествует о том, как научиться экспериментировать, чтобы увеличить свои шансы на решение самых серьезных проблем клиентов.
Я помню разговор с Эриком Рисом несколько лет назад, который напомнил мне анекдот про женщину и лотерейный билет. Эрик сравнивал эксперименты с посадкой семян в землю — вы не знаете, какое из них превратится в гигантское дерево. Но одно точно известно: если семена не посадить, у вас не вырастет ничего. Часто консультируя по методологии бережливого стартапа, Эрик встречает руководителей крупных компаний, которые отвергают небольшие эксперименты — саженцы в его аналогии, поскольку они «ничего не дают», т.е. не приносят заметный для бизнеса доход, скажем, $100 млн. Это еще не гигантские деревья.
Эрик подчеркивает, что один эксперимент не приносит доход такого уровня, однако неизвестно, какие новые эксперименты станут следующим крупным направлением бизнеса стоимостью $100 млн. «Если бы мы знали, какие идеи станут хитами, то только ими и занимались бы. Естественно, никто ничего не знает заранее, поэтому нужно быть готовым посадить достаточное число семян и наблюдать, как они растут». Когда они начинают прорастать, не топчите их из-за того, что они еще маленькие. Наоборот, поливайте их и не закрывайте солнечный свет. Или, выражаясь деловым языком, инвестируйте в них больше.
Как и деревья, каждая великая идея начинается с малого.
Иногда идеи рождаются у передовых команд, а иногда у лидеров компаний. Откуда бы ни пришла идея, дальнейшие действия должны быть одинаковыми.
Прежде всего оцените идею. Оценка необязательно должна быть исчерпывающей — для начала нового эксперимента нужны небольшие усилия. На самом деле вам нужно знать всего две вещи:
Две причины, по которым я мог бы отказаться от эксперимента, это: а) слишком маленькая возможность успеха и незначительность успешного результата или б) отсутствие у команды представлений о том, как измерить прогресс.
Но если ответы на эти два пункта приемлемы, то начните работу с небольшой командой. Это может быть новая команда или существующая. Но пяти человек должно быть достаточно, чтобы приступить к эксперименту.
Необязательно нацеливать команду на «великую идею», главное, чтобы в центре ее внимания был потребительский сегмент и проблема, требующая решения. Необязательно говорить команде, что нужно создавать, но скажите ей, на каком клиенте сосредоточиться и какую ценную проблему вы можете решить для этого клиента. Это клиентская и идейная составляющие командной работы.
Затем определите показатели успеха. Эрик Рис предельно ясно показывает, как сделать это, поэтому прочтите его книги «Бизнес с нуля» и «Метод стартапа», чтобы познакомиться с тем, что он называет «инновационный учет». Короче говоря, небольшой команде нужен набор показателей, чтобы определить, как выглядит успешный результат эксперимента. Учтите, что это не долгосрочные бизнес-показатели, а краткосрочные результаты экспериментов. Эрик называет это проверкой слепых предположений.
Когда команда оценит возможность (пункт 2 выше), она обычно строит модель с горизонтом 5–10 лет, опирающуюся на расчеты: «Если у нас будет 1000 клиентов, которые заплатят нам по $500 000 за пять лет, то это превосходно». Примерно так определяют, заслуживает ли эксперимент финансирования. Но следующий шаг — это не создание бизнеса стоимостью $500 млн, а проверка обоснованности допущений в этой модели, а именно: 1000 клиентов и доход $500 000 от каждого.
Ваш эксперимент может быть направлен на то, чтобы: а) выяснить, действительно ли один клиент заплатит вам столько за решение проблемы и б) подтвердить существование этой проблемы у достаточного числа клиентов, иначе говоря, возможность найти 1000 клиентов, которым можно продать услугу в течение следующих пяти лет.
Но если вы не сможете найти даже одного клиента или если вы найдете клиента, но он согласится платить только $1000 в год вместо $500 000, то это проблема. Или если клиенты платят нужные суммы, но в мире существует лишь 10 компаний, у которых есть потребность в вашей услуге, то это проблема.
Все делается для того, чтобы можно было предельно быстро и дешево узнать, действительно ли входные параметры вашей модели, определяющие успех, являются истинными. Масштабирование — это работа, которую нужно оставить на потом. Сейчас вы просто пытаетесь подтвердить гипотезу.
Другой ключевой момент связан с тем, что ваша гипотеза не является технической или научной. Чтобы понять это, вспомните некоторые известные эксперименты. Томас Эдисон в лаборатории, пытаясь сделать работоспособную лампочку, выдвинул научную гипотезу: свет можно получить, пропуская электричество через нить накала. Он проверил более 3000 материалов, чтобы доказать эту гипотезу. У братьев Райт также была техническая гипотеза: профиль крыла — вот что позволяет летать. У них были предположения о профилях крыла и о том, как они могут влиять на воздушный поток и подъемную силу. Эти предположения нужно было проверить в практических экспериментах.
Это научные гипотезы. В случае ПО ответ на научную или техническую гипотезу — «Компьютерная программа может сделать то-то и то-то» — почти всегда положителен, его можно точно воспроизвести. Гипотеза, которую вы на самом деле пытаетесь проверить, — это бизнес-гипотеза о том, что клиенты будут платить за компьютерную программу, которая делает то-то и то-то, или, еще шире, о том, что компьютерная программа, которая делает то-то и то-то, принесет нам больше денег.
Любая электронная таблица с прогнозом бизнес-перспектив нового продукта или инициативы является гипотезой — буквально заполнена числами, полна предположений. Эти предположения тестируются в небольших масштабах при небольших затратах. В мире, живущем по принципу «Создай или умри», вы на самом деле экспериментируете не с ПО, а с самой компанией: «Как наша компания может расти? Какие продукты мы должны производить?»
У братьев Райт имелась техническая гипотеза о форме крыла. У них не было бизнес-гипотез о том, как строить коммерческие самолеты, развивать авиационную промышленность или создавать аэропорты в крупных городах, чтобы превратить самолет в средство массовых перевозок. Они построили минимально жизнеспособный самолет, видоизмененный планер с мотором. Как только удалось доказать техническую гипотезу, они обратились к бизнесу и создали самолетостроительную компанию, но ни у кого из них не было большого интереса к бизнесу. Их величайшая инновация была связана с технологией, а не с бизнесом. В отличие от них, Генри Форд занимался и тем, и другим — он был инновационным конструктором бензиновых двигателей и других узлов автомобилей, но впоследствии привнес инновации в производство, которые, пожалуй, можно считать еще более значительными.
Одна из распространенных ошибок компаний заключается в отсутствии гипотезы, предшествующей эксперименту, — это означает, что они вкладывают деньги в тестирование технической гипотезы и даже создание прототипов, не останавливаясь для выяснения наличия достаточного спроса на продукт. Кто-то просто говорит: «Послушайте, было бы здорово, если бы мы смогли…» А бывает, что руководитель влюбляется в идею и приказывает инженерам развивать ее.
Энтузиазм — это здорово, и великие дела часто начинаются именно с него, но вам не следует двигаться дальше, пока вы не превратите идею в бизнес-гипотезу. Без этого вы не будете знать, для чего проводится эксперимент. Успех или неудача будут неоднозначными, и вы просто останетесь с вопросом: «Это помогает делу?» Ответ на него почти всегда будет отрицательным.
Наличие гипотезы и набора предположений, которые нужно подтвердить или опровергнуть, — это отлично, но вам требуется описание этого, чтобы отслеживать прогресс. В Twilio одна из наших ключевых ценностей выглядит так: «Записывай», и эксперименты являются отличной возможностью для реализации такой практики. Исходная гипотеза нередко забывается, поэтому сохранение ее и результатов тестирования в письменном виде позволяет всем идти в правильном направлении. Возможно, именно по этой причине ученые и изобретатели ведут подробные лабораторные тетради. Я заметил, что, если эксперимент и его ход не документируются должным образом, люди (особенно мы, руководители) забывают контекст и возвращаются к разговорам вроде «Почему дело не двигается с мертвой точки?!». Записи, напоминания о цели эксперимента и обновление результатов — отличный способ поддержки активного экспериментального мышления.
Сами эксперименты — это дарвиновский процесс, на основе которого мы можем учиться. Именно это делает природа, когда выбраковывает генетические мутации. Многие мутации неудачны, но некоторые приводят к появлению таких организмов, которые приспосабливаются, лучше функционируют и таким образом выживают. Быстрые и постоянные эксперименты и итерации — это базовый процесс, фундаментальный для жизни. Природа не плачет и не смущается из-за миллионов неудачных мутаций. Она просто продолжает их порождать.
В Twilio мы всегда стараемся проводить как можно больше экспериментов. Мы отправляем новые версии нашего продукта более 120 000 раз в год, т.е. более 300 раз в день. С каждым обновлением мы добавляем новые функции и возможности, исправляем ошибки, повышаем эффективность и проводим эксперименты.
В 2019 г. нашим директором по продуктам стал Чи Чу, который должен был помочь нам найти способы ускорить процесс экспериментирования. Чи получил степень бакалавра и магистра в области компьютерных наук в Массачусетском технологическом институте. Он опытный специалист, работавший в трех самых знаковых мировых софтверных компаниях: 14 лет в Microsoft, восемь лет в Google и четыре года в Amazon. Я никогда не встречал никого, кто так глубоко и много думал бы о создании софтверной организации и культуры, обеспечивающей инновации.
Вскоре после прихода в Twilio Чи представил несколько новых идей. Прежде всего он отказался от нашей старой системы, в которой инженеры могли предлагать новые продукты только в четвертом квартале, когда мы принимали бюджетные решения на следующий год. Это довольно традиционный способ ведения дел в большинстве компаний. Все приходят со своими идеями, какие-то из них получают одобрение, и руководство выделяет человеческие ресурсы и бюджет победителям. Большинство же остаются разочарованными.
Проблема в том, что «хорошие идеи приходят не только во время цикла планирования; они рождаются в течение всего года», говорит Чи. Он представил идею постоянных презентаций. Вместо того чтобы заставлять людей приходить раз в год и запрашивать огромный бюджет, мы создали форум, где каждый может изложить свою идею в любой момент. Если идея получает одобрение, мы финансируем очень небольшую исследовательскую группу, участие в которой может занимать у человека лишь часть рабочего времени. Команда получает ровно столько денег, сколько нужно для проведения короткого эксперимента.
Иногда эксперименты направлены вовсе не на открытие нового рынка или рост доходов, а на другой бизнес-результат, например на экономию денег. Чи провел конкурс, чтобы собрать идеи для «Наибольшего повышения эффективности», и победившая команда получила разрешение использовать полный двухнедельный спринт для конкретизации идеи плюс дополнительное финансирование при условии, что спринт подтвердит первоначальные гипотезы.
Как говорит Чи, «если вы достигаете целевого результата, то мы расширяем масштабы подобно стартапу, получившему следующий раунд финансирования. Таким образом, мы исследуем, получаем некоторую уверенность и наконец финансируем небольшую команду, чтобы добраться до первого коммерческого релиза».
В результате мы можем проводить одновременно больше экспериментов. Многие из них не ведут к успеху, но мы понимаем это быстрее и переходим к следующему эксперименту.
В 2019 г. Джефф Иммельт вошел в совет директоров компании Twilio после долгой карьеры в General Electric, где он занимал пост преемника генерального директора Джека Уэлча с 2001 по 2017 г. Под руководством Иммельта GE предприняла попытку цифровой трансформации грандиозного масштаба. При штате более 330 000 человек изменение курса компании с более чем 125-летней историей оказалось настоящим подвигом. В числе его детищ была программа GE Digital: создание софтверного бизнеса, который должен помогать клиентам получать большую эффективность от инвестиций в промышленное оборудование General Electric — ветряные турбины, реактивные двигатели и двигатели для локомотивов. Иммельт предположил, что на основе данных, собранных в процессе эксплуатации, компания сможет предсказывать отказы до того, как они произойдут, настраивать оборудование в режиме реального времени с помощью искусственного интеллекта для повышения эксплуатационных характеристик и в конечном итоге предоставлять клиентам более эффективное оборудование, которое требует меньшего объема обслуживания и ремонта. К сожалению, значительная часть доходов и прибыли General Electric приходилась на запчасти и ремонт, поэтому цифровая инициатива была встречена другими бизнес-лидерами General Electric со скептицизмом. Однако Джефф знал, что превращение в софтверный бизнес — единственный способ защитить и развить сервисы компании. Его догадки были правильными, и поэтому он запустил GE Digital, чтобы поддержать свои сервисные бизнесы большими данными, интернетом вещей и машинным обучением — и одним махом превзойти массу исходно цифровых компаний. Запустив эту инициативу, он вложил сотни миллионов долларов в большую идею: платформу промышленных приложений для интернета вещей.
Это обязательство было впечатляющим и, как заметил Джефф, необходимым, чтобы компания понимала серьезность его намерений. Вот его слова: «Чтобы быть успешной промышленной компанией, нам нужно стать успешными в цифровом плане. Никаких запасных планов у меня на самом деле нет». Несмотря на инвестиции в сотни миллионов долларов, через пять лет GE Digital получала всего $15 млн дохода от клиентов, что совершенно не соответствовало намеченным целям. После ухода Джеффа программа GE Digital была свернута, что позволило конкуренту, компании Honeywell, создать успешный промышленный продукт для интернета вещей.
Где же компания General Electric ошиблась? Если вы сформулируете проблему так: «Нам нужно развернуть эту $100-миллиардную компанию с помощью одной большой идеи», то давление на компанию окажется огромным, а места для неудачи окажется совсем мало. Как говорит Джефф, «мне нужно было дать понять, что я серьезен и что это не просто мимолетное увлечение. Один из способов сделать это в компании нашего размера — требовать гарантированную оплату». Однако такой подход был совершенно противоположен экспериментальному мышлению. У него был план, сотни миллионов долларов финансирования, прекрасный новый офис в Кремниевой долине и опытная команда управленцев, собранная для осуществления идеи. На мой взгляд, General Electric было бы гораздо лучше выделить не $200 млн, а $20 млн и разделить их на 5–10 команд со своей гипотезой относительно потребностей клиентов в цифровом будущем, которую нужно протестировать. Раз в несколько месяцев руководство должно было оценивать прогресс и предоставлять больше финансов командам, которым удалось подтвердить свои гипотезы. Остальные команды следовало бы либо ликвидировать, либо переориентировать на тестирование новых гипотез.
Джефф также отмечает, что привлеченные им специалисты, скорее всего, не подходили для процесса трансформации. «Я подбирал специалистов из крупных технологических компаний — Cisco, SAP, IBM и Oracle, а не истинных предпринимателей. Они думали о масштабе, а не об экспериментировании. Мне нужно было действовать не так».
Руководителям крупных компаний это может показаться странным, но иногда проблема заключается в избыточном финансировании. Когда вы вкладываете в инициативу сотни миллионов долларов и делаете это с большой помпой, на команду давит ожидание большого результата в нереально короткий срок. Подозреваю, что при более скромном финансировании и итеративном, экспериментальном подходе, они смогли бы достичь гораздо большего. Сегодня Джефф соглашается с этим: «У меня была команда и процесс, который был создан для размаха, а не экспериментирования. Жаль, что я не начал с малого, с предпринимательской командой и без лишнего шума. А к масштабированию, в котором так сильна General Electric, нужно было приступать только после первого успеха».
Итак, вы проводите эксперимент, который может принести один из трех результатов: вы получаете золото, выбываете из игры или оказываетесь где-то между этими двумя исходами. Мы делаем ошибки во всех трех сценариях.
Давайте сначала поговорим о большом успехе: предел мечтаний каждого, когда исходные предположения подтверждаются, а клиенты влюбляются в идею. Но толку от экспериментов нет, если вы не в состоянии продолжить успехи победителей. В Twilio мы это уже проходили. Мы начинали эксперимент и видели, что он успешен, но по-прежнему считали его лишь экспериментом, причем довольно долго, и не давали ему финансирование, позволяющее взорвать рынок. Мы не поливали саженец должным образом.
Мы усвоили, что при проведении экспериментов необходимо придерживать в запасе ресурсы, чтобы обеспечить мощный старт для того, что принесло успех. Amazon делает это хорошо. Ее виртуальный помощник на базе искусственного интеллекта Alexa изначально был экспериментом. Когда Alexa начал приобретать популярность, в Amazon поняли, что это — особенный продукт и он нуждается в мощной поддержке.
Небольшой команде Alexa потребовалось расширение, т.е. привлечение новых специалистов. Появилось столько открытых вакансий, что команда могла бы потратить все свое время на подбор сотрудников и собеседования, вместо того чтобы создавать и эксплуатировать Alexa. Ей грозила опасность утонуть под бременем собственного успеха! Поэтому Amazon ввела правило: любой поступавший на работу в Amazon при желании имел возможность войти в команду Alexa. Только представьте: команда Alexa могла переманить любого нового сотрудника из любого подразделения. Это экстремальная версия поддержки эксперимента.
Теперь посмотрим, что происходит, когда бизнес-гипотеза оказывается ложной. Мы много говорили о выдвижении гипотез и их тестировании. Ничто не разрушает предпринимательскую, экспериментальную культуру в большей степени, чем наказание за проведение эксперимента, доказывающего ложность гипотезы. (Обратите внимание, что я не называю это «неудачей».)
Боссу легко сказать: «Мы дали вам кучу денег, но не получили популярного продукта — вы, должно быть, потерпели провал». Это гарантированный способ сделать так, чтобы никто и никогда не пытался провести эксперимент или пойти на риск.
Вместо этого смотрите на ситуацию следующим образом: «У нас была гипотеза, которая в результате оказалась неправильной. К счастью, мы выяснили это всего за три месяца и затратили $50 000. Теперь мы можем сосредоточиться на другом».
Полная противоположность этому, когда компания отряжает на отработку идеи сотни человек, тратит пять лет на создание «идеального» продукта, покупает рекламный блок в финале Суперкубка по американскому футболу, вкладывает $25 млн в рекламную кампанию — и все для того, чтобы выяснить, что клиенты равнодушно относятся к продукту или клиентов просто недостаточно для оправдания инвестиций.
Разве вы не предпочли бы выяснить это за несколько месяцев, потратив тысячи долларов, а не за годы и миллионы? Вместо страданий по поводу того, что эта маленькая команда потратила впустую $50 000, думайте о том, что они сэкономили $25 млн! Вы должны поздравить их и обеспечить как можно быстрее следующим заданием.
Наконец рассмотрим самую сложную ситуацию: ту нечеткую середину, где гипотеза остается недоказанной — ни истинной, ни ложной, а все ваши показатели оказались неприемлемыми. Это самые трудные случаи и единственная настоящая неудача для команды экспериментаторов. Если ваша цель — доказать или опровергнуть гипотезу, а вы не можете сделать ни того, ни другого за разумное время, то эксперимент фактически терпит провал. Вот почему в начале эксперимента так важна наглядность показателей.
Что делать дальше? Прежде всего убедитесь, что вы отвели на эксперимент достаточно времени. Иногда терпение — это добродетель. Измените тактику. Если выполняемые вами тесты не дают ответов, попробуйте проводить их по-другому. Возможно, ваша гипотеза непригодна для тестирования, поэтому попробуйте перевести ее в более приемлемую форму. Возможно, проблема в вашей команде — не исключено, что просто плохо работает. Неудача для эксперимента — это длительный период отсутствия ответа на вопрос, верна ли гипотеза. Во время фазы быстрых итераций полезно еженедельно или, возможно, раз в две недели связываться с командой, чтобы помочь обучению в процессе экспериментирования. Но если команда продолжает безрезультатно работать в течение полугода или года, то, не исключено, настало время внести изменения.
Чтобы преодолеть проблему неоднозначности середины и выяснить, следует ли отказаться от эксперимента, нужно, как и во многих других случаях, спросить своего разработчика. Возможно, никто не принимает решения по той причине, что нет желающих сказать бизнес-лидеру правду. Это просто человеческая природа — мало кто любит сообщать плохие новости. Но из историй о Патрике Маккензи, Райане Лесли, Лие Калвер и Чаде Этцеле вы могли понять, что инженерное мышление нередко предполагает: а) наличие твердого мнения и б) нежелание держать это мнение при себе. Для инженеров важны факты. Я просто думаю об этом так: инженеры ненавидят лажу. Так что, если вам нужен тот, кто скажет правду, даже если она горькая, — ищите инженера, занимающегося разработкой.
Джефф Иммельт столкнулся с подобной ситуацией на посту генерального директора General Electric, когда он с группой руководителей пытался разобраться с проблемой в конструкции нового двигателя, который был разработан для пассажирского самолета Boeing 787 Dreamliner. Инженеры свели причину к критическому недостатку конструкции турбины первого контура. General Electric оказалась перед угрозой кризиса. Компания потратила на разработку двигателя пять лет и более $1 млрд, а рынок для этого двигателя оценивался в $50 млрд.
Джефф наблюдал и слушал, как люди обсуждают, что делать дальше, и тут произошло нечто неординарное. Один из инженеров-разработчиков, создававших турбину, встал. Он не был ни менеджером, ни руководителем, а всего лишь рядовым конструктором. Но он сказал то, что большинство, по всей видимости, не хотело слышать: «Это плохая конструкция. Мы неправильно спроектировали двигатель. Он не работает должным образом, это обойдется нам в сотни миллионов долларов, но мы должны его переделать».
Как вспоминает Джефф, «это был старший технолог, который даже не задумывался о политкорректности. Он сказал это совершенно уверенно! Он знал, что последствия такого решения обойдутся компании в $400 млн».
И Джефф последовал совету инженера. Это было дорогостоящее, но верное решение. Эта история показывает, почему полезно выслушивать инженеров, занимающихся экспериментами и хорошо знающих детали. К сожалению, эксперименты с реактивными двигателями стоят намного дороже, чем большинство решений в сфере программного обеспечения.
Однажды и я совершил эту ошибку. В начале работы компании Twilio мы заключили сделку с крупным телефонным оператором по созданию нескольких коммуникационных приложений для клиентов в области малого бизнеса. Это выходило довольно далеко за пределы нашего основного бизнеса, и разработчики, которых я попросил заняться приложениями, сомневались в мудрости моего решения. Я выслушал их опасения, но все равно попросил написать приложения, поскольку это помогло бы нам расширить отношения с оператором. «По стратегическим соображениям», — сказал я им тогда. В течение большей части года они с полным осознанием долга писали приложения, хотя и не переставали сомневаться в этом решении. Буквально за день до запуска один из топ-менеджеров оператора передумал и разорвал контракт. Работа наших разработчиков так и не увидела свет. Никто ничего мне не сказал, но фраза «Мы же тебе говорили» явно вертелась у разработчиков на языке.
Из этого случая я сделал два вывода. Во-первых, это был не эксперимент. У нас был контракт, и мы делали дело вслепую, без тестирования с участием клиентов. Об этом знали и разработчики. Во-вторых, я должен был прислушаться к ведущим специалистам, которые считали, что приложения бесполезны, а мои бизнес-суждения неуместны. Мы потратили на эту авантюру более миллиона долларов из нашего бесценного стартового капитала, а могли избежать этого, если бы я обратил внимание на мнение ведущих разработчиков.
Немногие вещи разделяют мир бизнеса на два лагеря сильнее, чем неудачи. В Кремниевой долине существует странная фетишизация неудач. Там открыто говорят о праздновании неудачи. Инвесторы в буквальном смысле вознаграждают бизнесмена, который потерпел неудачу, финансируя его следующую компанию. Обожание неудач так глубоко укоренилось в мышлении Кремниевой долины, что вы чуть ли не ожидаете увидеть там очень успешных предпринимателей, которые только и думают о возможности провала.
Но радуются вовсе не неудаче, а получению знаний, приближающих к цели. Неудача просто принимается как естественное следствие обучения. Когда говорят о принятии неудачи, подразумевают принятие процесса открытия.
Заметьте, когда я говорил о проведении экспериментов, речь шла не об успехе или неудаче, а об ускоренном обучении. Опровержение гипотезы — ценное знание, которое многие называют неудачей. Однако я называю это успехом: если вы быстро и дешево обнаруживаете тупик, то это ценно для бизнеса. В этом весь смысл представления процесса как серии экспериментов, которые в конечном итоге приводят к инновациям. Инновации — это не то, что появляется легко и просто. Это тяжелая, утомительная работа. И если вы не принимаете процесс и не извлекаете пользу из своих ошибок, то большинство людей уходит от вас. Вот почему Кремниевая долина так перегибает палку в отношении неудач.
Но давайте будем честными: никто не любит неудачи. Истинная неудача неприятна, и любой нормальный человек ее ненавидит. Неудача сама по себе не повод для радости, и ни один предприниматель, чья компания терпит неудачу, на самом деле не радуется и не празднует ее, как об этом любят рассказывать. Фетишизация неудачи грозит выйти из-под контроля, однако новаторам очень важно избежать клейма неудачника.
Самое большое беспокойство при проведении экспериментов вызывает опасение причинить вред клиентам. Ведь в процессе работы над изобретением и после создания выдающегося продукта вам нужны клиенты, которые купят этот продукт. Разрыв отношений с клиентами во время поиска не сулит ничего хорошего. К счастью, можно экспериментировать и одновременно знакомить клиентов с результатами экспериментов, если структурировать процесс разработки должным образом с самого начала.
Крупные технологические компании, такие как Facebook, Amazon и Google, имеют сложные многоуровневые системы развертывания своих продуктов, которые позволяют представить новую функцию определенной группе клиентов. Иногда они знакомят с новшеством случайную выборку пользователей (порядка 1%), чтобы увидеть их реакцию на него. Это может быть и более целенаправленный подход, например только пользователи из определенной страны или демографической группы. Вовлечение в эксперимент лишь небольшой части пользователей служит отличной возможностью для обучения, не принимая больших обязательств перед клиентской базой. Прекратить эксперимент, в котором участвует 1% пользователей легко, а также дешево. Гораздо сложнее и затратнее (в смысле денег и репутации) закрыть эксперимент, который представлен большому числу подписчиков. Конечно, это работает хорошо, если у вас сотни миллионов или миллиарды пользователей, а значит, такой подход годится не для всех типов компаний. К счастью, многие способы тестирования идей значительно проще и так же эффективны.
Самый простой способ — просто пообщаться с клиентами. «Вы бы купили вещь, которая…» — это очень простой способ проверки. Если вы помните, в процессе запуска Twilio я спрашивал многих разработчиков, хотели бы они получить сервис, обеспечивающий связь в их приложениях. Это был очень дешевый эксперимент с низким риском. Я использовал тот же процесс для тестирования нескольких других идей, в том числе для распределенной системы резервного копирования данных, подобной сервису Dropbox. Другой идеей было использование интернета и сервиса BitTorrent для подключения дешевого или бесплатного кабельного телевидения. Все, что я делал, — это опрашивал потенциальных клиентов, чтобы узнать, решит ли моя идея проблему, с которой они сталкиваются в жизни. Поскольку вы не даете никаких обещаний, то вряд ли разочаруете клиента. Чаще всего они рады, что кто-то задает им вопросы и думает об их проблемах.
Еще один способ тестирования идей в интернете называется «нарисованная дверь». Если вы предполагаете, что миру нужен какой-то технологический продукт, вашу гипотезу можно легко протестировать, создав простой сайт и купив рекламу в Google, чтобы посмотреть, вызовет ли это интерес. Вы создаете не продукт, а лишь маркетинговый сайт, чтобы понять, соответствует ли ваше ценностное предложение запросам аудитории. Учитывая эффективность интернет-рекламы, можно довольно точно нацелиться на гипотетических покупателей и увидеть, нажмут ли они кнопку «Купить» на сайте или нет. Здесь, однако, вы можете обмануть ожидания: если нет продукта, то кнопка «Купить» на самом деле неработоспособна. Обычно она приводит к переходу на страницу со словами: «Спасибо за проявленный интерес. Продукт еще не готов, но мы ценим ваш вклад». Вы всегда можете использовать вымышленное название компании, если не хотите навредить своему бренду.
Я проделал подобное в 2007 г. в процессе поиска идей перед запуском Twilio. При создании магазина Nine Star у меня были трудности с доставкой электронных писем от системы управления кассовыми терминалами клиентам. Они периодически попадали в папки для спама. Я предположил, что у других разработчиков была такая же проблема, поэтому провел быстрый тест типа «нарисованная дверь». Я купил доменное имя MailSpade.com и потратил около часа на создание простенького сайта, объясняющего потенциальным клиентам ценностное предложение. Затем я потратил около полсотни долларов на рекламу в Google, чтобы привлечь трафик на сайт. На сайте была кнопка «Начать прямо сейчас», но после нажатия на нее просто выскакивало сообщение «Ожидается в скором времени». Я просто проверял, достаточно ли сильно мое ценностное предложение, чтобы потенциальные клиенты захотели купить продукт. Наблюдая за поведением первых посетителей сайта, я смог многое понять — и все это за пять часов работы и полсотни долларов. Неплохо! В конце концов я решил заняться этой идеей в Twilio, но в 2009 г. три разработчика — Айзек Салдана, Хосе Лопес и Тим Дженкинс — основали компанию SendGrid для решения проблемы электронной почты. Спустя 10 лет Twilio приобрела SendGrid более чем за $2 млрд в доказательство того, что это была отличная идея!
На самом деле не так сложно проводить эксперименты, не причиняя вреда клиентам. Однако не совершайте ошибку и не относитесь к эксперименту так, будто это не эксперимент. Если вы не уверены, что миру нужна ваша идея, протестируйте ее экспериментально так, как я предлагаю в этой главе. Если сразу перейти к крупным вложениям и масштабному, шумному запуску, то вероятность потери репутации у клиентов сильно повышается. Запуск барахла с большой помпой оборачивается проблемой для бренда и отношений с клиентами. (Вспомните историю с напитком New Coke.) Если устроить шумиху, то вы, скорее всего, получите некоторое количество клиентов. Но если их число не будет соответствовать вашим вложениям, то вы закроете проект, а это наверняка разочарует клиентов. Поэтому я считаю, что эксперименты не повредят отношениям с клиентами, а вот их отсутствие может нанести более серьезный вред.
Новаторы знают, что путь к успеху вымощен неудачными попытками. Томас Эдисон однажды сказал: «У меня не было неудач. Я просто нашел 10 000 способов, которые не работают». А Уинстон Черчилль заметил, что «успех — это способность идти от одной неудачи к другой без потери энтузиазма». Но свой любимый подход к экспериментированию я позаимствовал у Джеффа Безоса. В письме акционерам Amazon в 2015 г. Безос напомнил, что три самых больших успешных проекта Amazon — Marketplace, Prime и AWS — начинались как эксперименты и что в тот момент, когда они были задуманы, никто не знал, окажутся ли они работоспособными. В конце концов, большинство экспериментов компании кончаются неудачей. Безос использовал аналогию с бейсболом, чтобы объяснить, почему он подталкивает разработчиков к проведению как можно большего числа экспериментов: «Если выбиваешь мяч за пределы поля, то у тебя случаются не только страйк-ауты, но и хоумраны». Он также отметил, что в бейсболе лучший результат удара битой — это грэнд-слэм, позволяющий набрать сразу четыре очка, а «в бизнесе подчас, если проявить инициативу, вы можете сорвать тысячу очков».
Так почему бы не сделать как можно больше попыток? Особенно когда затраты на проведение экспериментов так малы. Ведь для начала нужны три–пять человек, а потенциальный результат огромен! Из-за масштаба интернета эксперимент может привести к созданию приложения с сотнями миллионов пользователей. Соотношение риск/вознаграждение невероятно привлекательно, так что не переставайте пробовать!
В бейсболе средний показатель отбивания 0,300 поражает воображение, а 0,400 практически недостижим. Это означает, что подавляющую часть времени на бейсбольной площадке игрок ничего не добивается с помощью биты. Таким образом, в бизнесе при потенциальном результате подхода к бите в 250 раз больше средний показатель отбивания на уровне 0,0012 будет достаточным для вхождения в высшую лигу бизнеса! Конечно, все это выдуманная математика, но суть понятна. В бизнесе нередко ждут 100%-ного успеха, а потому и боятся разрешить экспериментировать. Преодоление этого страха — ключ к успешной инновационной деятельности.
В следующий раз, когда вы почувствуете нежелание попробовать новую идею, спросите у своих руководителей, что в этом плохого. Если вам скажут: «Это займет много времени», то спросите, как сократить время на получение знаний. Можно ли узнать что-то за день или два с помощью теста «нарисованная дверь» или опроса клиентов? Если услышите в ответ: «Это может не сработать», то соглашайтесь и снова спрашивайте, почему бы в любом случае не попробовать! Если вам отвечают: «Мы можем испортить отношения с клиентами и нанести вред бренду», то сократите масштабы тестирования до небольшой группы клиентов. Поинтересуйтесь у руководителей (возможно, один на один), опасаются ли они, что неудача повредит их карьере. Если ответ положителен, подумайте, как поощрять процесс экспериментирования, а не только результаты. Спросите своих разработчиков, как они измеряют промежуточный прогресс проводимых экспериментов — как они узнают, что находятся на правильном пути, прежде чем решаются на создание бизнеса за $100 млн? Спросите их, какую гипотезу они пытаются доказать с помощью эксперимента, и, если нужно, помогите им ее сформулировать так, чтобы ее можно было протестировать за приемлемые деньги. Эти вопросы помогут вам создать культуру, которая признает и поощряет экспериментирование и в конечном счете инновации.
Войти с помощью соц. сетей: