ГЛАВА ПЯТАЯ

ОТКУДА БЕРУТСЯ ИДЕИ

Как ни удивительно, идеи берутся от людей. Ни одна идея в истории человечества не родилась в груде валунов, теплой луже навоза или куче веток. Ни одна книга по самосовершенствованию, креативный семинар или мозговой штурм сами по себе не производят идеи. Их создают люди, хотя и с помощью этих инструментов. Следовательно, на проектах именно ваши сотрудники — а не процессы, методологии или комитеты — предлагают идеи и придумывают способ их использовать.

Это значит, что в идеях нет ничего волшебного. Все мы способны их придумать (хотя одним это удается лучше, чем другим). Никогда не забывайте, что одна из фундаментальных черт человека и других существ — использовать свои творческие способности для решения проблем, с которыми они сталкиваются в этом мире. Мало где учат, как применять эти умения, но мы ими обладаем. Наш вид до сих пор жив в основном благодаря тому, что мы умеем находить выход из различных ситуаций и изобретать инструменты и стратегии, которые помогают нам преодолевать трудности. (Хотя напрашивается вопрос: не создает ли характер применения нашего изобретательского таланта — по крайней мере, в XXI веке — больше проблем, чем решают наши изобретения?)

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

В основном я буду использовать этап проектирования (). Это период после составления общего плана проекта (видения) и до начала реализации. Если вы организовали проект иначе, ничего страшного — эта глава все равно вам пригодится. Мои советы легко применить к любой ситуации, которая требует решения проблем или генерации идей.

ПРОПАСТЬ МЕЖДУ ТРЕБОВАНИЯМИ И РЕШЕНИЯМИ

По непонятным мне причинам многим людям с трудом дается креативная работа. В большинстве книг о разработке ПО и проект-менеджменте мало внимания уделяется тому, как от списка требований дойти до формулировки грамотных проектных решений. Графики зачастую указывают даты формулировки требований и спецификаций, однако нет никаких инструкций о том, что должно происходить между ними (рис. 5.1).

Возможно, такой подход вполне приемлем, если работа представляет собой поэтапный, прямолинейный и простой процесс. Неоднозначность этого периода нивелируется простотой креативного задания, которое нужно выполнить. В любой другой ситуации, если команда не понимает, как проектировать продукт, она обречена на провал . Если проблемы сложные, ей нужно время, чтобы сравнить разные подходы и найти лучший из них, прежде чем сделать окончательный выбор.

Подобно путнику в тумане, если вы знаете, куда хотите попасть («Домой, пожалуйста»), это еще не значит, что вы знаете, какой путь выбрать («Все три дороги, по крайней мере, с моего ракурса, выглядят одинаковыми»). Опытные путешественники всеми силами стараются не попасть в тупик. К примеру, они пройдут небольшое расстояние по каждой дороге или найдут другой ракурс (холм, гору, геоцентрический орбитальный спутник-шпион на пульте управления), который даст им больше информации. Чем больше расстояние, которое нужно пройти, тем больше времени нужно потратить на его изучение.

Есть два простых способа «разведать территорию» — качественные требования и проектные исследования. Поскольку они тесно связаны, то часто пересекаются.

КАЧЕСТВЕННЫЕ ТРЕБОВАНИЯ И НИКАКИХ ОШИБОК

В  я кратко объяснил требования и их роль в процессе планирования. Грубо говоря, качественные требования эффективно отражают потребности клиента и / или его задачи по проекту, причем они достаточно ясные и понятные, чтобы их мог использовать любой, кто занимается этой работой. Хорошие требования, может, и не подсказывают, как решить проблему; однако они обозначают ее настолько четко и понятно, что человек, обладающий необходимыми навыками и знаниями, сможет со всей уверенностью найти решение. Большинство софтверных и проектных команд используют хотя бы неформальный процесс, иногда предельно простой — например, отправляют по электронной почте список с требованиями (по одному предложению на каждое).

Требования критически важны. Они служат отправным пунктом для генерации идей и потенциальных решений. Если требование гласит: «Нужен сарай, и он должен быть зеленым», — то все, кто занимается проектированием, представят себе самые разные типы зеленых сараев. Это полезно в двух смыслах. Во-первых, потому что сразу исключает из рассмотрения многие идеи (если кто-то сделает набросок голубого космического корабля, сразу будет понятно, что изображено не то). Во-вторых, позволяет проектировщикам задавать вопросы, чтобы уточнить требования. Проектировщик может задавать вопросы более низкого уровня, например: «Лаймово-зеленый допустим или только темные оттенки зеленого?» или «Какого размера должен быть сарай?»; или вопросы более высокого уровня, например: «Для чего будет этот сарай использоваться? Может, устроить сеновал? Это дешевле и больше подойдет для ваших нужд». В зависимости от того, кто отвечает за требования и проектирование (), разные люди влияют на то, как ответить на эти вопросы или какие изменения внести в них. Однако следует поощрять всех участников спрашивать и анализировать требования — это улучшает качество последних.

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

