Если вы посмотрите на методы, которые за последние двадцать пять лет получили развитие в области программного обеспечения, то убедитесь, что многие из наиболее распространенных идей разделяют agile – концепцию непрерывной обратной связи – непрерывного разговора с рынком. Этих принципов придерживаются и дизайнеры, рассматривающие идеи ориентированных на пользователя моделей, и приверженцы направлений дизайн-мышления и так называемого бережливого дизайна (направление lean-UX-дизайна, от англ. lean – «тощий», т. е. бережливый, экономный, минималистский – ред.), а также предприниматели, такие как Эрик Рис и Стив Бланк, которые сформулировали концепцию бережливого (англ. lean) стартапа и привнесли тестирование идей на потенциальных потребителях, и технологи, которые предложили бережливые и agile-методы, а также методы DevOps.

Более того, мы видели, как эти новые методы привлечения рынка к диалогу способствовали появлению новых подходов лидерства. Авторы данной книги много лет работали в технологической индустрии. Мы участвовали в развитии этих методов, и мы рады вам о них рассказать. Мы видели, как целая индустрия и вся совокупность знаний начинают накапливать способы работы, которые создают возможность двустороннего разговора с рынком, и мы рады поделиться тем, что узнали. Как вы увидите, мы считаем, что эти методы применимы далеко за границами сферы технологий.

Мы назвали эту книгу «Почувствовать и отреагировать» потому, что считаем, что эта фраза описывает основной механизм цикла обратной связи. В основе подхода «почувствовать и отреагировать» лежат следующие пять ключевых принципов.

Создайте двусторонний диалог. Цифровые технологии дали нам возможность вести двусторонний разговор с нашим рынком и нашими покупателями. Чего хочет рынок? Под рынком мы подразумеваем людей. (Когда мы говорим о том, чтобы быть ориентированным на клиента, мы имеем в виду именно это). Понимание невысказанных и неудовлетворенных нужд людей, пользующихся нашими товарами, услугами и технологиями, является ключом к раскрытию ценности. В этой возможности заключается путь к успеху в цифровой эпохе: нам не нужно прогнозировать, что будет работать. Вместо этого мы можем слушать, делать достоверные предположения, получать обратную связь практически в режиме реального времени и вносить корректировки.

Сосредоточьтесь на целях. В цифровую эпоху сложно, а иногда невозможно предсказать, какие характеристики продукта будут востребованы на рынке. Тем не менее мы часто планируем выход наших продуктов и управляем нашими бизнес-циклами так, будто точно знаем, как они себя покажут в работе. По сути, мы пытаемся управлять конечным результатом, а именно тем, что мы собираемся сделать. Вместо этого нам необходимо сконцентрироваться на целях: руководство должно заявить о бизнес-решениях, к которым они хотели бы прийти, а затем набрать команды, чтобы понять, как эти цели можно реализовать. Это означает, что нам придется создать условия, в которых команды смогут опробовать различные подходы, экспериментировать, обучаться и узнавать, что именно работает, методом проб и ошибок.

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

Создайте атмосферу сотрудничества. Все значимые цифровые успехи были достигнуты в результате сотрудничества между создателем продукта и аудиторией. Между разработчиками и пользователями. Между дизайнерами и заказчиками. Вам необходимо влиться в атмосферу сотрудничества, чтобы преодолевать преграды на вашем пути. Это означает, что следует очень серьезно подойти к организации команд, подразделений, программ и инициатив.

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

Это было Рождество 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 отреагировала, пытаясь использовать функцию отчетности, – применила то, что мы называем подходом «почувствовать и отреагировать» к решению проблемы неопределенности. Поскольку члены команды не были уверены в том, что происходит, они стали обновлять продукт так, чтобы самим понять, в чем же дело. Сначала они добавили новый пункт в процесс подачи отчета – вопрос «Почему вы жалуетесь на эту фотографию?». Этот открытый вопрос помог им узнать, что в большинстве случаев люди впадали в замешательство, пытаясь сформулировать, почему они жалуются на ту или иную фотографию. Вооружившись этим знанием, команда снова обновила продукт, на этот раз попросив людей связаться с тем, кто выложил ту или иную фотографию. Это отчасти помогло, но не решило всю проблему.

Затем команда 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. Мы не изменили проверенные методы и, конечно же, не рассматривали вопрос об изменении способа ведения нашего бизнеса с учетом новых реалий.

Однако по мере того, как мы становились все более опытными в использовании программ, мы научились лучше управлять компанией. Наши подходы – agile-методики, которые стали использоваться повсеместно, – позволили нам начать относиться к программному обеспечению больше как к тропикам. Наш процесс управления программным обеспечением теперь, скорее, лесоводство, нежели инженерия.

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

Чтобы работать в этом новом, непрерывном ритме, команды должны быть свободны. Они должны свободно экспериментировать и обучаться. Это означает, что командам нужно предоставить больше полномочий для принятия решений. Подход сборочной линии индустриальной эпохи стремился отделить интеллектуальный труд (область управления) от физического (область рабочего). Он пытался превратить рабочих в сборочные машины. Но люди не машины, и процесс выявления потребностей рынка и быстрого реагирования не вписывается в такого рода подход, направленный на минимизацию самостоятельного мышления и принятия решений. В этом новом мире стало меньше решений, которые могут быть спущены «сверху» «вниз» и вписаны в размеренный рабочий поток. Теперь многие решения должны приниматься «снизу» «вверх» людьми, которые имеют опыт работы с данными и доступ к самой последней информации. Эти люди являются самыми близкими к рынку, а не к руководству организации.

Давайте в качестве примера рассмотрим компанию Etsy, десятилетний интернет-стартап со штаб-квартирой в Нью-Йорке. Etsy – это рынок, на котором покупатели могут приобрести товары ручной работы более чем у миллиона независимых продавцов; считайте, что это крупнейшая в мире онлайн-ярмарка ремесел. Etsy известна своей культурой постоянных экспериментов. Она непрерывно тестирует и оптимизирует дизайн своего веб-сайта и мобильных приложений с помощью уже описанного метода A/B-тестирования. Компания разрабатывает несколько версий функции, выпускает их в течение короткого периода для небольшого, но тщательно отобранного числа пользователей, а затем отслеживает результаты. Эти продуманные схемы позволяют Etsy свернуть безуспешные проекты и запустить успешные изменения за пределы первоначальной испытуемой группы. И все это происходит очень быстро. Используя методы непрерывного развертывания, многие из которых она сама создала, Etsy способна постоянно вносить множество небольших изменений на своем веб-сайте, как правило, по 40–50 раз в день. Etsy также известна своей децентрализованной культурой. Каждая из команд, действуя в рамках стратегических принципов, свободно экспериментирует, обучается и вносит корректировки.

Etsy – это исключительно цифровой стартап, насчитывающий в своем штате около восьмисот человек и имеющий годовой доход в 275 млн долларов при общих продажах примерно на два миллиарда долларов в год[12]. Etsy по праву считается истинно цифровой компанией. Как насчет более традиционных отраслей?

Раз уж мы упомянули сборочные линии Генри Форда, давайте рассмотрим автомобильную промышленность, которая постоянно совершенствуется благодаря цифровым технологиям.

В марте 2015 года компания Tesla Motors, амбициозный производитель электромобилей, объявила о том, что займется решением одной из своих самых больших проблем, препятствующих пути к успеху, – проблемы, которую они называют «боязнь ограничения дальности поездки»: страх того, что электромобиль разрядится в таком месте, где в ближайшем радиусе не будет станции зарядки. Илон Маск, основатель компании, пообещал представить новую функцию, которая решит эту существенную проблему.

Около недели пресса и любопытные наблюдатели судачили по поводу того, как Tesla решит эту проблему. Затем на пресс-конференции Маск представил решение, а именно новую функцию под названием «уверенность в дальности поездки». Эта функция отслеживает использование заряда и условия движения в режиме реального времени (как быстро вы ехали? какая была погода? ровная дорога или холмистая?) для постоянного прогнозирования оставшегося запаса заряда. В то же время функция отслеживает местоположение ближайшей станции зарядки. С помощью этой функции автомобиль предупредит вас, когда вам понадобится подзарядка, и направит к наиболее подходящей зарядной станции. Маск заявил, что у автомобиля никогда не закончится энергия, только если вы сами этого не захотите.

Понимая, что это похоже на маленькую победу для моделей будущего, журналисты спросили, когда эта функция станет доступна. Что же ответил Маск? Каждый нынешний владелец получит обновление для своего автомобиля сразу же после пресс-конференции через программное обеспечение, которое будет доступно через интернет и установлено в автомобили Tesla с помощью Wi-Fi. Через несколько минут после того, как пресс-конференция закончилась, представители журнала Consumer Reports отреагировали в Твиттере:

Иными словами, мы начинаем понимать, что цифровую «начинку» автомобилей можно обновлять точно так же, как и наши смартфоны и компьютеры. И следующими на очереди, вероятно, будут другие традиционные промышленные товары.

Мы принимаем как должное то, что товары становятся все более «продвинутыми», и, может, поэтому не удивляемся, что автомобили 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, догадки – это мнение лишь одного человека (того, кто, чаще всего, занимает самую высокооплачиваемую должность). Хотя этот подход может работать в отраслях с большим прошлым, а также с очень низким уровнем неопределенности, повсеместное использование программного обеспечения ускорило темпы изменения ожиданий клиентов, снизило барьеры для входа на рынок новых конкурентов, а сбои на сервере стали угрозой для любой индустрии. Работа в такой новой реальности с этими новыми уровнями неопределенности делает планирование, основанное на предположениях, чрезвычайно рискованным.

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

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

Таким образом, предположения – это первый шаг в определении того, что мы знаем наверняка и что нам нужно почувствовать. Тогда следующий вопрос: как мы можем понять то, что нам нужно узнать? Сторонники концепции бережливого стартапа рекомендуют использовать научный метод для проверки наших предположений, а именно их выражение в виде проверяемых гипотез с последующей серией экспериментов для того, чтобы найти истину.

Возьмем в качестве примера историю с Fire Phone. Если бы вы сформулировали ряд предположений о проекте и выразили их в виде гипотез, это могло бы выглядеть так:

Взглянув на такое предположение, мы можем начать идентифицировать риски в нашем мышлении. Мы предполагаем, что мы станем зарабатывать больше денег, если у покупателей вместо iPhone будет телефон от Amazon. Это кажется довольно безопасным предположением, возможно, даже констатацией факта: нам не придется платить долю компании Apple с любой из покупок, сделанных с помощью устройства Fire Phone. Но следующая часть выглядит более тревожной. Предполагается, что клиенты переключатся на устройства Fire Phone, при этом не понятно почему. Поэтому нам нужна другая гипотеза:

Выраженный в словах, риск кажется очевидным.

Гипотезы служат зеркалом для нашего мышления. Они выстраивают наши предположения таким образом, что заставляют нас подвергать сомнениям свои собственные соображения. Обычно мы предпочитаем начинать с самых глобальных вопросов, а уж затем углубляться в детали. Как правило, вы начинаете с таких вопросов:

• Существует ли бизнес-проблема?

• Существует ли потребность клиента?

• Как мы узнаем, будет ли эта функция или сервис отвечать потребностям клиентов?

Когда вы со своими командами планируете свои следующие инициативы, задайте им следующие вопросы:

• Что является самым важным или чему нам нужно научиться в первую очередь?

• Каков самый быстрый, наиболее эффективный способ узнать это?

Как только вы ответите на эти вопросы, можете переходить к следующему набору вопросов и, соответственно, запускать инвестирование.

История Cooking Light демонстрирует, как одна небольшая команда может создать нечто новое, используя подход «почувствовать и отреагировать». Но что насчет большой компании, работающей в устоявшемся бизнесе?

Canadian Tire – это конгломерат со столетней историей стоимостью 13 млрд канадских долларов, владеющий магазинами хозяйственных и спортивных товаров, а также автомобильной продукции. Он является легендой Канады. А еще он стал новатором больших данных, использующим собранную информацию о поведении клиентов и покупках для постоянного улучшения своего бизнеса.

В течение многих лет Canadian Tire осуществлял программу лояльности под названием Canadian Tire “Money.”. Бумажная «валюта», обращающаяся с 1961 года, стала горячо любимым продуктом канадской культуры. В прошлом она даже использовалась как валюта для бартера. С более чем пятидесятилетней исторической и культурной инертностью, противостоящей любым изменениям в сложившейся системе, Canadian Tire признавал, что оцифровка Canadian Tire “Money” может повлечь потерю преданных клиентов и навредить бренду, но еще компания знала, что если у нее получится перевести программу в цифровую форму, то появится возможность узнать о поведении клиентов намного больше. Поэтому в последние годы она начала этот переход[18]. Однако для их клиентов выгода казалась менее очевидной.

Гипотеза компании заключалась в том, что в процессе плавного перехода к собственному мобильному приложению и внедрению дебетовых карт она смогла бы повлиять на выход населения из бумажной «валюты» и найти способы создать ценность для клиента. Чтобы ограничить риск сбоя запуска, Canadian Tire запустил версию приложения Canadian Tire “Money” только в одном из магазинов Новой Шотландии. По мере того как клиенты постепенно переходили к цифровой версии, Canadian Tire контролировал этот процесс, наблюдая за приростом и общаясь с клиентами. Оказывается, люди начали довольно легко переходить на новый формат. У многих из них уже были мобильные приложения в телефонах, одним из которых теперь являлась программа «Money», и они привыкли к цифровым платежам.

Иногда проблемы, которые кажутся нам сложными, оказываются тривиальными. То, что мы ценим внутри компании (в данном случае традиционную бумажную версию Canadian Tire “Money”), может быть воспринято за пределами наших стен совершенно иначе. Тем не менее, ограничив запуск одной «точкой», компания смогла выбрать комфортный уровень риска по сравнению с широким запуском в национальном масштабе.

Переход к цифровым технологиям стоил того, поскольку это дало начало новому разговору с клиентами об их покупках и о том, что Canadian Tire мог бы сделать для того, чтобы улучшить опыт своих покупателей.

Поскольку клиенты стали использовать цифровую версию, появлялось все больше новых данных. Отслеживая эти данные, компания стала видеть, как формируются потребительские модели. Например, она отметила особые возможности для улучшения сезонных продаж в магазине Новой Шотландии. Новая особенность восприятия подсказала, что клиенты стремятся купить все необходимое для завершения сезонной работы по уходу за газонами. Товары в магазине были распределены по типу продукции (например, газонокосилки с электроинструментами), а не по функциям (например, «уход за газоном»). Как результат, покупатели ходили по рядам и искали нужные им товары.

Среагировав на запрос, Canadian Tire реорганизовал размещение товара по принципу конкретных задач, чтобы клиентам было легче найти все, что им нужно, в одном ряду. Последующие данные показали, что новый план сработал. Он улучшил опыт клиентов и привел к увеличению продаж в магазине Новой Шотландии.

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

До сих пор мы говорили о подходе «почувствовать и отреагировать» с точки зрения процесса. Но у него есть и культурное измерение.

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

Стоит рассмотреть структуру команды на примере проекта Cooking Light Diet. Это была небольшая команда, состоящая из нескольких дизайнеров, разработчиков программного обеспечения, менеджера по продукции, редактора, диетолога, и нескольких других специалистов, которых время от времени привлекали к участию в проекте. Эти люди ежедневно трудились вместе, разрабатывая и корректируя планы, интерпретировали данные, общались с клиентами и принимали решения о направлении обслуживания. Работа проходила совместно, а беседы были построены таким образом, что наличие разных точек зрения в команде рассматривалось как преимущество. Эта установка позволила команде быстро двигаться вперед и решать разнообразные проблемы, набираясь при этом опыта.

В такой команде нет места ковбоям, ниндзя, рок-звездам или гуру. (Одинокий рейнджер не был сторонником сотрудничества). Людям, которые инвестируют в свои собственные идеи, будет трудно работать с командой, которая нацелена прислушиваться к рынку, собирать доказательства и находить лучшие идеи, независимо от их источников. Звездные личности не работают в «чувствующей» команде.

Менталитет команды должен формироваться на исполнительском уровне. Лидеры должны задать направление, а затем позволить команде собирать информацию, изучать ее и реагировать. Мы убедились в преимуществах этого типа лидерства на примере руководителей проекта Cooking Light Diet. Они признали бизнес-проблему, назначили команду для ее решения, дали ей целевые показатели успеха с точки зрения доходов и стратегических целей, устранили ограничения по автономии команды, а потом ушли с ее пути. В свою очередь, команда постоянно была на связи с лидерами, чтобы держать их в курсе того, что она узнавала. Члены команды предоставляли доказательства того, какие идеи оказались эффективными, в каких сферах нужны либо не нужны инвестиции, какие их планы способствовали прогрессу, а где следовало скорректировать ожидания. И лидеры реагировали на это. Этот непрерывный цикл общения предоставлял команде Cooking Light Diet свободу исследования на пути к наилучшему возможному решению.

Через полтора года сервис диетического питания вырос из управляемого вручную и насчитывавшего всего 12 клиентов в полностью автоматизированный сервис здорового питания с ежегодным доходом в 1 млн долларов, и продолжал расти. Функции, которые команда реализовала в данном сервисе, никогда не были зафиксированы в каком-либо специальном документе или предписаны руководством. Напротив, сервис начался с видения и был создан командой, которая была постоянно чувствительна к тому, что нужно рынку, и реагировала, предоставляя только те функции, которые несли какую-то ценность. Генеральный директор студии Pixar Эд Кэтмелл прекрасно описывает этот подход в своей книге «Корпорация гениев» (изд-во «Альпина паблишер», М., 2014 г. – ред.):

Мы расскажем больше о культуре и структуре команды во второй части книги. Но сейчас важно понять, что подобный подход к работе – это изменение (в некоторых случаях – глобальное) того порядка, который сложился сейчас в большинстве крупных компаний.

Когда вы собираете все воедино, на что это похоже? Рассмотрим пример цикла «почувствовать и отреагировать» на опыте компании Forward 3D, использовавшей этот подход для создания нового бизнеса[20].

Forward 3D – компания поискового маркетинга, которая проводит рекламные кампании в поисковых системах на основе ключевых слов, которые вводят пользователи. Это означает, что компании нужно собирать и анализировать данные о тех вещах, которые люди ищут в интернете. Ее руководители подумали, что смогут использовать эти данные не только для того, чтобы помочь клиентам проводить маркетинговые кампании. Они предположили, что могут помочь клиентам найти новые возможности для бизнеса.

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

Члены команды продолжили исследовать ситуацию дальше. Используя базовые сервисы, доступные в интернете любому предпринимателю, они создали тестовую страницу продажи клеток для попугаев. Это было тестирование целевой страницы, очень похожее на тактику, использованную командой Cooking Light Diet. Собственно, страница Forward 3D не позволяла людям покупать клетки, она просто предоставляла им возможность выражать свою заинтересованность, вести двусторонний разговор. А заинтересованность была очевидной. Основываясь на этих результатах, команда начала действительно продавать клетки через сайт JustCages.com, созданный для этой цели.

Команда организовала самые элементарные рабочие операции. Они нанимали грузоперевозчиков для выполнения разовых заказов, поэтому им не пришлось брать на себя финансовый риск организации складов. Вскоре это стало приносить прибыль, и команда снова отреагировала, занявшись улучшением веб-сайта. В конечном счете, когда эта затея получила доверие в компании, команда взяла на себя риск по организации складского хранения товара.

Генеральный менеджер МакНалти описал это так: «Чего мы совсем не сделали, так это красивого веб-сайта в первый же день. А то, что мы действительно сделали, был отклик на спрос с первых же шагов»[21]. Другими словами, команда сначала рискнула и создала предложение (на которое действительно был спрос), прежде чем перейти к изучению того, что потребуется для фактического управления бизнесом. Члены команды проверяли каждый шаг на этом пути с помощью небольших, не требующих инвестиций решений. То есть они создали непрерывный цикл «чувствования и реагирования» с целевой аудиторией. И каждый раз, когда они что-то узнавали, они быстро реагировали на данную возможность. Теперь Forward 3D является одним из крупнейших продавцов клеток для домашних питомцев в интернете.

✓ На практике подход «почувствовать и отреагировать» – это работа небольших, автономных команд, которые экспериментируют и учатся с целью обрести видение или «ухватить» стратегию.

✓ Команды исследуют путь, опираясь на свободные планы, проводя небольшие эксперименты и проверяя свои предположения по мере продвижения вперед.

✓ Команды делают ставку на непрерывное раскрытие ценности путем двустороннего разговора с рынком.

✓ Ценность определяется критериями, важными для клиента.

✓ Этот подход работает как для стартапов, так и для крупных компаний.

✓ Команды используют любые собранные ими данные, как количественные, так и качественные.

✓ Лучше всего метод подходит небольшим многофункциональным командам.

✓ Подход «почувствовать и отреагировать» – это больше, чем просто процесс. Это – культура. Он требует взвешенного отношения со стороны как членов команды, так и руководства.

Когда мы писали нашу первую книгу «Lean UX», мы преследовали цель показать современным практикам (дизайнерам, разработчикам, менеджерам по продукции и другим сотрудникам, которые формируют цифровые команды) эффективный способ работы с цифровыми технологиями. Подход, изложенный в этой книге, стал популярен среди работающих в цифровой сфере. Однако этот метод не избежал критики, и его распространение столкнулось с препятствиями.

Самый знаковый комментарий, который мы слышали в адрес «Lean UX», звучал так: «Нам нравится этот подход, но мы не можем его использовать». Проблема воплощения была самой важной: большинство компаний не приспособлены к тому, чтобы воспользоваться преимуществами непрерывного обучения, основанного на технологиях. Действительно, в 2015 году исследование журнала Harvard Business Review по особенностям лидерства в цифровой сфере показало, что многие менеджеры знают о проблемах, связанных с цифровыми технологиями, а именно: о риске ущерба бизнесу и необходимости создания эффективных ответных мер[22]. Многие из этих лидеров даже имеют четкое представление о том, как им следует действовать. И все же подавляющее большинство из них сталкиваются в своих организациях с сопротивлением изменениям. Установку «мы всегда так делали» – ежегодный финансовый бюджет, долгосрочное стратегическое планирование, иерархичность подразделений, системы стимулирования по принципу процента от продаж – на самом деле очень сложно преодолеть.

Сложно, но возможно. Организации все-таки решают эти проблемы и принимают изменения. Вот несколько примеров компаний, которые уже преодолели трудности реорганизации.

Если вы достаточно много рассуждаете о неопределенности, взвешенном подходе и обратной связи с рынком, вы обязательно столкнетесь с легендой о Стиве Джобсе. Люди в большинстве своем считают Apple, и в частности руководство Стива Джобса, моделью просчитанного процесса, по их мнению, именно дальновидное руководство и сила воли в сочетании с детальным планированием и устойчивым стремлением к совершенству позволили компании диктовать вкусы на рынке. «Где же эксперименты?» – спрашивают люди.

Нужно признать своеобразную гениальность Стива Джобса. Отметим, что мало кто из лидеров обладает такими же качествами, несмотря на их заявления об обратном. Тех же, кто считает, что они обладают аналогичной проницательностью, сложно будет разубедить.

Более глубокое изучение раскрывает довольно непростую историю мифа о гениальности Стива Джобса. Действительно, компания Apple создала одни из самых успешных потребительских товаров. Однако ее успех по большей части проявился в областях, где человек взаимодействует с машиной. Известные сбои Apple в программном обеспечении (помните сервис MobileMe?) и социальной сети (Ping) демонстрируют, что инструменты развития, которые эффективно служили компании в некоторых сферах, оказались недостаточны для работы с более сложными программными сервисами. Приложение iTunes, прежде считавшееся образцом простоты и мощности, теперь оценивают, как пример раздутого корпоративного программного обеспечения.

Как бы то ни было, традиционный рабочий процесс Apple связан с экспериментами, просто эти эксперименты держатся в тайне. Слухи о том, что компания Apple работает над созданием телефона, ходили годами, прежде чем в продаже появился первый iPhone. Специализированная пресса забита фотографиями первых прототипов Apple. Но эти прототипы, какими бы мощными они ни были, не смогут многому вас научить. Они не могут показать, что происходит, когда тысячи людей одновременно используют ваше программное обеспечение. Они не могут помочь вам выявить, путем анализа поведения пользователей возникающую ценность. Как и в случае с телефоном Fire Phone компании Amazon, режим секретности разработок является ограничителем. В какой-то момент идеи нужно проверять в естественных условиях.

Все же Apple может научить нас силе и способности видения, и культуре согласованности. Менеджер, который работал в партнерской компании Apple в 1990-х годах, рассказал нам историю о работе над созданием пакета товаров. Apple искала этого партнера, поскольку хотела включить один из своих продуктов в этот бандл (комплект, состоящий из нескольких товаров, продаваемых как единое целое – перев.). Но сначала менеджеры Apple хотели изменений в продукте партнера. В частности, они возражали против необходимости стадии установки требуемого продукта. «Он должен работать сразу же после распаковки» – заявил менеджер Apple, выражая культуру компании в отношении клиентского опыта. «Если он будет работать иначе, – сказал он, – то мы не будем его поставлять».

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

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

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

