Дэвид Данкан - Закон успешных инноваций - Зачем клиент «нанимает» ваш продукт и как знание об этом помогает новым разработкам

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

Ураганы «Катрина» и «Рита», обрушившиеся на побережье Мексиканского залива в 2005 году с разницей в месяц, породили целую серию новых впечатлений и процессов, необходимых для выполнения обещания о душевном спокойствии. Когда пришел ураган «Катрина», OnStar был достаточно нов и еще не эксплуатировался в условиях природной катастрофы. Когда на информационно-справочную службу обрушился шквал звонков, тут же вскрылись самые различные проблемы, не учитывавшиеся ранее. Звонок мог поступить от находящегося в состоянии паники клиента за рулем, которому сообщали, что его план OnStar не подразумевал инструкции в режиме реального времени. Изначально OnStar требовал, чтобы клиенты приобретали модернизированную версию с доступом к плану, который предоставлял инструкции.

К моменту приближения «Риты» OnStar осознал сложившуюся ситуацию: эти проблемы касались не только отдельных пользователей, но приобрели масштаб регионального кризиса. И хотя нельзя представить более мощного стимула к покупке апгрейда, чем возможность быть застигнутым ураганом, людям, предоставляющим данную услугу, такая позиция казалась неправильной – она не согласовывалась с работой, на которую их нанимали. Поэтому сотрудник, отвечавший за эту часть сервиса OnStar, принял решение незамедлительно предоставлять звонившим из зоны бедствия все функции, предлагаемые OnStar, не требуя апгрейда текущего плана. Вне всяких сомнений, это было правильное решение, говорит Хубер, «разговор занял всего пятнадцать секунд в моем офисе. Не думаю, что найдется много компаний, где подобное было бы возможным».

Не в самую последнюю очередь потому, что принять решение и выполнить его – два совершенно разных действия. Уровень разработки OnStar на тот момент технически не позволял сотруднику просто объявить, что все находившиеся в опасных зонах автоматически получат доступ ко всем услугам OnStar. Сервису пришлось ввести несовершенные обходные варианты – «нам предстояло быстро соорудить нечто из клейкой ленты и застежек-липучек», как вспоминал впоследствии сам Хубер. Например, OnStar нужно было разработать систему, которая бы отслеживала звонки из зоны бедствия и перенаправляла их в специальную справочную службу, имеющую доступ к полезной информации в реальном времени, в частности оптимальным путям эвакуации или актуальным прогнозам погоды. Реализовать все это на практике представлялось делом непростым. Однако сложности осуществления никогда не затеняли ясность поставленной цели. Команда была сориентирована с точностью лазера. По мнению Хубера, необходимая для выполнения работа служила компасом.

Как и Кук из Intuit, Хубер обнаружил, что сила фокусирования на необходимой для выполнения работе простирается намного дальше, нежели понимание того, какие свойства и функции нужны больше всего. Ясность необходимой для выполнения работы мотивировала сотрудников выкладываться на сто процентов, поскольку они отчетливо понимали, почему это так важно. Когда стрелка на «двустороннем компасе» явственно указывает на глубокое понимание работы, должен сдвигаться и второй ее конец, настраиваясь на более подробные характеристики работы.

«Стоило возникнуть чему-то, о чем мы никогда не задумывались, но очевидно связанному с нашим компасным направлением движения, как люди просто делали что надо. Просто принимались за работу, – говорит Хубер. – Мы не видели типичной реакции "Не вешайте на меня еще и эту обязанность"». Вместо этого, утверждает Хубер, повторяя слова Кука из Intuit, команда нередко черпала силы в этом фокусе.

Приведем пример двустороннего компаса в действии. После того, как в ходе обсуждений с врачами из пунктов скорой помощи выяснилось, что передача спасателям службы 911 заблаговременной информации о тяжести автомобильной аварии может спасать жизни, команда Хубера с готовностью сплотилась вокруг цели с новыми процессами. Им предстояло решить исключительно трудную техническую проблему – какая информация помогала установить серьезность автокатастрофы? Возникла потребность в сложном алгоритме и возможность автоматического определения релевантной информации. Изменение скорости. Использование ремней безопасности. Направление силы удара. Сколько машин участвовало в аварии? И так далее. «Помню обсуждение с инженерами, – вспоминает Хубер. – Я немного нервничал. Определенно, дело было нужное, но очень уж непростое и дорогостоящее. Но через относительно короткий промежуток времени они вернулись и ответили: „Мы, скорее всего, с этим справимся“. И не потому, что я заставлял их вкалывать по ночам и выходным. Просто они знали, что поставлено на карту, и это идеально соотносилось с работой, на которую нас нанимали. Мы ведь не над тем трудились, как встроить в сервис OnStar купоны на латте в Starbucks. Мы жизни могли спасать».