• Составьте план по обсуждению требований и итераций. Велика вероятность того, что некоторые из вопросов, которые зададут проектировщики, заставят переосмыслить требования. Необходимо запланировать подобную возможность и либо начать обсуждение с проектировщиками как можно раньше, чтобы успеть внести по­правки, либо оставить время для их внесения на более поздних этапах, после того как будут предложены стоящие идеи. Чем больше мы нацелены на решение конкретных проблем, а не на способы решения, тем меньше поправок придется вносить.
• Отследите ошибочные предположения. Зачастую требования предполагают, что клиент или пользователь нуждается в том, что на самом деле ему совершенно не нужно. Чтобы этого избежать, фанатично задавайте уточняющие вопросы: «Зачем это?», «Какую проблему это решает?» и «Чье это требование?» — чтобы вывести все предположения и допущения на чистую воду. Помните: всегда есть вероятность того, что кто-то случайно не так понял фразу или без всякого злого умысла внес ошибочные сведения.
• Ищите недостающую информацию. Самые вопиющие ошибки в требованиях связаны с упущением, частичным или полным. Частичное упущение означает нехватку какого-либо одного аспекта требования (например, не обозначен формат поля даты, хотя само оно указано) или отсутствие всего требования (сайт должен быть на греческом языке и поддерживать Firefox 1.0). Недостающая информация может означать две совершенно разные вещи: либо клиенту безразличен этот аспект проблемы, либо он важен, но клиент или не вспомнил о нем, или забыл записать. Как и с ошибочными предположениями, задача МП — отметить фрагменты недостающей информации и проверить, с чем именно связано их отсутствие.
• Определите относительные приоритеты по каждому требованию. Хотя все сведения кажутся нам значительными, необходимо указать степень важности каждого. После этого будет намного проще провести переговоры между теми, кто составлял требования, и теми, кто займется проектировкой (подробнее — в ).
• Исправьте или вычеркните ненамеренные двусмысленности. Такие слова, как быстрый, большой, маленький, приятный, симпатичный и применимый, нуждаются в уточнении. Их можно оставить без изменений, если все, кого касаются требования (клиент, босс, программист и т. д.), готовы обсудить спорные моменты позже. В иных случаях есть вероятность, что каждый автор требований использует двусмысленные выражения намеренно. Пограничные случаи («Наша домашняя страница должна загружаться в Firefox как минимум так же быстро, как ) — зачастую простейший способ разрешить двусмысленные требования. Как в этом примере, абсолютные требования (должен) и желательные требования (прекрасно, но можно обойтись и без этого) легко определить.

Возьмем одну формулировку проблемы из глав 3 и 4 и посмотрим, как написать качественные требования.

Большинство пользователей смогут быстро прочитать результаты поиска. Приоритет 1. Наша цель — поэтапно улучшать простоту применения поисковой системы. Мы перепроектируем страницу результатов поиска с учетом пяти основных жалоб клиентов и пяти основных проблем, выявленных в ходе исследования простоты использования существующего дизайна. Новая страница станет единой для отображения результатов поиска, введенного во все основные поисковые поля (панель навигации, домашняя страница, корзина) и, при разумных расходах, во все остальные поля.

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

ПРОЕКТНОЕ ИССЛЕДОВАНИЕ

Теперь, когда мы договорились, что требования важны, можно обсудить, как исследовать идеи, на которые они опираются.

После готовности требований проектировщики смогут исследовать обозначенную территорию. Есть огромная территория под названием «область проблемы», где полно потенциальных решений любой задачи. К примеру, есть бесконечное количество способов спроектировать дом, приготовить блюдо, построить систему, сайт или любой продукт, за который вам платят. Итак, пока вы не получите примерное представление о возможностях (ведь вы уже исследовали эту территорию раньше), неразумно воплощать в жизнь какие-либо конкретные решения. Первые идеи, которые придут вам в голову, вряд ли будут блестящими: вы же все еще изучаете область проблемы и пытаетесь составить общее представление о возможных вариантах.

Рисунок 5.2 иллюстрирует область решения проблемы, обозначенную в требованиях. Когда проектировщик приступает к изучению идей, удовлетворяющих этим требованиям, область проблемы начинает расти. Так происходит потому, что на раннем этапе каждый вопрос, каждая схема или модель открывают больше решений и возможностей, чем можно было разглядеть раньше. К примеру, требования утверждают: «Сайт должен предоставить возможность полнотекстового поиска со всех страниц», — однако не уточняется, какой поисковик следует использовать, как его сконфигурировать и как интегрировать его пользовательский интерфейс в сайт. Кому-то придется изучить разные возможности — а их будет много. (Хотя проблемная область в итоге сузится; мы поговорим об этом в следующей главе.)

В зависимости от сути требований границы проблемной области могут быть самыми разными. Если вам выделена только одна неделя на изучение альтернативы, а стоимость готового изделия всего $10, проблемная область узкая. Возможности проектировщика весьма ограничены. По сути, можно даже составить требования, которые вообще невозможно удовлетворить (например, создать вечный двигатель или решить NP-полные задачи за полиномиальное время). Время, бюджет, знания и конкретные критерии проектирования — все это влияет на масштабы и формат области решения проблем. Отчасти именно поэтому определение требований оказывает такое сильное влияние на процесс проектирования.

Это также объясняет, почему между проектированием и требованиями должна быть обратная связь. Если окажется, что некоторые запросы невозможно удовлетворить, учитывая ограничения проблемной области, должен быть способ скорректировать их. Или же, если проектировщик найдет фантастическую идею, которая отвечает задачам проекта, но требует корректировки требований, то в интересах клиента и бизнеса рассмотреть такую возможность.

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

СТРАХ И ПРОГРЕСС

Возможно, многие пропускают процесс проектирования, потому что боятся исследовать, особенно когда за ними кто-то наблюдает. Когда мы исследуем собственную работу (допустим, пытаемся оптимизировать алгоритм или совершенствовать документ), этот процесс никто, кроме нас, не видит, и мы вполне можем опробовать довольно странные идеи. Но когда проектирование становится запланированной работой команды, исследования каждого сотрудника видны остальным. Все скетчи или прототипы, которые он делает, придется показывать коллегам и открыто обсуждать. Если люди не доверяют друг другу и боятся критики, не удивительно, что этот процесс их пугает .

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

