Текст книги "Сделано"

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

Рис. 5.1. Проектирование зачастую воспринимается как некий таинственный процесс между началом планирования и завершением спецификаций

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


[Закрыть]. Если проблемы сложные, ей нужно время, чтобы сравнить разные подходы и найти лучший из них, прежде чем сделать окончательный выбор.

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

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

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

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

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

Итак, чем больше внимания уделяется грамотно составленным требованиям, тем выше вероятность того, что проектировщики найдут отличные решения. Если требований вообще нет, то специалистам придется работать на свой страх и риск (если вы проектируете без требований, в ваших же интересах их быстренько набросать). В качестве примерного руководства по грамотному их составлению предлагаю перечень необходимых действий для избежания распространенных ошибок[44]44
  Подробнее на эту тему см. Exploring Requirements: Quality Before Design, Donald Gause and Gerald Weinberg (Dorset House, 1989).


[Закрыть].

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

• Отследите ошибочные предположения. Зачастую требования предполагают, что клиент или пользователь нуждается в том, что на самом деле ему совершенно не нужно. Чтобы этого избежать, фанатично задавайте уточняющие вопросы: «Зачем это?», «Какую проблему это решает?» и «Чье это требование?» – чтобы вывести все предположения и допущения на чистую воду. Помните: всегда есть вероятность того, что кто-то случайно не так понял фразу или без всякого злого умысла внес ошибочные сведения.

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

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

• Исправьте или вычеркните ненамеренные двусмысленности. Такие слова, как быстрый, большой, маленький, приятный, симпатичный и применимый, нуждаются в уточнении. Их можно оставить без изменений, если все, кого касаются требования (клиент, босс, программист и т. д.), готовы обсудить спорные моменты позже. В иных случаях есть вероятность, что каждый автор требований использует двусмысленные выражения намеренно. Пограничные случаи («Наша домашняя страница должна загружаться в Firefox как минимум так же быстро, как www.cnn.com) – зачастую простейший способ разрешить двусмысленные требования. Как в этом примере, абсолютные требования (должен) и желательные требования (прекрасно, но можно обойтись и без этого) легко определить.

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

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

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

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

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

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

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

Рис. 5.2. Проектные идеи вытекают из формулировки задачи

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

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

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

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

Возможно, многие пропускают процесс проектирования, потому что боятся исследовать, особенно когда за ними кто-то наблюдает. Когда мы исследуем собственную работу (допустим, пытаемся оптимизировать алгоритм или совершенствовать документ), этот процесс никто, кроме нас, не видит, и мы вполне можем опробовать довольно странные идеи. Но когда проектирование становится запланированной работой команды, исследования каждого сотрудника видны остальным. Все скетчи или прототипы, которые он делает, придется показывать коллегам и открыто обсуждать. Если люди не доверяют друг другу и боятся критики, не удивительно, что этот процесс их пугает[45]45
  См. How to give and receive criticism, http://www.scottberkun.com/essays/35-how-to-give-andreceive-criticism/.


[Закрыть].

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

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

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

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

Рис. 5.3. Большинство возможных проектных решений не принесет успеха (а те, что принесут, не сгруппированы вместе, в отличие от этой диаграммы)

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

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

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


[Закрыть].

Другой подход: хотя Эйнштейн молодец, что открыл формулу E=mc², она мало чем поможет решить финансовые трудности вашему другу или тому, кто потерялся в пустыне Сахара (не говоря уж о том, кто потерялся в пустыне и одновременно пытается решить финансовые трудности)[47]47
  Приведем пример: миноксидил – лекарство, предназначенное для лечения высокого давления. Оказалось, что оно эффективно борется с абсолютно другой проблемой – выпадением волос. Если судить по одному критерию, формула миноксидила оказалась неудачной; а если судить по другому критерию – полным успехом. Так какая она? Зависит от контекста.


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

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

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

Рис. 5.4. Головоломка «Мыслить нестандартно» и ее решение

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

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

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

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

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