Однако оказывается, что, если цели команд устанавливаются с точки зрения изменения поведения клиента, а не предоставления набора функций, они в конечном итоге обеспечивают превосходные результаты. Принятие этой модели требует того, чтобы менеджеры среднего звена поверили, что именно она поможет им достичь их целей быстрее, чем прежние традиционные подходы.

Система поощрений не является чем-то, что команды могут изменить самостоятельно. Это ответственность, которая полностью ложится на плечи высшего руководства. При планировании дальнейших инициатив задайте себе следующие вопросы:

• Если мы представим новый набор функций вовремя и в рамках бюджета, как мы узнаем, что эти функции оказались верными?

• Способны ли мы измерить успешность этих новых инициатив с точки зрения бизнеса и результатов для клиентов?

• Как я могу расширить возможности своих команд, чтобы лучше использовать непрерывный поток информации, который они ежедневно получают от рынка, для запуска двустороннего разговора?

• Как я могу вознаградить их за использование этой информации для обоснования выбора, какую работу нужно выполнять, а какую нет?

Мы рассмотрим это более подробно в Главе 5, когда будем обсуждать планирование, основанное на целях.

Идеи о непрерывной обратной связи с рынком и постоянных изменениях могут показаться миражом, если вы работаете в отрасли со строгим регулятивным надзором. Такие организации часто ограничены необходимостью следовать четко определенному порядку, чтобы оставаться в рамках закона. Они обязаны проходить процедуру нормативных согласований и утверждений, прежде чем выпускать товары и услуги на рынок. Технологии могут ускорить сбор и синтез данных, но не могут ускорить бюрократию.

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

Компании частного сектора могут справиться с такого рода препятствием различными способами. Многие компании создают небольшие инновационные и исследовательские группы для изучения новых идей. Они тестируют идеи в небольших масштабах и в безопасных пределах, используя то, что мы называем песочницей – тактику, которую мы объясним в Главе 7. Кроме того, крупные компании часто вступают в диалог с регулирующими и законодательными органами, чтобы объяснить свои намерения расчистить путь для работы, которую они собираются сделать. Например, в 2015 году Комиссия по такси и лимузинам в Нью-Йорке предложила правила для платформ Uber, Lyft, а также других сервисов подсадки пассажиров. Руководители этих компаний и другие представители ИТ-индустрии встречались с регуляторами, чтобы объяснить, как работают современные команды разработчиков и почему эти правила будут обременительными. В итоге регулирующие органы отозвали свое предложение[23].

Организации государственного сектора тоже постоянно сталкиваются с подобными проблемами, а потому активно сотрудничают с регулирующими органами по интерпретации правил и уточнению границ. Один менеджер из правительственного агентства США рассказал нам о работе по разъяснению правил так называемой Оценки воздействия на конфиденциальность – определения рисков, которые препятствуют оперативной обработке данных. Поскольку команды все чаще применяют метод «почувствовать и отреагировать», мы ожидаем увидеть, что их работа приведет к изменениям работы регулирующих и надзорных органов.

Существуют ситуации, в которых соображения безопасности будут удерживать нас от проведения частых экспериментов в реальном времени. Например, вам вряд ли захочется проводить A/B-тестирование программных элементов аэробуса.

Иными словами, обсуждаемые методы не всегда применимы в любых ситуациях. Существует множество развитых отраслей, которые разрабатывают критически важные для безопасности системы и проводят регулируемые тестирования в безопасных условиях. Эти отрасли, как правило, имеют сильную инженерную культуру и традиции, а также создают системы с высокой степенью предсказуемости. Тем не менее было бы неверно полагать, что подход «почувствовать и отреагировать» не может быть использован в данных отраслях в определенных ситуациях. Мы прогнозируем распространение этого подхода, наряду с традиционными методами, даже в самых консервативных отраслях, связанных с безопасностью.

Компания Airbus Group, например, в качестве эксперимента открыла инновационные лаборатории для быстрой разработки и тестирования идей[24]. К примеру, одним из проектов лаборатории в Тулузе, стал новаторский способ обеспечения безопасности самолета на стоянке. В настоящее время это сложная комплексная работа с рядом беспрекословных к выполнению требований. Команды из лаборатории разрабатывают способы автоматизации этого процесса с помощью нескольких датчиков, располагаемых на уязвимых местах самолетов, при этом датчики контролируются в режиме реального времени службами аэропорта. Разделяя направления для исследований, Airbus минимизирует риски для своей основной деятельности. Эти лаборатории позволяют основному бизнесу работать без сбоев или рисков для безопасности. Как только идея докажет свою ценность, Airbus сможет предпринять следующие шаги для ее реализации или интегрировать ее в более широкий производственный процесс.

А General Electric начал программу под названием Digital Twins, которая включает в себя создание цифрового моделирования аппаратных продуктов. Реактивный двигатель получает «виртуального близнеца». Это позволяет GE в реальном времени контролировать работу конкретного двигателя, а также экспериментировать с новыми функциями и настройками в цифровой сфере без риска для безопасности в реальном мире.

В крупных компаниях, как правило, сложно получить разрешение на работу подобным способом. Любые изменения в крупных компаниях – это нелегко.

Обычно одна относительно автономная команда с грамотным менеджером может просто начать применять на практике некоторые из этих методов, и со временем, возможно, их успех закрепит использование такого подхода. Но когда эти методы станут распространяться на программы нескольких подразделений с разным уровнем иерархической подчиненности и внутренней коммуникации, проблемы в плане координации могут быть колоссальными.

Консультант по коучингу Дэвид Д. Блэнд в 2014 году взял на себя часть этих проблем, работая с командой в Toyota. Блэнд сотрудничал с легендарным автопроизводителем, чтобы помочь компании проверить новые функции автомобилей, которые были не совсем готовы к запуску в производство. В одном из проектов Toyota хотела проверить, будет ли способствовать настройка ее автомобилей к интеграции с газовыми насосами удобству заправки для клиентов.

Как обычно, Toyota создает команду для каждой инициативы и планирует ее бюджет на следующий год. Финансирование исследований осуществляется на основе бизнес-планов, которые позволяют прогнозировать не только уровень затрат, но и рентабельность инвестиций в будущем.

Блэнд и его команда бросили вызов этой традиционной модели, начав с ограниченного бюджета и сосредоточившись на создании прототипов нового сервиса. Эти прототипы были протестированы вместе с базовым программным обеспечением и некоторыми компонентами приборной панели автомобилей. Затем команда отобрала пользователей из Craigslist и Facebook. Им показали идеи, предоставив возможность пользоваться этими функциями. Так команда смогла быстро узнать, какие из разработок имеют потребительскую ценность, а какие, что не менее важно, не востребованы. Основываясь на идеях, высказанных в ходе двусторонних разговоров (в данном случае личных, а не по интернету), Toyota смогла принять решение о дальнейшем инвестировании в этот проект.

Прежде чем принять решение о следующих шагах, компания позволила небольшой команде работать самостоятельно, что дало разработчикам свободу строить циклы «почувствовать и отреагировать» так, как они считали нужным. Изолирование команды от повседневной бюрократии крупной организации предоставило исследователям свободу движения в их собственном ритме, они имели возможность тестировать свои идеи и корректировать свой курс по ходу работы.

Но в основном в крупных компаниях команды действительно от чего-то зависят, часто от выполнения работы другими командами. В таких случаях любые изменения в плане работы должны кем-то контролироваться. Подход одинокого волка здесь не сработает.

Но координировать работу нескольких команд, используя методы «почувствовать и отреагировать», можно. Например, в Westpac, крупнейшем банке Австралии, команды создают простой, основанный на результатах регламент, чтобы наблюдать за деятельностью нескольких команд в больших программах. Они используют программные установки, которые позволяют руководить выполнением работы в нескольких командах, но при этом дают возможность отдельным группам свободно экспериментировать. В Главе 5 мы более подробно расскажем о том, как это происходит в Westpac и других крупных организациях.

Подобный рабочий процесс подразумевает наличие самостоятельных команд со свободой действий и правом на провал. Менее подходящей среды, чем правительство, для этих вводных не найти. Там действует множество ограничений: законы, положения и процедуры; политика, выборы и бюджеты; круглосуточные новости и общественная отчетность. Удивительно, как вообще удается что-либо сделать. И все же цель правительства состоит в том, чтобы служить людям – возможно, это самая ориентированная на потребителя миссия. Итак, видите ли вы потенциал подхода «почувствовать и отреагировать» для двустороннего разговора с правительством в режиме реального времени?

Мы наблюдаем, как появляются новые правительственные структуры, созданные специально для решения этой проблемы, и существенно то, что они привержены подходу «почувствовать и отреагировать». В Великобритании недавно созданная правительственная цифровая служба (GDS, Government Digital Service) описывает этот подход следующим образом: «Мы всегда исходим из потребностей пользователей и реагируем на них быстро. Мы придерживаемся принципов гибкости во всем, что мы делаем. Мы придерживаемся открытого способа работы, поскольку прозрачность способствует улучшениям»[25]. GDS является лидером в этом движении, она стала образцом для создания подобных организаций в США (18F и Цифровая служба США, US Digital Service), Австралии (Учреждение цифрового преобразования, The Digital Transformation Office) и других странах.

Одной из главных проблем в правительстве являются государственные закупки. Традиционные правила требуют заключения с поставщиками контрактов, в которых очень точно указываются характеристики и функции поставок. Однако, как вы уже заметили, этот подход, разработанный для целей подотчетности и обеспечения разумного расходования денег налогоплательщиков, часто терпит неудачу, и порой довольно чувствительную. Но у работающих в правительстве чиновников нет выбора: Нуа Кунин, директор отдела инфраструктуры в 18F, внутреннего агентства цифровых услуг США, в 2014 году изложил факты в трех твитах.

Мы испытали это на себе. Потенциальный государственный заказчик из США обратился в нашу компанию за помощью в разработке новой системы. Клиент представлял мощную коммуникационную платформу, способную связать правительство и избирателей, – современную систему двустороннего разговора. Это была увлекательная и уникальная возможность: в то время ничего подобного не существовало. Излишне говорить о том, что мы хотели участвовать в этом проекте.

Руководители проекта объяснили нам свои цели: они хотели сэкономить миллионы долларов, которые ежегодно тратятся на почтовые расходы, заменив почтовые рассылки электронными письмами. Они представили длинный список функций, создание которых они требовали к конкретным датам, что, по их словам, было необходимо для достижения цели. Но когда мы пообщались, стало понятно, что эти предположения относительно сроков не проверялись. Мы предложили руководителям проекта другой подход, при котором успех измерялся с точки зрения снижения почтовых расходов (что и было целью), а не с точки зрения сроков создания функций.

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

Но ситуация меняется. Одним из первых проектов, над которым работала цифровая служба Великобритании, был новый способ заказа проектов – иначе говоря, новый способ утверждения расходов. Признав важность проверки предположений (а не определенных требований) до разработки системы в целом, GDS потратила восемь месяцев на исследование и тестирование, прежде чем перешла к заключительной альфа-фазе. GDS описывает это так: «При проектировании сервиса невозможно предсказать все заранее. В каждом проекте существует множество проблем, и на заключительном этапе [альфа-фазе] вы начнете исследовать решения для них»[27].

В США 18F таким же методом работает над правилами закупок. С конца 2015 года они экспериментировали со способами аккредитации подрядчиков и исполнителей и публиковали результаты этих экспериментов в своем блоге. К 2016 году они запустили пилотный проект этого нового подхода и подписали контракт на участие двух правительственных учреждений: ФБР и Министерства финансов США[28].

Мы находимся в самом начале пути, но очевидно, что уже началась работа по изменению системы.

Требуются определенные способности к овладению стилем работы «почувствовать и отреагировать». Люди, которые успешны в этой среде, в основном скромны, любопытны и чувствуют себя комфортно в условиях неопределенности. Они ориентированы на обучение и хорошее сотрудничество. Они хотят слышать мнения по поводу своей работы и готовы исправить ее, если что-то не так. Не все подходят под это описание.

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

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

Как оказалось, нам удалось достичь компромисса, который состоял в том, что бэк-инженеры будут по-прежнему принимать участие в процессе, но уже в качестве обработчиков данных. Им не нужно будет разговаривать с клиентами.

Это был момент обучения для всех нас. Запуск двустороннего разговора с помощью подхода «почувствовать и отреагировать» представляет собой зачатки обратной связи, которых пока нет. Для вашей команды это может являться неудобством. Если вы настроены на этот способ работы, следует ожидать, что кто-то из ваших коллег уйдет от вас. Адаптация к таким условиям поможет вашей организации быстро создать правильную среду. И чем скорее она будет создана, тем больше единомышленников будет привлекать.

Успешные компании, использующие подход «почувствовать и отреагировать», находят людей, желающих работать в таких условиях. Это исследователи, искатели, не удовлетворенные существующим положением. Эти люди притягиваются к среде, которая практикует способ работы, близкий к уловке-22 (Уловка-22 – ситуация, возникающая в результате логического парадокса между взаимоисключающими правилами и процедурами – перев.).

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

Бренды дают обещания. Если вы в бизнесе уже довольно давно, ваши клиенты ждут от вас определенных вещей – качества, сервиса, надежности. Вы, по понятным причинам, осторожны с экспериментами, не зная, как на них отреагируют покупатели. Вы не хотите рисковать и отталкивать их или показаться глупым – словом, впустую тратить время на какие-то идеи.

Эти опасения являются обоснованными. Некоторые из крупных компаний, с которыми мы работали, разделяют их. Чтобы избежать риска, многие организации могут проводить свои эксперименты за пределами бренда. Например, они могут представить свои новые идеи под названиями вымышленных компаний или опробовать новшества в столь небольших масштабах, что это ограничит влияние плохого тестирования на бренд.

Однако некоторые компании готовы экспериментировать открыто. Компания Nordstrom, лидер сетевых универмагов в США, известная качеством обслуживания клиентов, сняла видеоролик, запечатлевший эксперимент в магазине одной из своих инновационных команд. Сам эксперимент (а также видео, которое стало вирусным на YouTube) представляет бренд во всем его великолепии: решительный в бизнесе, уважительный и заботливый по отношению к потребностям клиентов. Nordstrom, по словам стратега Кристины Уодтке, «экспериментирует вместе со своими клиентами, а не на них»[29].