В целом, на мой взгляд, креативная работа — будь то строитель­ство мостов, проектирование космических кораблей или сайтов — несет в себе немало стереотипов. Менеджеры и лидеры должны первыми отказаться от этих шаблонов. Если говорить о поиске идей, два худших стереотипа отражены в следующих роковых фразах: «Плохих идей не бывает» и «Нужно мыслить нестандартно». Мы обсудим ошибочные постулаты, на которых основаны эти фразы, и сформулируем довольно простые подходы к креативу и поиску идей.

ПЛОХИЕ ИДЕИ СУЩЕСТВУЮТ

Не знаю, откуда взялась фраза «Плохих идей не бывает», но уверен, что это заблуждение. Я слышал ее в телерекламе и на мозговых штурмах. Эта красивая фраза призвана помешать людям фильтровать идеи слишком активно в ходе креативного процесса — поистине благородная цель! Но если применять ее к ситуации, связанной с решением проблемы, фраза оказывается абсолютно оторванной от реальности. Я располагаю неопровержимыми доказательствами того, что существует бесконечное число чудовищных, кошмарных, бесполезных, до смешного глупых и из рук вон плохих идей. Если приглядеться, то сразу станет очевидно, что их число постоянно пополняется.

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

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

ХОРОШО ИЛИ ПЛОХО ПО СРАВНЕНИЮ С ЧЕМ?

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

Другой подход: хотя Эйнштейн молодец, что открыл формулу E=mc², она мало чем поможет решить финансовые трудности вашему другу или тому, кто потерялся в пустыне Сахара (не говоря уж о том, кто потерялся в пустыне и одновременно пытается решить финансовые трудности) . Так можно ли назвать формулу E=mc² хорошей идеей? Возможно, что да, если ваши требования и область проблемы настолько широки, что нужно пополнить свои знания о Вселенной. А возможно, что нет, если вас заботит только ваш друг в Сахаре. Идеи кажутся хорошими или плохими только в определенном контексте. Неважно, насколько гениальна ваша идея в теории. Когда речь идет о проектах, которые должны создать реальный продукт для решения конкретной проблемы, неумение отличать теорию от практики имеет неприятные последствия.

Умные люди часто забывают о настоящих проблемах, которые нужно решить, из-за теоретических характеристик своих идей. Да, одни идеи могут быть элегантными, гениальными, креативными по сравнению с другими — даже если не решают реальных проблем. Иногда идея нравится человеку только потому, что доказывает его убеждения или приносит ему политическую выгоду. К примеру, программист отстаивает идею А и выступает против идеи Б, потому что идея А более элегантная — по крайней мере, объектная модель, которую он спроектировал, — несмотря на то что она хуже удовлетворяет требования клиента. Возможно, его личные требования противоречат требованиям проекта, но он не заметил разницы. Итак, всегда старайтесь разобраться, что вас мотивирует на самом деле на то, чтобы отстаивать ту или иную идею.

МОЖНО МЫСЛИТЬ СТАНДАРТНО И НЕСТАНДАРТНО

Вторая популярная и ошибочная фраза относительно идей: «Нужно мыслить нестандартно», — родилась из классической головоломки. Головоломка на рисунке 5.4 предлагает жертве, то есть участнику, соединить все точки только с помощью четырех прямых линий, не отрывая ручку от бумаги. Оказывается, это невозможно, если жертва не воспользуется пространством за границами головоломки, мысля (барабанная дробь) нестандартно. Смысл якобы вот в чем: ошибочно предполагая, что ограничения и условия — часть проблемы, мы надеваем на глаза шоры и сами себе мешаем искать решение. Очаровательно! Я дам вам минутку, чтобы насладиться этой мыслью, прежде чем порвать ее в клочья.

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

Реальная задача поиска решения или креативного мышления — знать, какие ограничения применять или игнорировать и когда это делать. Я видел суперкреативных людей, которые приходили ко мне с фантастическими идеями через три недели после последнего дедлайна, когда я мог бы воспользоваться ими. Я также был на мозговых штурмах по крошечным проектам с мизерным финансированием — уже отстающим от графика, — где люди предлагали свои «грандиозные, самые радикальные, нешаблонные идеи», которые лишь злили команду, потому что ни одна из этих гениальных идей не вписывалась в план проекта.

Кто-то должен возглавить процесс и решить, какие ограничения и требования можно игнорировать, корректировать, менять или обходить, а какие нужно соблюдать буквально. Креатив зачастую предполагает умение работать в определенных рамках, с ограниченными ресурсами или временем и нахождением хитрого способа превзойти ожидания (посмотрите фильм «Аполлон-13»). Для успеха редко нужны грандиозные, радикальные идеи. Чаще подходят простые, надежные, хорошие, которые вы к тому же умеете правильно применять.

Итак, моя мысль заключается в следующем: делайте со стандартами все, что считаете нужным. Можно мыслить стандартно, нестандартно, можно порвать стандарты в клочья или сжечь их на медленном огне, это неважно, главное — чтобы вы решили задачи проекта. Как сказал Томас Эдисон: «Черт, здесь нет никаких правил! Мы пытаемся чего-то добиться». Убедитесь, что все правила, создаваемые вами, служат интересам процесса и людей, а не наоборот.

Еще важно ответить на следующий вопрос: как сделать так, чтобы все думали над одной и той же проблемой? Как привлечь хорошие идеи? Хотите узнать, с чего начать?

ХОРОШИЕ ИДЕИ РОЖДАЮТСЯ ИЗ ХОРОШИХ ВОПРОСОВ

Компьютеры бесполезны. Они умеют только давать ответы.

