Скотт Беркун - Искусство управления IT-проектами

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

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

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

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

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

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

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