Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [47]

Вместо этого смотрите на ситуацию следующим образом: «У нас была гипотеза, которая в результате оказалась неправильной. К счастью, мы выяснили это всего за три месяца и затратили $50 000. Теперь мы можем сосредоточиться на другом».

Полная противоположность этому, когда компания отряжает на отработку идеи сотни человек, тратит пять лет на создание «идеального» продукта, покупает рекламный блок в финале Суперкубка по американскому футболу, вкладывает $25 млн в рекламную кампанию – и все для того, чтобы выяснить, что клиенты равнодушно относятся к продукту или клиентов просто недостаточно для оправдания инвестиций.

Разве вы не предпочли бы выяснить это за несколько месяцев, потратив тысячи долларов, а не за годы и миллионы? Вместо страданий по поводу того, что эта маленькая команда потратила впустую $50 000, думайте о том, что они сэкономили $25 млн! Вы должны поздравить их и обеспечить как можно быстрее следующим заданием.

Наконец рассмотрим самую сложную ситуацию: ту нечеткую середину, где гипотеза остается недоказанной – ни истинной, ни ложной, а все ваши показатели оказались неприемлемыми. Это самые трудные случаи и единственная настоящая неудача для команды экспериментаторов. Если ваша цель – доказать или опровергнуть гипотезу, а вы не можете сделать ни того, ни другого за разумное время, то эксперимент фактически терпит провал. Вот почему в начале эксперимента так важна наглядность показателей.

Что делать дальше? Прежде всего убедитесь, что вы отвели на эксперимент достаточно времени. Иногда терпение – это добродетель. Измените тактику. Если выполняемые вами тесты не дают ответов, попробуйте проводить их по-другому. Возможно, ваша гипотеза непригодна для тестирования, поэтому попробуйте перевести ее в более приемлемую форму. Возможно, проблема в вашей команде – не исключено, что просто плохо работает. Неудача для эксперимента – это длительный период отсутствия ответа на вопрос, верна ли гипотеза. Во время фазы быстрых итераций полезно еженедельно или, возможно, раз в две недели связываться с командой, чтобы помочь обучению в процессе экспериментирования. Но если команда продолжает безрезультатно работать в течение полугода или года, то, не исключено, настало время внести изменения.

Когда прекратить эксперимент? Спросите своего разработчика

Чтобы преодолеть проблему неоднозначности середины и выяснить, следует ли отказаться от эксперимента, нужно, как и во многих других случаях, спросить своего разработчика. Возможно, никто не принимает решения по той причине, что нет желающих сказать бизнес-лидеру правду. Это просто человеческая природа – мало кто любит сообщать плохие новости. Но из историй о Патрике Маккензи, Райане Лесли, Лие Калвер и Чаде Этцеле вы могли понять, что инженерное мышление нередко предполагает: а) наличие твердого мнения и б) нежелание держать это мнение при себе. Для инженеров важны факты. Я просто думаю об этом так: инженеры ненавидят лажу. Так что, если вам нужен тот, кто скажет правду, даже если она горькая, – ищите инженера, занимающегося разработкой.

Джефф Иммельт столкнулся с подобной ситуацией на посту генерального директора General Electric, когда он с группой руководителей пытался разобраться с проблемой в конструкции нового двигателя, который был разработан для пассажирского самолета Boeing 787 Dreamliner. Инженеры свели причину к критическому недостатку конструкции турбины первого контура. General Electric оказалась перед угрозой кризиса. Компания потратила на разработку двигателя пять лет и более $1 млрд, а рынок для этого двигателя оценивался в $50 млрд.

Джефф наблюдал и слушал, как люди обсуждают, что делать дальше, и тут произошло нечто неординарное. Один из инженеров-разработчиков, создававших турбину, встал. Он не был ни менеджером, ни руководителем, а всего лишь рядовым конструктором. Но он сказал то, что большинство, по всей видимости, не хотело слышать: «Это плохая конструкция. Мы неправильно спроектировали двигатель. Он не работает должным образом, это обойдется нам в сотни миллионов долларов, но мы должны его переделать».

Как вспоминает Джефф, «это был старший технолог, который даже не задумывался о политкорректности. Он сказал это совершенно уверенно! Он знал, что последствия такого решения обойдутся компании в $400 млн».

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

Однажды и я совершил эту ошибку. В начале работы компании Twilio мы заключили сделку с крупным телефонным оператором по созданию нескольких коммуникационных приложений для клиентов в области малого бизнеса. Это выходило довольно далеко за пределы нашего основного бизнеса, и разработчики, которых я попросил заняться приложениями, сомневались в мудрости моего решения. Я выслушал их опасения, но все равно попросил написать приложения, поскольку это помогло бы нам расширить отношения с оператором. «По стратегическим соображениям», – сказал я им тогда. В течение большей части года они с полным осознанием долга писали приложения, хотя и не переставали сомневаться в этом решении. Буквально за день до запуска один из топ-менеджеров оператора передумал и разорвал контракт. Работа наших разработчиков так и не увидела свет. Никто ничего мне не сказал, но фраза «Мы же тебе говорили» явно вертелась у разработчиков на языке.