Текст книги "Чувствуй и реагируй. Как создавать продуты, нужные людям именно сейчас"

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

ОЦЕНКА ДВИЖЕНИЯ DEVOPS: ТЕХНИЧЕСКАЯ ОСНОВА ПОТОКА

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

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

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

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

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

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

ПОНИМАНИЕ ТОГО, ЧТО ПОТОК ЯВЛЯЕТСЯ НЕ (ПРОСТО) ТЕХНИЧЕСКОЙ ПРОБЛЕМОЙ

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

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


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

«КУЛЬТУРА ОБСЛУЖИВАНИЯ» НЕ СОЗДАЕТ ДВУСТОРОННИЙ РАЗГОВОР. ЭТО УСТАРЕВШИЙ И РИСКОВАННЫЙ СПОСОБ РАБОТЫ В МИРЕ, УПРАВЛЯЕМОМ ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ.

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

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

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

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

КОНТРОЛЬ ОПЫТА КЛИЕНТОВ: НАБЛЮДАЙ И ЧУВСТВУЙ

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

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

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

КОНТРОЛЬ ОПЫТА КЛИЕНТОВ: ФУНКЦИИ И ЭКСПЕРИМЕНТЫ

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

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

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

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

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

СОЗДАНИЕ «ПЕСОЧНИЦЫ»: БЕЗОПАСНОГО МЕСТА ДЛЯ ИГРЫ

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

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

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

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

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

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

УПРАВЛЕНИЕ ЗА ПРЕДЕЛАМИ БЮДЖЕТА: ДАЖЕ ПЛАНИРОВАНИЕ ЯВЛЯЕТСЯ НЕПРЕРЫВНЫМ

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

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

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

Команда международного «Института внебюджетного финансирования», работающая над изменением моделей корпоративного управления, утверждает, что годовой бюджетный цикл глубоко ущербен. Какую проблему они считают «номером один»? «Бюджетирование препятствует быстрому реагированию. [Компаниям] нужно быстро реагировать на непредсказуемые события, но годовой бюджетный процесс никогда не соответствовал данной цели»[74]74
  Beyond Budgeting Institute, accessed September 1, 2016, http://www.beyondbudgeting.org/beyond-budgeting/bb-problem.html.


[Закрыть].

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


[Закрыть].

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

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

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

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

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

ВО ИЗБЕЖАНИЕ СИНДРОМА БЛЕСТЯЩЕГО ОБЪЕКТА: ПОДХОД «ПОЧУВСТВОВАТЬ И ОТРЕАГИРОВАТЬ» И НЕПРЕРЫВНЫЙ МАРКЕТИНГ

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

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

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

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

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

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

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

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

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

ПРЕДОСТАВЛЕНИЕ ЧЕГО-ЛИБО НА ПРОДАЖУ

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

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

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

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

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

ОТКАЗ ОТ ПРОЕКТОВ: НЕПРЕРЫВНЫЙ ПОТОК И УПРАВЛЕНИЕ ПРОЕКТАМИ

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