Это было Рождество 2012 года, и Facebook был популярным как никогда. Смартфоны и цифровая фотография тоже становились более востребованными, а Facebook был, бесспорно, самым популярным местом загрузки фотографий. Но даже с учетом всех этих преимуществ у социальной сети появилась новая проблема: пользователи стали жаловаться на непристойность миллионов фотографий. Чтобы своевременно просматривать все эти изображения, потребовались бы тысячи людей.
Эта история, впервые рассказанная NPR (возможно, речь о National Public Radio, крупнейшей государственной радиостанции США – ред.) в 2015 году, привлекла внимание читателей[5]. Но технологический мир слышал подобные истории и раньше. Компании, работающие в цифровом пространстве, все чаще сталкиваются с подобным эффектом: они запускают программное обеспечение, что приводит к непредсказуемым последствиям и реакциям на это. Все потому, что цифровая революция привнесла в мир бизнеса два важнейших фактора. Первый из них – это неопределенность: по мере усложнения программных продуктов становится все труднее прогнозировать, как люди будут их использовать. Наиболее продвинутые компании адаптируют свои процессы так, чтобы реагировать на эти неожиданности, задействуя второй фактор – непрерывные изменения. В отличие от промышленных, цифровые продукты могут быть оперативно изменены и обновлены. Компании, которые применяют принцип непрерывного изменения к своим продуктам, услугам и к своему бизнесу в целом, способны быстро адаптироваться в условиях неопределенности.
Прежние способы реакции на непредвиденные последствия не работают в цифровую эпоху. К примеру, метод тщательного, детального планирования снова и снова терпит неудачу. В 2013 году BBC прекратила попытки, которые она предпринимала на протяжении десяти лет, по созданию единой корпоративной системы управления контентом. Система под названием Digital Media Initiative должна была позволить сотрудникам BBC создавать цифровой контент, делиться и управлять им со своих рабочих мест. Несмотря на тщательные планы, разработанные командой проекта и спонсорами, после многих лет и потраченных почти 100 млн фунтов, проект не принес никаких результатов. Менеджеры проекта жаловались на то, что требования постоянно менялись, и это делало невозможным его реализацию. Другими словами, независимо от того, насколько усердно они занимались планированием, эти планы никак не могли воплотиться в жизнь. Условия постоянно менялись. Проект BBC провалился.
Каждый бизнес-лидер, с которым вы общаетесь, скорее всего, может рассказать вам похожие истории, связанные с проектами программного обеспечения и стратегическими инициативами, которые не смогли обеспечить улучшение стоимостных показателей и рост бюджета, соблюдение сроков выхода продукта или вовсе не смогли его представить. Ежегодно наше общество теряет сотни миллиардов долларов на неудачных попытках по разработке программного обеспечения, в основном потому, что управленцы считают, будто могут использовать подходы к управлению времен индустриальной эпохи для решения проблем цифровой эпохи.
В то же время программное обеспечение стало важнейшим элементом любого бизнеса, вне зависимости от его размеров. К примеру, в Goldman Sachs самым крупным подразделением сейчас является отдел технологий, в котором работают 8 тысяч – то есть 25 % – из 32 тысяч всех сотрудников.
Мы наблюдаем, как с развитием цифровых технологий трансформируются товары и услуги. Появление iPhone от компании Apple стало приговором для Nokia и RIM – двух компаний, которые специализировались на технологических продуктах, но не смогли справиться с непредсказуемыми изменениями, обусловленными цифровой революцией. Amazon «похоронил» Borders и Barnes & Noble. А Netflix сделал это с Blockbuster.
Технологическая революция уже началась. Мы не можем предсказать, по каким правилам она будет проходить. Покупатели используют IT-продукты самыми непредсказуемыми способами. Конкуренты появляются там, где мы их меньше всего ожидаем. Этот новый уровень изменяемости и неопределенности является одним из побочных эффектов цифровой революции. Нам необходимы новые способы реагирования.
Команда Facebook могла бы просто нанять больше экспертов для решения проблемы с «непристойными» фотографиями, но, прежде чем сделать это, сотрудники сами начали просматривать указанные фотографии. Именно тогда команда Facebook обнаружила нечто странное: большинство изображений на самом деле не были неуместными. Там были фотографии людей в уродливых свитерах, людей, которые тусовались со своими бывшими, и людей в нелепых позах. Но фотографии не являлись непристойными – на них не были запечатлены ни изображения обнаженного тела, ни проявления харрасмента, ни пропаганда наркотиков или какой-либо ненависти. Но у инструмента фотоконтроля Facebook не было такой категории, как «уродливые свитера», поэтому, если вам не понравилась фотография, выбор обозначить причину у вас был невелик: приходилось выбрать один из пунктов, чтобы отметить эту фотографию, и пункт «непристойное изображение» подходил больше, чем остальные.
Это неопределенность. Пользователи подходят к системе с собственными идеями о том, чем она может быть им полезна. Если они не видят простого способа достичь желаемого, они попытаются найти его. Точно так же, как поток воды обтекает препятствия, срезая непредсказуемые участки на пути, так и группа клиентов найдет самые легкие, быстрые пути для достижения своей цели. Если они смогут найти способ сделать это в вашей системе, они это сделают, даже если это окажется тем, что вы не могли предсказать, например, сообщат, что какое-то фото является непристойным. А если они не смогут найти способ для достижения своей цели, они, скорее всего, откажутся от ваших услуг в пользу чего-либо лучшего.
Команда разработчиков Facebook отреагировала, пытаясь использовать функцию отчетности, – применила то, что мы называем подходом «почувствовать и отреагировать» к решению проблемы неопределенности. Поскольку члены команды не были уверены в том, что происходит, они стали обновлять продукт так, чтобы самим понять, в чем же дело. Сначала они добавили новый пункт в процесс подачи отчета – вопрос «Почему вы жалуетесь на эту фотографию?». Этот открытый вопрос помог им узнать, что в большинстве случаев люди впадали в замешательство, пытаясь сформулировать, почему они жалуются на ту или иную фотографию. Вооружившись этим знанием, команда снова обновила продукт, на этот раз попросив людей связаться с тем, кто выложил ту или иную фотографию. Это отчасти помогло, но не решило всю проблему.
КОНКУРЕНТЫ ПОЯВЛЯЮТСЯ ТАМ, ГДЕ МЫ ИХ МЕНЬШЕ ВСЕГО ОЖИДАЕМ. IPHONE ОТ КОМПАНИИ APPLE СТАЛ ПРИГОВОРОМ ДЛЯ NOKIA И RIM, КОТОРЫЕ НЕ СМОГЛИ СПРАВИТЬСЯ С НЕПРЕДСКАЗУЕМЫМИ ИЗМЕНЕНИЯМИ, ОБУСЛОВЛЕННЫМИ ЦИФРОВОЙ РЕВОЛЮЦИЕЙ.
Затем команда Facebook добавила окно для ввода сообщения, чтобы люди могли им воспользоваться для прямой связи с тем, кто выложил ту или иную фотографию. Команда протестировала этот вариант. Результат стал несколько лучше. Затем они добавили опцию сообщения по умолчанию в окно для ввода сообщений. Стало еще лучше. Члены команды испробовали множество различных небольших изменений, тестируя их на небольших сегментах пользователей. Всякий раз изменения были нацелены на устранение проблемы и получение большей информации о ней.
Наконец путем уточнений, вопросов, тестов и измерений команда смогла решить проблему. Инструмент отчетности теперь обладает целой категорией опций для реакции на обескураживающие фотографии, направляет пользователей связаться с человеком, который выложил фотографию, и предлагает шаблонное письменное сообщение (которое пользователи могут редактировать, но редко это делают).
Тем не менее, если вы сейчас зайдете на Facebook и пожалуетесь на фото, есть вероятность, что вы увидите нечто отличное от того, что описано здесь. Все потому, что где-то на Facebook кто-то, оценив показатели этого инструмента, возможно, заметит проблему и займется тестированием, чтобы улучшить ситуацию. Вот что значит почувствовать и отреагировать, и это процесс, продолжающийся во времени.
Неопределенность, с которой столкнулась команда Face-book, является новой нормой. Тактика, которую она применила, является новым стандартом того, как нужно реагировать. И хотя тактику можно рассматривать как простой управленческий подход (измерение поведения пользователей, тестирование решений, масштабов, на которых оно сработает), она опирается на возможность действовать, и действовать быстро. До сих пор здравое реагирование в коммерческих и государственных компаниях ассоциируется с тем, что технологии – это дело специалистов, отделенных от основных бизнес-операций. Теперь мы знаем, что этот подход не годится. А причиной тому является следующее – он снижает способность бизнеса к действиям.
Другими словами, мы больше не можем позволить себе игнорировать технологии или оставлять их использование узким специалистам. Вместо этого мы все должны научиться справляться с ними – и с неопределенностью, которую они создают, и с возможностями, которые они предоставляют. Реальность такова: возложить ответственность за программное обеспечение на ИТ-отдел – это все равно что возложить ответственность за дыхание на «отдел кислорода».
Чтобы понять, почему мы выступаем за изменение того, как мы управляем нашими компаниями, необходимо сделать шаг назад, и разобраться, что же изменилось. Большая часть науки менеджмента, которую мы воспринимаем как должное, была разработана для производства определенного вида продукции. Поскольку производство изменилось (теперь мы создаем разные вещи по-разному и из новых материалов), наш подход к управлению тоже должен измениться.
Все мы знаем историю о Генри Форде и сборочном конвейере: разбив рутинную, повторяющуюся работу на небольшие участки, Форд смог революционизировать производство, занять доминирующее положение в автомобильной промышленности и изменить подход предприятий во всем мире к производству материальных товаров. Эта модель имела огромную ценность и стала главной моделью того, как должен выглядеть бизнес.
Наше раннее знакомство с персональными компьютерами и программным обеспечением мало свидетельствовало о том, что эти продукты отличаются от автомобилей (или от любого другого современного инженерного продукта, который создается методом сборочного конвейера). Конечно, ноутбуки, телефоны и другие высокотехнологичные устройства, которые мы покупаем, производятся на сборочных линиях – очень продвинутых, но все же конвейерах. И первые приобретенные потребителями компьютерные программы, казалось, были похожи на любой другой продукт. Мы приходили в компьютерный магазин, выбирали большую, запакованную коробку Microsoft Office или Lotus 1-2-3 и несли ее домой, чтобы установить на персональный компьютер. Эти продукты, безусловно, были «производственными» товарами, даже если разработчики программного обеспечения того времени подозревали, что что-то изменилось.
Но начиная с первой волны развития интернет-компаний в конце 1990-х годов мы стали наблюдать появление нового вида распространения программного обеспечения – как услуги SaaS (software as a service) – одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное ПО, полностью обслуживаемое провайдером – перев.). В этой модели мы не устанавливаем программное обеспечение на наши локальные компьютеры. Оно работает на сервере компании, и мы используем его через интернет и наши браузеры. Новшество, предложенное SaaS-компаниями, заключалось в том, что нам не нужно больше идти в магазин и снова обновлять программу; последняя версия программы будет всегда доступна, потому что она всегда работает на серверах компании.
Этот переход может показаться незначительным изменением процесса, однако сложно переоценить, насколько значителен сдвиг парадигмы, который он собой представляет. Почему? Все потому, что производственный процесс (копирование программного обеспечения на дискеты, CD- или DVD-диски) больше не является частью процесса распространения программного обеспечения. И исключив этот шаг, мы создали принципиально новую модель.
В этой новой модели изменяется подход к разговору с клиентами: вам больше не нужно убеждать их приобрести новую версию. Вы просто размещаете ее на вашем сервере. Также вам больше не нужно убеждать их устанавливать ваше обновление: они увидят его при входе в систему.
Более того, новая модель меняет экономические стимулы. В отраслях, которые построены на массовом производстве, высокая стоимость запуска новых продуктов компенсируется эффективностью сборочной линии, поэтому естественным стимулом является создание производственных линий единожды, а затем на них можно штамповать максимальное количество единиц товара. Автопроизводители создали хорошо известный ежегодный цикл продуктов «модель года», позволяющий и извлечь выгоду, и удовлетворить потребности рынка в новых товарах. Этот ежегодный ритм настолько стал нам привычен, что кажется вполне естественным, хотя это не так: это просто стратегия, основанная на производственном цикле.
Рассмотрим один потрясающий факт: Amazon выпускает очередное обновление программного обеспечения каждые 11,6 секунд[6]. Возможно, это происходит благодаря набору приемов, называемому непрерывным развертыванием. По сути, непрерывное развертывание позволяет разработчикам программного обеспечения поддерживать системы в состоянии постоянной готовности и вносить в них дополнительные изменения. Amazon занимает лидирующие позиции в этой сфере, но для других крупных компаний ежедневное обновление программного обеспечения стало обычным делом, а во многих компаниях это происходит по несколько раз за день.
Что это означает в плане управления? Мы считаем, что не будет преувеличением сказать, что это меняет всё. В цифровом мире больше нет никакого «промышленного производства». В мире с зафиксированными стадиями производственного процесса цена изменений высока: всякий раз, когда вы вносите изменения в продукт, вам нужно снова проходить через весь процесс производства, а это влечет за собой расходы. Таким образом, есть смысл ограничивать частоту изменений в производимых товарах. Однако, освобожденные от производственной стадии процесса, мы устраняем этот сдерживающий фактор. Ограничения на изменения существуют в других частях системы – например, сколько изменений может «переварить» пользователь или сколько изменений мы можем внести без ущерба качеству или увеличения других затрат. Но как демонстрируют лидеры отрасли, такие как Amazon, эти ограничения гораздо менее жесткие, чем мы могли бы представить. На практике теперь можно представлять новые функции, возможности и услуги клиентам и собственным сотрудникам на постоянной основе и в удивительно быстром темпе.
Почему Amazon так часто выпускает обновления? Не просто потому, что он это может. Нет, выпуск программного обеспечения зачастую является единственным индикатором подхода «почувствовать и отреагировать». Такой подход к работе подразумевает оперативные циклы чувствования того, что нужно рынку, и быстрое реагирование на эти потребности. Как вы убедились на примере с Facebook, этот подход позволяет командам понять всю сложность продукта, уменьшить неопределенность и найти новые конструктивные решения.
Давайте рассмотрим некоторые преимущества такой работы.
Первое поколение потребительского программного обеспечения изменило методы нашей работы. Электронные таблицы и текстовые программы обеспечили резкий рост в личной производительности. При этом программное обеспечение первого поколения также было гибким. Это выражалось в том, что, когда организации пытались предоставлять цифровые услуги, зачастую результат был плачевным. Неэффективным. Сбивающим с толку. Сложным в использовании.
Представьте, что вы звоните, например, в колл-центр, чтобы узнать о своем телефонном счете. Как часто вы слышали, чтобы оператор колл-центра не справляется со своей компьютерной системой? В прошлом часто приходилось подстраивать бизнес-процессы и поведение клиентов под то, как работает программа, поскольку скорость, с которой мы могли изменить программу, была медленной. Как-то раз мы подслушали беседу группы руководителей производства пластмассы, сравнивающих контрольные показатели в процессе обслуживания клиентов. Они оценивали, сколько заказов каждая из компаний обрабатывала ежедневно. Средним значением, кажется, было тридцать заказов в день. Затем один из руководителей сказал: «Мы обрабатывали около тридцати заказов в день. Потом мы установили новую систему приема заказов. Теперь мы обрабатываем примерно два заказа в день».
Благодаря новой возможности изменять программу на постоянной основе, у компаний также появились новые возможности – предоставлять клиентам услуги, основанные на электронных способах. Программное обеспечение, которое может быть весьма гибким, теперь оправдывает свой «программный» потенциал, и эта гибкость предоставляет нам новую общую маневренность, когда дело касается предоставления услуг рынку. Если раньше мы порой внедряли недостаточно востребованные услуги, то теперь мы можем корректировать их до тех пор, пока они не станут эффективными. И если нам нужно изменить стратегию или процесс, мы можем внести коррективы в программное обеспечение, которое легко их поддержит.
Если вы следите за новостями, то наверняка слышали о крупных технологических проектах, которые терпят неудачу. Недавний заголовок на CIO.com был весьма прямолинейным: «Успешность корпоративного программного обеспечения остается расплывчатой»[7]. Аналитики The Standish Group, изучающие результативность технологических проектов, уже много лет проводят сравнительной анализ отрасли. Самое последнее исследование показывает, что частота неудач ИТ-компаний составляет около 70 %, что, конечно, лучше, чем 80 % в 1990-х годах, но все же.
В Массачусетсе, например, правительство штата потратило более девятнадцати лет и больше 75 млн долларов на систему, которая соединяла суды штата друг с другом. Создание этой системы должно было занять пять лет. Однако спустя девятнадцать лет многие обозреватели считают проект незавершенным и бесполезным. И это очень дорогостоящая неудача.
Методы «почувствовать и отреагировать» могут в этом случае помочь. Традиционные ИТ-проекты склонны придерживаться подхода «большого взрыва» (Метод тестирования «большой взрыв» – вид интеграционного тестирования, в котором элементы программного или аппаратного обеспечения, или они оба, собираются в компонент или в целую систему сразу, а не по этапам – перев.), при котором программное обеспечение не предоставляется пользователям до тех пор, пока оно не будет готово «под ключ». Это означает, что до самого завершения проекта трудно сказать, находится ли построение системы на правильном пути. В то же время agile-подход, лежащий в основе метода «почувствовать и отреагировать», позволяет решить эту проблему путем частого запуска рабочих вариантов системы с самых ранних дней проекта. Это уменьшает риск того, что команда разработчиков отклонится от курса, и позволяет наблюдать за тем, что делает команда, поскольку она постоянно делится результатами своего труда.
Эта прозрачность является ключевым фактором, поскольку подразумевает наличие обратной связи. Работает ли программное обеспечение? Отвечает ли оно потребностям пользователя? Отвечает ли оно целям, которые преследует компания? Зачем тогда ждать до конца проекта?
Представьте на мгновение, что вы являетесь исполнительным директором компании Amazon. Вы владеете огромной интернет-компанией, и, когда люди что-то у вас покупают, вы зарабатываете на этом деньги. Чтобы потребители могли что-нибудь у вас купить, они должны завершить процесс оформления заказа на вашем сайте. Таким образом, в ваших интересах оптимизировать процедуру оформления заказов так, чтобы люди могли успешно с этим справляться. Вы не хотите запутывать их. Не хотите отвлекать их. Вы хотите вести их по течению до тех пор, пока они не завершат транзакцию.
Один из приемов, который использует Amazon и похожие компании, направленный на очень быструю оптимизацию процесса, заключается в выпуске различных версий какой-либо части веб-сайта (например, процедуры оформления заказов) и направлении входящего трафика в разные версии для сравнения их производительности. Это научный метод в действии. Он получил название A/B-тестирование и стал стандартным приемом в онлайн-мире. Например, этот метод был использован командой Facebook для тестирования своих решений относительно проблемы жалоб на фотографии. Такие компании, как Amazon, ежедневно осуществляют множество тестирований для оптимизации своих потоков. И хотя может показаться, что эти процессы оптимизации не очень ценны, на самом деле все наоборот. В одном хорошо известном случае крупный онлайн-ритейлер запустил годовой объем продаж в 300 млн долларов, изменив текст для одной из кнопок в процедуре оформления заказа[8].
В 2012 году команда предвыборной кампании Обамы использовала этот метод почти для всех опций, что они запускали на своем веб-сайте. В одном случае команда пыталась оптимизировать страницу пожертвований. Члены команды испробовали множество вариантов, прежде чем решили попробовать добавить цитату президента на страницу. По сравнению со страницей без цитаты, эта страница принесла увеличение пожертвований на 11,6 %. Эта цифра может показаться не особо большой, но, учитывая сам объем, это простое изменение за все время кампании увеличило сумму пожертвований на миллионы долларов[9].
Такой подход к процессу оптимизации обусловлен двумя важными факторами. Во-первых, вам нужна техническая инфраструктура, чтобы осуществить эти тестирования, собрать результаты и быстро отправить их нужным адресатам. Более важным является второй фактор: отношение руководства. Менеджеры должны быть в состоянии признать, что у них нет всех ответов, и они должны быть готовы в правильных обстоятельствах представить свои идеи для тестирования на рынке. Этот новый менталитет менеджмента является лишь первым элементом из числа важных управленческих инноваций, которые необходимо внедрить, если компании хотят добиться успеха в цифровую эпоху.
Чтобы понять, что мы называем «возникающей ценностью», необходимо оглянуться назад и оценить характер товаров и услуг, появившихся благодаря технологиям.
В ранние дни компьютерной революции, когда на рынке появлялись первые персональные компьютеры, люди говорили об «убойном приложении» – приложении, которое было бы настолько полезным и убедительным, что стимулировало бы масштабную покупку этих машин. Можно утверждать, что программы для обработки электронных таблиц (сначала VisiCalc, а затем Lotus 1-2-3) были движущей силой большей части первых покупок ПК. Для других убойным приложением являлся текстовый редактор. Но в любом случае, использование этих программ было схожим: человек, сидя за компьютером, взаимодействует с программным обеспечением и генерирует большую производительность с помощью более эффективного инструмента.
Теперь подумайте об убойном приложении нашей эпохи. На секунду представьте себе компьютер без подключения к интернету. Или, что еще хуже, представьте себе смартфон, который постоянно находится в режиме полета. Без подключения наши устройства практически бесполезны – они теряют большую часть своей ценности. Это происходит потому, что все чаще наши гаджеты подключают нас к услугам и, что еще важнее, к другим людям в интернете. Мы используем Twitter и Facebook, чтобы делиться новостями и информацией. Для покупок мы используем Amazon. Мы используем Uber, чтобы вызвать такси, а Google Maps и Waze – для навигации и получения информации о дорожной обстановке, собранной другими пользователями системы, в режиме реального времени. Наши приложения больше не являются автономными программами, работающими на наших персональных компьютерах.
И дело не только в том, что пользователи занимаются чем-то новым, что связано с этими технологиями. Компании все чаще предоставляют свои основные услуги с помощью связанных технологий. К примеру, Simple Bank – это банк, который доступен только через программу, несмотря на то, что там есть реальные люди, работающие за кадром. Компания Weight Watchers (компания, разработавшая методики для снижения веса – ред.) пополняет свои традиционные каналы, позволяя клиентам связаться с тренером через приложение в смартфоне.
Проектирование и создание таких систем требует иного подхода к управлению. Когда вы начинаете подключать приложения к более крупным системам связи, вы начинаете сталкиваться со сложностями и, соответственно, иным уровнем неопределенности. Сложно предсказать, как группы людей будут использовать эти системы и, как следствие, какие части системы они посчитают ценными.
Рассмотрим явление хештега. Это вездесущее средство пометки контента и бесед в интернете, пришедшее от пользователей Twitter в 2007 году в качестве способа связывать беседы друг с другом. Эта функция не была запланирована или введена Twitter. Скорее, пользователи системы начали отмечать свои разговоры ключевыми словами, которые они отправляли с помощью ведущего (хеш) символа – «#». Этот метод стал популярным среди пользователей, поскольку они могли договориться о теге, а затем использовать обычную функцию поиска в Twitter, чтобы найти все твиты с этим тегом. Другими словами, это способствовало появлению ценности и распространенности. Только два года спустя, в 2009 году, Twitter отреагировал на это, добавив функцию, которая относилась конкретно к хештегам, в систему. Twitter автоматически вставил гиперссылки во все теги, и, кликая по этим ссылкам, теперь можно было возвратиться к результатам по этому тегу[10].Теперь Twitter превратил хештег в доходный продукт: вы можете заказывать рекламу, которая использует конкретные хештеги для целевых аудиторий.
История о хештегах – это пример того, как компания реагирует (хоть и с опозданием) на непредсказуемое поведение своих пользователей таким образом, что притягивает их и создает ценность. Когда мы можем понять то, что хотят пользователи, у нас появляется основа для создания сервиса, что создает ценность для бизнеса.
Но компании, которые не готовы отреагировать на непредсказуемое поведение пользователей, сталкиваются с большими проблемами. В уже упоминавшемся примере с BBC Digital Media Initiative управляющие технологическим процессом менеджеры жаловались, что одна из причин неудачи проекта заключалась в том, что пользователи постоянно меняют требования к системе. Это распространенная претензия в мире технологий: одни указывают на непостоянство пользователей, другие обвиняют технологов в том, что те не реагируют на изменения. Реальность более коварна. Хотя тщательное изучение и анализ потребностей пользователей являются важными и ценными атрибутами, этого не всегда достаточно. Зачастую требования не могут быть известны заранее, и, как только систему запускают, обнаруживаются новые потребности, создающие новые требования.
И снова эта неопределенность в работе. Как показывает история с хештегом, если компании открыты для неопределенности, они могут почерпнуть в непредсказуемое поведении пользователей новые идеи. Если они могут отреагировать соответствующим образом, это явление – непредсказуемое поведение – превращается в непредсказуемую ценность. С другой стороны, когда компании пытаются прогнозировать будущее и отвергают возникающую реальность, пробел между планами и реальностью, вероятно, приведет к разочарованию, задержке и провалу проекта.
Хотя адекватно реагировать непросто. От руководителей требуется принятие нового мышления и готовность корректировать планы в ответ на новую информацию. Это новое мышление включает в себя принятие постоянных изменений и неопределенности, поиск обратной связи с рынком и готовность рассматривать эту обратную связь как потенциал для создания новых ценностей. Иначе говоря, лидерам нужно сказать: «Я не знаю ответа. Давайте узнаем его вместе».
Для типичного лидера XX века фраза «я не знаю» была табуированной. Признание в неуверенности (самому себе или другим) воспринималось как признак слабости. Этот способ мышления остается распространенным во многих организациях и представляет особую проблему, когда дело касается поиска возникающей ценности в сложных адаптивных системах: систем с большим количеством компонентов, которые ведут себя и взаимодействуют таким образом, что прогнозирование становится невозможным. В нашем контексте это системы, в которых невозможно точно предсказать, как люди будут с ними взаимодействовать и какие функции они будут использовать.
В статье в Harvard Business Review Дэвида Сноудена и Мэри И. Бун описывается, чем эти системы отличаются от механических систем индустриальной эпохи:
«Это как разница между, скажем, автомобилем Ferrari и бразильскими тропиками. Автомобили Ferrari – сложные машины, но опытный механик может разобрать одну из них и снова собрать, ничего при этом не изменив. Автомобиль статичен, а целое – это сумма его частей. С другой стороны, тропики находятся в постоянном потоке – какие-то виды вымирают, погодные условия меняются, сельскохозяйственный проект перенаправляет источник воды, и вся их совокупность – это намного большее, чем просто сумма их частей. Это область «неизвестные неизвестности», в которую переместилась большая часть современного бизнеса.»[11]
Не принимая неопределенность, вы не можете извлечь выгоду из нее. Поэтому многие компании идут по пути запуска перманентных, небольших, оперативных экспериментальных циклов, что и составляет суть подхода «почувствовать и отреагировать». Непрерывно внося небольшие изменения и оценивая результаты, команды в процессе работы находят тот метод, который теоретики, описывающие поведение сложных систем, рекомендуют для работы с этими непростыми комплексами.
С началом цифровой революции, привнесшей новые уровни сложности и неопределенности, большинство компаний пытались управлять ею, используя методы индустриальной эпохи, которые до того момента хорошо со всем справлялись. Используя аналогию Сноудена и Бун, мы представляли программное обеспечение чем-то вроде Ferrari. Мы не изменили проверенные методы и, конечно же, не рассматривали вопрос об изменении способа ведения нашего бизнеса с учетом новых реалий.
Однако по мере того, как мы становились все более опытными в использовании программ, мы научились лучше управлять компанией. Наши подходы – agile-методики, которые стали использоваться повсеместно, – позволили нам начать относиться к программному обеспечению больше как к тропикам. Наш процесс управления программным обеспечением теперь, скорее, лесоводство, нежели инженерия.
Теперь мы готовы сделать следующий шаг. Поскольку мы осознаем растущую зависимость от программных систем и серьезность того, как цифровая революция связала наши предприятия с остальным миром через эти системы, мы должны начать управлять нашими компаниями с помощью методов, которые мы применяем в программном обеспечении. Другими словами, если когда-то мы управляли своими программами так же, как компаниями, теперь необходимо управлять своими компаниями так же, как мы управляем нашим программным обеспечением.
Чтобы работать в этом новом, непрерывном ритме, команды должны быть свободны. Они должны свободно экспериментировать и обучаться. Это означает, что командам нужно предоставить больше полномочий для принятия решений. Подход сборочной линии индустриальной эпохи стремился отделить интеллектуальный труд (область управления) от физического (область рабочего). Он пытался превратить рабочих в сборочные машины. Но люди не машины, и процесс выявления потребностей рынка и быстрого реагирования не вписывается в такого рода подход, направленный на минимизацию самостоятельного мышления и принятия решений. В этом новом мире стало меньше решений, которые могут быть спущены «сверху» «вниз» и вписаны в размеренный рабочий поток. Теперь многие решения должны приниматься «снизу» «вверх» людьми, которые имеют опыт работы с данными и доступ к самой последней информации. Эти люди являются самыми близкими к рынку, а не к руководству организации.
ПОЧЕМУ AMAZON ТАК ЧАСТО ВЫПУСКАЕТ ОБНОВЛЕНИЯ? НЕ ПРОСТО ПОТОМУ, ЧТО ОН ЭТО МОЖЕТ. ТАКОЙ ПОДХОД К РАБОТЕ ПОДРАЗУМЕВАЕТ ОПЕРАТИВНЫЕ ЦИКЛЫ ЧУВСТВОВАНИЯ «БОЛЕЙ» РЫНКА И БЫСТРОЕ НА НИХ РЕАГИРОВАНИЕ.
Давайте в качестве примера рассмотрим компанию Etsy, десятилетний интернет-стартап со штаб-квартирой в Нью-Йорке. Etsy – это рынок, на котором покупатели могут приобрести товары ручной работы более чем у миллиона независимых продавцов; считайте, что это крупнейшая в мире онлайн-ярмарка ремесел. Etsy известна своей культурой постоянных экспериментов. Она непрерывно тестирует и оптимизирует дизайн своего веб-сайта и мобильных приложений с помощью уже описанного метода A/B-тестирования. Компания разрабатывает несколько версий функции, выпускает их в течение короткого периода для небольшого, но тщательно отобранного числа пользователей, а затем отслеживает результаты. Эти продуманные схемы позволяют Etsy свернуть безуспешные проекты и запустить успешные изменения за пределы первоначальной испытуемой группы. И все это происходит очень быстро. Используя методы непрерывного развертывания, многие из которых она сама создала, Etsy способна постоянно вносить множество небольших изменений на своем веб-сайте, как правило, по 40–50 раз в день. Etsy также известна своей децентрализованной культурой. Каждая из команд, действуя в рамках стратегических принципов, свободно экспериментирует, обучается и вносит корректировки.
Etsy – это исключительно цифровой стартап, насчитывающий в своем штате около восьмисот человек и имеющий годовой доход в 275 млн долларов при общих продажах примерно на два миллиарда долларов в год[12]. Etsy по праву считается истинно цифровой компанией. Как насчет более традиционных отраслей?
Раз уж мы упомянули сборочные линии Генри Форда, давайте рассмотрим автомобильную промышленность, которая постоянно совершенствуется благодаря цифровым технологиям.
В марте 2015 года компания Tesla Motors, амбициозный производитель электромобилей, объявила о том, что займется решением одной из своих самых больших проблем, препятствующих пути к успеху, – проблемы, которую они называют «боязнь ограничения дальности поездки»: страх того, что электромобиль разрядится в таком месте, где в ближайшем радиусе не будет станции зарядки. Илон Маск, основатель компании, пообещал представить новую функцию, которая решит эту существенную проблему.
Около недели пресса и любопытные наблюдатели судачили по поводу того, как Tesla решит эту проблему. Затем на пресс-конференции Маск представил решение, а именно новую функцию под названием «уверенность в дальности поездки». Эта функция отслеживает использование заряда и условия движения в режиме реального времени (как быстро вы ехали? какая была погода? ровная дорога или холмистая?) для постоянного прогнозирования оставшегося запаса заряда. В то же время функция отслеживает местоположение ближайшей станции зарядки. С помощью этой функции автомобиль предупредит вас, когда вам понадобится подзарядка, и направит к наиболее подходящей зарядной станции. Маск заявил, что у автомобиля никогда не закончится энергия, только если вы сами этого не захотите.
Понимая, что это похоже на маленькую победу для моделей будущего, журналисты спросили, когда эта функция станет доступна. Что же ответил Маск? Каждый нынешний владелец получит обновление для своего автомобиля сразу же после пресс-конференции через программное обеспечение, которое будет доступно через интернет и установлено в автомобили Tesla с помощью Wi-Fi. Через несколько минут после того, как пресс-конференция закончилась, представители журнала Consumer Reports отреагировали в Твиттере:
«Главная идея в заявлении от @TeslaMotors – это убежденность в том, что со временем автомобили можно будет улучшать точно так же, как и другие электронные устройства»[13].
Иными словами, мы начинаем понимать, что цифровую «начинку» автомобилей можно обновлять точно так же, как и наши смартфоны и компьютеры. И следующими на очереди, вероятно, будут другие традиционные промышленные товары.
Мы принимаем как должное то, что товары становятся все более «продвинутыми», и, может, поэтому не удивляемся, что автомобили Tesla становятся все современнее и современнее. Но это касается не только «умных» функций, другие параметры автомобильной отрасли тоже меняются. Владельцам автомобилей нового поколения не нужно обращаться в дилерский центр или к механику, чтобы получить обновление, – автомобили Tesla могут обновляться через беспроводной интернет, – поэтому процесс обслуживания изменился. Кроме всего прочего, Tesla отслеживает использование автомобиля в течение всего времени, поэтому всегда известно, когда автомобиль нуждается в обслуживании.
Таким образом, программное обеспечение меняет и наши товары (в данном случае, автомобили), и сам процесс обслуживания. Что-то еще? Да, оно также меняет основной цикл выпуска автомобильной промышленности. Вам больше не нужно покупать новую модель автомобиля, чтобы воспользоваться новейшими функциями. Производители могут запускать новые функции по мере их готовности.
Одним из ярких примеров новой возможности быстрого выпуска товаров является китайский производитель телефонов Xiaomi. Компания Xiaomi, основанная в 2010 году, выпускает телефоны небольшими партиями – 100 000 каждый вторник, и каждая из партий быстро распродается. Особенно впечатляет следующее: Xiaomi постоянно обновляет свои продукты, основываясь на отзывах пользователей на интернет-форумах. То есть идея, которую предлагает клиент, может перейти из форума к менеджеру, а затем к инженеру, а затем через пару дней воплотиться в жизнь. Как видим, эта компания участвует в двустороннем разговоре с покупателями.
Способность выпускать небольшие партии товаров с самыми последними, наиболее желаемыми функциями, дает Xiaomi огромное конкурентное преимущество. Компания получает обратную связь в относительно того, что хочет рынок, и ей не приходится строить чисто теоретические предположения. В мире производства, если ты не смог угадать, ситуация может оказаться очень затратной, если дело дойдет до заполнения складов товарами, которые никто не хочет покупать. Цифровые технологии, позволяющие компании оперативно собирать отзывы и производить телефоны небольшими партиями, уменьшают риск выпуска никому не нужных товаров. Если вы когда-нибудь занимались розничными продажами, то знаете о трудностях в прогнозировании производства продукции и цену неверным догадкам. Используя различные тактики цифрового мира, Xiaomi способна ограничить риск неопределенности долгосрочных прогнозов, производить небольшие партии товаров и обрести высокую степень уверенности в том, что она создает именно тот продукт, который хочет покупатель, то есть тот продукт, который будет продаваться.
В каждом из приведенных примеров – опыт Etsy, Tesla и Xiaomi – мы видим команды, которые используют возможности, предоставляемые цифровыми технологиями, для двустороннего разговора с рынком в реальном времени – то самое «почувствовать и отреагировать». Они понимают, каким клиентам нужно внимание и обслуживание. Исходя из того, какие потребности они почувствовали, они решают, какие функции разрабатывать или какие бизнес-процессы корректировать. Информация, которую они собирают, эффективна, но в то же время и разрушительна: она перечеркивает прежние планы и расписания. Когда у вас в режиме реального времени поступает информация о потребности в совершенствовании некоего механизма обслуживания, уделите ли вы в первую очередь внимание данной информации или будете работать по запланированному расписанию обслуживания? Когда вы узнаете о проблемах рынка, таких как, например, боязнь ограничения дальности поездки, будете ли вы ждать до следующего года, если сможете решить их завтра?
С другой стороны, у вас также появляются новые проблемы. Как вы можете выстроить маркетинговую кампанию по продвижению интересных новых функций, если вы не знаете, когда появятся эти функции или хотя бы, какие функции появятся в первую очередь? Как вы можете заключать контракты со своими клиентами, если вы даже не знаете, что будете им поставлять? Как вы можете координировать деятельность нескольких команд, если у вас нет плана?
Ответ состоит в том, что вам нужно изменить способ работы всех подразделений компании и то, что вы называете «планом». Недостаточно изменить способ реализации своих товаров и оставить остальную часть бизнеса функционировать так, будто этих изменений и не было. На BBC пытались сделать это со своим проектом Digital Media Initiative. Этот проект должен был привлечь менеджеров в качестве активных участников, а не просто пассивных потребителей. Ему были необходимы идеи этих менеджеров, а также других пользователей, чтобы понять, что нужно пользователям от системы. Однако по какой-то причине менеджеры не захотели принимать в этом существенное участие. Кроме того, они лишили проект источника жизнеспособности – обратной связи с пользователями, чем способствовали провалу инициативы. Чтобы создать канал успешного непрерывного разговора в цифровом мире, мы должны понимать, что он изменит способ взаимодействия людей в рамках данной организации.
Это означает, что нам нужно осмыслить и изменить способ функционирования наших команд. Нам необходимо изменить механизмы планирования, создания и продажи наших товаров и услуг. Мы должны изменить то, как мы взаимодействуем с покупателями, акционерами и пользователями во время этих процессов.
Эти изменения выходят далеко за рамки компетенции разработчиков программного обеспечения. Менеджерам по продукции приходится полностью переосмысливать то, как они составляют «дорожные карты» и верстают бюджет. Им приходится корректировать свой подход к координированию и планированию, изменять модели продаж и контракты с поставщиками. И, конечно, старшие менеджеры и руководители сталкиваются с приливной волной планирования «снизу вверх», которое бросает вызов их ожиданиям, поручениям и полномочиям. В организациях, которые смогли скорректировать свои подходы, чтобы воспользоваться этой силой, мы наблюдаем плавный переход к постиндустриальной эпохе. Но в организациях, которые продолжают навязывать подходы индустриальной эпохи, традиционного планирования «сверху», предстоят большие встряски. Шестеренки так или иначе будут стачиваться.
Мы видим множество организаций, которые находятся в состоянии стачивания шестеренок. Их технологические команды переходят с опережением в режим непрерывного ритма и придерживаются принципов непрерывного осмысления, которое и делает это возможным – однако организации испытывают трудности с интеграцией этих команд в другие направления бизнеса. Это происходит потому, что остальная часть бизнеса все еще не имеет модели для перехода на новый ритм.
Годами компании говорят о необходимости «прислушиваться к покупателю». Но одного этого недостаточно. С появлением цифровых технологий, насыщающих каждый элемент бизнеса, мы наблюдаем, как организации сталкиваются с управленческой неопределенностью на многих фронтах. IT-команды и аналитики сошлись в том, как решить эту проблему: используйте agile-методы, частые небольшие эксперименты, гибкое сотрудничество внутри и за пределами компании, а также непрерывное осмысление. Подход «почувствовать и отреагировать» интегрирует эти идеи и помогает организациям слушать и реагировать с большей оперативностью и гибкостью. Это выходит за рамки простого умения выслушать клиентов. Это непрерывный двусторонний разговор.
✓ Как следствие цифровой революции компании сталкиваются с новыми уровнями сложности и неопределенности.
✓ Подход индустриальной эпохи к управлению неопределенностью заключался в составлении подробных планов. Поскольку программные системы сложны, этот подход не работает. Подробные планы рушатся перед лицом реальности.
✓ Лучший способ справиться с неопределенностью – принять обучающий непрерывный, малосерийный подход, который будет направлять ваше дальнейшее движение.
✓ Этот подход, впервые примененный в цифровом мире, становится все более актуальным во всех сферах бизнеса, потому что многие операции так или иначе связаны с программным обеспечением.
Как подход «почувствовать и отреагировать» формирует двусторонний разговор с рынком? Как команды используют такой диалог для создания ценности? Давайте рассмотрим это на примере.
В 2014 году издатель журналов Time Inc. попросил нашу компанию помочь создать новый цифровой продукт для их ежемесячного журнала Cooking Light. Этот журнал потратил 30 лет на то, чтобы зарекомендовать себя как лучший источник рецептов здорового питания. Во времена, когда индустрия глянцевых журналов переживала трудности, а подписка на бумажные издания и доходы от рекламы снижались, управленческая группа Cooking Light столкнулась со сложной задачей. Их «фишкой» неизменно были популярные рецепты здорового питания, отзывы и советы, которые традиционно передавались в ходе двустороннего разговора, а именно в печатном виде. Их контент останется актуальным, наверное, во все времена (американцы переходят от фаст-фуда к здоровой пище), но все же Cooking Light не смог извлечь выгоду из этой тенденции. Что еще хуже, их старая модель постепенно двигалась к провалу. Необходимо было найти новые источники дохода.
Команде Cooking Light нужно было узнать, какой сервис сможет обеспечить привлекательную ценность для читателей. У членов команды было много идей, но они не знали, какая из них сработает, поэтому сначала им нужно было сосредоточиться на изучении ситуации, а не на действиях.
Это является руководящим принципом организаций, использующих подход «почувствовать и отреагировать». Начните с диалога с вашими покупателями, чтобы вы сначала могли изучить их потребности, соответственно улучшить свой продукт, а затем представить его. Первоначальные исследовательские усилия помогут определить, какой вариант вашей идеи будет резонировать с желаниями покупателей, и запустят процесс непрерывного изучения. Без изучения спроса вы рискуете предоставить товар или услугу, которые никому не будут нужны. Чем скорее вы узнаете, оправдывают ли ваши бизнес-стратегии дальнейшие инвестиции, тем меньше времени потратите на безуспешные начинания. Другими словами, чем раньше вы выясните, ошибаетесь ли вы, тем лучше.
Члены команды Cooking Light решили проверить эффективность того, что, по их мнению, было лучшей идеей, – нового сервиса диетического питания под названием Cooking Light Diet, который периодически отправлял рецепты блюд здоровой пищи на электронную почту пользователей. Они начали процесс изучения с создания тестовой целевой страницы – одностраничного веб-сайта, предназначенного для продвижения нового товара или услуги, которые скоро появятся. Команда разработала три версии этой страницы. Каждая из них содержала варианты трех элементов:
• Четкое описание услуги
• Стоимость услуги
• Способ бронирования услуги для клиентов
Ладно, там был и четвертый элемент, и он тоже был отличным.
Эти страницы были первой версией продукта, инициирующего общение с клиентами. Если бы тестовая версия сработала, тогда команда очень быстро нашла бы подход к клиентам, которых она хотела заполучить. Если бы она не сработала, команда не потратила бы на этот тест много времени и усилий и смогла бы попробовать еще раз.
Члены команды Cooking Light сначала хотели изучить (почувствовать), оправдывают ли их идеи дальнейшие инвестиции. А целевые страницы – это инструмент изучения с низким риском. Эти ранние обкатки продуктов позволяют команде почувствовать интерес покупателя, его намерение, восприятие ценности и ценовую чувствительность. Это быстрый способ изучения. Попытка создать и запустить тестовую целевую страницу или даже три – самый простой шаг по сравнению с созданием полнофункционального сервиса.
Показатель усилий, затраченных на этот процесс, измерялся днями. Обычно создание целевой страницы занимает примерно день, и, как правило, вы получаете результаты тестирования в течение недели, что гораздо эффективнее традиционной стратегии по изучению рынка, требующей недели и месяцы. Команда очень быстро получила информацию о рынке.
В ходе первого тестирования команда узнала отличную новость: и постоянные читатели, и даже те, кто не читает Cooking Light, подписались на новую услугу по ценам выше ожидавшихся. Этот высокий уровень взаимодействия с начальным продуктом укрепил желание команды инвестировать дальше и создавать его следующую версию.
Команда Cooking Light начала с двух вещей: определения стратегической цели и составления списка вопросов. Это удивительно экономный и простой подход к новой большой инициативе. Но перед лицом неизвестности (тему неопределенности мы обсуждали в Главе 1) члены команды сочли, что особого выбора у них нет.
Они видели ситуацию следующим образом: между их текущим состоянием (сокращение подписки и доходов от рекламы) и желаемым результатом (услуги с высокой добавленной стоимостью, которые буду способствовать росту доходов) был туман. В этом тумане они могли видеть на несколько шагов вперед (интерес пользователей к контенту и готовность за него платить), но дальше пути видно не было. Какой сервис они должны создать? Как им следует его позиционировать? На какой сегмент рынка они должны ориентироваться в первую очередь?
Наиболее типичным индустриальным подходом было бы создание подробного плана еще до начала работы команды. Вместо этого у них было достаточно бюджета для того, чтобы двигаться в любом направлении и надеяться, что это направление правильное. При таком подходе они могли потратить очень много денег и времени. Однако члены команды поняли, что такой метод является рискованным. Учитывая, что туман скрывал все, за исключением следующих нескольких шагов, команда рисковала упасть с обрыва. Каждый следующий маленький шаг, который вносил некоторую ясность (например, реакция на тестовую целевую страницу), позволял членам команды осмыслить новую информацию, уменьшить неопределенность и скорректировать свое направление.
Тестирование целевой страницы и непрерывное обучение на рынке – все это элементы методологии бережливого стартапа, подхода, определенного Эриком Рисом в его популярной книге «Бизнес с нуля» (изд-во «Альпина Паблишер», 2014 г. – ред.)[14]. Рис предложил рассматривать стартапы и другие новые, рискованные проекты как эксперимент. Суть эксперимента не в том, чтобы определить, может ли организация создать новый сервис или продукт, а в том, что эти эксперименты, основанные на быстром сборе отзывов рынка, определяют, должна ли организация работать над ними вообще. То есть сначала он предлагает рассмотреть рыночный риск, а затем технический риск.
Название «бережливый стартап» происходит от производственной практики компании Toyota, известной своим бережливым производством. Тайити Оно, автор концепции бережливого мышления, в послевоенной Японии работал с Эйдзи Тойода из Toyota над созданием системы для максимизации стоимости, эффективного использования ограниченного капитала и ликвидации ненужных затрат. Они оба верили, что система (компания, продукт, проект) всегда движется от состояния сомнения к состоянию уверенности, постоянно стремясь к совершенству. Каждый шаг по направлению к совершенству и потребительской ценности является значимым. Все остальное – ерунда.
Обучение, ведущее от сомнения к уверенности, зачастую является процессом проб и ошибок. Методом проб и ошибок мы учимся ходить, ездить на велосипеде, читать или играть на музыкальном инструменте. Другими словами, мы учимся посредством действий. Когда мы создаем команды для проектов, мы хотим, чтобы они могли действовать, и именно таким образом, чтобы это принесло им какие-либо знания.
В рамках старой модели индустриальной эпохи мы, чтобы чему-либо научиться, как правило, полагались на тщательное предварительное исследование. К тому времени, как мы приступали к действиям, мы считали, что изучение уже завершилось. Подход «почувствовать и отреагировать» – другой. Мы меньше уделяем внимания предварительному исследованию и больше концентрируемся на изучении посредством действия. Мы хотим, чтобы наши команды имели возможность попробовать что-то новое и чтобы мы не винили их за «неудачные» попытки. Любой ответ команды (положительный или отрицательный) является единицей прогресса. Она приносит членам команды коллективные знания и позволяет им в следующий раз задать лучший вопрос (т. е. организовать лучший диалог с рынком).
На сегодняшний день команда Cooking Light Diet ответила на свои первые вопросы. Тестирования целевой страницы помогли членам команды найти идею, которая обладала достоинствами – она обещала вывести их к стратегической цели. Члены команды составили большой список клиентов, которые были готовы заплатить за сервис. Теперь группа была готова перейти к следующим вопросам. Пришло время более подробно выяснить, какой контент и функции будут важны для покупателей.
Члены команды знали, что исследование того, какие функции нужно создать, как должна работать система и как она должна выглядеть, могло занять недели. Вместо этого они снова выбрали оперативное изучение. Они решили запустить пилотную версию сервиса. В этом эксперименте они взяли первые 12 имен из списка ожидания и предоставили им доступ к сервису. Все это было необыкновенно интересно для участников, за исключением одной маленькой детали: сервиса как такового не было, по крайней мере в классическом понимании. В реальности команда запустила тестирование Волшебника страны Оз, называемое так потому, что система, по идее, управляемая программным обеспечением, на самом деле полностью функционировала благодаря усилиям человека «за кулисами», прямо как в фильме.
Команда Cooking Light Diet поддерживала диалог с первой группой участников нового проекта с помощью электронной почты и телефонных интервью. Работники использовали информацию, собранную во время этих бесед, чтобы «вручную» создать меню для каждого участника. Они еженедельно отправляли каждому покупателю меню на красиво оформленном шаблоне. В конце каждой недели члены команды проводили телефонные беседы со своими новыми клиентами, чтобы понять, какие элементы нового сервиса были ценными. Они опрашивали участников, по каким рецептам те готовили еду, какая дополнительная информация была им важна, интересовались процессом покупок и планирования. Они пытались понять, что сделает сервис более привлекательным. Команда не создавала веб-страниц, почти не писала код и не потратила ни копейки на маркетинг. Тем не менее их клиенты опробовали новый сервис. Благодаря этим личным, нетехнологичным взаимодействиям, члены команды Cooking Light Diet продолжили разговор, который они начали с тестов целевой страницы. При этом они выстраивали алгоритм циклов обучения для проекта в целом.
Методы Волшебника страны Оз иногда называют услугами консьержа, потому что они основаны на личном взаимодействии между поставщиком услуг и покупателем. Такой непосредственный контакт с клиентами делает возможным ценный двусторонний разговор, который позволяет командам сосредоточить свои усилия на тех функциях, которые обеспечивают максимальную ценность для клиентов.
Затем команда Cooking Light Diet начала постепенный перевод сервиса – функцию за функцией – на автоматизацию. При этом они продолжали выполнять работу вручную до тех пор, пока у них не появилось четких доказательств необходимости автоматизации, а затем создали наименьшее число программ, которые удовлетворяли бы эту потребность. Иногда доказательства были качественными: они общались с несколькими клиентами и получали обратную связь. В других случаях, особенно по мере роста сервиса, доказательства были количественными. С помощью системных показателей команда определяла, что некоторые функции использовались не так часто, как ожидалось, и корректировала программу. Таким вот образом, внедряя по одной функции за раз, команда и запустила сервис. С каждым новым, немного более сложным его запуском члены команды все лучше понимали, что именно нужно рынку, а затем реагировали на это посредством постоянных обновлений.
Команда получила возможность постоянно проверять свои идеи и совершенствовать свое понимание благодаря тому, что группа управления создала обстановку, в которой команда могла экспериментировать, что сыграло решающую роль. В частности, политика менеджмента использовала следующую тактику:
• Позволяла команде совершать ошибки, пока те были относительно несерьезными, и команда на них училась.
• Обеспечила свободу в рамках четко заявленных границ для принятия собственных решений, так что время не было потрачено впустую из-за ожидания обратной связи от руководителей.
• Оценивала поведение клиента как показатель прогресса, а не количество функций, которые запускала команда.
Это хороший пример механизма, используемого чуткими организациями. Это компании, которые ценят обучение, помогают командам с решением рабочих проблем, при этом четко ограничивая рамки, в которых те могут работать, и устанавливая точные показатели успеха. Команды выясняют, как лучше всего решить проблемы, переходя от вопроса к вопросу, а критерии успеха служат барометром прогресса.
По поводу подобного вида рабочего процесса возникает один общий вопрос относительно общего видения и успеха. Ошибочно полагать, что, поскольку члены команды не уверены, что будет дальше, у них нет плана или видения. Или, что еще хуже, будто они просто оптимизируют свой сервис на основе получаемых данных, без единой концепции, направляющей их работу.
Это никак не относится к подходу «почувствовать и отреагировать». Напротив, данный подход – это способ реализации видения, использующий фактические данные, собранные в ходе непрерывного двустороннего разговора с рынком, для принятия решений. Такой подход основан на согласованной с целями – а не детальным планом – координации деятельности команд. На самом деле, чем яснее видение, тем проще использовать методы восприятия и реагирования.
Опыт команды Cooking Light Diet – это только один пример того, как это происходит. Начав с простой идеи («создать сервис рецептов здорового питания для людей, которым нравятся наши рецепты, чтобы повысить доход от бренда»), команда смогла следовать этому видению и создала успешный бизнес.
Постановка задачи этой команды, скорее, направлена на извлечение выгоды от запуска сервиса для компании. Но какую ценность он создаст для покупателей? Команда Cooking Light Diet знала: чтобы добиться успеха, ей необходимо понять, что, по мнению клиентов, является ценным, а затем сосредоточить свою работу на этом направлении. По мере того, как члены команды продвигались вперед и узнавали все больше, у них появился второй аспект видения, который выражал задачу с точки зрения клиента: «Мне нужны вкусные, легкие блюда, которые будут способствовать улучшению моего здоровья».
КОМПАНИЯМ, КОТОРЫЕ ПРОДОЛЖАЮТ НАВЯЗЫВАТЬ ПОДХОДЫ ЭПОХИ ТРАДИЦИОННОГО ПЛАНИРОВАНИЯ, ГРОЗЯТ БОЛЬШИЕ ВСТРЯСКИ. ШЕСТЕРЕНКИ ТАК ИЛИ ИНАЧЕ БУДУТ СТАЧИВАТЬСЯ.
Эти задачи стали двумя ориентирами команды. Способны ли функции, над которыми они работали, решить проблемы их клиентов? Может ли команда ответить на запрос покупателей так, чтобы обеспечить ценность для своего бизнеса?
В мышлении индустриальной эпохи успехом считался запуск продукта, особенно если он был произведен вовремя и в рамках бюджета, поскольку в те времена связь между продуктом и его использованием обычно была довольно ясной. Полусантиметровое сверло дрели может проделать полусантиметровое отверстие. В рамках традиционных и понятных производственных категорий вы могли быть уверены, что, если вы сделаете что-то, что работает, удовлетворяет спрос и оптимально по цене, вы станете успешны.
Но по мере того, как наши продукты становились более сложными, а также по мере роста ожиданий клиентов, уровень неопределенности относительно услуг тоже вырос. Одного лишь создания продукта уже недостаточно, поскольку связь между его назначением и фактическим использованием стала менее очевидна. В чем заключается «применение» Facebook? Как люди будут использовать видео, которые они сняли на свои смартфоны? Если вы внедрите сервис диетического питания в телефоны, как люди будут его использовать? В информационную эпоху мы сталкиваемся с таким большим количеством ситуаций, что сложно полагаться на традиционное понимание рынка. Откуда мы знаем, что нам производить? Как мы можем узнать, что с этим будут делать люди? В информационную эпоху лучший способ понять ценность – это позволить нашим покупателям рассказать нам о том, что для них является ценностью. Другими словами, ценность определяем не мы, а наши покупатели.
Так что создание какого-либо продукта – это не цель. Напротив, успех – это степень достижения своей цели путем помощи клиентам достичь результата, к которому они стремятся. Облегчите возможность связи с семьей и друзьями, упростите поиск здоровой пищи в супермаркете – все это результаты, которые создают ценность для вашего клиента, и если она была понята правильно, то и для бизнеса. В этом заключается новое определение «выполнено» в отношении товаров или услуг. Это можно назвать развивающейся целью. В мире непрерывного обучения и реагирования в режиме реального времени мы имеем возможность продолжать совершенствоваться. Мы переходим от инициативы к инициативе исходя из нашего понимания того, насколько эффективны будут наши дальнейшие инвестиции. Учитывая непрерывную природу программного обеспечения, прежнее значение слова «выполнено» больше не имеет смысла. В организациях, использующих подход «почувствовать и отреагировать», слово «выполнено» означает, что мы максимизировали опыт или решили переориентировать наши приоритеты на другие результаты.
Катастрофа, произошедшая в 2014 году с Fire Phone компании Amazon, является классическим отрицательным примером, как это ни странно для компании, которая разработала и часто использовала многие из обсуждаемых нами методов «почувствовать и отреагировать» (мы хвалили ее за это в Главе 1).
Мотивированная ростом спроса на мобильные устройства, компания Amazon начала работать над Fire Phone в 2010 году, когда на рынке появился iPhone 4. Пользователи мобильных телефонов становились все более важным сегментом торговли для Amazon, и компания хотела получить больше контроля над магазинами мобильных устройств, чем позволял регламент компании Apple. Правила Apple о том, что компании могут и не могут делать через приложения iOS, включают в себя строгие положения о торговле, в том числе то, которое предусматривает, что Apple получает 30 %-ную долю от каждой продажи через приложение[15]. (Причина, почему вы не можете купить книгу для Kindle на iOS, состоит в том, что Amazon не хочет платить компании Apple 30 % от своих продаж). Поэтому Amazon создал Fire Phone для решения данной бизнес-проблемы: компания хотела получить полный контроль над магазином, который клиенты посещали с помощью своих мобильных устройств.
Но в чем заключается ценность для покупателей? Разработчики бились над ее определением, ограниченные режимом строгой секретности относительно данного товара. У Джеффа Безоса, генерального директора Amazon, было много идей насчет создания интересных функций. Но «круто» и «ценно» – не одно и то же. Со временем Безос все больше вовлекался в проектирование и создание Fire Phone и, согласно опубликованным отчетам, игнорировал отзывы своей команды, ставящей под сомнение его подход[16]. Не было никакого разговора с рынком, только мнение Безоса. Он настаивал на том, чтобы телефон имел ряд таких функций, как, например, динамическая перспектива (Псевдотрехмерная функция Dynamic Perspective работает с помощью четырех сенсоров, расположенных по углам фронтальной части устройства. Они отслеживают положение головы пользователя и соответствующим образом изменяют перспективу отображения на экране, чтобы создать иллюзию 3D – ред.) – нечто вроде 3D-дисплея, для которого не нужно иметь специальных очков. Но эта «фишка» не обладала большой потребительской ценностью. Безос предположил, что гаджет с такими необычными функциями привлечет внимание покупателей больше, чем iPhone. Безос сделал масштабное предположение без опоры на непрерывный двусторонний разговор с целевой аудиторией, который позволил бы определить направление развития востребованных функций.
Он был неправ. Четыре года спустя, в июле 2014 года, Fire Phone появился на рынке США. В течение нескольких дней стало ясно, что потребители не впечатлились ни дизайном, ни платформой, ни необычными функциями, на появлении которых так сильно настаивал Безос. Fire Phone стоимостью 199 долларов должен был конкурировать непосредственно с iPhone компании Apple, но потребители не увидели в нем ценности. Они восприняли гаджет тем, чем он и являлся, – легким способом посетить магазин Amazon, что было выгодно для самой компании, а не для ее клиентов.
После списаний непроданного со склада товара на 170 млн долларов, Fire Phone стоил 99 центов, пока в 2015 году совсем не исчез из продажи. Неформальные источники рассказывают о высокомерии, управлении по принципу «сверху-вниз» – подходах, продемонстрированных Безосом в качестве руководителя[17]. Несмотря на то, что люди в команде не были согласны с ним, они позволили принять решение именно своему боссу. В конце концов, он много раз бывал прав. Почему бы ему не быть правым и в этот раз?
Если бы Безос прислушался к рынку, это могло бы помочь. Если бы он расценивал некоторые из своих решений как предположения, подлежащие проверке, или же как вопросы, на которые необходимо найти ответы, а не слепо следовал своим догадкам, все могло бы сложиться по-другому.
Планирование «сверху-вниз», устойчивое к изменениям, которое мы наблюдали в истории о Fire Phone, является слишком распространенным явлением. Для больших организаций это норма. Чаще всего этот подход формулируется в документе под называнием дорожная карта. Это неоспоримый документ. Он дает четкое понимание того, где мы находимся, куда мы направляемся и какие шаги нужно предпринять, чтобы добраться из точки А в точку В. Он создает ощущение прогресса и служит мотивационным инструментом для команд, менеджеров, руководителей и зачастую внешних партнеров и акционеров. Этот документ фиксирует ожидания относительно того, какие показатели будут достигнуты.
А еще это чистой воды вымысел.
Представьте себе менеджера по продукции в команде Cooking Light Diet, который следует «дорожной карте» с самого начала реализации инициативы. Он будет придерживаться определенного набора показателей, ценовой стратегии и дат поставки. Затем после каждого эксперимента или беседы с клиентами ему придется пересматривать план-график и обращаться к акционерам за получением одобрения, при этом каждый раз наблюдая за тем, как подрывается доверие. Члены команды тоже будут ждать одобрения, а их продуктивность снизится почти до нуля. Их обучение будет восприниматься как проблема.
Альтернативой функциональных «дорожных карт» является составление более свободных планов и их корректировка по мере обучения. (Мы поговорим об этом подробнее в Главе 5). Команда Cooking Light Diet сохранила несколько документов, используемых в ходе проекта. Первым был список вопросов, предположений и рисков. По мере процесса обучения команда перемещалась по этому списку, находя ответы на вопросы, уменьшая риски и добавляя новые вопросы. Вторым был список возможных функций. Там были перечислены функции, которые, по мнению команды и заинтересованных лиц, могут понадобиться, но эти предположения необходимо подтвердить. Каждую неделю команда изучала отзывы, полученные в ходе бесед с клиентами и в процессе анализа системных показателей. Они сопоставляли отклики обратной связи со списком возможных функций, а затем определяли свои приоритеты на предстоящую неделю.
Выпускников бизнес-школ, сертифицированных менеджеров проектов учат, что их команды нуждаются в необходимых для эффективной работы условиях. Поэтому команды составляют подробные планы (на языке рынка, они разрабатывают требования), а затем оценивают объем работы, который потребуется для исполнения плана. Они сообщают об этом менеджерам, которые на основе этого формируют финансовые модели, распределение ресурсов и планы финансирования. Менеджеры, в свою очередь, сообщают об этом исполнительному руководству, а если акции компании продаются на бирже, то и фондовым рынкам. После завершения всех этих публичных и подробных процедур все готовы следовать плану.
Звучит знакомо? Должно. Именно так большинство компаний планирует свои ежегодные финансовые программы и сроки выполнения проектов. Удивительно, что мы продолжаем следовать этим правилам, потому что такой вид плана всегда является неправильным.
Почему? Да потому, что такие планы основаны на предположениях. На догадках.
Если нам повезет, мы будем работать с догадками, подкрепленными экспертными знаниями, годами опыта работы в отрасли, представлениями о корпоративной эффективности и предпочтениях клиентов и конкурирующих компаний. В худшем случае, как было с Fire Phone компании Amazon, догадки – это мнение лишь одного человека (того, кто, чаще всего, занимает самую высокооплачиваемую должность). Хотя этот подход может работать в отраслях с большим прошлым, а также с очень низким уровнем неопределенности, повсеместное использование программного обеспечения ускорило темпы изменения ожиданий клиентов, снизило барьеры для входа на рынок новых конкурентов, а сбои на сервере стали угрозой для любой индустрии. Работа в такой новой реальности с этими новыми уровнями неопределенности делает планирование, основанное на предположениях, чрезвычайно рискованным.