Неслучайная случайность. Как управлять удачей и что такое серендипность

Сакити Тоёда, основатель Toyoda Automatic Loom Works (его сын Киитиро основал автомобильный отдел, который под названием Toyota Motors вошел в число крупнейших мировых производителей) и ключевая фигура японской промышленности ХХ столетия, создал подход, известный как «пять почему». Мир сильно изменился, и в некоторых аспектах этот подход устарел, но основной его принцип по-прежнему полезен. Тоёда установил, что, столкнувшись с трудностями, следует пять раз задать вопрос «Почему?» – и вы доберетесь до первопричины проблемы. Каждый вопрос заставляет погрузиться в проблему все глубже, но первопричина, а следовательно, и решение часто обнаруживается только на последних этапах.

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

Чего вы хотите?

Размышляя над решением проблем, мы обычно мыслим линейно[77]. Не так важно, что перед нами – рабочая задача, учебная или домашняя проблема или что-либо еще, – обыкновенно мы разделяем это на несколько этапов и действуем в определенном порядке:

1. Определить и сформулировать проблему/потребность.

2. Попытаться решить ее:

a) либо сосредоточившись на решении конкретной проблемы;

б) либо постепенно переопределяя или заново формулируя проблему по мере поступления новой информации[78].

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

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

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

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

Однако не все вопросы разрешаются так легко. Американский ученый Герберт Саймон выделил два основных вида проблем: «хорошо структурированные» и «слабо структурированные»[81]. Хорошо структурированные проблемы – то есть те, которые можно четко разграничить, – могут быть решены при помощи алгоритмов и процедур, описанных выше в медицинском примере[82]. И все же этот невероятно эффективный метод решения задач далеко не так хорош для решения слабоструктурированных проблем, которые часто невозможно четко определить – по крайней мере поначалу. А еще он может ограничить серендипность. Недавние исследования показали, что если вы определяете проблему слишком узко, то сразу ограничиваете поле возможных ответов и можете просто не найти тот ответ, который являлся бы и ценным, и творческим[83].

Есть и другая причина того, что слишком конкретный вопрос порой не позволяет обнаружить наиболее эффективное решение (или даже не одно). Человек или организация, столкнувшиеся с проблемой, редко могут предоставить всю возможную информацию о том, что им действительно нужно. Часто по мере изучения вопроса появляются новые данные[84]. Это становится настоящей проблемой в случае, когда тот, кто формулирует проблему, и тот, кто ее решает, разделены, например, организационными преградами. В этом случае тем, кто ищет решение, недоступна возможность увидеть другие потенциальные потребности или проблемы, и находить лучшие решения становится намного сложнее. Как часто вы могли наблюдать, как IT-отдел компании решает проблему, но при этом накладывает раздражающее ограничение на то, как вы можете работать, или даже создает совершенно новую проблему? И дело здесь не в том, что специалисты работают плохо, – просто тем, кто должен решить проблему, слишком сузили задачу и не позволили взглянуть на картину целиком.

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

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

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

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

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

Подобные подходы все чаще выходят на первый план, и их продвигают такие организации, как дизайнерская группа IDEO. Метод разработки идей, известный под названием быстрое прототипирование, заключается в том, что разработчик, решая изначальную задачу, создает легкомодифицируемую и недорогую рабочую модель. Затем пользователи испытывают прототип и собирают данные о том, насколько хорошо он работает. Далее вносятся изменения в некоторые характеристики, новую модель возвращают дизайнеру или разработчику, и вскоре создают усовершенствованный прототип[85]. А потом цикл начинается снова – настолько быстро, насколько это возможно.