Пабло Пикассо

Чтобы избавить себя от некоторых совершенно ненужных требований в колледже, я изучал теорию логики и философии. Множество вещей я выучил и забыл, но одно запомнил точно — как задавать правильные вопросы. С логикой у меня было все в порядке, но так как остальные слушатели курса были старше меня и уже получили степень бакалавра, я постоянно отставал от группы. Я быстро понял, что если не задавать товарищам и преподавателям тщательно сформулированные вопросы, в ответ получишь массу сложной информации, которая не внесет никакой ясности в твою жизнь. Кстати, я обнаружил, что многие инженеры, врачи и другие эксперты интеллектуального труда с радостью делятся всем, что знают, даже если никто не просит. Они просто путаются в собственных знаниях.

Тщательно сформулированные вопросы — единственный способ направить обсуждение сложных тем в полезное русло. Помню, мой преподаватель по логике буквально вынуждал меня учиться этому. К примеру, я просил: «Не могли бы вы объяснить эту часть теоремы Геделя о неполноте?» На что он отвечал: «Конечно. Понимаете, все системы доказательства можно свести к основному набору характеристик, продиктованных несколькими примитивными рекурсивными функциями». Я говорил: «Так, понятно. Замечательно. Но не могли бы вы объяснить мне вот эту фразу?» — и показывал ему на одно-единственное предложение в доказательстве, обведенное тремя красными кругами, с гигант­ским знаком вопроса. Преподаватель кивал головой и говорил: «Ах это! (Пауза.) Что ж, история систем логических доказательств берет начало из благородной попытки выразить аспекты существования человечества через систему, поддающуюся проверке…» А я восклицал: «Боже правый! Нет, вот это, — я указывал на фразу. — Что это значит? Как это связано с предыдущим предложением?» А он гнул свое: «Конечно, конечно! Понимаете, теории доказательств связаны с теорией логики, потому что лемма неосязаемости между неординарными, но бесконечными ценностями…» Мне оставалось только махнуть рукой и отправиться в ближайший паб.

Я понял, что без правильных вопросов я никогда не получу правильные ответы. Иногда, впрочем, этого было сложно добиться, даже задавая правильные вопросы. Но мне все-таки удалось закончить тот курс, и позже я обнаружил, что в Microsoft, да и вообще в технологическом секторе, умение формулировать вопросы — бесценно. Проблемы общения, с которыми я столкнулся в колледже, мало чем отличались от проблем, которые возникли у меня позже с проектировщиками, юристами, управляющими, маркетологами, разработчиками и клиентами. Люди упорно и в огромных количествах выдают информацию, которая не имеет никакого отношения к тому, что вам нужно узнать. И логически правильно составленные вопросы, заданные решительным тоном, действительно помогают направить обсуждение в полезное русло.

Есть три типа вопросов конкретно для креативных решений: фокусирующие (хорошие), креативные (тоже хорошие) и риторические (плохие).

ФОКУСИРУЮЩИЕ ВОПРОСЫ

Грамотный вопрос позволяет человеку или группе понять, что для выполнения задачи отсутствуют важные, полезные, а порой и ключевые элементы. Он сужает тему дискуссии и привлекает внимание к конкретным аспектам ситуации. «Можно ли, используя существующую кодовую базу, создать систему, отвечающую требованиям к производительности?», или «Как пользователи поймут, когда нужно перейти к этому экрану?», или «Можно ли смешивать арахисовое масло с шоколадом?». Грамотный вопрос, состоящий всего из нескольких слов, выделяет важный элемент проблемы (либо ее решения), игнорируя всю второстепенную или несущественную информацию, и создает условия для рождения ответа. Умные люди, слыша грамотную постановку проблемы, с радостью бросают все силы на поиск ответа. Хорошие вопросы, как магниты, привлекают сообразительных и креативных людей, а вместе с ними и все их блестящие идеи.

Профессиональные менеджеры и креативные люди мастерски формулируют вопросы. Они чувствуют, когда поиски решения заводят на ложный путь, понимают, какие важные элементы отсутствуют в обсуждении или в плане, и восполняют пробелы с помощью своевременных и грамотно сформулированных вопросов. В сильных командах, даже если МП задает неверный вопрос, кто-то другой обязательно спросит то, что нужно. «Знаешь, Скотт, мы уже отказались от этого требования. Так что лучше подумать, действительно ли наше новое проектное решение отвечает обновленному списку?» После короткой дискуссии вся команда сосредоточится на новых рабочих задачах. Хорошие вопросы как катализаторы: объединяют знания и энергию дискуссии — усиливая, корректируя и кристаллизуя одновременно, — и перенаправляют их на более плодородную почву.

После того как вы выстроите доверие в команде, самый важный во­прос — продукт проект-менеджмента, креативного мышления и умения решать проблемы — звучит следующим образом: Какую проблему вы пытаетесь решить?

Если вас уважают и этот вопрос не покажется очередной раздражающей болтовней, его можно использовать практически в любой дискуссии, в любое время и на любом этапе проекта, чтобы уточнить два момента. Во-первых, команда должна четко сформулировать, что она пытается выяснить. Во-вторых, у каждого из присутствующих должен быть один и тот же ответ, по крайней мере на данный момент (нет ничего хуже, чем пять умнейших людей, которые трудятся вместе, но, сами того не осознавая, пытаются решить разные проблемы). Вопрос работает удивительно хорошо в любых дискуссиях — от общей стратегии компании до деталей конкретных решений по синтаксису кода, рутинных тестовых сценариев и вопросов проектирования. Он настолько эффективен и полезен, что я сделал из этой фразы постер и повесил над своим столом. Когда мне кажется, что проектирование и поиск идей зашли в тупик или люди предлагают противоречивые вещи, я задаю этот мегаваж­ный во­прос. Он позволяет каждому сделать перезагрузку, подзарядить свои «батарейки» и направить все внимание на то, чем следует заниматься на самом деле.

