Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Джефф также отмечает, что привлеченные им специалисты, скорее всего, не подходили для процесса трансформации. «Я подбирал специалистов из крупных технологических компаний – Cisco, SAP, IBM и Oracle, а не истинных предпринимателей. Они думали о масштабе, а не об экспериментировании. Мне нужно было действовать не так».
Руководителям крупных компаний это может показаться странным, но иногда проблема заключается в избыточном финансировании. Когда вы вкладываете в инициативу сотни миллионов долларов и делаете это с большой помпой, на команду давит ожидание большого результата в нереально короткий срок. Подозреваю, что при более скромном финансировании и итеративном, экспериментальном подходе, они смогли бы достичь гораздо большего. Сегодня Джефф соглашается с этим: «У меня была команда и процесс, который был создан для размаха, а не экспериментирования. Жаль, что я не начал с малого, с предпринимательской командой и без лишнего шума. А к масштабированию, в котором так сильна General Electric, нужно было приступать только после первого успеха».
Огромный успех, полный провал и все, что между ними
Итак, вы проводите эксперимент, который может принести один из трех результатов: вы получаете золото, выбываете из игры или оказываетесь где-то между этими двумя исходами. Мы делаем ошибки во всех трех сценариях.
Давайте сначала поговорим о большом успехе: предел мечтаний каждого, когда исходные предположения подтверждаются, а клиенты влюбляются в идею. Но толку от экспериментов нет, если вы не в состоянии продолжить успехи победителей. В Twilio мы это уже проходили. Мы начинали эксперимент и видели, что он успешен, но по-прежнему считали его лишь экспериментом, причем довольно долго, и не давали ему финансирование, позволяющее взорвать рынок. Мы не поливали саженец должным образом.
Мы усвоили, что при проведении экспериментов необходимо придерживать в запасе ресурсы, чтобы обеспечить мощный старт для того, что принесло успех. Amazon делает это хорошо. Ее виртуальный помощник на базе искусственного интеллекта Alexa изначально был экспериментом. Когда Alexa начал приобретать популярность, в Amazon поняли, что это – особенный продукт и он нуждается в мощной поддержке.
Небольшой команде Alexa потребовалось расширение, т. е. привлечение новых специалистов. Появилось столько открытых вакансий, что команда могла бы потратить все свое время на подбор сотрудников и собеседования, вместо того чтобы создавать и эксплуатировать Alexa. Ей грозила опасность утонуть под бременем собственного успеха! Поэтому Amazon ввела правило: любой поступавший на работу в Amazon при желании имел возможность войти в команду Alexa. Только представьте: команда Alexa могла переманить любого нового сотрудника из любого подразделения. Это экстремальная версия поддержки эксперимента.
Теперь посмотрим, что происходит, когда бизнес-гипотеза оказывается ложной. Мы много говорили о выдвижении гипотез и их тестировании. Ничто не разрушает предпринимательскую, экспериментальную культуру в большей степени, чем наказание за проведение эксперимента, доказывающего ложность гипотезы. (Обратите внимание, что я не называю это «неудачей».)
Боссу легко сказать: «Мы дали вам кучу денег, но не получили популярного продукта – вы, должно быть, потерпели провал». Это гарантированный способ сделать так, чтобы никто и никогда не пытался провести эксперимент или пойти на риск.
Вместо этого смотрите на ситуацию следующим образом: «У нас была гипотеза, которая в результате оказалась неправильной. К счастью, мы выяснили это всего за три месяца и затратили $50 000. Теперь мы можем сосредоточиться на другом».
Полная противоположность этому, когда компания отряжает на отработку идеи сотни человек, тратит пять лет на создание «идеального» продукта, покупает рекламный блок в финале Суперкубка по американскому футболу, вкладывает $25 млн в рекламную кампанию – и все для того, чтобы выяснить, что клиенты равнодушно относятся к продукту или клиентов просто недостаточно для оправдания инвестиций.
Разве вы не предпочли бы выяснить это за несколько месяцев, потратив тысячи долларов, а не за годы и миллионы? Вместо страданий по поводу того, что эта маленькая команда потратила впустую $50 000, думайте о том, что они сэкономили $25 млн! Вы должны поздравить их и обеспечить как можно быстрее следующим заданием.
Наконец рассмотрим самую сложную ситуацию: ту нечеткую середину, где гипотеза остается недоказанной – ни истинной, ни ложной, а все ваши показатели оказались неприемлемыми. Это самые трудные случаи и единственная настоящая неудача для команды экспериментаторов. Если ваша цель – доказать или опровергнуть гипотезу, а вы не можете сделать ни того, ни другого за разумное время, то эксперимент фактически терпит провал. Вот почему в начале эксперимента так важна наглядность показателей.
Что делать дальше? Прежде всего убедитесь, что вы отвели на эксперимент достаточно времени. Иногда терпение – это добродетель. Измените тактику. Если выполняемые вами тесты не дают ответов, попробуйте проводить их по-другому. Возможно, ваша гипотеза непригодна для тестирования, поэтому попробуйте перевести ее в более приемлемую форму. Возможно, проблема в вашей команде – не исключено, что просто плохо работает. Неудача для эксперимента – это длительный период отсутствия ответа на вопрос, верна ли гипотеза. Во время фазы быстрых итераций полезно еженедельно или, возможно, раз в две недели связываться с командой, чтобы помочь обучению в процессе экспериментирования. Но если команда продолжает безрезультатно работать в течение полугода или года, то, не исключено, настало время внести изменения.
Когда прекратить эксперимент? Спросите своего разработчика
Чтобы преодолеть проблему неоднозначности середины и выяснить, следует ли отказаться от эксперимента, нужно, как и во многих других случаях, спросить своего разработчика. Возможно, никто не принимает решения по той причине, что нет желающих сказать бизнес-лидеру правду. Это просто человеческая природа – мало кто любит сообщать плохие новости. Но из историй о Патрике Маккензи, Райане Лесли, Лие Калвер и Чаде Этцеле вы могли понять, что инженерное мышление нередко предполагает: а) наличие твердого мнения и б) нежелание держать это мнение при себе. Для инженеров важны факты. Я просто думаю об этом так: инженеры ненавидят лажу. Так что, если вам нужен тот,
