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