Дизайн-мышление, бережливое производство, шесть сигм (от англ. Six Sigma – концепция управления производством, разработанная компанией Motorola в 1980-х годах с целью снижения отклонений в процессах производства электронных компонентов. Вся идея направлена на то, чтобы максимально улучшить качество работы организации. В основу были положены статистические методы управления процессами – ориентированные на клиента инновации, lean-дизайн, agile-методы, цикл НОРД (англ. ООDА [observe, orient, decide, act] – концепция, разработанная Джоном Бойдом в 1995 году, также известная как «петля Бойда». НОРД – это кибернетический самовоспроизводящийся и саморегулирующийся цикл, имеющий в своей структуре четыре процесса: наблюдение, ориентацию, решение, действие – ред.). Звучит знакомо? В свое время эти идеи были «хитами сезона» в управленческих кругах. И не было никаких сомнений в том, что именно эти идеи спасут наши компании. Вот только когда шумиха вокруг них утихала, их спокойно забывали. Может быть, вы считаете, что «почувствовать и отреагировать» – это еще одна штука, которую можно добавить к этому списку.

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

Эти подходы означают процесс, но это не только процесс. Они предполагают изменение культуры. Подход «почувствовать и отреагировать» – это самый новый вариант подхода к управлению неопределенностью, в которой мы живем уже давно. Она определенно предшествовала еще промышленной революции. Поэтому, несмотря на то, что различные «хиты сезона» могут появляться и исчезать, технологии всегда с нами. А подход «почувствовать и отреагировать» – это о том, как управлять цифровым миром.

✓ Несмотря на то, что ни один подход не годится для разных ситуаций, «почувствовать и отреагировать» может и должен использоваться в ситуациях неопределенности.

✓ Подход «почувствовать и отреагировать» – это не отказ от видения; он часто является лучшим способом для достижения видения.

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

✓ Даже крупные компании, правительственные структуры, регулируемые отрасли и отрасли, связанные с безопасностью, используют методы «почувствовать и отреагировать».

✓ Правила закупок могут являться препятствием, но организации должны пересмотреть стандарты закупок, чтобы преодолеть его.

✓ Даже хорошо известные бренды могут использовать данный подход.

✓ Подход «почувствовать и отреагировать» не является «хитом сезона». Это естественная реакция на природу современной работы.

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

Прикиньте ситуацию к своей организации. Вот ваши товары или услуги. Вы знаете, о том, как они были произведены, приобретены, как ваши клиенты покупают их. Эти процессы меняются благодаря цифровым технологиям.

Подумайте о том, как вы их продаете, рекламируете, о том, как обучен ваш персонал. Как вы платите своим сотрудникам и поставщикам? Как вы работаете со своими партнерами? В каждом из измерений вашего бизнеса вы наверняка наблюдаете радикальные изменения. А движущей силой этих изменений являются цифровые технологии. Или, точнее говоря, эти изменения обусловлены тем, что ваши конкуренты, клиенты, пользователи и, да, даже ваши сотрудники теперь могут сделать (и делают) благодаря этим технологиям.

В 1990-х годах Amazon, пожалуй, была первой компанией, получившей крупное коммерческое преимущество за счет использования пользовательского контента. Позволяя покупателям оценивать товары на своем сайте, компания активно вела двусторонний разговор со своими клиентами и предоставляла материальные выгоды покупателям, которые ищут товары в интернете. Доступ к данному контенту способствовал клиентскому выбору в пользу Amazon, а не других конкурентных сервисов. За последние десять лет мы убедились, что интернет-рецензии и другой пользовательский контент становятся реальной силой. Они меняют отрасли в целом.

Рассмотрим сегмент косметической индустрии, которая на протяжении многих лет полагалась на прилавки с косметикой в магазинах как на важнейший канал сбыта. Эти прилавки играют важную роль в удовлетворении потребностей клиентов. Покупатели могут зайти в универмаг, изучить ассортимент и получить ценный совет, инструкцию по применению от профессионалов.

Но в последнее время этот канал сбыта оказался под огромным давлением: платформа YouTube, которая раньше размещала в основном видео с кошками и забавные домашние ролики, обновилась, в том числе обзавелась каналами, специализирующимися на разного рода советах. YouTube заполонили видеоинструкции: недавний запрос в поиске по слову «мейкап» выдал почти 8,5 млн видеороликов. Эти материалы охватывают огромный спектр тем – «урок мейкапа для карих глаз», «для начинающих», «для темнокожих женщин», «для подростков». Некоторые из этих видеороликов, как и многое в интернете, не очень хороши, но есть и действительно отличные видео. Лучшие авторы становятся звездами. Согласно статистике, пользователи YouTube ежедневно смотрят более 120 млн бьюти-видеороликов[30]. Возможно, более важно то, что из всего бьюти-контента, доступного на этом сайте, ведущие бренды контролируют только 3 %.

Дело не в том, что бренды не пытались создать свой собственный контент. А в том, что пользователи хотят услышать мнение других покупателей. Наверное, самой знаменитой в сфере мейкап является Мишель Фан, использующая YouTube в качестве своей основной платформы: у ее канала более 8 млн подписчиков, а учебные видеоролики собирают более 1,1 млрд просмотров. Она начала публиковать видео на YouTube в 2007 году. В 2010 году крупный косметический бренд Lancôme начал спонсировать видеоролики Фан и сделал ее своим «официальным блогером-визажистом». Также впечатляет сотрудничество Фан с головной компанией Lancôme – L’Oreal, которая в 2013 году создала новую линейку продуктов под названием «em by Michelle Phan».

Бренды, как и ритейлеры, чувствуют на себе влияние пользовательского контента. Согласно недавнему докладу компании Ernst & Young по данной отрасли, «сложно будет поддерживать рост, прибыльность и лояльность клиентов к бренду. Новое поколение клиентов «на связи» имеет мгновенный доступ к информации о ценах по всему миру, возможность сравнить продукты и ознакомиться с мнением популярных блогеров. Это усложнит поддержание высоких ценовых различий, имеющих решающее значение для продукции класса «люкс»[31].

Поскольку цифровые услуги стали мейнстримом, они изменили наши ожидания как потребителей. Если нам нужно что-нибудь узнать, мы используем Google-поиск. Если мы хотим куда-нибудь добраться, мы используем Uber. Хотите сменить старый отель в иностранном городе? Предоставьте это Airbnb. Если нам нужно что-нибудь купить, Amazon доставит все необходимое за пару дней, а в некоторых городах и в течение часа. Мы консультируемся у таких экспертов, как Мишель Фан, через YouTube, Twitter и Pinterest. А еще все эти сервисы и услуги доступны на экране наших смартфонов – где бы мы ни находились и где бы они нам ни понадобились.

Почему эти сервисы пользуются успехом? Потому, что они предоставляют клиентам необходимую им ценность, отвечающую их потребностям. Технологии, которые правильно регулируются, настолько податливы, что позволяют поставщикам услуг и создателям контента не только предлагать свои услуги, но и корректировать их практически в режиме реального времени, ориентируясь на спрос клиентов и обратную связь от них.

Это является ключевым моментом в нашем подходе к взаимодействию с клиентами. Те же технологии, которые обеспечивают непрерывное обучение в наших организациях, стимулируют и взаимодействие в реальном времени, которое наши покупатели ожидают от компаний. Если мы не отреагируем, не оправдаем их ожиданий, они перейдут к другому поставщику быстрее, чем мы произнесем слово «iPhone».

Приход новой эпохи ожиданий клиентов не так давно продемонстрировал легенда менеджмента Том Питерс. Он поделился в Твиттере своей разочарованностью по поводу новой капсульной кофемашины Nespresso. Поскольку за его аккаунтом в Твиттере следят 127 тыс. читателей, Питерс позволил себе многотвитную тираду с жалобами на некачественный сервис.

Он пытался зарегистрировать кофемашину, подаренную женой (нам тоже стало ее немного жаль). В итоге написал в Твиттере следующее:

Четыре часа спустя Питерс продолжил, все еще будучи расстроенным:

Еще через три часа Питерс бросил вызов своим читателям:

Попытки команды Nespresso по обслуживанию клиентов в Твиттере устранить проблемы Питерса были тщетными. Трения между покупателем и компанией, которые когда-то были их личным делом, теперь перестали быть конфиденциальными. Клиент и продавец разбирались в Твиттере публично, а весь интернет за этим наблюдал. И, что еще хуже, историю подхватили СМИ, что усилило конфуз компании[33].

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

У Spotify была проблема с работой сервиса. По технологическим причинам потоковая передача музыки могла осуществляться только по единственной учетной записи. Если вы слушали музыку в Spotify на своем компьютере, а затем решали послушать ее на телефоне, то на компьютере потоковая передача прекращалась. Для некоторых пользователей это не являлось большой проблемой. Но это означало, что ваша семья не могла пользоваться одним аккаунтом: например, члены семьи не могли слушать музыку на кухне, если вы в этот момент слушали ее в своей машине.

Клиенты жаловались на это, и сервис Spotify смог оценить масштабы проблемы, посмотрев на статистику сервиса. Но заключалась ли проблема в том, что один слушатель использовал разные девайсы, или же в том, что люди делились своими аккаунтами? Компании нужно было получить больше информации. Без лишнего шума, в рамках своих двухмесячных обновлений компания представила функцию, которая предупреждала клиентов о том, что другое устройство собирается прервать их потоковую передачу, и предоставляла им возможность предпринять следующий шаг. Это изменение улучшило качество обслуживания клиентов, но не более того. Зато оно дало возможность Spotify для сбора (чувствования) данных. Отчасти на основе этого понимания компания смогла наблюдать за данными и собирать доказательства, позволяющие предложить клиентам новую услугу: «семейный» план, который за чуть более высокую ежемесячную плату позволяет одновременно передавать потоковую музыку всем членам семьи.

Эти истории иллюстрируют две важные концепции. История с Spotify показывает, что если вы понимаете, что хотят ваши клиенты, то наверняка сможете найти способ создать для них ценную услугу – ту, за которую они готовы заплатить. История с Nespresso подтверждает вторую концепцию: даже устоявшиеся бизнес-модели, как у Nespresso (они продают кофеварку, а затем продолжают «навариваться» на клиентах, поставляя им капсульный кофе, который требуется для этой кофеварки), теперь являются многоканальными сервисами. Клиенты Nespresso покупают у компании капсульный кофе в интернете, и – угадайте что? Nespresso – часть бизнеса программного обеспечения. Недостаточно продавать кофемашины, которые хорошо выглядят и варят вкусный кофе. Нужно еще и правильно представить свой сервис.

Реагирование на отзывы потребителей больше не является добровольным делом. Игнорирование обратной связи означает не только риск потери продаж, но и потерю способности публично позиционировать ваш бизнес. Это особенно касается индустрии продажи автомобилей.

До массового распространения интернета покупатели автомобилей, прежде чем принять решение о покупке, посещали несколько дилерских центров. Теперь доля посещений дилерских центров перед продажей в среднем составляет 1,9 %. Большую часть информации клиенты узнают в интернете. Они проверяют наличие товара, сравнивают цены и читают отзывы о качестве обслуживания клиентов[34]. Покупатели приходят в дилерский центр, будучи уже проинформированными о транспортном средстве, которое они хотят приобрести, зная обо всем, от его характеристик до «правильной» стоимости. Они подготовлены так, как должен быть подготовлен каждый дилер. Дилерские центры знают о своей плохой репутации в области обслуживания, а также знают о том, что их покупатели сейчас знают больше, чем когда-либо. И дилерские центры сами начали применять технологии для обращения к этим информированным с помощью интернета клиентам.

Sonic Automotive – компания, которая входит в список 500 организаций по версии Fortune и является одним из самых крупных американских автомобильных конгломератов – уже много лет ощущает на себе сдвиги в поведении будущих автовладельцев. Компания отслеживает активность клиентов через все возможные каналы связи – в интернете, через мобильные приложения, а в последнее время и через покупки в своих магазинах. Для улучшения обслуживания клиентов, готовых обратиться к другому дилерскому центру в мгновение ока, Sonic вооружил своих продавцов в салонах планшетами iPad, которые помогают обеспечить незамедлительный доступ и к перечню товаров, и к заявленным предпочтениям клиентов, и к последующим услугам, финансовым и страховым. Теперь продавцы способны реагировать на запросы клиентов, выбравших их дилерский центр как раз потому, что в нем возможно то, что невозможно у конкурентов. В данном случае цель состояла в повышении доверия к продавцу, который стал отзывчив к конкретным запросам и способен завершить продажу без ужасных процессов вроде «передачи клиента финансисту».

Необходимо внедрять цифровые инструменты в традиционный процесс продаж. Но цель состоит в том, чтобы искать решения, удовлетворяющие требованиям клиентов. Поэтому Sonic дополнительно изменил еще одну ключевую составляющую своей модели – схему расчета зарплат. Новая схема уходит от модели компенсации с учетом комиссии, которая, как считалось, создает состязательные отношения между покупателем и продавцом. Теперь размер вознаграждения продавца состоит из 75 % в виде основного оклада и 25 % – в виде бонусов, которые зависят от отзывов клиентов. Следовательно, цель продавца состоит не только в том, чтобы продать как можно больше автомобилей, но и в том, чтобы обеспечить лучший клиентский опыт. Комментарии в интернете, отзывы, рейтинги и другие формы пользовательского контента сводятся к общей оценке этого опыта работы с клиентами. Дивиденды могут быть количественно определены в продажах, повторных продажах, упоминанием в онлайн-обзорах и маркетинге «из уст в уста».

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

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

Животноводство насчитывает многовековую историю, основанную на сочетании непосредственного опыта управления стадами животных и мудрости, передаваемой из поколения в поколение. Тем не менее молодое поколение, занявшись подобным семейным делом, все больше проявляет техническую подкованность. То есть новые животноводы меньше полагаются на опыт старшего поколения и больше – на Google. Зачем обо всем помнить, если можно просто «загуглить»?

Select Sires – американская компания, которая обслуживает производителей молочных продуктов и говядины. Основанная в Огайо, она является «крупнейшей организацией по искусственному осеменению в Северной Америке»[35]. Говоря иначе, она продает бычье семя скотоводам. Одни клиенты разводят скот для мяса, другие – для молока. Эти фермеры обращаются к Select Sires, чтобы те помогли им выращивать стада и поддерживать их здоровье и воспроизводство.

Для Select Sires конкурентность в данной отрасли сильно выросла. Из-за смешения бычьих родословных дифференциация на уровне продукции (само семя) становится затруднительной. Если Select Sires выращивает скот высшего сорта, то покупатель, который обычно является опытным животноводом, затем может использовать этого быка для создания конкурирующего продукта. Таким образом, Select Sires придется предложить еще более хороший продукт.

Управление генетикой крупного скота является сложным, ресурсоемким процессом. Необходимо способствовать созданию желательных характеристик в стаде, избегать инбридинга (инбридинг – скрещивание близкородственных форм в пределах одной популяции организмов – перев.) и следить за сильными и слабыми особями в стаде. Для фермеров, владеющих сотнями или тысячами животных, это может стать невероятно сложной задачей. А для Select Sires – это возможность для дифференциации.

В 1960-х годах, в первые дни работы Select Sires, сотрудники оценивали животных в стаде по пятнадцати различным характеристикам, находясь рядом с ними и записывая информацию на листке бумаги. Затем скотоводы перебирали все эти листки, пытаясь найти лучший вариант для разведения – предоставления услуги спаривания. С годами сбор информации о животных стал прерогативой портативных компьютеров, а анализ стал более современным и совершенным. Теперь молодая, технически подкованная целевая аудитория компании требует мгновенного доступа к генетическим сведениям и другим данным для сравнения.

Чтобы удовлетворить этот спрос, Select Sires набрала штат инженеров-программистов. Компания создала поисковую службу (считайте, что это Google для производителей крупного рогатого скота) с различными базами данных, которая позволяет покупателям увидеть, в чем товары Select Sires превосходят своих конкурентов.

Также компания создала цифровую версию своих услуг. Клиент может указать ряд желаемых качеств, которые он хотел бы видеть в будущем стаде. Например, если стадо предназначено для производства молока для сыроваренного завода, фермер может использовать веб-инструменты от Select Sires, чтобы выбрать необходимые качества животных и увидеть результаты, представляемые в считанные секунды. Процесс, который занял бы много часов бумажной работы, теперь происходит мгновенно.

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

Не только клиентские аспекты бизнеса базируются на цифровых технологиях. Компания Select Sires привнесла технологии и в складской процесс, что позволило сборщикам и упаковщикам работать более эффективно, оперативно и совершать меньше ошибок, чем раньше. На складе продукция хранится в контейнерах размером с кофейное зерно, которые, в свою очередь, хранятся в жидком азоте. Раньше выполнение заказа включало использование бумажных бланков и инвентарных списков, крошечных маркировок и ручной системы отслеживания. Теперь, чтобы найти продукт, работники склада перемещаются по помещению на тележке, имеющей портативный компьютер и пару мониторов. Следующий проект Select Sires нацелен на то, чтобы воплотить все эти функции в мобильном телефоне.

То, что верно для Select Sires, является верным и для остальных отраслей. Дело не только в конкретных клиентах, продуктах, сервисах и операциях. Постепенно и по всем фронтам всё начинает подчиняться программам. Впечатляет то, в какой степени Select Sires смогла к этому адаптироваться. Компания изменила то, как она представляет и продает свой продукт. Она усовершенствовала процесс сбора данных и создала на его основе сервис. Она оптимизировала выполнение операций. А члены команды продолжают переосмысливать то, как они ведут дела и как используют технологии для того, чтобы привнести самую высокую ценность на свой рынок.

В книге «Дилемма новатора» профессор Гарвардского университета Клейтон Кристенсен описывает разрушительные инновации (под которыми он подразумевает инновации, изменяющие отрасли и создающие новые рынки), которые зачастую поначалу не кажутся опасными. Такой инновацией может являться обучающее пособие мейкап для подростков на You-Tube. Видеоролик, конечно, менее функционален, чем ваш основной продукт. (Как известно, Мишель Фан проходила собеседование как соискатель работы в отделе косметики Lancôme, но ее не взяли из-за отсутствия опыта)[36]. Это еще не опасно. Это игрушка. В результате компании отмахиваются от инноваций и продолжают двигаться по-накатанному. Так происходит до тех пор, пока эта «игрушка» не становится хитом для клиентов. И уж тогда сотрудники компании начинают обращать на нее внимание – что к тому моменту зачастую оказывается слишком поздно.

Предпринимательство не ново, как и разрушительные инновации. Новым в настоящее время является резкое повышение значимости технологий и соответствующее ей снижение цен. Это послужило сигналом для целого поколения предпринимателей, которые возятся со своими собственными «игрушками». У них есть доступ к масштабу и охвату, на создание которого в прошлом ушли бы годы (а также потребовались бы огромные инвестиции).

Более того, технологии ускорили ритм работы этих предпринимателей. Раньше им бы потребовались многие годы на то, чтобы вывести свою концепцию на рынок. Теперь идею можно спроектировать, создать ее прототип и отправить на рынок, а время на обратную связь займет пару дней. Эти «игрушечные» тестирования очень легко списать со счетов, пока вы внезапно не обнаружите, что они представляют собой материальную угрозу для вашего основного бизнеса. Примеры этого технологически подпитываемого явления можно найти в СМИ.

Проект BuzzFeed был запущен в 2006 году как серия экспериментов по поиску наиболее распространяемого в интернете контента. Его основатель Иона Перетти, который руководил другим медиастартапом the Huffington, запустил сопутствующий проект, ориентированный на сортирование миллионов ссылок, чтобы найти те, которые нашли отклик у массовой аудитории. Два года спустя BuzzFeed насчитывал миллион посетителей в месяц, привлекая их сочетанием фотомемов, броских подборок (как, например, «21 фотография для восстановления вашей веры в человечество») и спонсируемого контента. За этим последовало финансирование сайта, и компания начала расти.

Несмотря на то, что контент был банален (и, возможно, поэтому традиционные СМИ игнорировали его), BuzzFeed совершенствовал новый вид модели распределения на основе обмена. Проводя эксперимент за экспериментом, BuzzFeed узнавал что-то новое. Функции, которые в итоге сохранились на сайте, опирались на одного лишь действие: обмен информацией. И именно этот постоянный обмен контентом помог привлечь до 150 млн посетителей в месяц (данные на момент написания книги).

BuzzFeed мог бы почивать на лаврах и продолжать в том же духе, но за пять лет своего существования он сделал еще кое-что интересное. Компания задействовала свою платформу и аудиторию и начала предоставлять им традиционный новостной контент. BuzzFeed нанял опытных журналистов, которые освещали новости спорта, политики, а также внутренние и международные события. К 2012 году традиционные поставщики новостей вдруг встрепенулись. Число читателей уменьшалось. Куда они делись? Оказывается, они направлялись туда, куда и все время: на BuzzFeed. Но теперь, наряду с просмотром подборки тридцати самых очаровательных котят в мире, люди читали о президентском избирательном цикле и других главных новостях. «Игрушка» обрела силу. Менее чем за десять лет BuzzFeed собрал аудиторию, численность которой в три раза превысила аудиторию такого издания, как New York Times.

В этом и заключается сила технологий. Она не опирается на традиционные бизнес-модели или точки зрения. Она не ограничена физическим производством товаров или географическими рамками. Технологии могут быть использованы для экспериментирования, разговора и обучения в темпе, невозможном для классических методов. BuzzFeed – это только одна из новых медиакомпаний, применивших новый подход, но будьте уверены, так происходит в каждой отрасли.

Впрочем, к 2013 году руководители New York Times все-таки обратили на это внимание. Почувствовав давление цифровой революции, они распорядились провести внутреннюю проверку, которая длилась полгода (что является вечностью с точки зрения интернета). Результатом стал Инновационный отчет New York Times, составленный в марте 2014 года и предназначенный для внутренней аудитории, но просочившийся в интернет вскоре после своего появления[37]. Этот документ отличается основательностью, беспристрастностью и проницательностью – это модель, к которой должны стремиться обучающиеся организации.

Этот отчет также содержит, что справедливо, обвинения в использовании традиционной деловой практики для работы в цифровом пространстве. Там также сформулированы уроки, ценные и за пределами журналистики. Этот документ отражает понимание того, на чем следует сосредоточиться, когда ваша компания движется навстречу будущему.

Отчет начинается со следующих слов:

Как организация, созданная более полутора столетия назад для деятельности в определенной сфере, может резко изменить подход, мотивацию, организационную структуру и механизмы реализации для решения новых задач? Наверное, лучше всех сформулировал ответ Одри Купер, главный редактор San Francisco Chronicle: «Мы надеемся в конечном итоге прийти к следующему: вместо того, чтобы быть газетой, которая создает веб-сайты, мы хотим считать себя цифровой компанией, которая также занимается выпуском газет»[39].

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

В качестве реакции на результаты собственного исследования Times предприняла значительные шаги по объединению цифровой и печатной деятельности издательского дома. Вы могли оценить эти изменения, наблюдая за освещением Церемонии вручения премии «Оскар» в 2014 году: газета «твитнула» ссылку на заметку, опубликованную 161 год назад и посвященную истории о Соломоне Нортап, чьи мемуары послужили основой для фильма «12 лет рабства», получившего в тот год три награды. Также газета реорганизовала работу отдела новостей, в том числе закрыв сотрудникам доступ к версии NYTimes.com через компьютеры, чтобы переключить их внимание на мобильные устройства. А в последнее время веб-аналитики начали сообщать журналистам статистику просмотров их статей. Последнее является весьма противоречивым приемом, однако эта информация призвана осведомить каждого о том, с какими проблемами распространения сталкивается газета. Эти изменения, хоть и довольно рискованные, отражают настрой авторов отчета: «Наши усилия могут быть несколько шероховаты, поскольку мы ищем новые способы привлечь внимание наших читателей»[40].

Похоже, по крайней мере пока, что это работает. В последнем на момент выхода книги отчете Times сообщила, что доходы от цифровой рекламы выросли на 10,6 %, а доходы от цифровой подписки поднялись на 13,3 %[41].

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

Если и есть что-то, что цифровая экономика переопределила, так это наша способность играть в глобальном масштабе. Было время, когда глобальный охват означал, что вам нужно было озаботиться офисами, складами и персоналом на каждом континенте. Теперь это не так.

Ни один бизнес не воплощает новую идею масштаба очевиднее, чем Facebook – пример охвата XXI века. Имея 11 тысяч сотрудников, компания обладает рыночной капитализацией в 257 млрд долларов. Сравните с компанией General Electric, которая имеет близкую рыночную капитализацию в 288 млрд долларов, но при этом на нее работают более 300 тысяч сотрудников и компания содержит офисы почти в каждой стране. Wal-Mart с рыночной капитализацией в 212 млрд долларов имеет более 2,2 млн сотрудников.

Возможно, более значимым критерием является охват Facebook: платформа может похвастаться непостижимой цифрой в 1,6 млрд (да, именно миллиарды) ежемесячных активных пользователей. Несмотря на то, что большая часть сотрудников компании находится в Калифорнии, почти 83 % пользователей Facebook живут за пределами США. А компании на момент написания данной книги всего 16 лет. Как она смогла достичь такого глобального влияния с весьма небольшим штатом сотрудников и за такой короткий срок? Конечно же, благодаря программному обеспечению.

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

В последние несколько лет Domino’s Pizza активно экспериментировала с цифровыми каналами. Рестораны этой сети расположены повсюду в Соединенных Штатах, но вам не обязательно находиться поблизости, когда вам захочется пиццы. Domino’s сейчас использует как минимум восемь цифровых каналов. Вы можете сделать заказ через Twitter. Можете заказать пиццу из своего автомобиля, используя платформу Ford’s SYNC или с помощью мобильного приложения. А недавняя разработка позволяет вам заказать пиццу, просто отправив эмодзи «кусочек пиццы» в ближайший ресторан Domino’s. Эта сеть ресторанов никогда не славилась самой лучшей пиццей, но Domino’s явно надеется, что удобство и юмор привлекут и сохранят лояльную клиентскую базу. Это может показаться «игрушкой», но вспомните уроки из «Дилеммы Новатора»: сегодняшние «игрушки» могут стать завтрашними революционными инновациями.

Другим брендом, который плетет многоканальный опыт из цифровой сетки, является фешн-дизайнер Rebecca Minkoff. В ее флагманском магазине в Нью-Йорке сотрудники используют радиочастотные чипы, чтобы отслеживать перемещение товаров. Когда клиент приносит какую-либо вещь в примерочную, специальный сенсорный экран, вмонтированный в зеркало, «узнает», что вещь находится здесь, и превращает зеркало в дисплей, на котором данный образец демонстрируется в разных цветах, а также показываются подходящие аксессуары. Покупатели могут запросить другой размер или цвет напрямую через зеркальное устройство. Еще клиенты могут использовать его, чтобы заказать бесплатный кофе или бокал шампанского, просто введя свой телефонный номер. И благодаря этой детали Minkoff способен замкнуть круг, связав посещение магазина с онлайн-аккаунтом каждого отдельного клиента. Если покупатель зашел на сайт, совершил покупку или составил список желаемых товаров, магазин также может вывести эти товары на зеркальный экран.

Мерчендайзеры Minkoff также черпают информацию из этой системы. Они могут отслеживать, какие товары попадают в примерочную, какие из них там и остаются, а какие покупают. В некотором смысле весь магазин реагирует на поведение клиентов (как традиционно, так и интернет-версии) и создает ценность как для покупателей, так и для бизнеса[42]. Это еще один пример непрерывного разговора с клиентами, возможный благодаря цифровым услугам.

За счет чего цифровые инновации повышают лояльность клиентов и расширяют их охват? Легко предположить, что покупатели всегда охотятся за новейшими разработками или гаджетами. Однако реальность заключается в том, что именно реагирование на потребности клиентов улучшает пользовательский опыт и создает ценность.

Дело не в самих технологиях, а в том, что они стали товаром, причем дешевым. Но именно ценность, которую вы предлагаете клиентам, создает конкурентное преимущество. Если вы можете сделать продукт проще в использовании, сократить время, необходимое клиенту для выполнения задачи, или предоставить нужную информацию в тот момент, когда она понадобится, вы победите. Этим и занимается Uber – сервис, который решает небольшую, но все-таки проблему с вызовом такси чрезвычайно хорошо. Благодаря возможности технологий предоставить сервису глобальный охват, Uber перевернул традиционный бизнес такси, и всего лишь за шесть лет этот сервис появился в 58 странах и 300 городах. Оказывается, Uber получил 10 млрд долларов выручки за 2016 год, не имея при этом ни единого автомобиля. Именно за такого рода улучшения пользовательского опыта потребители платят и делятся информацией с друзьями. И именно такие моменты восторга повышают лояльность к вашему бренду.

То, что принесло успех и масштаб Мишель Фан, BuzzFeed, Uber и бесчисленному множеству других компаний, – это распространение цифровых платформ. Платформы везде. Они формируют основу наших цифровых взаимодействий. Вы можете представлять их в виде строительных блоков – это части и элементы инфраструктуры, которые мы объединяем для создания цифровых продуктов и услуг. Такое широкое распространение платформ интересно по нескольким причинам.

Прежде всего, системы, которые технологическим компаниям приходилось создавать с нуля, теперь доступны всем. Они развиты, стабильны и становятся лучше с каждым днем. Поэтому нам не нужно создавать свои собственные системы для управления основными процедурами (вход клиентов в систему, платежи и т. д.), теперь мы можем передать выполнение этих задач другим и сфокусироваться на создании только тех элементов, которые уникальны для нашего бизнеса.

Существует высококачественное программное обеспечение с открытым исходным кодом, которое ничего не стоит для пользователей. Платформы, которые не предоставляют открытый исходный код, обычно являются совсем недорогими для начала. Поставщики часто предлагают бесплатные или недорогие планы, увеличивая цену только по мере роста. Это снижает барьер для входа и предоставляет неопытным компаниям тот же доступ к инструментам мирового класса, что и международным корпорациям.

Мы можем использовать социальные сети для того, чтобы начать общаться с клиентами по всему миру. Любой человек с кредитной картой может разместить рекламу на Facebook (в интернете покупка объявления займет около пятнадцати минут) и мгновенно заполучить аудиторию, которая в настоящее время оценивается в 1,6 млрд человек. Мы можем создать блог на WordPress или аккаунты на Pinterest, Tumblr, Instagram и Snapchat и сразу же привлечь большое количество людей.

Более того, платформы электронной торговли, такие как eBay и Etsy, способствуют появлению специализированных розничных торговцев. Когда торговцы «вырастают» из этих предложений, они могут с легкостью создать свои собственные «точки» электронной торговли на таких платформах, как Shopify, позволяющих создать интернет-магазин на своем веб-сайте. Любые платежные системы можно за считанные минуты интегрировать на сайт с помощью разработчиков программного обеспечения.

Основные инфраструктурные услуги, которые нам нужны, доступны в облаке. AWS, подразделение веб-сервисов Amazon, теперь служит центром обработки данных для огромного числа цифровых компаний. Их клиентом даже стало Центральное разведывательное управление США[43]. И как у всех поставщиков платформ, барьер для входа смехотворно низок. Вы можете запустить свой бизнес на AWS с помощью кредитной карты и веб-браузера и с этой базы продолжать расти дальше.

Что общего у всех этих платформ? Это программные сервисы, созданные и разработанные для улучшения условий ведения бизнеса. Они позволяют команде перейти от идеи к запуску всего за несколько дней; они делают создание MVP (minimum viable product – минимально жизнеспособный продукт) возможным. Они обеспечивают гибкость масштабирования в соответствии с производительностью бизнеса. Они позволяют компаниям сконцентрироваться на создании только тех элементов своих систем, которые добавляют ценности, обращаясь к сторонним поставщикам за ординарными вещами. Это великие уравнители между большими корпорациями и начинающими предпринимателями. И хотя крупные компании, несомненно, сталкиваются с множеством сложных проблем, конкурентная угроза, создаваемая этими платформами путем «вооружения» небольших фирм, не менее реальна.

The New York Times недавно опубликовала историю о Nielsen Media Research. Служба телевизионных рейтингов в течение многих лет была барометром для телевизионщиков и рекламы, пытающихся понять, что американцы смотрят по телевизору. Однако Nielsen по-прежнему рассылает опросники «контрольным» семьям в бумажной форме. Что еще хуже, по словам зрителя, с которым общались Times, в этом опроснике нет строки, где он и его семья могли бы вписать названия шоу, которые они смотрели с помощью потоковой передачи видео Netflix. Эта семья уже пять лет жила без кабельного телевидения, но в Nielsen об этом не знали. Понятно, что руководители медиа были разочарованы[44].

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

Знание предпочтений подписчиков подпитывает очень конкретную реакцию со стороны Netflix. В недавнем интервью директор по созданию контента Тед Сарандо сообщил, что компания, в отличие от традиционных сетей, не думает о рейтингах: «Мы можем запустить шоу для двух миллионов человек, а можем и для 30 миллионов». Но компания не хочет сравнивать разные шоу друг с другом. «Это оказывает большое давление на талант, чего мы не хотим», – пояснил директор[45].

Современные компании, предоставляющие услуги в цифровом виде, обладают встроенными возможностями для сбора данных. (Развитые платформы для сбора и анализа данных позволяют относительно легко использовать эту возможность с самого начала). Они знают о том, чем заняты их клиенты, и могут быстро отреагировать на их оценки. У них есть возможность принимать более обоснованные решения практически в режиме реального времени. Им больше не нужно делать рискованные предположения о том, чего хотят их клиенты: они могут это почувствовать.

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

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

Наиболее распространенным способом организации команд для быстрого реагирования является использование agile-методов. Эти методы способствуют расширению возможностей и позволяют командам принимать решения на основе данных. К сожалению, многие компании переняли agile-методы, не вполне понимая, зачем они им. Часто эти методы используются для выполнения заданного плана. Принятие оперативных решений (способность реагировать на обратную связь с рынком) остается вне компетенции команды, что снижает общую эффективность. Это мышление индустриальной эпохи, оперирующее длительными производственными циклами, сборочными линиями и иерархическими цепочками. Такой подход «по старинке» позволяет более проворным конкурентам извлечь выгоду из возможностей, прежде чем это сделаете вы. Чтобы соответствовать требованиям времени, вы должны передать контроль над тактическими решениями командам, которые ближе всего к пониманию потребностей рынка.

Существует еще один вид ожиданий потребителей, которому вам нужно соответствовать, если вы хотите, чтобы ваш бизнес развивался. Речь о ваших сотрудниках. Вне работы ваши сотрудники являются обычными потребителями. Они пользуются теми же технологиями, что и другие люди. А в офисе им слишком часто предлагают работать с устаревшими технологиями или ограничивают доступ к данным жесткими требованиями безопасности. (Если у вас есть знакомый, работающий на Уолл-стрит, вы наверняка знаете, что он носит с собой два смартфона – корпоративный и личный). Запросы на усовершенствование системы, как правило, сопровождаются процедурами утверждений, получения разрешения на бюджетирование, реализация их также зависит от скрытого политического маневрирования.

Большинство сотрудников настроены выполнить свою работу хорошо. Чтобы обойти препятствия и реализовать некоторые свои замыслы, они иногда вынуждены обходить систему. Это явление известно как теневые ИТ-ресурсы (Теневые ИТ – программное обеспечение и сервисы, тайно используемые сотрудниками, без получения от организации соответствующего разрешения – перев.). Часто сотрудники пользуются неутвержденными технологическими системами. По некоторым оценкам, так происходит в 75 % компаний. Хоть и неудивительно, что системные администраторы недовольны этой партизанщиной, есть основания полагать, что большинство сотрудников, использующих такие приемы, более продуктивны в работе. Они ищут способ работать лучше, использовать преимущества технологий, но корпоративные ограничения не позволяют делать это легально.

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

Компании Select Sires нужно было нанять инженеров-программистов для решения задач, связанных со спецодеждой и навозом. При этом руководство компании понимало, что без наличия современных систем и предоставления свободы их использования они никогда не найдут и не удержат разработчиков программного обеспечения. Это верно для любой компании, пытающейся нанять специалиста в цифровое подразделение, – для банков, фармацевтических компаний, газет и розничных организаций. Аналитик Мэри Микер в своем «Докладе об интернет-трендах 2015 года» отметила, что 41 % миллениалов, скорее всего, будет для работы загружать приложения на свои телефоны и ноутбуки, аналогичный показатель для работников старшего возраста она оценила в 24 %[46]. Расширение возможностей ваших сотрудников с помощью технологий – это так же важно, как и удовлетворение растущих потребностей ваших клиентов.

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

Реальный мир редко живет по спортивным законам: две команды, два подхода, один победитель. Но в 2012 году у нас появилась такая история: Митт Ромни против Барака Обамы в президентской гонке США.

Мы не будем обсуждать политику, различные ее курсы, «левых» и «правых». Речь пойдет о быстрорастущих организациях в фундаментальной отрасли нашего времени – в цифровых технологиях. Эта история будет о том, как старый, традиционный подход к традиционным технологиям был побежден новым, интегрированным подходом «почувствовать и отреагировать».

Успешные президентские кампании в США подразумевают сбор средств, координацию сотрудников-волонтеров и стимулирование явки на выборах. В наши дни эти и многие другие операции выполняются с помощью программных систем, которые компаниям необходимо создать. Это большое технологическое усилие, совершаемое в неблагоприятных, непредсказуемых условиях, и все это должно происходить быстро.

На первый взгляд план Ромни, включавший систему с кодовым названием Orca (Orca – с англ. касатка – перев.), казался пределом мечтаний по применению мощных компьютерных систем. В штабе Ромни задумали всеобъемлющую информационную систему, которая будет отслеживать все голоса избирателей на всех избирательных участках в стране и позволит волонтерам видеть критические «точки» в своих округах. Предполагалось запустить ее прямо в день голосования, чтобы иметь возможность убедиться, что каждый потенциальный избиратель Ромни добрался до избирательного участка.

«Мы узнаем больше, чем нам скажут экзитполы, – заявила на канале PBS Гейл Гитчо, директор по коммуникациям кампании Ромни (Экзитпол – используемая в мировой социологической практике процедура опроса граждан, производимого социологическими службами на выходе из избирательных участков после голосования – перев.). – В пять часов, когда выйдут экзитполы, я сомневаюсь, что мы обратим на них внимание, потому что у нас будет гораздо больше фактической информации»[47].

В штабе Ромни были уверены, что их технологические усилия, управляемые нанятыми лучшими цифровыми фирмами, станут их секретным оружием. «Кампания Обамы любит хвастаться своей деятельностью, – сказала Гитчо, – но это ничто по сравнению с нашим планом»[48].

Сам Ромни в видеоролике, посвященном своей технологической программе, сказал так: «С современными технологиями… наша кампания будет иметь беспрецедентное преимущество в день выборов».

Они назвали систему Orca, поскольку касатки являются единственными известными хищниками, охотящимися на нарвалов – именно таким было кодовое имя системы, разработанной командой Обамы.

Штаб Обамы, конечно же, работал над собственными программными системами еще за много месяцев до выборов. Члены команды просто не говорили о них, по крайней мере, скрывали это от прессы. За пределами штаба мало что было известно об этих усилиях.

С прессой техническая команда Обамы не общалась, но находилась в диалоге со своими волонтерами. Фактически в течение нескольких месяцев, предшестовавших дню выборов, команда, кроме сервиса для волонтеров, создавала новый сервис – тестировала и постоянно совершенствовала широкий спектр услуг. По сути, система пряталась у всех на виду. А члены команды не просто разработали инструмент для привлечения голосов, но и создали систему сбора средств, координации волонтеров и анализа данных. Еще они создали умные программы взаимодействия с избирателями. Ироничный видеоролик кампании «Ужин с Бараком» послужил на самом деле открытой дверью в сложном двустороннем разговоре с избирателями. Система представляла собой современное пролонгированное взаимодействие «почувствовать и отреагировать», которое могут поддерживать цифровые программы. А вот кампания Ромни не запускала Orca до самого дня выборов.

Итак, как все прошло? День выборов обернулся катастрофой для Orca Ромни. Первые предупреждающие знаки были замечены накануне вечером, когда волонтеры Ромни впервые взглянули на эту систему. Они были встревожены тем, что многие операции предназначены для пользователей смартфонов, в то время как многие волонтеры использовали простые, старые мобильные телефоны. А вот система Обамы имела преимущество в том, что волонтеры пользовались ею уже в течение нескольких месяцев. Они тоже поначалу были неуверенными пользователями, но кампания использовала обратную связь для постоянного улучшения системы, так что ко дню выборов все работало гладко.

В день выборов Orca рухнула после первого же запроса и была недоступна для большинства, если не для всех. Члены цифровой команды Ромни, занимавшиеся вопросами безопасности, решили сохранить систему в режиме секретности и управлять ею из одного из центров обработки данных, который был расположен недалеко от Бостон-гарден, где разместился операционный штаб Ромни. В результате такого решения люди, которые разработали систему, не имели доступа к системам Бостон-гарден до самого дня выборов. И управлять этими системами должны были не разработчики, подразумевалась передача обязанностей другой структуре. Таким образом, у двух команд в распоряжении была только одна попытка сделать все правильно. У них не было времени на то, чтобы войти в курс дела, и будет еще меньше времени на то, чтобы решать появляющиеся проблемы. Зак Моффат, директор по цифровым технологиям команды Ромни, позднее сказал: «Основная проблема заключалась в том, что мы проводили бета-тестирование в другой среде, а не в Бостон-гарден»[49]. Иначе говоря, команда никогда не проверяла систему в реальных условиях и не развивала сотрудничество с пользователями, что помогло бы преодолеть эту проблему.

Команда Обамы пошла в ином направлении. Была создана команда, имевшая тесную интеграцию с разработчиками и операционистами. Все эти люди работали не в разных фирмах, а с самого начала проекта трудились вместе. Сообща члены команды создали и протестировали надежную и устойчивую к сбоям систему. Они не использовали какой-то единственный центр по обработке данных, а управляли своей системой на облачной службе Amazon, что позволило тестировать и корректировать программу с первого дня и вплоть до дня голосования.

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

Митт Ромни – опытный стратег. Он является ветераном управленческого консалтинга 1970-х и 1980-х годов. До прихода в политику он работал в Бостонской консалтинговой группе, был партнером в Bain & Company. Он знает, как нужно управлять крупными организациями. Но в ходе своей кампании 2012 года, по крайней мере в том, что касалось технологий, он работал по старой схеме.

У команды Обамы были основания полагать, что ее подход был лучше, чем у Ромни: члены штаба Обамы за четыре года до того пытались сделать многое из того, что пытался сделать Ромни в 2012 году. И тогда у них тоже ничего не вышло. Таким образом, выявив свои технологические неудачи в кампании 2008 года, команда Обамы выбрала совершенно иной подход. Вместо того, чтобы строить большие планы, они обошлись небольшими. Они могли создать «большой взрыв», но вместо этого предпочли откалывать кусочек за кусочком. И еще, вместо того, чтобы действовать в полной секретности и изоляции, они работали совместно, невзирая на должности и подразделения.

Они знали, что и как им нужно делать, отчасти благодаря тому, чему индустрия программного обеспечения научилась за последние десять лет. Кампания Обамы собрала в штаб-квартире в Чикаго великолепную команду из людей, разбирающихся в технологиях, многие из которых бросили свои фирмы в Кремниевой Долине, чтобы работать над тем, что действительно было новым стартапом – кампания Обамы, называющаяся «Обама для Америки». Эти люди, впитавшие культуру Кремниевой Долины, смогли привнести в кампанию самые современные методы.

В 2011 году легендарный предприниматель в области технологий Марк Андриссен поделился своей убежденностью в том, что «программное обеспечение поглощает мир». Мы согласны с его метафорой. И не только мы: ее часто цитируют.

Последствия этого «поглощения» сейчас ощущаются в полной мере. Организации, ориентирующиеся на старые промышленные методы, теперь должны противостоять мощнейшим силам программного обеспечения. Им нужно составить новый план действий, по образцу описанного в Части I этой книги. В Части II мы углубимся в детали этого плана и исследуем выводы для менеджеров всех подразделений организации.

✓ Все чаще организациям приходится сталкиваться с революционной силой программного обеспечения.

✓ Программное обеспечение изменяет не только товары и услуги, которые вы предоставляете, но и то, как вы управляете своим бизнесом.

✓ Программное обеспечение изменяет рыночные ожидания относительно вашего бизнеса, расширяет возможности конкуренции и способствует появлению новых соперников.

✓ Чтобы выживать и процветать, ваша организация должна признать, что старая схема управления должна быть заменена новой.

Как определить, когда работу можно назвать выполненной? Для большинства из нас это кажется довольно простым: это означает, что мы сделали нашу работу. Мы учимся этому в начале нашей школьной жизни. Выполните свою домашнюю работу. Выполните работу по дому. А когда закончили, можете поиграть со своими друзьями, почитать книги, посмотреть фильм и так далее. Мы переносим этот подход на свое рабочее место. Закончите отчет. Сделайте обход. Сходите на собрание. Когда вы закончите? «Конец рабочего дня!»

Но нам нужно сделать шаг назад и разобраться, что на самом деле означает слово «выполнено». Означает ли оно, что мы отправили товар или запустили сервис? Может, оно означает «зарабатывать» деньги для компании? Как ни странно, обычно нет. Обычно это на пару шагов от этого. Иногда это означает: «Мы создали вещь, которую вы указали в контракте». А порой это предполагает: «Мы написали программу, протестировали, как она работает, и внедрили ее на сервер».

Однако обычно это не означает: «Мы закончили делать то, что, как мы знаем, повышает ценность бизнеса».

Это важное различие, и нам необходимо четко его понимать. Большинство команд в бизнесе работают над созданием определенной продукции. Тем не менее создание этой продукции – это не то же самое, что успех. То, что мы закончили создание какой-либо вещи, не означает, что она создаст для нас ценность. Если мы хотим поговорить об успехе, нам нужно определить заданное состояние, к которому мы стремимся. Давайте назовем желаемый успех результатом.

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

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

Действительно ли компании предпочитают «выполнено», а не успех? И если так, то зачем?

Оказывается, бывают ситуации, когда эти понятия либо тождественны, либо имеют настолько понятную и четкую связь, что могли бы быть тождественными. Так часто происходит в промышленном производстве. Благодаря методике создания и проектирования промышленных товаров вы знаете, что если ваша производственная линия выпускает Модели-T, то можно быть вполне уверенным в том, что они будут функционировать так, как и было задумано. А благодаря многолетней истории продаж вы также можете быть уверены, что добьетесь успеха: вы будете продавать примерно то количество автомобилей, которое и планировали. Менеджеров, работающих по такой системе, можно простить за то, что они думают, будто их работа заключается просто в выполнении чего-либо.

Однако благодаря программному обеспечению связь между «мы выполнили это» и «это привело к планируемому эффекту» более-менее ясна. Будет ли наш недавно переделанный сайт действительно способствовать, например, росту аудитории или эти изменения приведут к неожиданным последствиям? Об этом очень трудно узнать без создания и тестирования системы. В отличие от промышленного производства, мы не создаем бесчисленное количество экземпляров одного товара. Вместо этого мы создаем единую систему (или набор взаимосвязанных систем, которые представляются нам как одна система) и зачастую не знаем до тех пор, пока не «выполним», будет ли то, что мы запускаем, работать по плану.

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

В типичном процессе мы бы поручили внутренней команде разработать запрос на предложение (RFP – request for proposal). Этот запрос основывался бы на некотором анализе бизнес-проблемы, содержал описание характера решения и перечень требований (как правило, характеристик системы), а также просьбу поставщикам о представлении предложений.

На основе RFP поставщики представляют предложения, обычно информируя о способе решения: сколько времени это займет, кто будет над этим работать, сколько это будет стоить и, конечно, почему именно этот поставщик лучше прочих подходит для выполнения данной работы.

Как только мы выбираем поставщика, мы заключаем контракт, фиксирующий разработанные нами требования, а также цену и сроки, обещанные поставщиком. Подобного рода контракт свидетельствует, что обе стороны содействуют выполнению проекта, нацеленного на некий результат. Поставщик, скорее, стремится к созданию заданного набора функций (другими словами, к «выполнению»), чем к разработке чего-то, что принесет успех.

Если вы приобретаете пользовательское программное обеспечение примерно тем способом, который описан, вы знаете, что происходит дальше. Поставщик не выполняет обещанное. Опытный ИТ-менеджер объясняет: «Проблема в фиксированных контрактах. Вы оба обманываете друг друга в том, что якобы понимаете, в чем состоит проблема». В результате, когда выясняется истинная природа проблемы, каждая из сторон должна вносить корректировки. Результат поправок? Поставщик опоздал и превысил бюджет. Но опытный менеджер знает: «В итоге всегда появляется проблема, и вместо того, чтобы решать ее или улучшать продукт, вы спорите о том, кто за это заплатит».

Старое маркетинговое клише верно: покупатели не хотят полусантиментровое сверло дрели, они хотят, чтобы дрель просверлила полусантиметровое отверстие. Иначе говоря, их заботит конечный результат, и им совсем не интересно, какими средствами он будет достигнут. То же самое относится и к менеджерам: им все равно, как достичь своих бизнес-целей, они просто хотят их достичь.

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

Оказывается, подобную проблему – срыв планов вследствие неопределенности и ошибочную реакцию в виде составления все более подробных планов – военные командиры пытались решить на протяжении сотен, если не тысяч лет. Они разработали систему военного руководства под названием управление целями как альтернативу жесткой системе руководства, которая очень подробно определяет, что подразделения должны делать в бою. Новая гибкая система, напротив, предписывает высшему командованию устанавливать цели и задачи, но при этом оставляет принятие конкретных решений людям, ведущим боевые действия. В работе Стивена Бунгей «The Art of Action» прослеживается развитие этих идей в прусской армии 1800-х годов и описывается система, которую военачальники разработали для того, чтобы справляться с неопределенностью на поле битвы[50].

Такое гибкое командование строится на трех важных принципах:

• Не командуйте больше, чем нужно, или не планируйте сверхпредсказуемые условия;

• Донесите до каждого подразделения как можно больше идей, необходимых для достижения цели;

• Убедитесь в том, что каждый человек свободен в принятии решений в пределах своей ответственности.

В переложении к нашим целям это означает, что мы будем ориентировать команды на цель, которую хотим достичь (наше намерение), предоставляя им большую, но с определенными ограничениями, степень самостоятельности для ее достижения, и при этом будем готовы к тому, что наши планы будут корректироваться по мере их выполнения.

Давайте рассмотрим пример того, как одна команда, с которой мы работали, воплотила эти принципы в жизнь. В 2014 году компания Taproot Foundation решила создать цифровой сервис, который бы связывал некоммерческие организации с квалифицированными специалистами, предоставляющими свои услуги на волонтерской основе. Считайте, это было что-то вроде сервиса знакомств для добровольцев. Taproot Foundation пришлось работать с внешними поставщиками, и в конечном итоге они выбрали для этого проекта нашу фирму.

В начале нашего знакомства лидеры Taproot Foundation описывали систему, которую они хотели бы получить, с точки зрения ее функций: она должна иметь опцию регистрации для волонтеров, которые смогут перечислить там свои навыки, а у некоммерческих организаций была бы возможность искать этих самых волонтеров на основе перечисленных навыков; в ней должна быть контактная сеть для организаций, а еще система планирования, позволяющая сторонам организовывать встречи, и тому подобное. Мы были обеспокоены этим списком. Он был длинным, и, хотя каждый из его элементов казался разумным, мы считали, что могли бы достичь большей ценности с меньшим набором функций.

Чтобы перевести разговор с темы деталей, мы спросили: «Чего должна добиться успешная система? Если бы мы должны были доказать себе, что в систему стоит инвестировать, какую информацию мы бы использовали?» Этот разговор дал некоторые четкие, конкретные ответы. Прежде всего, система должна быть запущена в конкретный день, примерно через четыре месяца. Организация участвует в ежегодном мероприятии по случаю празднования дня отрасли, и ее руководители хотели бы продемонстрировать систему спонсорам. Мы спросили: «Что для вас значит запуск?» И снова их ответы были конкретными: нам нужно, чтобы X участников были активными со стороны волонтеров, а Y участников были активными со стороны организации. Поскольку цель сервиса состояла в том, чтобы количество волонтеров и организаций для совместной работы над проектами было сопоставимо, мы должны были сверстать Z соответствий: определенный процент пересечения этих совпадений должен был создать предпосылки для успешных, завершенных проектов.

Такими были наши показатели успеха: X и Y участников, Z совпадений, процент выполненных проектов. (На самом деле, обычно мы устанавливаем конкретные количественные цели, но для этой истории используем переменные).

Затем мы спросили: «Если мы сможем создать эту систему и достигнуть целей без каких-либо функций из вашего списка пожеланий, это вас устроит?» Тут начался более сложный разговор.

Понятно, что руководители, подписавшие контракт, были обеспокоены: какие у них гарантии того, что это будет полноценный проект?

Одно из обязательных условий для руководителей и менеджеров в ходе переговоров с партнерами – защита интересов своей организации. Они должны найти договорную формулировку, которая будет гарантировать продукт партнеров. Однако проблема с контрактами заключается в том, что менеджеры часто видят такую гарантию в конкретном наборе элементов: вы создаете функцию А, а затем мы заплатим вам сумму В. Тем не менее такая прописанная определенность – это ложная защита. Она гарантирует только то, что ваш поставщик дойдет до этапа «выполнено». Она не гарантирует того, что набор функций, который вы описываете в договоре, сделает проект успешным. С другой стороны, поставщики, по понятным причинам, не решаются подписываться на достижение цели, в основном потому, что они редко имеют возможность контролировать все переменные, которые приводят к успеху или неудаче проекта. Таким образом, обе стороны соглашаются на компромисс, который обеспечивает безопасность критерием «выполнено» и в то же время ограничивает свободу, которая и порождает успех.

Наш контракт с Taproot содержал не только список желаемых функций, но и список желаемых целей. Вот цели, которые мы вписали в этот контракт:

Эта формулировка упрощена (в оригинале было много юридических терминов), но отражает суть соглашения. Такого рода компромисс – перечисление функций, которые, по нашему мнению, были важны, с привязкой к представлению о целях, что важнее, – является ключом к управлению целями, а не результатом.

Стоит признать, что многие организации не обладают достаточной гибкостью с точки зрения процессов финансирования проектов и правил закупок, поэтому для их руководителей такого рода контракт может оказаться вне пределов компетенции. Однако, как мы обсуждали в Главе 3, дальновидные организации работают над тем, чтобы это изменить.

Так как же продвигался проект? Сначала команда считала, что самой важной вехой является запуск системы. Чтобы не ждать четыре месяца (срок исполнения проекта), члены команды решили запустить ее как можно скорее. Как оказалось, они смогли выйти в эфир для пробной аудитории в течение месяца. Они запустили радикально упрощенную версию сервиса с очень небольшим количеством автоматических функций. Большая часть работы в системе выполнялась вручную специальным человеком, комьюнити-менеджером (комьюнити-менеджер – специалист в области создания, поддержки и развития сообществ/структур – перев.), действующим за кулисами. (Подобный подход, который использовался командой Cooking Light Diet, мы описали в Главе 2).

Этот диспетчерский подход к минимальному жизнеспособному продукту (MVP) стал популярным способом запуска систем. Команда Taproot знала, что потребуется больше автоматизации, если она хочет, чтобы система расширялась в масштабах, но также она знала, что автоматизация может появиться и позже. Досрочный запуск достиг двух целей. Во-первых, он гарантировал, что команде будет что показать спонсорам на ежегодном мероприятии. Это было чрезвычайно важной маркетинговой и торговой целью. А во-вторых, что более важно, он позволил команде выяснить, какие функции ей действительно понадобятся для масштабной работы системы. Другими словами, это вывело команду в режим «почувствовать и отреагировать» – двусторонний разговор с рынком, который и будет направлять развитие сервиса.

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

Ко второму месяцу проекта команда создала систему с пересмотренным порядком действий, а затем сосредоточилась на ее настройке – определении деталей, необходимых в бизнес-процессах, и создании программного обеспечения для поддержки этих процессов. Как команде облегчить перечисление проектов организациям? Как убедиться в том, что списки мотивируют волонтеров? Насколько простой может быть контактная система? Как упростить планирование встреч? К окончанию четырехмесячного проекта у команды появилась система, созданная и запущенная в течение трех месяцев, намного превосходящая цели производительности, прописанные в контракте.

Подобные проекты работают потому, что они следуют гибким принципам руководства. Они предоставляют командам стратегию и набор целей для достижения, наряду с набором ограничений, а также предоставляют свободу использовать свои знания о ситуации для решения проблем. В данном случае стратегия, которой придерживалась Taproot Foundation, заключалась в использовании возможностей интернета увеличить влиятельность организаций в десятки раз. Стратегические ограничения для проекта также были ясны: спонсоры платили за то, чтобы команда создала онлайн-сервис подбора. Независимо от того, как действовала команда, она должна была создать этот сервис, хоть и заручилась значительной долей свободы для определения того, как он будет выглядеть. Также у команды были жесткие ограничения по дате: система должна была быть запущена через четыре месяца. Но у команды было достаточно свободы, чтобы решить, как ей функционировать.

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

Мы увидели много примеров провала централизованного планирования в современную эпоху. Достаточного вспомнить неудачи советского блока и коммунистической китайской экономики XX века, чтобы увидеть примеры того, что экономисты называют проблемой местных знаний: речь о том, что центральные органы планирования не имеют четкого понимания реальности на местах для разработки адекватных детальных планов. Сколько хлеба нужно в этом городе? Сколько пшеницы нужно поставить этой фабрике? А что если будет плохой урожай? Что если на складе случится пожар? Что если в регионе едят рис?

Противоположностью централизованного планирования является децентрализация власти. На периферии этого децентрализованного спектра находятся такие явления, как анархия, холакратия и даже, в глазах некоторых, гибкая разработка программного обеспечения.

Agile-подход действительно дает возможность небольшим, эгалитарным командам принимать решения. В небольших масштабах это напоминает системы, подобные анархическим, с их радикально инклюзивным видением. Сторонники холакратии, например, утверждают, что вы можете управлять крупными организациями без традиционной иерархической системы. Последователи аgile-методов подобных заявлений не делали. Идея о том, что гибкая политика не вписывается в проблематику масштабных организаций и подходит только для уровня команд, была осмыслена технологическим консультантом Дэном Нортом. В ходе выступления на конференции в 2013 году он описал это следующим образом:

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

В последние годы подход agile перестал считаться методом для особо продвинутых и стал распространенным способом работы. Авторы недавнего доклада, подготовленного по заказу компании Hewlett-Packard, подсчитали, что более 90 % крупных организаций либо уже используют эти подходы, либо работают над их широким использованием[52]. И по мере обретения популярности этих методов, организации по всему миру пытаются найти решения для масштабирования гибкого подхода. Как указывает Норт, это обусловлено тем, что гибкость по существу является «командным» методом работы, а крупным организациям нужна система для координирования работы многих команд.

Один из наиболее популярных подходов к такому координированию называется масштабированный гибкий фреймворк, или SAFe (scaled agile framework). Как следует из аббревиатуры, SAFe дает менеджерам чувство комфорта. В конце концов, огромная организация, в которой существуют самоуправляемые команды – это кошмар для менеджеров. Очень похоже на анархию.

SAFe – это способ дробления больших проектов на небольшие части, работа над которыми поручается командам, а также создания системы подотчетности, гарантирующей, что команды завершат работу, на выполнение которой они подписались. Проблема данного подхода заключается в том, что он, собственно, является подходом «более детализированного плана», который исключает влияние неопределенности. SAFe уводит команды от подхода «почувствовать и отреагировать» и направляет к методам централизованного планирования. Фактически, это снижает статус гибкой команды до уровня производственной команды – ей выставляется фиксированный набор требований, и ожидается, что со сборочной линии сойдет конкретный произведенный товар. Этот подход может подойти для каких-то конкретных задач, но в целом он ограничивает возможность команды обучаться с помощью обратной связи по мере продвижения вперед. А ведь именно опыт обратной связи позволяет командам ориентироваться в условиях высокой неопределенности.

Вместо того, чтобы пытаться вписать гибкость в систему руководства и управления, многие организации придерживаются принципов координирования, больше похожих на командование, – как правило, создают то, что мы называем целевыми «дорожными картами».

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

• Стратегическое намерение («Мы хотим увеличить долю организации на рынке в десять раз»);

• Стратегические ограничения («Мы сделаем это путем создания онлайн-сервиса, который должен начать работать к X числу»);

• Определение успеха («Сервис будет сопоставлять показатели в X процентов»).

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

Существует критический компонент руководства, который выходит за рамки того, что вы обсуждаете. Не менее важно то, как вы передаете свои мысли. Информация должна идти и «сверху вниз», по цепочке командования, и в обратном направлении. Иначе говоря, общение должно идти в обоих направлениях, и этот обмен данными «сверху» и «снизу» должен циркулировать постоянно. Он продолжителен во времени. Только в такого рода процессе коммуникаций формируется согласованность.

Работая над этой книгой, мы узнали о компании, которая рассматривала эти методы как часть ежегодного планирования. Эта американская фирма – стартап, занимающийся онлайн-торговлей, – является одной из наиболее успешных организаций, практикующих гибкие методы. Они не из тех, кто делает все «по правилам». Компания воплощает многие идеи и приемы, свойственные гибкому подходу. Помимо всего прочего, фирма является одним из первых и успешных последователей метода, называемого процессом непрерывного развертывания, – сторонником идеи о том, что программное обеспечение выпускается не каждые несколько месяцев или каждые пару недель, а непрерывно. (Мы рассказывали об этом в Главе 1. Это процесс, с помощью которого Amazon способен выпускать обновление каждые 11,6 сек). На протяжении многих лет они развивали культуру экспериментов, A/B-тестирования и оптимизации.

Аgile-методы позволяют применить экспериментальный подход к выпуску новой программы. К примеру, компания хочет изменить дизайн страницы продукта на своем веб-сайте. Вместо того, чтобы гадать, в каком исполнении страница будет работать лучшего всего, она быстро разрабатывает и создает несколько версий страницы, запускает их на сайте, направляет часть контролируемых пользователей к каждой из версий, а затем определяет, какая из страниц лучшая.

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

К концу 2015 года компания насчитывала уже 5 тысяч сотрудников, ее годовой доход оценивался в сотни миллионов долларов. Проблема с координированием становилась все более острой. Руководители понимали, что они должны обеспечить большую согласованность. При разработке «дорожной карты» на год они использовали методы планирования и «сверху-вниз», и «снизу-вверх».

В первой части работы участвовали высшие руководители, которые представили перечень стратегических задач на следующий год. Эти темы стали инструкцией «сверху-вниз» – координирующими идеями, которые будут служить движущим фактором. Стратегия – это выбор, который касается не того, чего вы не делаете, а того, что вы решили сделать. И после периода повышенного внимания к одному сегменту клиентов руководители решили в наступающем году сосредоточиться на другом сегменте, которому, по их мнению, ранее уделялось меньше внимания. Исходя из этой концепции, руководители сформулировали ряд небольших задач, включая опыт использования мобильных телефонов. (Стивен Бунгей подчеркивает, что хорошее заявление о стратегии часто «выглядит банальным» для сторонних наблюдателей. Ценность появляется благодаря согласованности, которую вы создаете в ходе непрерывного процесса формулирования стратегии)[53].

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

Далее руководителям среднего звена управления было необходимо понять, как распределить усилия – иначе говоря, как создать «дорожную карту» на год. Лидеры команд по созданию продукта объединились, чтобы составить общий список инициатив. Они сгруппировали инициативы с точки зрения того, какие задачи поддерживает каждый проект, а затем оценили их с точки зрения вклада в общую задачу – то есть связали каждую инициативу с целью и показали, как эти цели будут поддерживать стратегические планы, представленные руководством. Они подсчитали число работников, необходимое для каждой инициативы, и отправили расчеты специалистам по финансам, которые сопоставили эти планы с некоторыми из основных финансовых показателей, и рассмотрели, как предлагаемая схема может повлиять на результаты. После этого план был отправлен обратно на рассмотрение руководства.

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

Это пример того, что мы считаем целевой «дорожной картой». Она четко связывает планируемую вами работу с целями, которые вы собираетесь достичь, а также со стратегическими задачами. Это создает целостную историю, которая связывает лидеров организации с непосредственными исполнителями.

Один менеджер компании сказал: «В самых лучших компаниях есть «редактор продуктов». У них есть история, сюжет. Если вы посмотрите на Apple, у них история тоже есть. С таким подходом и у нас есть сюжет. Как лидеру по созданию продукта, мне это нравится. Мне есть куда расти».

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

Давайте рассмотрим некоторые элементы, которые сделали этот процесс успешным, и оценим, насколько он соответствует подходу «почувствовать и отреагировать», которого придерживается эта компания.

• Стратегия выражается как намерение. Вместо того, чтобы представить детальный план, руководители задали направление и попросили близких к клиенту сотрудников уточнить детали.

• Ситуационная осведомленность определяет тактику. Сотрудники обладают глубокими познаниями о том, каковы реальные условия, и понимают, что надо бы исправить. Они смогли подобрать лучшую тактику для достижения цели.

• Обязательства распространяются, скорее, на цели, чем на функции. Связывая инициативы с конечными целями, а не с конкретными функциями, руководители дают сотрудникам возможность гибко подходить к выполнению своих заданий и использовать свои компетентные суждения для достижения желаемых целей.

• Сочетание планирования «снизу-вверх» и «сверху-вниз» обеспечивает баланс. В отличие от негативного опыта, когда следствием планирования «снизу-вверх» становилось отсутствие координации (по аналогии с тем, как во многих организациях планирование «сверху-вниз» оборачивается «вычеркиванием» гибкости), выбранная модель процесса способствовала сбалансированности всех ресурсов.

Подход «снизу-вверх» в сочетании с инициативой «сверху-вниз» являлся одним из методов составления целевой «дорожной карты» на ресурсе GOV.UK, официальном сайте правительства Великобритании. Усилия команд, работающих над этим сайтом, направлены на достижение новаторской цели – встраивание деятельности национального правительства в онлайн-пространство. Проводимая там работа, благодаря ее прозрачности и открытости, предоставляет уникальную возможность изучать современные цифровые методы.

Описывая процесс составления «дорожной карты», Нейл Уильямс, возглавляющий подразделение по созданию продуктов в правительственной цифровой службе (Government Digital Service, GDS) Великобритании, указал: «Вероятно, самая сложная задача в создании «дорожной карты» для крупного, многокомандного продукта состоит в правильном балансе между бизнес-целями (“сверху-вниз”) и приоритетами команды (“снизу-вверх”)»[54].

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

Также «дорожная карта» должна обеспечивать баланс между конкретными обязательствами и обеспечением пространства для гибкого подхода в текущей деятельности. Другими словами, она должна четко фиксировать, что команды намерены сделать, и в то же время позволять им корректировать планы и развиваться в ходе обучения.

Обычно команда использует комбинацию тактик. Во-первых, члены команды ответственно относятся к соблюдению сроков. Во-вторых, они стараются ограничить принятие жестких обязательств относительно чего-либо, кроме самых ближайших задач[55]. Они разбивают «фронт работ» на три блока. Относительно «текущей» работы, в перспективе ближайшего месяца, они берут на себя относительно жесткие обязательства по продуктам и срокам. «Плановая» работа, рассчитанная на срок до трех месяцев, находится в стадии рассмотрения, но еще без конкретики. И, наконец, есть еще долгосрочный блок под названием «приоритетная» работа. Ее разработка носит предварительный характер[56].

В таком подходе заключен один из центральных принципов руководства: не командуйте больше, чем нужно, и не планируйте в рамках гипотетических обстоятельств, которые не можете предвидеть.

Дональд Рейнертсен, изучающий бережливые методы, рассуждает о планировании и согласованности так: «Современные военные не создают планов для достижения цели, они представляют план как инструмент для поддержания согласованности»[57]. И действительно, Нейл Уильямс подтвердил в разговоре с нами, что цель GOV.UK заключалась в создании «согласованной автономии».

Важность согласованности подтверждается степенью открытости проекта GOV.UK. Все планы-графики доступны как для внутренних групп, так и для общественности. Команда использует различные инструменты для обеспечения прозрачности своей работы – это и огромный плакат на стене, и официальный активный блог, доступный на сайте, и «дорожная карта», размещенная в программе под названием Trello[58]. Такая степень открытости призвана обеспечить согласованность между командами, заинтересованными лицами и общественностью.

В старейшем банке Австралии Westpac (фактически, старейшей компании континента) команда по работе с клиентами составила так называемую «карту путешествия потребителя» с целью обеспечения согласованности внутренних инициатив и программ.

Карта путешествия потребителя – это большая схема из многих листов (в Westpac обычно составляют графики во всю стену), которая показывает путь клиента по мере его взаимодействия с компанией. Например, каков процесс получения кредитной карты? А ипотечного кредита? Такой бизнес-подход является сложным и требует участия многих команд. Он охватывает многие банковские сферы, от мобильных и интернет-приложений до внутренних систем, используемых в филиалах, колл-центрах и вспомогательных подразделениях. Люди, создающие и использующие эти системы, должны работать согласованно, если они надеются обеспечить хорошее обслуживание клиентов. Карта путешествий предназначена для обеспечения согласованности среди всех этих команд.

Команда по обслуживанию клиентов фактически создает две карты путешествия потребителя для каждого из процессов и помещает их рядом на так называемой «стене проектирования». Первая карта, которую команда называет As Is («как оно есть», или картой текущего состояния), показывает, каким текущим процессом занят клиент. Она содержит объективную оценку недостатков, затруднений и проявлений неэффективности – в этом ее основной смысл.

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

Команде Westpac потребовалось некоторое время, чтобы разработать верный план-график. Членам команды пришлось проявить настойчивость, чтобы избежать излишней детализации. Они не хотели слишком быстро блокировать функции, которые пока не проявили себя. Иначе говоря, они хотели предоставить свободу действий каждой из команд, позволить им участвовать в выработке правильного решения. Айан Мьюир, руководитель по обслуживанию клиентов, сказал нам: «Главное – найти правильный баланс: вы рассказываете историю о будущем, когда у вас нет всей нужной вам информации».

Итак, на стене две карты путешествия потребителя – пришла пора фазы планирования. И группе по реализации предстоит изучение и анализ карт. Команды уже участвовали в создании карты, и следующим шагом нужно выяснить, как реализовать их предложения. Этот шаг подразумевает согласованность и межкомандное координирование. Дэн Смит, менеджер по работе с клиентами, рассказывает: «Я говорю им: «Это не соответствует моему видению будущего. Как вы думаете, что мы должны сделать, чтобы оно стало лучше?»».

На данном этапе менеджеры команд часто находят на карте что-то, что важно для работы их подразделения, находится в зоне его ответственности. Например, одним из основных препятствий для более оперативного получения кредиток, была необходимость подтверждения личности клиента в отделении банка. Работая над проблемой, Westpac смог создать процедуру электронной идентификации на основе мобильного телефона, которая позволяет клиентам не приходить в банк лично. Эта, казалось бы, простая функция, потребовала большой работы нескольких команд и отделов банка.

Смит поведал нам, что дело не столько в таких инструментах, как карты путешествия потребителей или стена проектирования. Скорее, эти инструменты служат фоном для самой важной части процесса: совместных обсуждений и проектирования. Общее собрание, на котором рассматриваются идеи и обсуждаются исследования, дает больше ценности для всех членов команды, нежели стандартные практики принятия решений – в конференц-зале после рассмотрения презентации, или после обмена примерно двадцатью электронными письмами в течение нескольких дней. Таким образом, собрания по поводу проектирования служат некой средой для совместной работы команд, позволяющей согласовывать цели.

Создавая планы-графики на основе ориентированных на клиента картах путешествия, команда Westpac использует опыт клиентов в качестве ключевого измерения. Это немного отличается от других подходов, примерами которых мы поделились в этой главе. Те команды использовали принципы организации, которые более ощутимо ориентировались на бизнес-результаты. Тем не менее в опоре на клиентский опыт есть преимущества, особенно если его развитие соответствует стратегической цели. В Westpac это действительно является одной из стратегических целей.

В agile-контексте может быть трудно создать отличный клиентский опыт. Одним из источников разочарований является так называемый долг опыта или долг проектирования. Подобно техническому долгу (технический термин для обозначения поддержания домашнего хозяйства – такая работа всегда полезна, но никогда не является приоритетной, и потому накапливается с течением времени), долг опыта появляется из-за небольших проблем с проектированием, которые со временем накапливаются и снижают качество клиентского опыта: то непонятные инструкции здесь, то дополнительное всплывающее окно там.

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

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

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

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

Лиза Райхельт, руководитель по проектированию услуг и исследованию пользовательской аудитории в Управлении цифрового преобразования австралийского правительства, рассказала нам, что для ее работы вполне нормально привлекать чиновников правительства к детальному, ориентированному на пользователя планированию. «Когда у вас есть три уровня управления (федеральное, государственное, и местное) и множество учреждений, вы можете увидеть программы, которые можно легко разделить между 20, 30 или 40 подразделениями», – поделилась она. Возникающая в результате проблема координирования может показаться неразрешимой, но потенциал сервисов справляется с этим, акцентируя ценность на интересах потребителей. В качестве примера она предложила оценить различие между «предоставлением карты льготного медицинского обслуживания по возрасту (достижению 65 лет)» и «помощью в переходе к новой фазе жизни».

Следующий уровень управления программой – это портфельный менеджмент. Крупные организации должны найти способ анализировать свои инвестиции по всему портфелю продуктов. Как же в этом контексте применить подход «почувствовать и отреагировать»?

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

Как мы уже говорили, основная причина принять подход «почувствовать и отреагировать» заключается в неопределенности. В отношении портфеля продуктов можно выделить три основные категории неопределенности:

• Связанные с клиентами. Есть ли в продукте необходимость? Удовлетворяет ли наше решение какую-то определенную потребность?

• С устойчивым развитием. Является ли бизнес устойчивым? Достаточно ли велик рынок? Можем ли мы создать технологию, инфраструктуру и операционные системы, которые позволят нам выгодно предоставлять услуги?

• Связанные с ростом. Как мы можем развить свой бизнес?

Кроме того, эти категории более или менее напрямую соотносятся с жизненным циклом предприятия. Некоторые компании явно используют эти сопоставления. Например, компания Intuit, производитель финансового программного обеспечения и услуг в Кремниевой Долине, использует известную модель трех перспектив McKinsey & Company’s для портфельного менеджмента.

Модель трех перспектив является основой для управления ростом. Эта модель, сформулированная Мердадом Багаем, Стивеном Коли и Робертом Уайтом в книге «Алхимия роста» («Вестник McKinsey», 2002 г., № 2 – ред.), доказывает, что рост следует рассматривать с точки зрения трех временных перспектив – краткосрочной, среднесрочной и долгосрочной[60]. Перспектива 1 представляет собой возможность краткосрочного роста. В этой точке находится ваш основной бизнес, и вы должны управлять его ростом и эффективностью. Перспектива 2 определяет, где находятся ваши растущие подразделения. Эти направления необходимо развивать. Некоторые из них станут вашим основным бизнесом в среднесрочной перспективе. И, наконец, Перспектива 3 указывает долгосрочное будущее. Здесь появляются и оцениваются новые варианты, которые либо отклоняют, либо продвигают дальше. Авторы отмечают, что в любой момент времени ваш портфель должен содержать проекты во всех трех перспективах.

В компании Intuit команды изображают три типа неопределенностей на модели трех перспектив:

• В Перспективе 3 они задают вопросы, связанные с клиентами. В чем их нужды? Можем ли мы найти удовлетворяющее эти потребности решение? Купят ли люди продукт нашего решения и, что еще важнее, понравится ли он им?

• В Перспективе 2 идеи, которые вырастают из Перспективы 3, оцениваются с точки зрения их жизнеспособности. Можем ли мы заработать на этом достаточно денег для укрепления нашего бизнеса? Можем ли мы сделать его эффективным и воспроизводимым? Может ли мы найти доказательства того, что мы способны сделать бизнес достаточно крупным и стоящим наших инвестиций?

• В Перспективе 1 компании, получившие признание клиентов, основное внимание уделяют росту и эффективности. Что мы можем сделать для того, чтобы наш бизнес стал более крупным и прибыльным?

Компании, которые ответственно подходят к управлению портфелем продуктов, признают ценность балансирования портфеля с точки зрения риска, стратегических целей и жизненного цикла продукта. Компания Intuit распределяет свои инвестиции между тремя видами перспектив таким образом: в Перспективу 3 – 10 %, в Перспективу 2 – 30 %, в Перспективу 1 – 60 %[61].

Позиция Intuit имеет решающее значение для обеспечения эффективного планирования по всему портфелю, поскольку она устанавливает приоритетность. Бывший вице-президент Intuit Хью Молотзи пишет об этом следующее: «Распространенной ошибкой компаний является измерение прогресса своих предложений с использованием стандартных бизнес-показателей (как, например, доход, прибыль и привлечение клиентов) независимо от того, на каком этапе находятся эти предложения. Планирование по перспективам помогает нам избежать этой ошибки, давая представление о том, какими должны быть наши ожидания от предложений на каждом этапе их развития»[62].

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

Все это является фоном для главного вопроса – как мы понимаем подход «почувствовать и отреагировать» в контексте планирования портфеля? Главная задача заключается в понимании того, как вы можете применить этот подход к каждому отдельному типу неопределенности. Гипотеза из Перспективы 3, проверка которой состоит в прогнозе любви клиентов, существует в колоссальной неопределенности. Кто эти клиенты? Какую проблему они пытаются решить? Какое решение мы можем предложить? Как мы будем зарабатывать деньги? Это классический случай стартапа.

В Перспективе 2 – уровень разрешения проблемы продвигается на шаг вперед. Допустим, вы определили бизнес, который актуален для небольшой группы клиентов. Именно на этом этапе ваши эксперименты будут нацелены на подтверждение правильности бизнес-модели и перспектив продвижения к прибыльности. Однако бизнес на этой стадии развития наиболее уязвим. Разработчики покинули защищенную гавань научно-исследовательской группы или лаборатории инноваций, где рождаются и вынашиваются идеи Перспективы 3. Как утверждает организационный аналитик и автор книги «Преодоление пропасти» Джеффри Мур (Издательский дом «Вильямс», М. 2006 г. – ред.), эти инициативы являются «незрелыми»[63]. Но довольно часто они нацелены на те же операционные показатели, что и основные предприятия из группы Перспективы 1. Мур утверждает, что это ошибка. Этим компаниям необходимо сосредоточиться на поиске решений, прежде чем они смогут получить прибыль, сопоставимую с показателем основных предприятий. Вопросы этого этапа, как правило, относятся к тому, как высвободить потенциал роста и как направить эксперименты на развитие тактических приемов, которые, как вы считаете, помогут росту. Как мы можем привлечь к данному бизнесу больше клиентов? Что мешает их привлечению? Используем ли мы правильные методы или нам нужно что-нибудь добавить или исправить? Обслуживаем ли мы нужный сегмент рынка? Нужно ли нам добавлять смежные сегменты?

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

Суть заключается в следующем: когда вы определяете, как распределить работу среди команд и как измерять их производительность, следует помнить о том, что нет единого набора критериев, по которым можно оценить их результативность. Скорее, лидеры должны учитывать, на каком жизненном цикле находится инициатива и с какими неопределенностями сталкиваются команды. Только после этого можно создавать соответствующие задачи для команд.

✓ Изменение способа планирования и распределения работы является одним из самых важных элементов данного подхода.

✓ Именно лидеры создают условия, в которых команды способны применять данный подход. Команды могут сколько угодно пытаться «быть гибкими», но, если руководство выстроено неправильно (не предоставлена свобода действий, цели определены неточно, а ограничения непонятны), они мало что смогут сделать.

✓ Неопределенность изменяет способ планирования. Планы должны быть ориентированы на результаты, которые команды пытаются достичь.

✓ Этот новый вид планирования сказывается и на уровне команды, и на уровне программы, предполагающей использование новых методов межкомандного координирования, и на уровне портфеля, где важно дифференцировать типы целей для разных жизненных циклов продукта.

✓ Используйте принцип целевого руководства, чтобы направлять команды. Это означает, что команды должны стремиться достичь цели, а не выдать определенный результат.

✓ Координируйте деятельность нескольких команд (программ) с помощью целевых «дорожных карт».

✓ Согласованность в рамках единой стратегии становится более важной, чем когда-либо, и должна обеспечиваться надежным коммуникационным процессом, включающим интеграции «сверху-вниз» и «снизу-вверх», а также двусторонний разговор.

✓ Оптимальный способ планирования портфеля – задавать целевые результаты с учетом различных этапов жизненного цикла продукта.

Основой цифровых инноваций является небольшая многофункциональная команда. Это двигатель современной разработки программного обеспечения, его сердцевина, базовая молекула. В то время как промышленное производство основано на использовании сборочных линий, цифровое производство обычно строится вокруг этой небольшой команды.

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

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

Другая легенда – это стартап в гараже. В этой истории небольшая группа людей (два, три, четыре или, может быть, пять неудачников) объединяется для поиска идеи. Они привносят в работу свои различные навыки (вспомните о таланте видения Стива Джобса и его умении продавать вкупе с инженерным гением Стивом Возняком) и превращаются в команду, способную создать новую долларовую компанию-миллиардера.

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

Цифровое производство действительно двигают группы, в чем-то похожие на предпринимательскую команду в гараже. Основу этой команды обычно составляет сбалансированная группа, объединяющая все разнообразные качества и возможности, необходимые для запуска цифровых продуктов и услуг, а также для быстрой интерпретации сведений, полученных в результате двустороннего разговора. Сотрудники этих команд обычно выполняют три основные функции: проектирование, управление продуктом и дизайн. По степени устойчивости конструкции – это табурет на трех ножках. Проектирование занимается физическим осуществлением – созданием продукта. Управление контролирует жизнеспособность бизнеса – как ему поддерживать свое существование. Дизайн улавливает предпочтения – как сделать что-то, чего хотят люди[64].

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

В 2012 году PayPal, компания электронных платежей, назначила Дэвида Маркуса на должность президента. Маркус, который присоединился к компании в 2011 году, когда она приобрела его стартап, задумал модернизировать PayPal, которая к тому времени превратилась в медлительную бюрократическую компанию. Он хотел вернуть ей предпринимательский дух, который у нее когда-то был. Маркус изменил способ распределения людей по командам. Он ограничил количество временных команд. Маркус организовал рабочие помещения так, чтобы команды могли находиться вместе. Также он изменил метод работы групп-разработчиков – вместо жестких, последовательно «каскадных» подходов предложил им более гибкий подход.

Одним из самых первых проектов PayPal, применившим такой подход, стала доработка продукта Checkout. В то время Checkout генерировал 75 % дохода PayPal, что составляло примерно 3,5 млрд долларов. Маркус собрал небольшую команду во главе с Биллом Скоттом, опытным технарем, которого переманили из компании Netflix, и поставил цель запустить модернизированный продукт через шесть недель.

Если вам такой подход кажется слишком напористым, согласимся с вами, особенно с учетом ситуации в PayPal в то время. В 2011 году на создание приложения в среднем уходило полгода, а это 26 недель. Внесение простых изменений на страницу могло занять шесть недель. На изменение текста в нижнем колонтитуле веб-страницы уходило два месяца. Дела продвигались медленно по двум причинам. Во-первых, технологическая платформа компании со временем стала фрагментированной, поэтому внесение простых изменений часто требовало кропотливой и однообразной работы. Во-вторых, административные процессы – проектирование, утверждение, построение, тестирование и снова утверждение – были очень медленными. Работа переходила от одного отдела к другому в весьма неторопливом темпе.

Проект по модернизации Checkout назывался Hermes. Дизайнеры и разработчики работали в одной комнате. Начался еженедельный цикл проектирования, построения, тестирования и обучения. Они отказались от старых последовательных процедур. Вместо этого члены команды расписывали свои идеи на доске, а затем возвращались за свои столы и создавали то, что они только что расписали. Они тестировали продукт вместе с клиентами, обращая внимание на то, что работало, а что – нет, а затем анализировали свои разработки исходя из полученных знаний. Основываясь на этом двустороннем общении со своей целевой аудиторией, они разработали приложение в течение нескольких дней, а через несколько недель уже были уверены в нем. И даже несмотря на то, что они не могли представить продукт через шесть недель (нельзя изменить технологические циклы так же быстро, как процессы, зависящие от человека), они вышли на этап значительной трансформации. Члены команды инициировали изменения в PayPal в направлении более предпринимательской компании.

Сейчас новый совместный подход является в PayPal нормой. Над проектами работают многофункциональные команды. Они способны запустить новый код в реальном времени в течение нескольких минут, а не недель. Это свидетельствует о том, что компания осуществила радикальные изменения – в способе не только командной организации работы, но и всего технологического комплекса, устройства рабочих мест и многого другого[65].

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

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

Например, в крупных цифровых агентствах производство веб-сайтов для клиентов часто проходит через прогнозируемые последовательные стадии. Ведь чтобы продавать продукты, нужно учесть требуемые для этого людские ресурсы и объем работы. В начале проекта подход разрабатывают стратеги. Затем, как правило, подключаются исследователи, которые общаются с клиентами или проводят анализ за столом. Они преподносят свои идеи в виде отчета для клиента, который также передается проектной группе агентства. Потом исследователи и стратеги переходят к другим проектам, а этим начинают заниматься дизайнеры. Дизайнеры берут идеи исследователей и прогоняют их через wire framing – процесс создания шаблона для сайта, а затем передают эту работу другим специалистам для завершения графического дизайна. Потом проекты передаются инженерам, которые создают продукт. Наконец, работа переходит к подразделению контроля качества, специалисты которого составляют план тестирования и проверяют сайт на ошибки. После чего сайт передается операционной команде, которая ответственна за его загрузку на производственный сервер и за саму загрузку сайта. (Аутсорсинговые проектные фирмы тоже часто используют некоторые версии этого процесса, хотя на ранних этапах основное внимание уделяется определению требований, а не стратегии, и проектные работы, скорее всего, будут связаны с техническим проектированием и выстраиванием архитектуры систем).

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

Это все совершенно разумно, и в то же время совершенно неправильно. Давайте выясним почему.

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

Вторая проблема с такого рода проектным потоком состоит в том, что знания, которые создаются на каждом этапе работы, теряются в каждой точке передачи. Знания не похожи на шасси автомобиля. Они не могут двигаться по ленте сборочного конвейера. Они живут в нашей голове. Они хаотичны и никогда не могут быть полностью переданы от одного человека к другому. Вне зависимости от того, насколько хорошо мы документируем то, что узнали, что-то из этого остается в нашей голове, а что-то либо неправильно интерпретируется, либо искажается предубеждениями носителя этих знаний или их получателя.

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

Альтернативой индустриальной модели является создание небольших, самодостаточных команд, использующих подход «почувствовать и отреагировать». Этим командам предоставляется независимость в самостоятельной работе по выполнению порученного задания – в поиске и создании ценности. Самостоятельная команда имеет полный набор возможностей для использования данного подхода, а также имеет возможность вести двусторонний разговор с рынком.

Группы, которые способны прочувствовать рынок, взаимодействуют с ним – общаются с клиентами и наблюдают за ними, отслеживают то, как они используют продукт, и инициируют испытания и проверки, чтобы более четко ощущать потребности рынка. Команды, которые способны прочувствовать рынок, в состоянии понять и воспринять информацию. Утвердить на ее основе решения, а затем отреагировать.

У команды «почувствовать и отреагировать» существуют следующие возможности: мониторинг и наблюдение за клиентами, запуск экспериментов, понимание и интерпретирование данных, право принятия решений о том, как реагировать, и предоставление ответа.

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

Давайте рассмотрим историю двух разных команд в одной компании, чтобы оценить некоторые факторы, которые либо способны сделать этот подход успешным, либо нет.

В 2006 году перед командой брокерской фирмы с Уолл-Стрит стояла задача: компания добилась успеха в своем основном бизнесе электронной торговли, но руководители знали, что необходимо предоставлять дополнительные виды электронных торговых услуг для того, чтобы диверсифицировать свою деятельность.

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

В электронной торговле клиенты используют различные инструменты для отправки заявок своим брокерам. Они могут позвонить, отправить им электронное письмо или воспользоваться приложением, которое предоставляет брокер. Команда этой компании разделилась во мнениях о том, какой из методов следует выбрать.

Были озвучены три возможных способа предоставить клиентам новый сервис, и у каждой из идей были свои сторонники.

1. Некоторые члены команды предлагали создать новое «нейтральное» приложение для клиентов. Предполагалось, что оно будет включать все торговые услуги, предлагаемые компанией. Также оно позволит клиентам вести торговлю с брокерами из других фирм. Обычно клиенты хотят управлять своими сделками из одного приложения, независимо от того, с каким брокером имеют дело, и сторонники данной концепции утверждали, что покупатели хотят эту многофункциональность. Разработка данной системы потребовала бы серьезного объема работы.

2. Другие менеджеры утверждали, что фирма должна создать приложение, позволяющее заключение сделок только с ее участием, – приложение «одного брокера». Люди, придерживающиеся данной позиции, считали, что компания не должна тратить время на то, чтобы помогать клиентам торговать с конкурирующими брокерами.

3. Наконец, третья группа утверждала, что дополнительного приложения вообще не нужно. Они считали, что фирма должна просто сделать сервис доступным для клиентов через уже существующие торговые приложения для клиентов.

Команды стратегии и управления продуктами спорили и предлагали каждая свое. В конце концов команда управления продуктом приняла решение создать приложение «одного брокера» (вариант 2). Важно отметить, что это решение было принято на основе аргументов его сторонников, а не на основе обратной связи с рынком.

Итак, команда разработчиков получила задание: создать приложение «одного брокера», где был бы предоставлен основной и новый бизнес.

Группа начала свою работу с того, что отправила команды дизайнеров и исследователей наблюдать за клиентами и опрашивать их о потребностях. Они быстро выяснили, что клиенты хотели все и сразу в одном месте. То есть вряд ли приняли бы крупное новое приложение «одного брокера».

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

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

Любой наблюдатель, который в тот момент влился бы в команду, решил бы, что именно так выглядит идеальное сотрудничество. Члены команды совместным трудом проделали отличную работу. Разработчики, дизайнеры, менеджеры по продукту и тестировщики – все они перебрались в комфортный конференц-зал и работали в атмосфере согласия друг с другом. Члены команды консультировались друг с другом по поводу ключевых решений, использовали множество современных agile-методов, были увлечены постоянной модернизацией рабочего процесса.

Проблема заключалась в следующем: команда никогда не представляла приложение клиентам. Члены команды поставили перед собой столь масштабную задачу – создание грандиозного приложения, призванного заменить существующие приложения конкурентов, – что никак не могли добраться до финиша. Цикличный подход был хорош для решения технических проблем, но он никогда не смог бы помочь найти решение, которое отвечало бы потребностям пользователя от начала до конца.

Когда семена сомнения, зароненные первоначальными исследованиями, начали прорастать, заинтересованные лица начали беспокоиться еще сильнее. Прибавьте к этому цену задержки: даже спустя два года команда все еще не могла представить сервис покупателям. Понятно, что у акционеров лопнуло терпение, и проект был закрыт. А ведь в течение долгого времени над проектом работали полтора десятка человек. Все их усилия, всё потраченное время – всё ушло впустую.

В следующем году некоторые сотрудники из этой команды были назначены на новый проект и поклялись исправить свои ошибки.

В ходе нового проекта команда дизайнеров создала совершенно другой механизм исследований. После первоначального цикла исследований, который принес знания, поставившие под вопрос стратегический план, команда дизайнеров с командой стратегов решили провести совместное недельное исследование ожиданий клиентов. Проектная группа хотела избежать проблемы, с которой она столкнулась ранее, сообщив о результатах, не вписывающихся в утвержденную концепцию. Члены команды хотели, чтобы лица, принимающие решения, увидели все своими глазами.

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

Когда члены команды завершили исследование, они были преисполнены решимости избежать еще одной ошибки, проявившейся во время прошлого проекта: на этот раз они хотели представить проект клиентам как можно скорее. Поэтому, несмотря на то, что у них были амбициозные планы на продукт, который они, в конечном итоге, создали, они задались вопросом: «Какую самую минимальную вещь мы можем создать, чтобы выйти рынок через три месяца или раньше?» Чтобы ответить на данный вопрос, они привлекли в свою группу продавцов и трейдеров, которым предстояло работать с этим сервисом, а также членов инженерной команды, которым поручено было создать его. Этот конференц-зал сильно отличался от предыдущего. Он не был местом исключительно для инженеров или для команды по продукту. Здесь работала самодостаточная бизнес-команда. Эта команда в ходе серии совместных сеансов проектирования создала набросок сервиса, который намеревалась представить в его начальной стадии клиентам, вооруженным небольшим количеством программ. Со времени, когда они подтвердили, что сервис работает так, как и задумывалось, члены команды планировали привнести в программное обеспечение больше функциональных возможностей, которые позволили бы сервису расширяться в масштабах.

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

Эта история представляет два важных результата. Первый – относительно поэтапной и цикличной разработки. Второй – командного сотрудничества и гибкости.

Поэтапная разработка начинается с грандиозного видения: вы смотрите в будущее, планируете что-то значительное, и делаете это своей целью. Затем вы дробите достижение цели на этапы и реализуете проект шаг за шагом. Представьте, что вы строите кирпичный дом. С точки зрения программного обеспечения, такой способ работы обладает некоторыми преимуществами. Работая с небольшими блоками, вы можете создать технически надежное программное обеспечение: каждый блок можно обособить и проверить, что позволяет создавать системы, которые будут стабильны и которые можно будет легко поддерживать и изменять с течением времени.

Проблема с поэтапной разработкой состоит в том, что, когда вы упорядочиваете процессы, которые выстраиваете правильно, у вас до самого конца не будет ничего, что является «выполненным» с точки зрения клиента: покупатели не могут въехать в дом, в котором нет крыши или не установлены окна. Это означает, что вы не предоставляете ценность клиенту до самого конца очень долгого процесса. Что еще хуже, это означает, что вы до самого завершения не начинаете двусторонний разговор, чтобы получить обратную связь. При выполнении первого проекта в брокерской компании использовался данный подход, и, поскольку он не нес никакой ощутимой ценности, он был уязвим.

Цикличная работа – это совсем другое. Поскольку разработка программного обеспечения – это не то же самое, что строительство кирпичного дома, она может меняться по мере создания. Конечным итогом может стать люксовый отель, но вы можете начать создавать шатер, затем добавить туда настил, и тогда он превратится в люксовый шатер, потом вы могли бы возвести стены, чтобы он стал похож на хижину, затем крышу и так далее. Таким образом вы обеспечиваете ценность для клиента с самых ранних этапов и с каждым циклом предоставляете все более ценное решение, которое выпускаете на рынок. И с каждым из этих циклов вы получаете обратную связь по мере развития системы. Во втором проекте брокерской компании использовался именно этот подход, который уже на раннем этапе смог обеспечить ценность для клиентов, что помогло достичь успеха проекта в целом.

Сотрудничество команды – это то, что делает цикличную разработку возможной. Такой вид работы подразумевает скромную оценку видения. Оно у вас есть, но вы должны быть готовы признать, что не уверены, что ваш план сработает. Вы можете настроить свою команду на получение обратной связи и принятие решений в ответ на нее. Чтобы это сработало, вы должны признать, что эти решения будут приниматься не единожды, а скорее всего, непрерывно, в ответ на каждый цикл.

Первым шагом в создании группы, способной реагировать на то, что она узнает, является создание самодостаточной многофункциональной команды. Для команд разработчиков программного обеспечения это означает, что специалисты всех направлений работают вместе в тесном цикле сотрудничества. Суть совместной работы не ограничивается простым включением в группу технических специалистов. Такой вид сотрудничества важен, но, как вы узнали из предыдущей истории, этого недостаточно. Если команда действительно работает над тем, чтобы представить ценность для клиента и бизнеса, то лица, принимающие бизнес-решения, должны быть также вовлечены в циклы сотрудничества.

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

Не только цифровые команды открывают для себя способности многофункциональной организации.

В январе 2013 года Чип Бланкеншип, генеральный директор GE Appliances, собрал одну небольшую многофункциональную команду в одном помещении и бросил ей вызов – представить к выпуску новый высококлассный холодильник с двумя отделениями через год, при том, что где-то три месяца обычно нужны для разработки[66]. Более того, он хотел через три месяца получить рабочую модель. Бланкеншип был сторонником идеи бережливого стартапа и хотел понять, работают ли эти принципы при создании бытовой техники.

Единственный способ сделать это быстро – собрать команду вместе и заставить работать над одной задачей.

Члены команды начали продумывать, как успеть к сроку, и выявили ограничения в традиционном процессе. Они поняли: для того чтобы продвигаться в этом деле быстрее, им нужно создать непрерывный поток обратной связи от продавцов, дизайнеров, поставщиков материала и покупателей. В традиционной модели для проведения всех этих бесед могли бы потребоваться месяцы. Команда хотела сократить этот этап до нескольких дней или даже часов. Члены команды понимали, что им придется ужать временные рамки циклов, если они хотят справиться к сроку. И не только беседы должны протекать быстрее. Команда хотела генерировать быструю обратную связь с рынком, поэтому ей был необходим способ для привлечения клиентов. Наконец, команда понимала, что, по мере определения того, что работает, а что – нет, она должна быть в состоянии быстро реагировать с помощью обновлений: было нужно, чтобы все участники процесса знали о новых направлениях, в которых движется команда.

Группа провела начальные беседы с поставщиками, которые были в восторге от того, что стали частью этого процесса: им представили предварительный вариант продукта и таким образом позволили планировать приобретение материалов для масштабного производства.

В состав команды также входил финансист: группа понимала, что традиционные расчеты экономической модели не сгодятся для этого проекта. Обычно, когда дело касается проектов с многолетними сроками, команда по продукту никак не пересекается с финансами. Просто с точки зрения финансов при создании типичного проекта бытовой техники мало что день ото дня меняется. Этот проект был не таким. Команде нужен был финансист, который понимал бы, что пытается сделать команда, и мог помочь ей с расчетами. Было необходимо создать экономическую модель, которая была бы достаточно гибкой, чтобы реагировать на часто вносимые корректировки.

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

Конечные результаты говорят сами за себя. Товар продается в два раза активнее обычного, стоит в два раза дешевле и поставляется на рынок в два раза быстрее, чем предыдущие модели холодильников.

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

Основная модель команды, как мы убедились, включает взаимодействие специалистов трех основных функциональных областей – разработки, технологий и бизнеса. Однако нередко к командам подключают специалистов других областей. Компания Taproot Foundation, представленная в Главе 5, работает над созданием онлайн-сервиса по подбору работодателей и специалистов для совместной работы над проектами. В команду, управляющую этим интернет-рынком, входят и комьюнити-менеджеры. Для успешной работы сервиса требуется глубокий, непрерывный контакт с сообществами, простого администрирования веб-сайта в данном случае недостаточно. В некоторых компаниях могут быть виды деятельности, требующие создания отдельных команд, но при этом тесное сотрудничество между ними не предполагается. Например, в журналистике стремление защитить редакционный контент от влияния коммерческих соображений привело к созданию так называемой Великой китайской стены, которая разделяет творческие и коммерческие подразделения. Но опыт со стенами становится все более проблематичным. И в Докладе об инновациях New York Times, на который мы ссылались в Главе 4, содержится прямой призыв к более тесному сотрудничеству через эту стену: «Существует ряд отделов и подразделений, которые считаются частью бизнес-блока, но которые явно ориентированы на опыт читателя, включая отделы разработки, технологий, распространения, потребительского анализа, НИОКР. Выполняемые ими функции представляют собой очевидную возможность для лучшей интеграции»[67].

Мы начинаем видеть, как в цифровых медиакомпаниях эта стена рушится. В этих новых организациях делают меньше различий между редакционной работой и выпуском продукта. Инженер BuzzFeed описывает сотрудничество следующим образом: «Возможность тесного сотрудничества с редакционной группой и бизнес-отделом является одной из самых полезных в моей работе. Я создаю технологии для людей, которые сидят напротив меня»[68]. В Vox Media правила сотрудничества прописаны в Кодексе поведения компании:

Многие команды привлекают специалистов только в случае конкретной необходимости, а не на постоянной основе. Возможно, в какой-то ситуации вам понадобится специалист из юридической группы или комиссии по проверке соответствия стандартам, но каждый день они вам не нужны. Это относится к любому виду специализации.

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

Существуют надежные экономические модели, которые позволяют определить, включать ли данного специалиста в основную команду или же привлекать его к работе в нескольких командах неполный рабочий день. Типичным примером является подразделение пожарной охраны: должна ли пожарная команда быть в каждой компании? Большинство организаций ответит «нет»: имеет смысл полагаться на централизованно предоставляемые городские услуги. Однако некоторые компании (например, те, у кого работа с огнем является ключевой операцией) могут нуждаться в постоянной пожарной службе.

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

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

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

Приводим список ключевых изменений, позволяющих эффективно сотрудничать командам, использующим подход «почувствовать и отреагировать»:

• Создание автономных команд под конкретные задачи;

• Использование многофункциональных команд;

• Создание специализированных групп;

• Поддержка новых рабочих направлений;

• Совместное размещение команды;

• Осторожность при дистанционной работе;

• Осторожность с аутсорсингом;

• Изучение опыта и использование минимально жизнеспособных процессов.

Считайте этот список отправной точной, а не инструкцией. Каждой организации, которая реализует эти идеи, придется подходить к ним творчески. Считайте эти идеи, скорее, принципами, чем жесткими правилами.

Ранее мы рассматривали концепцию результата в сопоставлении с целью. Идея состоит в том, что не нужно приказывать командам выдавать конкретный результат, например, «выясните, как запустить наш новый сервис для торговли». Чтобы достичь цели, команды должны иметь возможность решать, что им делать, и еще они должны иметь необходимые ресурсы, возможности для эксперимента, а также разрешение на обучение и на то, чтобы начать заново. Это означает, что команда должна обладать возможностями, которые охватывают весь спектр бизнес-процесса. Также им необходимы полномочия, чтобы не приходилось ждать одобрения. Им нужна свобода действий.

Используя эти возможности, они смогут предпринимать оперативные действия и вычислять оптимальный путь для продвижения вперед.

Однако без предоставления таких возможностей случаются плохие вещи: когда командам приходится ждать одобрения, они становятся зависимыми от лиц, принимающих решения. Они замедляются, оказываются не способны дать ответ в нужный момент. Они ограничены в способности обучаться и приносить пользу.

Таким образом, когда вы сталкиваетесь с неопределенностью, автономные команды, которые способны обучаться, – это именно те, кто создаст ценность для вашей организации.

Ранее в этой главе мы описывали возможности автономных команд: мониторинг и наблюдение за клиентами, проведение экспериментов, осмысление и интерпретация информации, принятие решений о том, как реагировать, и, собственно, ответ. Эти возможности формируют основу многофункциональных команд, к созданию которых мы стремимся. На практике это означает, что мы должны создавать команды из многофункциональных групп, убедившись, что основные функции команды (разработка, проектирование и управление продуктом) у них слажены.

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

Еще одним препятствием является отсутствие координации между функциональными подразделениями. Во многих организациях этим подразделениям выделяется бюджет, не учитывающий координирование с другими подразделениями. Таким образом, даже если наличие многофункциональных сотрудников отвечает интересам команды, подразделение, к которому «приписано» данное лицо, может не разделять эти интересы. Иными словами, способ планирования совместной работы подразделений и принципы бюджетирования имеют решающее значение.

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

Опять же, все может оказаться не так просто, как кажется. Зачастую количества сотрудников недостаточно для того объема работы, которую им предстоит выполнить. В результате организации пытаются «выжать» из членов команды как можно больше, назначая сотрудников сразу на несколько проектов. На реальном заводе абсурдность такого способа распределения работы очевидна. Невозможно, чтобы кто-то работал на двух производственных участках одновременно. Но интеллектуальная работа настолько абстрактна, что этим можно манипулировать при рассмотрении задач.

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

Гораздо эффективнее, если сотрудник работает в одной команде и над одной задачей.

Наверное, самое важное, что вам нужно сделать с точки зрения эффективности совместной деятельности, – это помочь команде переосмыслить свою работу. Такой вид сотрудничества обычно требует от членов команды изменить манеру, в которой они выполняют свою индивидуальную работу. Менеджеры по продукту могут иметь привычку создавать подробные планы и экономические модели: им нужно научиться ставить вопросы и экспериментировать. Дизайнеры обычно хорошо справляются с работой в Photoshop: скорее всего, во время обсуждений рабочего процесса им будет комфортно воспринимать информацию на электронной доске. Разработчики могут иметь привычку работать с подробными документами: они должны свыкнуться с отображением результатов в виде эскизов. И каждый должен смириться с тем, что внесение изменений и переработка уже сделанного являются ценными этапами процесса, а не затратами, которых следует избегать.

По мнению Билла Скотта из PayPal одна из причин успешности его команды у бывшего нанимателя, компании Netflix, состояла в том, что команда разделяла идею непрерывного улучшения: «Я понял, что, особенно в работе над пользовательским интерфейсом, мы отбросили 90 % кода, написанного в том году»[70]. И дело не в том, что команда написала плохой код, а в том, что она считала его всего лишь инструментом обучения. Это было частью постоянных усилий команды по поиску правильного решения.

Как только у вас появилась команда и вы нацелили ее на выполнение проекта, у вас появились условия для обеспечения хорошей совместной работы. По крайней мере фундамент. Следующим шагом будет мотивация членов команды работать вместе.

Самый простой способ заставить людей работать вместе – это усадить их в одно помещение. Люди, которые работают рядом, более естественно коммуницируют. В эпоху текстовых сообщений, чатов, электронной почты и видеоконференций силу личной беседы по-прежнему трудно переоценить.

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

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

Это не означает, что размещение в едином пространстве – единственный способ организовать хорошее сотрудничество. Но это все-таки дает важное преимущество.

Пожалуй, ни одна тема в технологических командах не обсуждается так же горячо, как удаленная работа. Она давно стала частью технического мира. Действительно, мыслительная деятельность идеально подходит для удаленной работы. Компьютеры и интернет предоставили нам инструменты для работы в любой точке мира, и многие работники дорожат этой свободой.

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

При планировании участия удаленных работников в команде важно уделять особое внимание вещам, которые могут создать несбалансированную связь, которые препятствуют реальному общению. Как минимум, разница в часовых поясах, в которых работают члены команды, должна быть незначительна, чтобы люди бодрствовали в одно и то же время. А для выстраивания доверительных социальных взаимоотношений, которые делают возможным сотрудничество, члены команды должны регулярно видеться друг с другом, как минимум раз в несколько месяцев.

Начиная с конца 1980-х годов мы наблюдаем рост использования аутсорсинговых и оффшорных ИТ-услуг. Аутсорсинговые компании выступают с, казалось бы, привлекательным предложением: используя их недорогие услуги в области ИТ и разработке программного обеспечения, компании получают возможность избежать необходимости самостоятельного управления этими нестратегическими бизнес-функциями, передав их высококлассным экспертам и сосредоточившись на своих основных компетенциях.

Как мы надеемся, мы уже совершенно ясно дали понять, что ИТ и разработка программного обеспечения теперь должны рассматриваться в качестве основной бизнес-функции, а также стать основной компетенцией для каждой фирмы любого размера. В проектах и программах, в которых неопределенность играет существенную роль, компании все больше уходят от ИТ-аутсорсинга. С недавних пор мы заметили нарастающую тенденцию развития ИТ-услуг внутри организации[71].

Аутсорсинг часто ассоциируется с офшорингом, практикой переноса рабочей деятельности в другие части мира для оптимизации в сфере найма, стоимости и графика. Многие организации размещают основные бизнес-подразделения, продажи и маркетинг в штаб-квартирах в крупных городах и создают инженерные центры за много тысяч миль от них.

Аутсорсинг и офшоринг создают схожие проблемы. Оба тактических приема порождают команды работников, которые отделены от покупателей и акционеров и не способны к автономному обучению. Это также приводит к трудностям в построении хорошего сотрудничества с коллегами по бизнесу и невозможности самостоятельно установить двусторонний разговор с рынком.

Конечно, существуют технологические проекты, для которых подходит аутсорсинг. Проекты с низким уровнем неопределенности (что строить и что будет работать) отлично подойдут для аутсорсинговых и офшорных команд. Один из методов такого типа работы – использование двухкомпонентного agile-подхода.

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

Преимущество двухкомпонентной agile-разработки состоит в том, что она позволяет одной команде оперативно выявлять потребности рынка, а другой – работать более размеренными темпами для обеспечения масштабирования. Однако сложно скоординировать такую работу хорошо. Существует риск возродить старые проблемы сборочного конвейера: оперативная информация может несвоевременно возвращаться к команде разработчиков, что снизит потенциал возможных изменений. Также происходит изоляция производственного компонента, что лишает его возможности получать предпросмотр перспективы.

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

Одним из наиболее ценных методов улучшения командного процесса является ретроспективное совещание, на которое периодически (обычно каждые две-три недели) собираются члены команды, чтобы обсудить и улучшить рабочий процесс. Существует множество способов проводить такие совещания, но самое главное – это применять методы подхода «почувствовать и отреагировать» к самой команде. Что работает? Что не работает? Что мы можем изменить, чтобы улучшить положение дел?

Другими словами, члены команды рассматривают свой рабочий процесс, как и свои усилия по производству продукта, в качестве объекта для непрерывного улучшения. Мы часто советуем командам начинать с минимально жизнеспособного процесса и использовать ретрооценки и непрерывную обратную связь (как внутри, так и за пределами команды), а также экспериментировать с процессами для улучшения совместной работы и рабочего процесса в целом.

Сначала эти ретроспективные совещания могут казаться утомительными. Если команды не привыкли к таким дискуссиям, первое открытое обсуждение проблем может показаться некомфортным. Однако подобно тому, как для улучшения ваших товаров нужна обратная связь, так и для улучшения рабочего процесса требуется изучение.

Один из известных приемов компании Toyota состоит в том, что любой, кто увидел производственную проблему, имеет возможность остановить работу линии. Этот подход предотвращает производство некачественной продукции и позволяет заводу быстро выявлять и исправлять неполадки. Подобным образом регулярные ретроспективные обсуждения акцентируют внимание команды на качестве производственного процесса, позволяют ей быстро адаптироваться к новым обстоятельствам и улучшать свою работу.

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

✓ Ключевые функции совместной работы, как правило, включают в себя разработку, проектирование и управление продуктом, но, в зависимости от организации, могут быть востребованы и иные навыки.

✓ Чтобы организовать сотрудничество, рассмотрите возможность использования целевых автономных команд, многофункциональных команд, а также профильных команд.

✓ Поддержите новые рабочие потоки и разместите команды в одном помещении. Если вы привлекаете удаленных или внешних сотрудников, будьте осторожны, оценивайте их влияние на agile-процесс.

✓ Адаптация минимального жизнеспособного процесса и проведение регулярных ретроспективных обсуждений будут способствовать более эффективному сотрудничеству членов команды.

AutoTrader UK является крупнейшим рекламным сайтом с объявлениями о продаже автотранспортных средств в Великобритании. Компания, основанная в 1977 году как печатное издание, запустила свой первый веб-сайт в 1996 году. А с июня 2013 года она полностью перешла на цифровой формат, закрыв свой печатный бизнес. Как сообщает компания, теперь AutoTrader UK контролирует более 80 % доли рынка[72]. Перед переходом компании на цифровой формат группа разработчиков создавала обновления веб-сайта раз или два в год. Когда цифровой сервис стал единственной целью команды, она удвоила этот темп до квартального. Как и следовало ожидать, каждый раз, когда команда выпускала новые функции продукта, покупатели отвечали обратной связью. Но не всегда эта обратная связь была положительной.

Менеджеры могли бы легко разочароваться от негативных отзывов или списать их со счетов, потому что они противоречили их установкам. Вместо этого они воспринимали такие отклики как возможность чему-нибудь научиться: «Каждый раз, когда мы запускаем новое обновление, мы видим, где мы были правы, а где нет. И чем чаще мы будем применять новые идеи, тем быстрее мы сможем обучаться и вносить корректировки». Они начали задаваться вопросом: «Почему же мы учимся только четыре раза в год? Почему бы не делать это четыре раза в неделю?»

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

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

Есть еще одно преимущество в увеличении темпа: снижение потерь, связанных с задержкой, – если функция окажется ценной для покупателей, внедрив ее на рынок раньше, вы получите больше пользы. И наоборот, чем дольше вы медлите с выпуском, тем меньше ценности вы сможете предоставить. Та ценность, которую вы упускаете, является потерями, связанными с задержкой.

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

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

Одной из интересных вещей, появившихся в мире технологий за последние десять лет, является направление DevOps (акроним от англ. «development» – разработка и «operations» – операции) – набор идей и процессов, которые позволяют командам выпускать надежное программное обеспечение быстро и с меньшими рисками, чем прежде. DevOps – технический и инфраструктурный уровень того, о чем мы говорили на протяжении всей книги, поэтому стоит потратить несколько минут на основные концепции этого направления и оценку влияния, которое оно оказывает на организации.

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

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

Представьте, что вы являетесь тестировщиком обеспечения качества. Вы привыкли получать добротное новое программное обеспечение примерно каждый месяц. Это означает, что у вас есть много времени на проверку, прежде чем прибудет новое программное обеспечение. А теперь представьте, под каким давлением вы окажетесь, когда разработчики начнут поставлять вам программное обеспечение каждые две недели или каждый день, а может, и много раз за день. Единственный способ успевать за всем – это изменить ваш процесс, рабочий поток и инструменты. Вы начинаете использовать ваш ранний опыт сотрудничества, новые стратегии тестирования и автоматизированные тесты. Суть не в том, что надо работать усерднее и быстрее. Дело в использовании автоматизации. Речь идет о фундаментальном изменении подхода к обеспечению качества.

То же самое произошло и с операционными рабочими потоками. В условиях менее частых выпусков программного обеспечения команды довольствовались медленными неавтоматизированными процессами. Запуск нового программного обеспечения можно было запланировать на вечер пятницы, чтобы избежать любого риска для систем, использующихся в рабочее время. Неважно, что этот запуск в пятницу вечером мог затянуться на выходные: если они закончат к утру понедельника, это все еще будет считаться достаточно быстрым.

Как только выпуски стали более частыми, операции по запуску перестали за ними не поспевать. Операционные команды также начали автоматизировать свои процессы, менять рабочий поток и оптимизировать сотрудничество с разработчиками. Эти новые подходы – суть идеологии DevOps, и они привели к феноменальным изменениям. Компании когда-то были рады выпускать новое программное обеспечение несколько раз в год, но сейчас мы видим компании, которые приняли подходы DevOps и, выпускают новое программное обеспечение несколько раз в день.

Команда из AutoTrader UK знала все о DevOps. Компанию возглавлял генеральный директор Тревор Мэзер, который ранее руководил одной из ведущих инженерно-консалтинговых фирм, использовавшей agile-подход.

Технический директор AutoTrader Крис Келли пояснил: «[Наша цель] – представить платформу, которая способствует постоянному внедрению функций по видам продуктов, а также предоставляет инструменты и механизмы, позволяющие командам измерять и контролировать свои приложения, в процессе производства»[73]. Иначе говоря, AutoTrader UK нацелена предоставить своим командам возможность как можно скорее передавать свои идеи в руки клиентов, а затем отслеживать производительность этих функций, чтобы понять, насколько они успешны.

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

В Главе 6 мы говорили о важности небольших многофункциональных и самостоятельных команд. Однако в любой организации, независимо от ее размера, ни одна из команд по-настоящему не является самостоятельной. Команды полагаются на руководителей в формировании своих задач, предоставлении финансирования и установлении границ, в пределах которых они могут работать. Они опираются на маркетинг и продажи для определенных видов взаимодействий с рынком. Короче говоря, существует много точек координирования, и не все функции могут быть делегированы команде. Поэтому, несмотря на то, что «самостоятельность» является важным ориентиром для команд, они редко когда являются самостоятельными на 100 %, а еще реже они становятся экономически рентабельными.

Поэтому организациям просто необходимо действовать скоординированно. Прежде основу бизнеса производственных организаций составлял предсказуемый, повторяющийся процесс, и координировать его было несложно, потому что бизнес двигался в ожидаемом ритме. Годовой бюджет. План на год. Месячный план продаж. Еженедельный журнал. Ежедневная газета. Это делало механизмы контроля и управления предсказуемыми. Головной офис мог предугадать рабочий ритм бизнеса. В организациях, использующих подход «почувствовать и отреагировать», координирование является более органичным и требующим согласованности, что мы обсуждали в Главе 5.

Все это сводится к одной простой идее: по мере того, как мы переходим от производства отдельных наименований к процессу непрерывного производства (как это происходит в рамках DevOps), важно учитывать больше составляющих, чтобы соответствовать ритму и темпу новых способов создания товаров и услуг.

Распространенный страх, который испытывают менеджеры относительно перехода к непрерывному производству, имеет отношение к клиентскому опыту. Менеджеры опасаются, что постоянные изменения разрушительно скажутся на опыте клиентов, которые доверяют привычной продукции. Как вы получите преимущества от потока, постоянно и хаотично меняющего опыт клиентов?

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

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

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

В большинстве организаций, реализующих DevOps-подходы, менеджеры способны контролировать то, какие конечные пользователи видят новые функции и когда. Этот контроль осуществляется с помощью так называемых флагов функций или переключателей функций. Можете считать, что они предназначены для включения или отключения функций. Но они позволяют менеджерам по продукции, например, экспериментировать с новыми функциями, предоставляя их только небольшой, выбранной группе пользователей. Флаги функций позволяют проводить A/B-тестирование альтернативных версий функции и убирать те, которые вызывают замешательство. И, как правило, они указывают, что решение о развертывании программного обеспечения, скорее, является бизнес-решением, а не техническим решением.

Хорошая новость заключается в том, что эта возможность предоставляет менеджерам новую колоссальную власть. Более того, она позволяет организациям гораздо более детально контролировать, что и когда видит клиент. Таким образом, весь жизненный цикл функции может быть передан под контроль разработавшей ее команды. С другой стороны, иногда бывают веские организационные причины для координирования выпуска функций. Например, многие розничные онлайн-магазины ограничивают внесение изменений на своем веб-сайте во время сезона праздничных покупок. Это основное «окно» для заработка, и на этот период осторожность должна быть гарантирована. У других компаний тоже могут быть клиенты, которые не склонны к изменениям: торговец, который использует онлайн-сервис для расчета ежемесячной заработной платы, не хочет каждый месяц изучать новые функции. И, конечно, некоторые ситуации имеют последствия для безопасности, поэтому поставщикам таких систем нужно поддерживать соответствующий контроль.

Тем не менее многие из формальных механизмов контроля за выпуском, которые были реализованы в более ранней технологической эпохе, потеряли свою актуальность. К примеру, в 2002 году правительство США ввело в действие мандаты, определяющие порядок выпуска нового программного обеспечения. Среди прочего, они предусматривают, что все государственные учреждения проводят оценку воздействия на конфиденциальность (PIA) любого обновления системы, которое собирает личную информацию. Этот механизм был предусмотрен исключительно из благих побуждений, но, когда PIA занимает три недели, это вызывает значительные проблемы для agile-команды, нацеленной ежедневно выпускать программное обеспечение. Команды разработчиков правительства США в эту самую минуту борются с этой проблемой.

Здесь нет общего решения, за исключением того, чтобы признать принцип, согласно которому полномочия на выпуск должны быть максимально ограничены (в большинстве случаев уровнем команды). Также должны быть установлены четкие пределы полномочий и действий, чтобы команды знали, когда им нужно координировать свои усилия с другими для принятия решений о выпуске продукции.

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

В организационной работе для подобных ограничений идеально подходит метафора песочницы – это безопасное место с четкими границами, в пределах которых могут работать команды. Принцип «песочницы» генерирует положительный эффект как для руководителей, так для подчиненных. Руководители испытывают законный страх, что их подчиненные разовьют такую креативность, что это повлечет за собой проблемы, ответственность за которые придется нести начальству. Указание четких границ, в рамках которых люди могут работать, способно снизить этот риск. А опасения подчиненных связаны с тем, чтобы не перейти какие-либо непредопределенные границы. Если руководитель прояснит, где проходят эти границы, будет сгенерировано пространство для творчества.

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

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

Как и со многими вещами в мире подхода «почувствовать и отреагировать», границы, которые формирует «песочница», бывает трудно предвидеть. Нередко команды сталкиваются с запретами и вынуждены выяснять, где пределы их полномочий. Например, команда может запросить доступ к списку рассылок компании только для того, чтобы проверить свои планы. Это время начать строить «песочницу». Команда должна объяснить свою мотивацию (например, «мы хотим протестировать эту идею») и провести работу с заинтересованными лицами внутри компании, чтобы определить основное направление, которое устроит каждого. Заинтересованные стороны должны быть на раннем этапе привлечены к обсуждению и выработке постоянных правил, на основе которых все будут действовать, вместо того чтобы проводить одноразовые согласования всякий раз, когда возникает тот или иной вопрос. Команды, создавшие «песочницу», могут двигаться к решению задач оптимальным темпом, экспериментируя в рамках очерченных границ.

Отметим, что «песочницы» и другие формальные ограничения являются не единственным способом предоставить командам свободу действий в рамках оговоренных границ. Более подробно поговорим об этой культуре в Главе 8, а пока заметим, что многие организации со временем убеждаются, что данный подход учит верить в то, что в рамках своих полномочий люди поступят правильно. Так, компания AutoTrader UK в настоящее время приближается к отметке 25 000 релизов в год, а ее операционный директор Коу считает ключом к преобразованиям переход от формального процесса к большей автономии и расширению самостоятельности команд при разработке продуктов. Все это подразумевает опору на здравый смысл.

В мире непрерывных, быстрых изменений некоторые процессы придерживаются более медленных ритмов. Возможно, это нигде не является более верным, чем в финансовой сфере, где доминирует ежегодный бюджетный процесс. Если вы работали менеджером в организации любого размера, то вы, без сомнения, принимали участие в процессе составления бюджета, который занимает так много времени и требует столько сил и внимания, что мы часто называем его бюджетным сезоном, продолжающимся с октября по декабрь. Как плохо, что процесс, который добавляет так мало ценности, требует целого сезона! Что еще хуже, называя этот период «сезоном», мы, кажется, наделяем его неизбежностью природных явлений. «Конечно, идет снег, – пожимаем мы плечами. – Зима на дворе».

Почему бы организациям не пересмотреть бюджетный процесс? Если есть возможность постоянно обучаться, зачем тогда ограничивать свою способность к реагированию, составляя ежегодные планы, которые препятствуют изменениям?

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

Команда международного «Института внебюджетного финансирования», работающая над изменением моделей корпоративного управления, утверждает, что годовой бюджетный цикл глубоко ущербен. Какую проблему они считают «номером один»? «Бюджетирование препятствует быстрому реагированию. [Компаниям] нужно быстро реагировать на непредсказуемые события, но годовой бюджетный процесс никогда не соответствовал данной цели»[74].

Соня Кресоевич, старший вице-президент по глобальному жизненному циклу продуктов международной образовательной издательской компании Pearson, объяснила нам: «Организация должна уметь реагировать. Двадцать лет назад Pearson была печатным издательством. Это очень предсказуемый бизнес. Теперь, когда мы переходим к цифровым технологиям, где успешность и провал весьма волатильны, нам нужно адаптировать наши процессы к этим изменениям»[75].

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

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

Консилиумы принимают решения по финансированию того, что Pearson называет глобальным жизненным циклом продукта – действующей с 2013 года системы, призванной обеспечить последовательную, воспроизводимую и масштабируемую основу для принятия решений об инвестициях в продукцию. Эта модель не сильно отличается от модели трех перспектив, используемой в Intuit (она описана в Главе 5). В модели Pearson жизненный цикл состоит из шести фаз, а не трех, однако фундаментально концепции схожи. На ранних стадиях в идеи инвестируют немного и ожидают, скорее, что они принесут плоды обучения, а не финансовые результаты. Иначе говоря, командам предлагается проверить свои бизнес-идеи, а не заработать прибыль. Как только идею утвердят, консилиум по продукции инвестирует дополнительные средства и тогда уже будет ожидать более традиционной доходности.

Консилиумы по продукции дают Pearson возможность быстро и непрерывно выделять деньги на идеи в течение года. Эта схема позволяет компании инвестировать в потенциально интересные области, избегая запуска крупных проектов, которые не доказали свою ценность. Также она ограничивает риск перефинансирования недоказанных идей. «Вы не можете предсказать будущее, – говорит Кресоевич. – Если ваша единственная способность реагировать заключается в сокращении расходов в октябре, то вы не являетесь компанией, способной отозваться на спрос. Вы не даете ответную реакцию там, где вы можете способствовать росту или где у вас появилась новая возможность показать себя».

Компании неохотно меняют процессы финансового управления, и их можно понять. Тщательное управление финансами является основой успеха. Тем не менее процесс, который реализует Pearson, показывает, что даже компания, которой больше ста лет (Pearson была основана в 1844 году), сталкиваясь с будущим, начинает меняться. Оказывается, это возможно – переосмыслить один из наиболее консервативных элементов бизнеса (процесс финансового управления), чтобы он лучше вписывался в век информации.

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

Наша клиентка с одобрения руководителей, которым она сообщила о данной проблеме, решила сменить направление – предложила другую идею, которая некоторое время вызревала в организации, но на поверку также оказалась малоценной. Такова природа инновационной работы. Вы пробуете идею за идеей и в основном продолжаете свой путь, испытывая провал за провалом. Однако, к нашей истории. С теми неподтвержденными идеями мы работали быстро и эффективно, и наша клиентка была счастлива до самого окончания проекта, то есть до тех пор, пока мы не поделились своими результатами с ее боссом. Он изумился: «Вы ничего не создали? Я думал, вы собираетесь создать приложение!»

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

Маркетологи тоже знакомы с силой «блестящих объектов». Альфред Слоун, легендарный глава General Motors, с середины 1920-х годов начал использовать силу ежегодных изменений дизайна и стиля для усиления потребительского спроса на автомобили GM. И благодаря этому гениальному ходу появилась так называемая модель года. Ежегодно производители автомобилей демонстрируют «модель этого года» – новую версию прошлогоднего автомобиля с некоторым количеством модификаций – чтобы привлечь покупателей, поднять цену и удержать рынок. Этот прием стал стандартом автомобильной промышленности и главным в маркетинговой практике. Но в мире «почувствовать и отреагировать» сложнее сфокусировать маркетинг на новом продукте или новой функции. Крупные кампании нужно планировать, для чего требуется время. Но как это сделать, если вы не знаете, что у вас получится? И как вы можете запускать крупные кампании, когда изменения происходят не раз в год, а небольшими, частыми порциями?

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

• Маркетинг может стать частью команды. Группы, использующие подход «почувствовать и отреагировать», сталкиваются с неопределенностью в отношении позиционирования, брендинга и заявления о себе. Каков наиболее эффективный способ рассказать о продукте или услуге, которые мы предлагаем? Как мы можем сообщить о преимуществах? Как мы можем заинтересовать людей? Все эти вопросы команды должны решать на ранней стадии, а не постфактум. Привлекая маркетинг в основную команду, вы получаете возможность проводить эксперименты, которые касаются предложения в целом – от особенностей и функций до позиционирования, бренда и публичного месседжа.

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

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

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

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

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

Тем не менее система стимулирования, принятая в отделах продаж, часто входит в противоречие с принципами работы остальных команд, особенно следующих культуре непрерывности. Планы продаж, как правило, привязаны к датам – продавцы должны обещать определенные функции к определенным датам. Такой тип продаж создает массу проблем для команд разработки продукта, и опять же, фиксированные привязки снижают поток, обратную связь и возможность обучения.

Продавцы, со своей стороны, могут быть сбиты с толку постоянно меняющимися планами-графиками, что затрудняет их общение с клиентами. Трансформация методов продаж в процесс с высокой долей консультативного элемента представляется наиболее перспективным способом интеграции продаж в команды, использующие подход «почувствовать и отреагировать». Если консультативный способ продаж не вполне подходит, можно использовать другие критерии успеха продаж, например качество обслуживания клиентов. Команды The Sonic Automotive, представленные в Главе 4, поступают именно так. Вместо того, чтобы сосредотачиваться на продаже максимально дорогих автомобилей, они фокусируются на улучшении опыта клиентов. Они знают, что в этом состоит их самое большое преимущество, являющееся лучшим способом «закрыть» продажу. От этого зависит их заработная плата. Такой подход представляется выигрышным как для отдела продаж, так и для группы по реализации, поскольку помогает командам по реализации получить информацию о клиентах из первых рук, а отделам продаж дает возможность для улучшения опыта клиента и повышения ценности.

Наконец, как и в случае с маркетингом, команды по продажам сами могут извлечь выгоду из принятия подхода «почувствовать и отреагировать». Подходы тестирования и оценки, которые применяются в мире неопределенности разработки продуктов и маркетинга, могут оказать огромное влияние на мир продаж.

Развитие программного обеспечения переводит традиционное «проектное» мышление в категорию устаревших. Когда будет выпущена программа? Никогда. Таким образом, вместо того, чтобы делать ставку на «проекты», у которых есть даты начала и окончания, agile-подход утверждает становление команд, основой которых является непрерывность. То есть вместо формирования команды для создания набора функций, мы можем нанять команды для достижения набора результатов (мы это обсуждали в Главе 5).

Именно так произошло в компании AutoTrader UK, где команды больше не финансируются на ежегодной основе для создания набора функций. Вместо этого организация ежеквартально оценивает каждую команду на предмет следования основной цели конкретной инициативы.

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

✓ Непрерывность производства и принятия решений, а также обучение являются основой подхода «почувствовать и отреагировать».

✓ При переходе от промышленного производства к миру непрерывного производства – с использованием Dev-Ops, agile-методов и подходов бережливого стартапа – важно учитывать другие бизнес-процессы и также изменять их на непрерывные.

✓ Менеджеры по продукту должны пересмотреть тактику управления выпуском, чтобы, соблюдая нормативные требования, контролировать чувствительность клиентов, учитывать сезонность и межкомандные привязки.

✓ Организации должны использовать «песочницы» для определения ограничений операций для команд, которые сохраняют свою свободу действий.

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

✓ Ежегодный процесс бюджетирования следует пересмотреть в пользу более частых периодических проверок прогресса команд относительно достижения бизнес-результатов.

✓ Маркетинговые команды должны приспособиться к миру, в котором функции продукта часто неизвестны до самого его выпуска.

✓ Команды по продажам должны отойти от практики обещаний относительно функций и дат и начать применять действенный подход, помогающий командам понять потребности клиента и рынка.

В Главе 1 мы коротко рассказали историю о том, как в 1996 году правительство Массачусетса решило создать новую цифровую систему, связывающую более ста судов по всему штату. Цель заключалась в создании общей базы данных судебных протоколов и документов, оказании помощи судебным администраторам в отслеживании рабочей нагрузки и обеспечении более эффективного сотрудничества между юрисдикциями. В проект MassCourts, под таким названием известна эта система, изначально был заложен бюджет в размере 75 млн долларов, и большая его часть досталась компании Deloitte & Touche, основному куратору[76]. Первоначально предполагалось, что система будет развернута в течение пяти лет и передана в эксплуатацию штату. Но в апреле 2015 года газета Boston Globe опубликовала статью о том, что и девятнадцать лет спустя проект все еще не завершен.

Но несмотря на крайнюю задержку по срокам, перерасход бюджетных средств (для завершения проекта штат был вынужден компенсировать средства за счет других фондов) и нехватку современных функциональных возможностей (к примеру, система недоступна через интернет), Deloitte утверждает, что он успешно выполнил проект[77]. Эксперт Майкл Кригсмен, выступая в качестве свидетеля в законодательном собрании штата, спросил: «На какой планете этот проект можно считать успешным?»[78]

Как Deloitte может утверждать, что проект был успешным? Все сводится к тому, как работают ИТ-закупки. Кригсмен отметил: «Чтобы понять… мы должны рассмотреть первоначальный контракт. Слишком часто эти соглашения определяют выставление счетов на основе этапов процесса, а не бизнес-целей процесса».

Так было и в этом случае: правительство штата Массачусетс установило этапность платежей исходя из предоставления функций, а не из удовлетворения потребностей клиентов, удобства использования или бизнес-результатов. Это означало, что, если Deloitte завершал создание функции и проходил проверку ее качества, он получал оплату. При подобном подходе компания могла выставлять счета, получив в итоге большую часть от общей суммы в 75 млн долларов, установленной штатом Массачусетс для проекта.

Работа по таким условиям создает культуру, которая возвышает ценность предоставления над успехом. Это и есть позиция Deloitte в данном споре. Компания определила условия, а представители штата согласились. Но это все равно, что поручить своему младшему брату проследить за банкой с печеньем. «Ты сказал проследить за ними! Ты не говорил, что я не должен их есть!»

То, как вы представляете свою работу, способствует процессу формирования культуры. Если вы попросите людей создать функции, они это сделают и оценят вклад этих функций в общую ценность, даже если это не раскрывает общей картины успеха. Они оценят особенности труда, которые делают возможным предоставление этих функций. С другой стороны, если вы попросите людей быть ответственными за успех, вы попросите их работать по-новому. И чтобы в конечном итоге такой подход сформировал новую культуру, этот культурный переход требует осознанности, развития и поддержки.

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

Традиционная культура руководства и контроля индустриальной эпохи поощряет, чтобы вы придерживались плана – даже если вы узнаете, что план больше не имеет смысла. Не задавайте вопросов. Не поднимайте шум. Просто сосредоточьтесь на задании. Мы называем это культурой обслуживания. Не удивительно, что подход дзидока компании Toyota показался радикальным познакомившимся с ним в 1980-х годах представителям американского автопрома, приверженцам традиционной «культуры обслуживания». Подход дзидока, в частности, подразумевает, что любой работник производственной линии может (просто обязан) остановить линию, если заметил недоработку или проблему с качеством. Идея заключается в том, чтобы решить проблему прежде, чем она сможет негативно повлиять на качество автомобилей. Только после того, как проблема решена, линию можно было перезапустить. Американские рабочие, обучающиеся наряду с рабочими из Toyota в 1980-х годах, были потрясены, увидев этот подход. Единственным «священным» законом американского автопроизводства был постулат о том, что линию нельзя останавливать несмотря ни на что. Этот момент – когда «культура обслуживания» входит в противоречие с культурой качества – формирует проблему, с которой организации сталкиваются при определении ценностей.

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

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

Таким образом, это устаревший и рискованный способ работы в мире, управляемом программным обеспечением.

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

1. Сдержанность. Если вы не знаете, как будет выглядеть конечный продукт, вы должны узнать об этом.

2. Разрешение на провал. Всякое исследование подразумевает, что иногда мы ошибаемся. И это нормально.

3. Саморегуляция. По мере того, как мы находим новые доказательства, мы продолжаем наше обучение в тех направлениях, которые, по нашему мнению, приведут к лучшим результатам.

4. Прозрачность. Она подразумевает обмен новой информацией (хорошей или плохой) в самом широком смысле, чтобы другие могли соответствующим образом скорректировать свои исследования.

5. Акцент на действии. Анализ и вдумчивость важны, но обучение происходит посредством действий. Мы должны побуждать людей действовать, а не ждать разрешения.

6. Эмпатия. Сопереживание, добрые чувства к покупателям, пользователям и товарищам помогают нам найти ценность.

7. Сотрудничество. Привнося различные точки зрения на проблему, мы находим лучшие для нее решения.

Келлан Эллиотт-МакКри, технический директор в Etsy с 2011 по 2015 год, возглавлял новаторскую команду, на которую многие люди из мира технологий смотрели с восхищением. Члены команды Etsy были лидерами движения DevOps и первопроходцами сообщества разработчиков открытого ПО. Они представили множество методов, которые признаны последним словом техники. Тем более примечательно, что после своего ухода из Etsy, Эллиотт-МакКри написал короткое эссе, в котором основное внимание уделялось не техническим достижениям, а культурным – культуре, которую он помог создать за время своего пребывания на должности технического директора[79]. Несмотря на то, что его роль была все же технической, новые подходы распространились на всю культуру организации.

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

Одно дело воспринимать это умом. Однако смирение – это эмоциональная сторона знаний. Нам постоянно приходится сталкиваться с большим давлением со стороны наших коллег, начальников и покупателей, которые хотят, чтобы мы с уверенностью могли ответить на их вопросы. Первый менеджер по продукции компании Google Раджен Шет вспоминает, как в 2006 году первые клиенты интересовались у него насчет трехлетнего плана-графика компании относительно пакета корпоративных продуктов. У Шета и его команды была концепция развития, однако их план реализации был полон неопределенности. В конце концов, никто никогда раньше не создавал пакеты веб-продуктов для предприятий, по крайней мере в тех масштабах, которые планировал Google. Команда создала гибкую «дорожную карту», но она была рассчитана всего лишь на год. «Откуда я могу знать, что я буду делать через три года, когда я даже не уверен в том, чем буду заниматься через три месяца?» – восклицал Шет[80].

Это тяжелая ситуация для менеджера. В случае с Шетом, он просил корпоративных клиентов покупать такие продукты как системы электронной почты, которые обычно служат организации с десяток лет. Смотреть клиентам в глаза и говорить: «Я, правда, не знаю, как мы это получим, но я уверен, что получим», – это действительно тяжело. Однако, столкнувшись с таким давлением, немногие из нас поступят так, как это сделал Шет: признаются, что чего-то не знают. Напротив, мы составляем планы, берем на себя обязательства и формируем бюджет. В краткосрочной перспективе это может показаться отличным выбором, поскольку подобная тактика позволяет нам избежать неудобных разговоров. Однако такой подход часто порождает негативные последствия в долгосрочной перспективе. Клиенты и заинтересованные лица хотят верить, что инициативы можно прогнозировать, планировать, рассчитывать под них бюджет. Но когда случается что-то непредвиденное, разрушающее наши тщательно составленные планы, мы сталкиваемся с новой проблемой: приходится сообщать плохие новости. Стремление избежать разочарования из-за разрыва между планами и реальностью настолько велико, что мы можем полностью отказаться от обучения (в том числе на ошибках). Не обращайте внимания на проблемы! Пусть конвейер продолжает работать! Уложитесь в срок!

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

Таким образом, сдержанность и смиренность являются важным строительным элементом культуры обучения. Признание того, что мы не можем ответить на все вопросы, означает, что мы должны найти способ получить эти ответы. Мы должны выяснить, как нам узнать то, что нам нужно для достижения успеха.

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

Однажды мы работали с командой из крупной организации по оказанию финансовых услуг в США. Целью было помочь ей понять, как разрабатывать концепции в R&D (НИОКР – ред.) лаборатории. На наших первых встречах мы предложили почаще экспериментировать. На каждое предложение следовал один и тот же ответ: «Ой, мы не можем этого сделать, потому что…». Это, конечно, огорчало и нас, и наших клиентов, поскольку мы все хотели работать по-новому. Но как ни грустно, члены команды говорили правду. Им не разрешалось рисковать, хотя тактические приемы, которые мы предлагали, казались нам достаточно незначительными. Один молодой менеджер несколько месяцев спустя в телефонном разговоре рассказала нам, что, несмотря на запреты, команда провела несколько небольших экспериментов. Они увенчались успехом, и ее босс праздновал ее успех, но при этом сказал ей никогда больше так не делать!

«Песочница», о которой мы рассказали в Главе 7, является способом снижения риска во время проведения экспериментов. Идея состоит в том, чтобы создать набор процедур, правил и запретов, которые будут приняты в вашей организации, и благодаря чему будет допустим какой-либо провал. Но процедурные рекомендации являются только частью «песочницы». Нужно, чтобы разрешение на эксперимент стало частью культуры. Уровень взаимопонимания между коллегами и руководителями должен допускать, что ваш прогресс не будет прямолинейным и предсказуемым, и подразумевать, что вас будут оценивать не по быстроте реализации (количеству вещей, которые вы поставляете), а по скорости обучения, а также по общему прогрессу в достижении стратегических целей – другими словами, по степени постижения сути вопросов.

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

Мотивацией этого процесса является то, что неудачи следует рассматривать как возможности для обучения. Чтобы учиться на ошибках, вам нужно провести точную оценку того, что произошло, почему это произошло и как этого избежать в следующий раз. Проще, наверно, организовать поиски виноватого, чтобы привлечь его к дисциплинарной ответственности. Но в таком случае у вовлеченных в эксперимент людей больше не будет мотивации сообщать правду о том, что произошло. Они начнут скрывать ее, чтобы избежать наказания. Таким образом, для того чтобы люди могли обучаться, процесс «безупречного вскрытия» должен включать в себя железную гарантию того, что они могут высказаться, не опасаясь наказания. «Песочницы», «безупречные вскрытия» и другие разрешающие провал тактики обучения в итоге снижают большие риски, с которыми сталкиваются организации. Эти методы позволяют командам обучаться и реагировать на изменяющиеся условия. Это достигается путем поощрения небольших рисков. Это компромисс, с которым многим организациям трудно согласиться. Вместо этого многие из них настаивают на усилении управления процессами, чтобы снизить все риски. При таком подходе смешиваются различные виды рисков. Команда видит небольшие операционные риски и стремится их полностью контролировать, при этом не обращая внимания на большие экзистенциальные риски. Когда вы усиливаете контроль над операционным процессом, вы уменьшаете свободу действий своей команды. Поскольку ваши команды считают, что у них не так много свободы, чтобы отходить от «стандартных» процессов, они будут становиться менее любопытными и начнут искать все более безопасные решения. А значит, они, вероятнее всего, останутся прежними, несмотря на изменения рынка, развитие технологий и появление новых парадигм, которые бросают вызов вашей позиции.

Netflix, еще одна компания, придающая большое значение культуре управления, выступает против «контролирующих» видов управления в качестве основного принципа: «Процесс представляет заманчиво сильные результаты в краткосрочной перспективе»[81]. В качестве альтернативы Netflix ценит ответственных сотрудников, которым предоставлена свобода работать в рамках оговоренных ограничений с разрешением на провал, что создает возможность и для специалистов, и для организации расти и развиваться.

Разницу в подходах управления описывает знаменитая теория «X и Y в менеджменте»[82] профессора теории управления Дугласа МакГрегора, автора книги «The Human Side of Enterprise The Human Side of Enterprise» («Человеческая сторона предприятия», на русском языке не издавалась – ред.), вышедшей в середине ХХ века. Он указал, что существуют по крайней мере два вида отношения менеджеров к своим сотрудникам, которые преобразуются в два типа подходов к управлению. Теория X предполагает, что сотрудникам не нравится работа и единственный способ заставить их ее выполнять – это жесткий контроль, указания и угрозы. Никаких чувств. Никакого отклика. Никакого обучения. Эта теория гласит, что сотрудники избегают ответственности и инициатив и чувствуют себя комфортно, только когда руководство дает четкие указания и жестко контролирует.

Теория X описывает мировоззрение, присущее многим менеджерам промышленных предприятий. В прогнозируемом мире, где производство, затраты и рынок сбыта вашего продукта известны, управление согласно теории X воспринималось как правильное. В этой теории является аксиомой, что сотрудникам нельзя доверять принятие решений. Эта теория совместима с типом управления «сверху-вниз», где менеджеры принимают решения, а работники трудятся. На самом деле могут существовать такие организации, в которых такой метод управления оправдан, хотя успех производственной системы Toyota, поощряющей вдумчивость и принятие решений относительно производственной линии, ставит его под сомнение.

Тем не менее для работников интеллектуальной сферы осмысление и принятие решений являются работой. А в рамках культуры обучения мы все становимся работниками интеллектуальной сферы. В этой новой мировой теории управления элементы концепции X, скорее всего, приведут к дисбалансу организации.

В отличие от теории X, теория Y, по МакГрегору, – это мировоззрение, основанное на иерархии потребностей, описанной А. Маслоу. Теория Y предполагает, что безопасность и страх не являются единственной мотивацией сотрудников. Напротив, теория Y утверждает, что саморегуляция, ориентированность на большие задачи и желание усовершенствовать среду – вот истинные драйверы улучшения производительности, результативности и инноваций. Именно в ситуациях, когда организация объединяется вокруг ясной цели, саморегуляция способна обеспечить превосходную реализацию задачи. Самостоятельные работники захотят взять на себя личную ответственность за качество, сотрудничество, креативность и обучение.

Эта согласованность с задачей очень важна в мире подхода «почувствовать и отреагировать». Работники должны понимать задачу, осознавать, что она для них значит, и видеть, как их работа способствует ее достижению.

Предпочтение подходов в стиле теории Y широко распространено в мире программного обеспечения и отражено в Манифесте гибкой разработки ПО. Один из принципов Манифеста гласит: «Создавайте проекты в среде мотивированных людей. Дайте им пространство и поддержку, которые им нужны, и доверьтесь тому, как они выполнят свою работу»[83].

В начале 2000-х годов Nokia стояла на вершине мира мобильных телефонов. До появления смартфонов (первый iPhone был представлен в 2007 году) Nokia была бесспорным лидером. И все же компания потеряла свое могущество. Она не смогла эффективно среагировать на изменения на рынке, и всего через семь лет после выхода iPhone, в 2014 году, Nokia продала свой бизнес мобильных телефонов корпорации Microsoft. Однако этот бизнес продолжает испытывать трудности. К концу 2015 года на его долю приходился лишь 1 % мировых продаж смартфонов[84]. Что случилось?

В недавнем исследовании, проведенном Куи Хюи и Тимо Вуори, профессорами кафедры стратегии европейской бизнес-школы INSEAD, утверждается, что неудача коренится в «общих опасениях среднего и высшего звена менеджеров, [что] приводит к инертности всей компании и делает ее бессильной, неспособной реагировать на игру смены устройств компании Apple»[85]. Авторы исследования выявили модель, в которой «темпераментные лидеры и напуганные менеджеры среднего звена [боялись] говорить правду». В результате руководители организации не смогли составить точную картину реальности на рабочих местах. Менеджеры среднего звена либо молчали о плохих новостях, либо откровенно лгали руководству о состоянии работы.

В результате, слыша только хорошие новости, топ-менеджеры становились еще более требовательными с точки зрения технических амбиций и сроков представления продукта. Но эти требования были нереалистичными, поскольку команды были уже далеко позади рынка. В итоге качество продукции настолько упало, что Nokia, некогда техническому лидеру, пришлось прибегнуть к аутсорсингу для построения операционной системы смартфонов.

Древнегреческий драматург Софокл писал: «Не мил гонец с известием плохим». Мы знаем, что всегда можно обвинить «гонца». Правда, это годится только для того, чтобы «накормить» босса той информацией, которую он хочет слышать. Иногда так происходит с информационными потоками в наших организациях. Так, в Nokia это привело к тому, что Хюи называет «плюралистическим молчанием», когда никто не хочет говорить правду. Но если бы ее приняли, это могло бы спасти бизнес смартфонов компании Nokia. Чтобы процветать в эпоху информации, нам необходима сама информация. Таким образом, организации, которые придерживаются принципа прозрачности (честного обмена информацией), в итоге буду процветать.

Майк Блэнд, бывший сотрудник Google, а сейчас руководитель 18F, новой организации цифровых услуг при правительстве США, недавно высказался о важности прозрачности, основываясь на своем опыте сначала в Google, затем в правительстве. Блэнд описывает свои мотивы к созданию веб-информационного центра, который помогает сотрудникам 18F находить друг друга, узнавать, над чем работают коллеги, и делиться знаниями. Он пишет: «Мы считаем, что то, как мы работаем, так же важно, как и то, что мы производим для наших партнеров. Продукт является отражением процесса. 18F представляет собой пример открытой, процветающей, обучающейся организации, который члены других федеральных учреждений могут перенять для своих команд»[86].

Если вы долгое время работали в какой-нибудь организации, вы знаете, что существуют определенные темы, которые обсуждаются снова и снова. Иногда такие темы называют «религиозными войнами», потому что они обладают свойством постоянной борьбы, в которой каждая из сторон уверена в своей позиции. Когда в очередной раз поднимаются такие темы, менее фанатичные сотрудники возмущаются: «Ну вот, снова началось».

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

Неопределенность – наш враг и препятствие. Как мы уже выяснили, в эпоху информации мы не всегда можем точно предсказать, что повлекут за собой наши действия. Мы не можем применять методы ньютоновской математики, чтобы предугадать поведение наших программных продуктов. Вместо этого мы должны пробовать, тестировать идеи, исследовать. Короче говоря, чтобы двигаться вперед и добиться ясности, мы должны действовать. Один из принципов, который мы изложили в нашей книге Lean UX, состоит в том, что командам необходимо уделять пристальное внимание анализу. Мы призывали группы разработчиков что-нибудь делать (прототип, эксперимент, опросы клиентов), чтобы получить информацию, которую они упустили, а не для того, чтобы засесть в конференц-зале и обсуждать обоснованность идеи.

Такой же подход пригоден и на уровне управления. Поскольку ваша компания работает с изменениями в ответ на неопределенность, которую создают технологии, руководство должно сделать акцент на действие и эксперименты, которые генерируют информацию, необходимую для принятия решений.

Несколько лет назад исследователь дизайна Джаред Спул провел исследование команд, чтобы выяснить, как на успех продукта повлияло взаимодействие с клиентами. Согласно его исследованию, опубликованному в 2011 году, команды, которые общались с клиентами как минимум по два часа в течение шести недель из расчета на каждого члена команды, производили успешные продукты[87].

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

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

Иногда сопереживание к клиентам – это единственный шанс вашей компании сохранить сильные позиции на рынке перед лицом глобальной конкуренции. Вот с какой ситуацией Maxdome, немецкий сервис потоковой передачи видео, столкнулся в 2015 году. Перед Maxdome стояли две главные проблемы.

Первая заключалась в том, что немецкий рынок вообще скептически относится к сервису подписок. Вторая в том, что такие признанные лидеры, как Netflix и Amazon Prime, усиливали давление и стояли на пороге локальных запусков. Дочерняя компания немецкой медиакорпорации ProsiebenSat.1. Maxdome решила создать свой собственный сервис (а также культуру компании) с нуля.

Генеральный директор Maxdome Марвин Лэнг понимал, что он не сможет выиграть гонку против хорошо финансируемых соперников, Netflix и Amazon Prime[88], за счет функций. Итак, вместо того, чтобы дать своим командам список функций для разработки, Лэнг поставил перед ними стратегическую проблему – задачу: победить, став лучшими в категориях «находка видеоконтента» и «вдохновляющий контент». В этом состояла цель сервиса. Компания не станет измерять прогресс с точки зрения созданных функций. Контрольными показателями будут являться привлечение клиентов, использование ими сервиса и их удержание.

Чтобы понять, как выявить данные факторы, Лэнг поставил своим командам еще одну задачу: узнать своих клиентов. Он был уверен в том, что организация, которая понимает потребности, проблемные моменты и культурные причуды своих клиентов, непременно создаст превосходный сервис. «Мы, как команда управления, теперь всегда всех призываем проводить реальное клиентское тестирование по любым вопросам и ставить клиента на первое место, – сказал он нам. – Звучит очень просто, но на самом деле это не так». Лэнг использовал пять тактик, направленных на достижение этой цели.

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

Во-вторых, ежегодно во время праздничного сезона менеджеры Maxdome отправлялись продавать услуги компании на оживленных торговых улицах по всей Германии. Этот опыт является более передовым, чем ответы на телефонные звонки. Менеджеры не просто разбираются с жалобами клиентов; они активно пытаются убедить случайных прохожих приобрести услугу на месте. (На протяжении всей книги мы обсуждали важность двустороннего разговора с рынком. Иногда мы имели это в виду в метафорическом смысле, но в данном случае менеджеры должны были в буквальном смысле общаться со своими клиентами). Они пробуют на улице разные тактики продаж, чтобы понять, что работает, а что нет. Приемы и концепции, которые превращают незнакомцев на улице в клиентов, – это то, что менеджеры будут интегрировать в маркетинг и рекламу, а также в разработку продуктов в предстоящем году.

Третья инициатива Maxdome состояла в том, чтобы предоставить неограниченный бюджет для контакта с клиентом. Любой сотрудник организации может провести исследования пользовательского опыта клиентов, чтобы определить, как (или следует ли) дальше продвигать инициативу. Единственное требование заключается в том, чтобы информация, полученная в ходе этих исследований, была широко доступной и чтобы их результаты использовались при принятии решений. С тех пор, как Лэнг в 2015 году запустил данную программу, Maxdome проводит от 40 до 50 исследований в год.

В-четвертых, Maxdome запустил процесс, который называется «догфудинг», производное от фразы «не отведал сам кашу – не давай собаке нашей» (англ. «eating your own dogfood»). Эта практика обязывает сотрудников компании регулярно использовать сервис, который они создают, как базовый для своих нужд и развлечений в нерабочее время. Ничто и никто так не будет мотивировать менеджера команды на создание интуитивно понятной и удобной функции потоковой передачи видео, как его трехлетняя дочь, которая просит, чтобы папа скорее включил ее любимый мультфильм: ее не устраивает задержка для переключения в меню, медленно выдающего результаты поиска по скудному выбору контента.

Последняя инициатива Maxdome – передача знаний. Каждый месяц фирма проводит собрание всей команды, на которое приглашаются представители клиентов. Они обсуждают актуальные проблемы. Кроме того, Лэнг всегда демонстрирует короткие видеоролики, запечатлевшие менеджеров, отвечающих на звонки в колл-центре. Это помогает закрепить идею о том, что эмпатия является задачей всей компании.

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

Этот подход помог Maxdome в областях за пределами качества продукции. Не удивительно, что, когда люди ощущают себя способными выполнять более качественную работу, их удовлетворенность возрастает. Так было и в Maxdome. С момента запуска этих программ, сообщает Лэнг, число сотрудников, которые рекомендовали бы Maxdome в качестве работодателя, увеличилось вдвое, с 35 % до примерно 70 %.

В 1959 году музыкант Майлз Дэвис собрал свой секстет, чтобы записать новый альбом, который он назвал «Kind of Blue». Музыканты собрались, практически не имея представления о том, что они будут играть, да еще и без репетиций. Дэвис был на пике своей карьеры, но он разочаровался в бибопе, джазовом стиле, в котором играл в течение десятилетия. Он экспериментировал с новым стилем, модальным джазом, и в «Kind of Blue» он хотел отдаться ему без остатка.

В течение всего лишь двух дней группа записала то, что впоследствии стало самой продаваемой джазовой записью всех времен и что многие люди считают величайшей джазовой записью, созданной когда-либо. Один критик писал: «Kind of Blue – это не просто творческая вершина Майлза Дэвиса, это альбом, который превосходит все, что сделали конкуренты, а запись, которая считается решающим элементом джазового альбома, признана эталоном совершенства»[89]. Как такое стало возможным? Какую культуру создал Дэвис во время этих сессий, что позволило сотворить это чудо?

В своем выступлении на TED talk в 2011 году Стефон Харрис, известный джазовый музыкант, отметил, что «на сцене не бывает ошибок»[90]. Он сказал, что каждая сыгранная нота – это возможность продвижения «продукта» вперед в новом направлении, но только если вы слушаете то, что делают ваши коллеги по группе, и готовы ловить возможности, которые создает их исполнение. Харрис утверждает, что такое сотрудничество – способность слышать и готовность принять то, что создают ваши коллеги, – это то, что позволяет родиться джазовой импровизации.

Джаз – это импровизированная музыка. Ее нельзя предугадать, записать или подготовить заранее. Импровизированная музыка – это взаимодействие свободы и ограничений. Музыканты подчиняются определенным ограничениям – тональность, ритм, аккордовые последовательности, – которые объединяют их. Но также им свойственна свобода познания – принимать решения в рамках этих ограничений. Так называемые «ошибки» – это то, когда музыканты выходят за эти рамки. Они берут ноту вне заданной тональности или выбиваются из общего темпа. Чуткая, сотрудничающая группа может уловить этот момент и превратить его в возможность. Они принимают новую ноту, понимают, что она подразумевает переход в новую тональность, и решают двигаться в данном направлении.

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

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

Один из секретов, который делает сотрудничество таким могущественным, заключается в том, что оно объединяет людей с разными точками зрения и разными навыками для совместной работы над проблемой. Конечно, то, что делает разнообразие столь мощным инструментом, может также служить поводом для конфликта: разные люди следуют разным ценностям, делают разные предположения, имеют разные предвзятости и предрассудки и представляют разные знания. Чтобы превратить этот микс в продуктивную команду, вам необходимо обрести какую-то общую цель и создать атмосферу доверия.

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

Иногда мы забываем о важности социальных связей, но они обязательно возникают, когда речь идет о творческих коллективах. В недавней статье о создании продуктивных дизайн-студий дизайнеры Рис Ньюман и Люк Джонсон изложили пятнадцать правил для хорошей дизайн-студии, и многие из них касаются создания хороших социальных связей в команде. Например, говорите «доброе утро» и «хорошего вечера» – и это уже начало строительства доброжелательной социальной культуры. Больше смейтесь, чтобы снизить конфликтность и сблизить людей. Обедайте вместе, чтобы ослабить напряжение. Будьте чутки и человечны. Общайтесь лично, вдохновляя к доверию и открытости. Рассказывайте о личном, делитесь семейными историями, раскройте свои интересы – и вы будете видеть друг друга более человечными. Это отличные приемы, которые подойдут для любой команды, не только для дизайн-студий, поскольку они создают атмосферу, в которой возможно сотрудничество[92].

Как вы меняете культуру? Это вопрос, на который нет простых ответов, а также тема нескончаемых дебатов для менеджеров, консультантов и экспертов. Мнений множество. «Культура – это общение», – заявляет эксперт. Другой считает: «Культура – это то, что вы делаете, а не то, что вы говорите». А третий утверждает: «Культура – это то, чем вы занимаетесь, когда рядом нет генерального директора». В какой-то степени все они правы – эти идеи не конфликтуют между собой, а отражают различные части одного целого. Формирование культуры, как и многое из того, о чем мы говорим в этой книге, полно неопределенности.

Итак, с чего вы начинаете? Мы думаем, что важным первым шагом является принятие идеи о том, что культура, как и все остальное, находится в постоянном состоянии изменений. Шани Хилтон, заместитель главного редактора BuzzFeed, сказала журналисту: «Мы все еще находимся в состоянии поиска. Мы в стадии изменений, мы привыкли к этому, и мы согласны с этим. Чем крупнее мы становимся, тем сложнее заставить людей понять, что мы не должны делать что-либо так, как мы делали это последние полгода»[93].

А Джон Бортвик, венчурный капиталист и предприниматель, который управляет компанией Betaworks, инновационным инкубатором в Нью-Йорке, выразился следующим образом: «Каждое изменение, каждое нововведение считается новой нормой, новым устойчивым состоянием, когда на самом деле новая норма – это состояние постоянных инноваций»[94].

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

Иначе говоря, необходимо инициировать культурные изменения. Принятие изменений в качестве культурной ценности начинается на самых высоких уровнях организации – с проявлений прозрачности и сдержанности на уровне управления и топ-менеджеров. Это влияет на то, как мы строим наше общение с сотрудниками, и отражается в том, как мы выстраиваем отношения в организации. Вот, к примеру, видение Дина Баке, главного редактора New York Times, планов на будущее отделов новостей:

Так много из того, что мы обсуждали в этой главе, отражено в данной записке. Готовность экспериментировать. Открытость для дискуссий. Акцент на сопереживание. И принятие непрерывных изменений.

Культура распространяется не только сверху. Нельзя навязывать культуру организации, по крайней мере без нанесения значительного ущерба. Основатель Zappos, Тони Шей, пытался это сделать в 2015 году, заставив 140 своих сотрудников принять холакратию – стиль управления, который исключает менеджеров из процессов в пользу автономных коллективов. Шей заявил тогда, что любой, кто не хочет работать в новой системе, может взять выходное пособие и уйти. Судя по некоторым опубликованным отчетам, примерно 18 % работников приняли это условие, но многие из тех, кто решил остаться, испытывали моральные трудности и ощущение предательства[96].

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

Келлан Эллиот-Маккри в том эссе, которое мы цитировали ранее, пишет: «Вы строите культуру обучения, оптимизируя глобально, а не локально. Ваш общий прогресс, как и команда с общими инструментами, приемами и убеждениями, является более важным, чем отдельные очаги гениальности. Это наиболее оптимально». Он указывает, что непрерывное совершенствование – это не заслуга одного человека. И не ответственность одного отдела. Это должно стать общим приоритетом организации.

✓ Подходы «почувствовать и отреагировать» касаются не только изменений процесса. Они в равной степени утверждают и культуру обучения.

✓ Ключевыми элементами культуры обучения являются сдержанность, разрешение на провал, саморегуляция, прозрачность, акцент на действие, эмпатия и сотрудничество.

✓ Менеджеры должны следовать этим ценностям и поддерживать их появление в организации.

✓ Изменение культуры полно неопределенности. По сути, культура является продуктом постоянного диалога вашей организации с самой собой и о себе. Поэтому подходите к нему с позиций подхода «почувствовать и отреагировать». Наблюдайте за тем, что работает, совершенствуйте это и не бойтесь экспериментировать.