КРЕАТИВНЫЕ ВОПРОСЫ

Креативные вопросы абсолютно другие — они работают в противоположном направлении, указывая на те области, которые еще не изучены, но могут оказаться полезными. «Сколько разных вариантов представить эту информацию на домашней странице мы можем предложить клиентам?» или «Для чего еще можно использовать базу данных поисковика?». Благодаря подобным вопросам проектные обсуждения протекают намного плодотворнее — с активной дискуссией, скетчами и анализом ответов. Грамотные креативные вопросы обычно увеличивают количество альтернатив и расширяют область дискуссии (а вот область видения проблемы — не всегда). Как мы увидим в этой главе, большой банк идей — зачастую единственный способ найти верное решение. Хорошие вопросы направляют креативного человека в правильную или неправильную сторону, но в итоге все равно выводят на верный путь.

РИТОРИЧЕСКИЕ ВОПРОСЫ

Но будьте осторожны: у креативных вопросов есть темная сторона — вопросы риторические. Их задают без каких-либо намерений получить буквальный ответ. Как родитель, ругающий ребенка («О чем ты думал, когда слопал всю коробку хлопьев?» или «Как ты мог позволить Салли намазать экран телевизора арахисовым маслом?»), риторические во­просы убивают дискуссию. Они пробуждают чувство вины и провоцируют негативные суждения. Они подразумевают, что автор во­проса знает больше, чем тот, кому вопрос адресован. Их часто задают люди, обладающие властью (например, разозленный босс или учитель), но не знающие, как ею пользоваться. Формулируя вопрос по показанному выше принципу, редко можно получить нужный ответ. Однако при аккуратном применении риторические вопросы могут разрядить обстановку и немного встряхнуть тех, кого надо («Давайте, ребята, неужели это все, на что вы способны?»). Однако их следует использовать редко, даже в благих целях.

Фокусирующие и креативные вопросы помогают определить исходный материал, необходимый для плодотворного мышления. Нужен опыт, чтобы понять, когда их использовать и какой тип вопроса выбрать, а когда просто участвовать в дискуссии и предлагать идеи. Конечно, если команда плодотворно работает и придерживается верного направления, проявляя при этом максимум креатива, необходимости в подобных во­просах не возникает. В конце концов, важно качество идей, а не вопросы или конкретные процессы, которые привели к ним.

ПЛОХИЕ ИДЕИ ПРИВОДЯТ К ХОРОШИМ

Впервые я увидел, как работает дизайнер, когда учился на первом курсе колледжа. Я плохо понимал, чем занимаются представители этой профессии, и решил, что в основном они просто делают вещи красивыми: дизайнерские джинсы, сумки и т. д. Тот парень придумывал дизайн нового портативного стерео. Он работал в учебной студии факультета дизайна — просторном помещении с множеством таблиц, скетчей, прототипов и чертежей . Он делал наброски разных идей для стерео. Я спросил, чем он занимается или, точнее выражаясь, как его работа вписывается в «дизайн» — что бы это слово ни значило для него.

Он задумался на минуту, улыбнулся и ответил: «Мне сложно понять, как выглядят хорошие идеи, пока я не увижу плохие». Я вежливо кивнул, но решил, что не стоит обращать внимание на его слова. Раз я не понял, что он имеет в виду, значит, он странный, творческий человек и дело вовсе не в моем невежестве.

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

Итак, лучшие идеи и проектные решения требуют разгона. Они не появляются в результате волшебных заклинаний или силы воли («Будь гением, сейчас же! Я серьезно! Прямо… сейчас!»). Каждый рисунок, набросок или прототип, каким бы смешным и жалким он ни казался, учит дизайнера (или инженера, или ученого) новому взгляду на проблему и повышает вероятность, что следующая попытка окажется лучше предыдущей. Все великие умы, занятые решением сложных проблем, не обходились без гор скомканных бумажек. Кто-то это скрывал, кто-то принял как факт. В любом случае принцип «плохие идеи приводят к хорошим» дает нам свободу проектировать так, как нам нравится. Будьте готовы запачкать руки и допустить массу ошибок на ранних этапах, потому что чем быстрее вы их совершите, тем быстрее доберетесь до хороших идей.

ХОРОШЕЕ ПРОЕКТИРОВАНИЕ — ПЛОД МНОЖЕСТВА ХОРОШИХ ИДЕЙ

Цель проекта не в том, чтобы решить одну-единственную проблему. Все намного сложнее. Большинство проектов по созданию программных продуктов требуют решения десятка проблем. При этом предпочтение отдается вариантам, предусматривающим удобство пользователей и возможность разработки в кратчайшие сроки. Количество взаимодействующих частей и компонентов в проектировке и создании автомобиля, сайта или программного продукта требует от проектировщиков многочисленных корректировок и поправок. Тестирование и корректировка — неотъемлемая часть процесса.

Все креативные стремления от инжиниринга до искусства подчиняются этой фундаментальной истине, как не раз говорили известные мыслители и творцы:

Два самых важных инструмента, которыми располагает архитектор, — ластик в офисе и кувалда на стройке.

Фрэнк Ллойд Райт

Лучший инструмент физика — мусорное ведро.

Альберт Эйнштейн

Иногда я делаю пять рисунков, но нужно понимать, что из двадцати работ только одна будет успешна.

Винсент Ван Гог

