Однако не все вопросы разрешаются так легко. Американский ученый Герберт Саймон выделил два основных вида проблем: «хорошо структурированные» и «слабо структурированные»[81]. Хорошо структурированные проблемы – то есть те, которые можно четко разграничить, – могут быть решены при помощи алгоритмов и процедур, описанных выше в медицинском примере[82]. И все же этот невероятно эффективный метод решения задач далеко не так хорош для решения слабоструктурированных проблем, которые часто невозможно четко определить – по крайней мере поначалу. А еще он может ограничить серендипность. Недавние исследования показали, что если вы определяете проблему слишком узко, то сразу ограничиваете поле возможных ответов и можете просто не найти тот ответ, который являлся бы и ценным, и творческим[83].
Есть и другая причина того, что слишком конкретный вопрос порой не позволяет обнаружить наиболее эффективное решение (или даже не одно). Человек или организация, столкнувшиеся с проблемой, редко могут предоставить всю возможную информацию о том, что им действительно нужно. Часто по мере изучения вопроса появляются новые данные[84]. Это становится настоящей проблемой в случае, когда тот, кто формулирует проблему, и тот, кто ее решает, разделены, например, организационными преградами. В этом случае тем, кто ищет решение, недоступна возможность увидеть другие потенциальные потребности или проблемы, и находить лучшие решения становится намного сложнее. Как часто вы могли наблюдать, как IT-отдел компании решает проблему, но при этом накладывает раздражающее ограничение на то, как вы можете работать, или даже создает совершенно новую проблему? И дело здесь не в том, что специалисты работают плохо, – просто тем, кто должен решить проблему, слишком сузили задачу и не позволили взглянуть на картину целиком.
Например, вы могли дать IT-команде следующий бриф: «Нам нужно, чтобы команда A могла читать файлы типа X». Несомненно, IT-специалисты решат эту задачу. Но, возможно, команде A необходимо еще и редактировать эти файлы, а новое решение не позволяет этого. Или же, наоборот, было важно, чтобы команда A не могла ничего менять, а теперь у нее есть доступ. И так далее.
Такой неразберихи можно было избежать, вовлекая IT-отдел в процесс решения проблемы (например, в обсуждение первопричины) вместо требования выполнить слишком узкую задачу. Только в этом случае IТ-отдел сумел бы разработать действительно эффективное решение.
То же самое относится к любому человеку или организации: слишком конкретное определение проблемы ограничит круг возможных решений и уменьшит вероятность серендипного исхода. Обычно определение проблемы значительно сужается, если изначально вы приложили много усилий, чтобы понять, в чем именно заключается эта проблема. Это может сработать, если проблема хорошо структурирована, но в быстро меняющейся и неопределенной ситуации (например, в стартапе) важные проблемы или задачи вряд ли будут настолько простыми.