со сложностями и, соответственно, иным уровнем неопределенности. Сложно предсказать, как группы людей будут использовать эти системы и, как следствие, какие части системы они посчитают ценными.
Рассмотрим явление хештега. Это вездесущее средство пометки контента и бесед в интернете, пришедшее от пользователей Twitter в 2007 году в качестве способа связывать беседы друг с другом. Эта функция не была запланирована или введена Twitter. Скорее, пользователи системы начали отмечать свои разговоры ключевыми словами, которые они отправляли с помощью ведущего (хеш) символа – «#». Этот метод стал популярным среди пользователей, поскольку они могли договориться о теге, а затем использовать обычную функцию поиска в Twitter, чтобы найти все твиты с этим тегом. Другими словами, это способствовало появлению ценности и распространенности. Только два года спустя, в 2009 году, Twitter отреагировал на это, добавив функцию, которая относилась конкретно к хештегам, в систему. Twitter автоматически вставил гиперссылки во все теги, и, кликая по этим ссылкам, теперь можно было возвратиться к результатам по этому тегу[10].Теперь Twitter превратил хештег в доходный продукт: вы можете заказывать рекламу, которая использует конкретные хештеги для целевых аудиторий.
История о хештегах – это пример того, как компания реагирует (хоть и с опозданием) на непредсказуемое поведение своих пользователей таким образом, что притягивает их и создает ценность. Когда мы можем понять то, что хотят пользователи, у нас появляется основа для создания сервиса, что создает ценность для бизнеса.
Но компании, которые не готовы отреагировать на непредсказуемое поведение пользователей, сталкиваются с большими проблемами. В уже упоминавшемся примере с BBC Digital Media Initiative управляющие технологическим процессом менеджеры жаловались, что одна из причин неудачи проекта заключалась в том, что пользователи постоянно меняют требования к системе. Это распространенная претензия в мире технологий: одни указывают на непостоянство пользователей, другие обвиняют технологов в том, что те не реагируют на изменения. Реальность более коварна. Хотя тщательное изучение и анализ потребностей пользователей являются важными и ценными атрибутами, этого не всегда достаточно. Зачастую требования не могут быть известны заранее, и, как только систему запускают, обнаруживаются новые потребности, создающие новые требования.
И снова эта неопределенность в работе. Как показывает история с хештегом, если компании открыты для неопределенности, они могут почерпнуть в непредсказуемое поведении пользователей новые идеи. Если они могут отреагировать соответствующим образом, это явление – непредсказуемое поведение – превращается в непредсказуемую ценность. С другой стороны, когда компании пытаются прогнозировать будущее и отвергают возникающую реальность, пробел между планами и реальностью, вероятно, приведет к разочарованию, задержке и провалу проекта.
Хотя адекватно реагировать непросто. От руководителей требуется принятие нового мышления и готовность корректировать планы в ответ на новую информацию. Это новое мышление включает в себя принятие постоянных изменений и неопределенности, поиск обратной связи с рынком и готовность рассматривать эту обратную связь как потенциал для создания новых ценностей. Иначе говоря, лидерам нужно сказать: «Я не знаю ответа. Давайте узнаем его вместе».
Адаптация к сложным обстоятельствам
Для типичного лидера XX века фраза «я не знаю» была табуированной. Признание в неуверенности (самому себе или другим) воспринималось как признак слабости. Этот способ мышления остается распространенным во многих организациях и представляет особую проблему, когда дело касается поиска возникающей ценности в сложных адаптивных системах: систем с большим количеством компонентов, которые ведут себя и взаимодействуют таким образом, что прогнозирование становится невозможным. В нашем контексте это системы, в которых невозможно точно предсказать, как люди будут с ними взаимодействовать и какие функции они будут использовать.
В статье в Harvard Business Review Дэвида Сноудена и Мэри И. Бун описывается, чем эти системы отличаются от механических систем индустриальной эпохи:
«Это как разница между, скажем, автомобилем Ferrari и бразильскими тропиками. Автомобили Ferrari – сложные машины, но опытный механик может разобрать одну из них и снова собрать, ничего при этом не изменив. Автомобиль статичен, а целое – это сумма его частей. С другой стороны, тропики находятся в постоянном потоке – какие-то виды вымирают, погодные условия меняются, сельскохозяйственный проект перенаправляет источник воды, и вся их совокупность – это намного большее, чем просто сумма их частей. Это область «неизвестные неизвестности», в которую переместилась большая часть современного бизнеса.»[11]
Не принимая неопределенность, вы не можете извлечь выгоду из нее. Поэтому многие компании идут по пути запуска перманентных, небольших, оперативных экспериментальных циклов, что и составляет суть подхода «почувствовать и отреагировать». Непрерывно внося небольшие изменения и оценивая результаты, команды в процессе работы находят тот метод, который теоретики, описывающие поведение сложных систем, рекомендуют для работы с этими непростыми комплексами.
СРАВНЕНИЕ СТАРОЙ МОДЕЛИ С ПОДХОДОМ «ПОЧУВСТВОВАТЬ И ОТРЕАГИРОВАТЬ»
С началом цифровой революции, привнесшей новые уровни сложности и неопределенности, большинство компаний пытались управлять ею, используя методы индустриальной эпохи, которые до того момента хорошо со всем справлялись. Используя аналогию Сноудена и Бун, мы представляли программное обеспечение чем-то вроде Ferrari. Мы не изменили проверенные методы и, конечно же, не рассматривали вопрос об изменении способа ведения нашего бизнеса с учетом новых реалий.
Однако по мере того, как мы становились все более опытными в использовании программ, мы научились лучше управлять компанией. Наши подходы – agile-методики, которые стали использоваться повсеместно, – позволили нам начать относиться к программному обеспечению больше как к тропикам. Наш процесс управления программным обеспечением теперь, скорее, лесоводство, нежели инженерия.
Теперь мы готовы сделать следующий шаг. Поскольку мы осознаем растущую зависимость от программных систем и серьезность того, как цифровая революция связала наши предприятия с остальным миром через эти системы, мы должны начать управлять нашими компаниями с помощью методов, которые мы применяем в программном обеспечении. Другими словами, если когда-то мы управляли своими программами так же, как компаниями, теперь необходимо управлять своими компаниями так же, как мы управляем нашим программным обеспечением.
ПОНИМАНИЕ НЕПРЕРЫВНОГО РИТМА АВТОНОМНЫХ ГРУПП
Чтобы работать в этом новом, непрерывном ритме, команды должны быть свободны. Они должны свободно экспериментировать и обучаться. Это означает, что командам нужно предоставить больше полномочий для принятия решений. Подход сборочной линии индустриальной эпохи стремился отделить интеллектуальный труд (область управления) от физического (область рабочего). Он пытался превратить рабочих в сборочные машины. Но люди не машины, и процесс выявления потребностей рынка и быстрого реагирования не вписывается в такого рода подход, направленный на минимизацию самостоятельного мышления и принятия решений. В этом новом мире стало меньше решений, которые могут быть спущены «сверху» «вниз» и вписаны в размеренный рабочий поток. Теперь многие решения должны приниматься «снизу» «вверх» людьми, которые имеют опыт работы с данными и доступ к самой последней информации. Эти люди