Нет такого понятия, как неудача. Только если сдаться слишком рано.

Джонас Солк

Есть способ сделать лучше, найдите его.

Томас Эдисон

Ошибайтесь. Снова ошибайтесь. Ошибайтесь лучше.

Сэмюэл Беккет

Если хотите добиться успеха, увеличьте количество неудач в два раза.

Том Уотсон, IBM

Я пишу 99 страниц ерунды на каждую страницу, достойную восхищения.

Эрнест Хемингуэй

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

Но даже если вы разумно подходите к вопросу и отводите достаточно времени проектированию, задача все равно непростая. Поиск и создание полезных идей требуют совершенно не тех навыков, которым большинство из нас учится в школе или офисе. Мне самому, несмотря на многие годы обучения и работы в проектировании, пришлось совершенно по-новому взглянуть на то, откуда берутся идеи.

ПЕРСПЕКТИВА И ИМПРОВИЗАЦИЯ

На спор с Айкой Юксел и Ванессой Лонгакр, двумя бывшими коллегами по Microsoft, мы втроем записались на класс комической импровизации в местном колледже. Уже после первого дня я понял, что мой ужас при одной мысли о том, что придется шутить по команде, оказался совершенно необоснованным. Я обнаружил, что большинство людей, если они научатся быть внимательными (чего и добивался этот курс), могут найти смешное в совершенно обыденных ситуациях. Главное — суметь увидеть вещи, которые зачастую остаются незамеченными, и проводить между ними связи.

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

По-настоящему качественное проектирование требует понимания сути дела. Во всей ее полноте и глубине. Необходима страстная увлеченность, чтобы досконально понять — разжевать, а не просто быс­тренько проглотить. Большинство не уделяет этому времени. Креатив — это умение проводить связи. Если спросить креативного человека, как он выполнил ту или иную задачу, ему станет неловко, потому что на самом деле он ничего особенного не делал — просто что-то разглядел. Через какое-то время все стало для него очевидным. Потому что он осмыслил свой опыт и синтезировал новые знания. И причина, по которой он смог это сделать, заключается в том, что у него больше опыта или он больше думал о своем опыте, чем другие. К сожалению, это большая редкость. Многие люди в нашей отрасли не обладают разноплановым опытом. У них недостаточно точек, которые нужно связать между собой, и в итоге они выдают абсолютно линейные решения, без широкого взгляда на задачу. Чем шире понимание человеческого опыта, тем лучше будут наши проектировщики .

Единственное мое замечание к этим словам: автор предполагает, что креативные люди обладают неким особым талантом, не доступным остальным. Я не верю, что люди с рождения попадают в одну из категорий: либо креативные гении, либо болваны, лишенные воображения. Если курс по импровизации, который я прошел, является показателем, большинство людей вполне способны развивать наблюдательность, остроту восприятия мира, себя и связи между явлениями, удовлетворяя тем самым критерию Джобса.

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

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

Я обнаружил, что курс по импровизации помог мне выйти за рамки своей должности и отношений и расти так, как я не смог бы расти в привычной жизни. Этому способствовали четыре правила, которым мы следовали на занятиях, чтобы не терять бдительности и стимулировать новые идеи. Позже я обнаружил, что эти правила легко применить во время мозгового штурма в небольших группах — то есть в ситуациях, когда нужно найти новые идеи, создать длинные списки концепций и мыслей, которые позже будут рассмотрены более тщательно.

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

ПРАВИЛА ИМПРОВИЗАЦИИ ДЛЯ ГЕНЕРАЦИИ ИДЕЙ

Чтобы провести импровизационную игру для мозгового штурма (предупреждение: это не подходит для глубокого осмысления проектного решения), нужно несколько условий: небольшая команда (2–8 человек), удобная комната, достаточно времени, минимум одна задача, связанная с проектом, и человек у доски, чтобы коротко записывать каждую предложенную идею. Итак, кто-то берет на себя функцию ведущего и встает у доски. Необходимо представить задачу, по которой группа будет искать идеи. Задачу можно позаимствовать из формулировок проблемы, требований или придумать самим. Как только договоритесь насчет задачи, люди начнут предлагать идеи, которые ведущий записывает на доске.

Игра начинается, когда кто-то предлагает идею, и за этим следует обсуждение. Есть четыре правила обсуждения.

1. Да, и… Когда кто-то выдвигает свою мысль, единственный допустимый ответ: «Да, и [впишите сюда что хотите]». Первая реакция — развивать мысль или перенаправить ее, например: «Нам понадобится поисковая строка…» — «Да, и будет разумно перенаправить пользователя в нужное место, когда он набирает запрос». Или «Да, и можно будет использовать новый поисковик, который мы готовим, и быстрее получить результаты». Задача — двигаться в позитивном русле и выработать у себя привычку слушать других, чтобы помочь им с их идеями, вместо того чтобы просто ждать, когда представится возможность высказать свои.

2. Никакого дилетантства. Недопустимо предлагать идею и говорить: «Извините, знаю, что идея ужасная» или «Я не блещу креативом». Дилетантство означает, что вы не вкладываетесь в то, что говорите. Ваши идеи не обязаны быть блестящими. Они даже могут быть ужасными, и при этом стимулировать кого-то другого предложить что-то получше. Если ваш сосед скажет «Да, и…», он может придумать что-то интересное с вашей «паршивой» идеей, и ни он, ни вы до этого никогда не додумались бы иным путем.

