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