• Подвергайте все сомнению. Мне очень нравятся «глупые» вопросы. На самом деле они касаются настолько основополагающих вещей, что ответ, кажется, лежит на поверхности. Но если принять их всерьез, часто оказывается, что вопрос на самом деле очень глубокий: очевидное совсем не всегда оказывается таким уж очевидным. Что-то кажется нам ясным просто потому, что так было всегда, но, когда мы ставим это под сомнение, оказывается, что мы не понимаем, почему было так. Очень часто именно такие «глупые» вопросы, заставляющие нас подвергать сомнению очевидное, помогают найти решение проблемы.
Единственный способ узнать, разумна ли идея, — проверить ее, создать быстрый прототип, или макет, каждого возможного решения[55]. На ранних стадиях такого процесса это могут быть наброски, модели из пенопласта и картона или простые изображения, выполненные с помощью обычных графических программ. Я делал макеты в виде таблиц, слайдов PowerPoint, а также эскизов на карточках или стикерах. Иногда идеи лучше всего передавать с помощью скетчей, особенно если вы разрабатываете сервисы или автоматизированные системы, которые трудно прототипировать.
Одна из популярных техник прототипирования называется «Волшебник из страны Оз» в честь классической книги Франка Баума (и ставшего классическим фильма)[56]. Волшебник на самом деле был обычным человеком, но с помощью спецэффектов ухитрялся казаться таинственным и всемогущим. Другими словами, он был подделкой: у волшебника не было никаких особых магических сил.
Метод «Волшебник из страны Оз» можно использовать для имитации огромной, мощной системы задолго до того, как она будет построена. Он крайне эффективен на ранних стадиях совершенствования продукции. Я когда-то использовал этот метод для тестирования системы бронирования авиабилетов, которая была спроектирована исследовательской группой в центре Пало-Альто корпорации Xerox (сегодня это просто исследовательский центр Пало-Альто, или PARC). Мы приводили людей в мою лабораторию в Сан-Диего по одному, усаживали их в маленькой изолированной комнате и заставляли вводить в компьютер свои требования к туристической поездке. Они думали, что взаимодействуют с автоматизированной программой, разработанной для помощи в организации путешествий. На самом деле в соседней комнате сидел один из моих аспирантов, который читал набранные запросы и набирал ответы (при необходимости просматривая реальные графики перелетов). Эта симуляция позволила нам многое узнать о требованиях к такой системе. Например, мы узнали, что запросы людей сильно отличаются от тех, которые мы разработали в качестве ответов системы. Например, один из выполнявших задание попросил билет туда и обратно из Сан-Диего в Сан-Франциско. После того как система определила нужный рейс в Сан-Франциско, она спросила: «Когда вы хотели бы вернуться?» Человек ответил: «Я бы хотел лететь в следующий вторник, но мне бы хотелось прилететь до занятий, которые начинаются в девять утра». Таким образом, мы поняли, что недостаточно просто понимать предложения: система также должна была решать проблемы, используя пространные знания о таких вещах, как аэропорт, места встречи, схемы движения, задержки на получение багажа и аренду автомобилей и, конечно, парковки — это существенно превышало способности системы. Наша первоначальная цель состояла в том, чтобы она понимала язык. Исследования показали, что цель была слишком узкой: система должна была понимать деятельность людей.
Прототипирование на этапе спецификации проблемы выполняется главным образом для того, чтобы убедиться, что проблема понята верно. Если целевая аудитория уже использует нечто связанное с новым продуктом, это нечто уже можно считать прототипом. На этапе проектирования решения задачи применяют реальные прототипы предлагаемого решения.