3. Никаких блокирующих вопросов. Вопросы вызывают у авторов идей защитную реакцию. Возразив: «Какого лешего нам это делать?», вы задаете новый, осуждающий контекст вокруг идеи. Он подразумевает, что нет ни одной веской причины делать то, что человек предложил, пока не будет доказано обратное, а это неподходящая атмосфера для открытого и свободного высказывания мыслей (зато вполне подходящая для более поздних этапов подробных обсуждений). Воспринимайте игру как проверку вашего интеллекта: как превратить изначальную идею во что-то полезное? Делайте любые предположения и допущения, чтобы осмыслить идеи других членов команды. Принимайте вещи такими, какие они есть, и двигайтесь дальше. В двух словах, разъясняющие вопросы периодически полезны, но они не должны перетягивать на себя внимание. Лучше перейти к следующей идее, чем сосредоточиваться лишь на «избранных». Если ваша цель — найти как можно больше идей, их количество в час важнее, чем качество каждой отдельной. Для общей цели генерации идей лучше вообще ничего не сказать, чем отметить, какая эта мысль глупая.

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

Результатом подобного упражнения должен стать список примерных, схематичных идей, которые кто-то позже отсортирует. И выберет достаточно интересные, чтобы развивать их или обсуждать подробнее. Поскольку последующие обсуждения уже не касаются генерации «сырых» идей, правила импровизации для них не так актуальны — хотя настрой должен быть тот же.

ДРУГИЕ ПОДХОДЫ К ГЕНЕРАЦИИ ИДЕЙ

Для тех, кто не готов к игре в импровизацию или нуждается в более простом способе генерации идей, перечислим несколько традиционных вариантов.

• Выберите книгу по креативному мышлению. Есть множество хороших книг. Две мои любимые: «Рисовый штурм» Майкла Микалко и «Шесть шляп мышления» Эдварда де Боно. Многие другие популярные книги также хороши, однако больше всего пользы мне принесли эти две.
• Обратите внимание, когда вы наиболее креативны. Подумайте, в каких условиях вам легче проявлять креатив. Когда вы одни? Или вокруг много людей (каких именно)? Когда музыка включена или выключена? Все условия разные, и вы не сможете найти источник своего креатива, если не подумаете, что именно вас вдохновляет. Например, модное кафе, медитация на скамейке в парке или наблюдение за тем, как солнце медленно опускается за Бруклинским мостом.
• Помните, что креативу способствует упорство. Людям, которые кажутся креативными, далеко не всегда проще придумывать идеи, чем вам. Но они, вероятно, больше времени тратят на тренировку соответствующих частей мозга, чтобы поддерживать их, так сказать, в хорошей форме. Креатив — это навык, как и любой другой, и хотя рождаемся мы с разными талантами, каждый может развиваться в том, что ему нравится, если вложит в это силы.
• Купите карты по мозговому штурму ThinkPak Майкла Микалко. Это набор игровых карт, которые призваны помочь индивидам или группам придумать новые идеи для любых задач . Есть и другие похожие наборы, я считаю эти самыми удачными.

ПРОЕКТИРОВАНИЕ НАЧИНАЕТСЯ С КЛИЕНТСКОГО ОПЫТА

Технологические визионеры никак не поймут разницы между осуществимым и желаемым.

Эдвард Мендельсон

Лучшая в мире архитектура, основанная на лучших объектных моделях, блестящих алгоритмах и самом быстром и при этом надежном коде, будет бесполезной, если клиенты не поймут, как пользоваться этим продуктом. Алгоритмы и человеко-часы инженерных затрат окажутся ненужными, поскольку никто не сможет оценить качество проделанной работы.

Единственная страховка против такого разворота событий — начать проектирование сверху вниз, то есть с того, что клиент увидит на экране, затем спуститься к высокоуровневым компонентам, а затем и к отдель­ным рабочим элементам. После готовности чернового варианта UX-концепции следует обдумать, насколько технические идеи вписываются в эти концепции. Могут ли проектировщики воплотить это? Какие компромиссы понадобятся? Какие ограничения следует рассмотреть? Работа продолжается, обсуждения между экспертами команды переходят с одного этапа проектирования на другой, чтобы убедиться, что по ходу работы сохраняется интегральность пользовательского опыта без противоречий с тем, что возможно (и вероятно) со стороны разработчиков. Мысль проектировщика движется в двух направлениях: от желаемого клиентского опыта вниз к технологии и от практической технологии снова вверх — к клиентскому опыту (рис. 5.5).

Мозговой штурм поможет понять, как и с чего начать проектирование. Многие первые идеи, вероятно, будут описывать, как спроектировать систему для решения проблемы. Каждая из идей имеет как минимум одно визуальное представление того, как приложение или сайт будут выглядеть для пользователей. Это можно сделать схематически или обсудить, не написав ни одной строчки кода. (Если проект представляет собой встроенную систему или ядро ОС — системы без реального пользовательского интерфейса, — следует обдумать, какие условия не приемлемы ни при каком раскладе.)

Визуализация, скетчи, рисунки, а в некоторых случаях прототипы — первый шаг к пониманию идеи. Если ее нельзя изобразить, то уж точно нельзя построить. UML-диаграммы и Visio — не то же самое, что наброски и чертежи. Диаграммы абстрактны. Они не показывают того, что увидит пользователь, и, следовательно, могут скрывать самые разные проблемы и детали, которые необходимо обдумать.

Вспомним одну из формулировок проблем из главы 3: «С домашней страницы сложно найти часто используемые элементы». Предположим, что после мозгового штурма команда выделила три достойные идеи:

• динамически выстраивать страницы по приоритетам, опираясь на то, что используют клиенты;
• избавиться от того, на что клиенты никогда не кликают;
• упорядочить материал на домашней странице по группам, значимым для клиентов.

Прежде чем разработчик задумается над реализацией этих задач, кто-то должен определить, насколько эти идеи соотносятся с клиентским опытом. Возможно, несмотря на всю их гениальность в теории, никто в компании не сможет придумать качественное проектное решение , благодаря которому клиентам было бы легче ориентироваться. Поэтому в интересах команды начать именно с клиентского опыта: это простейший способ исключить ненужную работу, выяснить, какое проектное решение следует выбрать и почему, а также сократить необходимость серьезных изменений на более поздних этапах. Управлять этим процессом нелегко, однако посредственный результат лучше, чем полное его отсутствие.

ПРОЕКТИРОВАНИЕ — ЭТО ЦЕПОЧКА ОБСУЖДЕНИЙ

С несколькими набросками пользовательских интерфейсов можно приступать к проектированию. Неформальная проработка набросков с разработчиками, тестировщиками и маркетологами становится отправной точкой важных обсуждений. Разработчик может дать проектировщику рекомендации по работе; или предложить изменения, которые ее облегчат; или ознакомить проектировщика с технически возможными вариантами. Чем раньше начнутся обсуждения, тем больше идей можно придумать, проанализировать и дора­ботать.

Важно, чтобы все воспринимали процесс объективно: как цепочку проб, дискуссий, вопросов и исследований, которые повторяются, пока не будут сформулированы удовлетворяющие всем требованиям предложения (которые нужно задокументировать в спецификациях). Если кто-то не хочет участвовать в подобном диалоге, им следует передать хотя быть часть своих полномочий по принятию решений тем, кто готов к этому. Хотя участие разработчиков в проектировании повышает его качество, следует помнить: проектирование — это не разработка; лучше исключить людей из процесса, чем пытаться изменить процесс им в угоду.

Если цели, задачи и проблемы ясны, проектные обсуждения будут протекать в положительном русле. Конечно, разногласий не избежать, но они будут незначительными, если все участники решают одну и ту же проблему. Подобные столкновения лишь позволят людям расширить свой кругозор. Как гласят правила импровизации, идея одного человека может стать отправной точкой для другого, с иным опытом работы или иным мнением; для более неожиданного и более удачного варианта, чем первоначальный.

Мне нравится работать с хорошими людьми, потому что, если я предложу идею, они предложат идею получше, потом я предложу что-то еще лучше и так далее: похоже на чехарду, и результат оказывается намного удачнее, чем если бы я делал только то, что я хочу.

Терри Гиллиам, кинорежиссер

Сотрудничество, о котором говорит Гиллиам, возможно, только когда члены команды доверяют друг другу. Именно менеджеры и лидеры обязаны создавать доверительную атмосферу и должны быть открыты хорошим идеям независимо от их источника. Подробнее об этом мы поговорим в .

РЕЗЮМЕ

• Многие команды не умеют грамотно использовать время между требованиями и спецификациями.
• Качественные требования и проектные обсуждения — лучшие занятия в этот период.
• Идеи хороши или плохи только в сравнении с задачами и другими идеями.
• Ограничения полезны для поиска идей, а нестандартное мышление не всегда приносит нужный ответ. Иногда оптимальное решение — найти способ работать в рамках указанных ограничений.
• Вопросы, перспективы и импровизированные игры — инструменты поиска новых идей.
• Лучшая отправная точка для проектных идей — клиентский опыт.
• Идеи превращаются в проектные решения в ходе обсуждений между разными людьми с разным опытом работы.

УПРАЖНЕНИЯ

А. Найдите человека, которого вы считаете более креативным, чем вы сами. Спросите, откуда он черпает свои идеи и какие привычки помогают ему культивировать креатив. Позаимствуйте одну из его привычек и практикуйте ее в течение недели. (Если не получается, берите пример с Пикассо, Эйнштейна или любого другого человека, который славится креативным мышлением в вашей области.)

Б. На ваш взгляд, требования помогают или мешают креативу? Как сформулировать требования, чтобы они способствовали поиску креативных идей?

В. Какую самую безумную идею вы когда-либо предлагали? Можете сейчас придумать способ сделать эту идею еще более безумной?

Г. Какую самую безумную из своих идей вы никогда никому не рассказывали? Почему? Чего вы боялись? Насколько этот страх связан с вашим умением быть креативным на работе?

Д. Проектные работы означают, что итог непредсказуем. Иногда самые удачные идеи не приносят ожидаемых результатов. Как лидер проекта может укрепить уверенность команды, когда ее любимая идея оказывается неудачной или когда лучший прототип отвергнут?

Е. Какую проблему вы пытаетесь решить, читая эту книгу? Делая эти упражнения? Может, вы находитесь в ситуации, при которой полезно задать этот вопрос.

Ж. Допустим, вы занимаетесь перепланировкой дома или квартиры. Составьте список 10 фокусирующих вопросов для стимуляции креативного мышления. Затем составьте список 10 креативных вопросов.

З. На следующем мозговом штурме или креативной сессии запишите на доске правила. Предложите провести эксперимент всего на 10 минут, во время которого каждый присутствующий должен следовать этим правилам. Какие результаты вы получите? Захотелось ли вам изменить эти правила или дополнить их?

И. Если проектирование — цепочка обсуждений, то как оно влияет на необходимость развивать навыки общения? Может ли человек быть блестящим проектировщиком, если с ним невозможно разговаривать? Может ли блестящий проектировщик быть при этом отвратительным командным игроком?

К. Можно ли спрогнозировать, сколько идей вам нужно, чтобы выбрать достойную? Есть ли взаимосвязь со сложностью задачи, которую вы пытаетесь решить? Или другие факторы? Или прогнозировать слишком сложно?

Отправить