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

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

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

Рис. 2.1. Простейшая схема календарного плана, созданного по правилу трех частей

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

Разработка по частям (беспроектный проект)

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

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

 

Разделяй и властвуй (большие планы равны множеству мелких)

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

Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели – фазами, а в некоторых организациях их называют этапами. Хотя в XP считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.

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

Гибкий и традиционный методы

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

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

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

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

Рис. 2.2. Большой проект должен представлять собой последовательность более мелких проектов

Так или иначе, я прошу прощения у всех опытных разработчиков, почувствовавших недомогание при чтении данного раздела или вовсе лишившихся чувств. Заканчивая его, я обещаю, что подобный облегченный и упрощенный взгляд на планирование – это практически все, что вам понадобится, чтобы усвоить понятия, излагаемые в оставшейся части главы.

 

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

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

 

Выстрел вслепую издалека

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

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

Барри Боэм (Barry Boehm) в 1988 году в своем эссе на тему разработки программных продуктов писал, что ошибки тем масштабнее, чем раньше при реализации проекта делались расчеты для календарного плана (рис. 2.3). Если все расчеты делались на ранней стадии, отклонения могут составлять до 400 % в обоих направлениях (подозреваю, что ошибки всегда работают против нас, стремясь отнять больше времени, чем мы ожидаем, хотя Боэм в своих данных этого не показал). В период проектирования по мере конкретизации решений расхождение сокращается, но остается еще весьма значительным. И только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.

Рис. 2.3. Диапазон возможных отклонений от расчетных сроков в процессе реализации проекта (заимствовано из книги Боэма «Software Engineering Economics»)

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

 

Календарный план – это оценка вероятности

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

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

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

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

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

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

 

Расчет – дело тонкое

В процессе проектирования (обсуждаемого в главах 5 и 6) одной из задач проектировщиков, программистов и тестировщиков является разбиение проекта на небольшие части работы, которая имеет некие завершенные формы. Эти части, часто называемые элементами структурной декомпозиции работ (Work Breakdown Structure, WBS), или просто работами, становятся строками в главном календарном плане проекта. Работы разумно (скрестите пальцы) распределяются среди программистов команды и в соответствии с ними строится календарный план. Каждая из этих работ должна иметь предполагаемый срок завершения, назначенный программистом, и на основе этих предположений создается календарный план.

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

Весь мир держится на расчетах

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

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

 

Качественное проектирование – залог хороших расчетов

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

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

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

Вот несколько дополнительных советов, позволяющих добиться качественных расчетов:

 Установите базовые показатели доверия расчетам. Предположение – 40 % доверия, качественный расчет – 70 %, подробный и полный анализ – 90 %. Руководители команд должны прийти к соглашению, насколько точными должны быть расчеты, сколько времени отвести программистам для их проведения и как управлять риском неверных расчетов. Не заостряйте внимание на цифрах: пользуйтесь ими лишь для конкретизации качества расчетов. Расчет с 90-процентным доверием должен означать, что сроки выдерживаются в 9 случаях из 10. Если вы решите обратиться к команде с просьбой поднять качество расчетов, то должны подкрепить свою просьбу выделением дополнительного времени.

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

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

 Расчеты зависят от понимания программистами целей проекта. Расчеты основываются на программистской интерпретации не только проектировочных спецификаций (если таковые имеются), но также целей и параметров, заложенных в проект. Джеральд Вейнберг (Gerald Weinberg) в книге «The Psychology of Computer Programming» (Dorset House, 1971) отмечал прямое влияние недостаточно четко поставленных целей высокого уровня на низкоуровневые предположения, допускаемые программистами. Какой бы понятной ни была бы технологическая проблема, подходы программистов к ее решению могут в корне меняться в зависимости от общего замысла всего проекта.

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

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

 Существуют известные методы улучшения качества расчетов. Наиболее известным является метод PERT (Program Evaluation and Review Technique – метод оценки и пересмотра планов), в котором предпринимается попытка минимизировать риски путем вычисления усредненной величины из результатов лучшего, среднего и худшего расчетов. Этот метод хорош по двум причинам. Во-первых, всем дается понять, что расчеты сродни прогнозам, отражающим диапазон возможных результатов. Во-вторых, руководителям проектов дается возможность отрегулировать агрессивность или консервативность календарных планов (больший вес может придаваться низким или высоким оценкам).

 

Элементарные просчеты

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

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

• Существует ли в календарном плане отдельная форма учета дней болезни и отпусков всех сотрудников?

• Были ли учтены периоды праздников или другие времена года с большими нерабочими периодами (например, от Дня благодарения до Рождества в США или летние отпуска в Европе)? В эти периоды добиться соблюдения намеченных сроков крайне трудно.

• Допущены ли сотрудники к календарному плану и вменялось ли им (в мягкой форме) в обязанность регулярно отчитываться за проделанную работу?

• Проводит ли кто-нибудь ежедневный или еженедельный анализ выполнения календарного плана в целом? Обладает ли этот человек достаточными полномочиями, чтобы задавать резонные вопросы и вносить поправки?

• Чувствует ли команда причастность к календарному плану и ответственность за его выполнение? Если нет, то почему? Внесла ли команда свой вклад в составление календарного плана и в определение объема работ или все это было спущено им сверху?

• Чего больше было в действиях руководства командой, добавления требований по характеристикам продукта или помощи в их исключении? Говорили ли когда-нибудь руководители команды решительное нет новым объемам работ и предоставляли ли они своей команде разумную философию реагирования на новые (запоздавшие) требования?

• Находили ли сотрудники поощрение и поддержку, если говорили нет новым требованиям, если те шли вразрез с их целями и представлениями?

• Какая вероятность была заложена в расчеты? 90 %? 70 %? 50 %? Нашла ли она отражение в главном календарном плане высокого уровня? Был ли клиент, вице-президент или заказчик уведомлен об этом? Обсуждалось ли другое предложение, более затратное по времени, но имеющее более высокую вероятность соблюдения сроков?

• Имели ли место периодические согласования и пересмотры календарного плана со стороны руководителей команд и руководителей проекта?

• Учтено ли в календарном плане сокращенное рабочее время в период праздников. (Обычно череда праздников снижает продуктивность работы.) Учтены ли в плане наиболее вероятные разрушительные погодные явления (например, снежные заносы в Чикаго, торнадо в Канзасе или жара в Сиетле)?

• Был ли достаточно качественным уровень разработки технических требований и проектирования для получения качественных расчетов времени, отводимого на работы?

• Была ли у расчетчиков достаточная практика или опыт в производстве расчетов времени, отводимого на работы?

 

Эффект снежного кома

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

На самом деле все еще хуже. Вероятность наступления ряда независимых событий равна произведению вероятностей наступления каждого отдельного события (так называемая совместная вероятность). Отсюда следует, что если вероятность прочтения вами этой главы до конца равняется девяти шансам из десяти (9/10), а вероятность того, что вы осилите и следующую главу, также равна 9/10, то суммарная вероятность, что вы дочитаете до конца обе главы, равняется уже не 9/10, а 81/100. Это означает, что если у вашей команды 90-процентная вероятность точного следования еженедельному графику работ, с течением времени шансы срыва сроков возрастают. Вероятность – вещь холодная и беспощадная, напоминающая нам, что энтропия существует повсеместно и не благосклонна ни к проектам, ни к их руководителям.

Рис. 2.4. Эффект снежного кома

 

Для небольшого индивидуального проекта корпоративного веб-сайта вряд ли стоит затевать столь же сложный процесс планирования, как для проекта отказоустойчивой операционной системы, в реализацию которого вовлечено триста человек и 10 миллионов долларов. Обычно, чем больше людей и сложнее проект, тем больше потребностей в серьезном планировании. Тем не менее планы приносят пользу даже самым простым индивидуальным проектам. Они дают возможность пересмотреть решения, выдвинуть предположения и прояснить соглашения между людьми и организациями. Планы действуют в качестве функции принуждения в борьбе со всеми видами глупости, поскольку требуют, чтобы в процессе рассмотрения других вариантов были решены все основные проблемы. Как сказал Авраам Линкольн: «Если бы у меня было шесть часов на то, чтобы срубить дерево, я бы потратил четыре часа на заточку топора». Я привел эту цитату, чтобы показать, что продуманная подготовка сокращает время работы.

При планировании проекта нужно найти ответы на два вопроса. Ответ на первый вопрос, «Что делать?», обычно называется выработкой требований. Ответ на второй вопрос, «Как делать?», называется проектированием или выработкой технических условий (рис. 3.1). Требование должно заключаться в тщательном описании критерия, которому работа призвана соответствовать. (Например, требование к приготовлению пищи может состоять в приготовлении недорого, вкусного и питательного блюда.) Хорошо продуманные требования легко понять и трудно неверно истолковать. Для выполнения требований могут быть выбраны различные варианты проектирования, но определить, насколько они соблюдены, можно только глядя на завершенную часть работы. Технические условия представляют собой простой план создания продукта, удовлетворяющего указанным требованиям.

Рис. 3.1. Самый простой, но весьма удобный взгляд на планирование. Если неизвестно, что делать, значит, не настало время определять, как делать

Представленные три действия, выработка требований, проектирование (или выработка технических условий) и реализация, настолько объемны, что каждое из них достойно отдельной книги (см. библиографию). Первые два действия рассматриваются с точки зрения перспективы проектного уровня в нескольких последующих главах, а реализации внимание уделено чуть позже (в главах 14 и 15).

 

Типы проектов

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

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

 Небольшая команда, работающая по контракту. Фирма, состоящая из пяти—десяти программистов и одного руководителя, нанятая заказчиком для создания веб-сайта или программы. С ними заключается контракт, оговаривающий взаимные обязательства. По окончании контракта все связи обрываются до заключения следующего контракта или начала следующего проекта.

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

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

 

Как на планирование влияет его организация

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

 Кто выдвигает требования? Кто-то должен выдвигать требования и выставлять их на утверждение заинтересованных сторон (заказчика или вице-президента). В варианте супермена-одиночки все очень просто: все полномочия принадлежат самому супермену. У команды, работающей по контракту, должен быть заказчик, желающий строго контролировать выработку требований и, по возможности, процесс проектирования. Наконец, многочисленная группа разработчиков может иметь в корпорации комиссию или иную структурную единицу, предназначенную для выполнения этой работы (и утверждающую выдвинутые требования). Она может состоять из разных людей, имеющих право выдвигать требования высокого («Это будет спортивный грузовик») и низкого («Он будет проезжать 20 миль на одном галлоне топлива и иметь привод на четыре колеса») уровней.

 Кому поручено проектирование? Аналогично процессу выдвижения требований, кто-то должен осуществлять проектирование самой работы. Проектирование отличается от выдвижения требований, поскольку всегда существует множество возможных проектов, ведущих к удовлетворению конкретного набора требований. Проектирование, как и выдвижение требований, зачастую является договорным процессом между двумя и более заинтересованными сторонами. Один человек или команда может отвечать за ход процесса проектирования и выработку идей (проектировщик), а другой человек (вице-президент) или команда – обеспечивать руководство и оценивать работу первой команды. Учтите, поскольку проектирование – искусство глобальное и от политической власти независимое, люди, которым предоставлено право проектировать, могут не иметь на это особого таланта.

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

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

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

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

 

Документы, разрабатываемые при обычном планировании

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

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

 Анализ потребностей рынка (Marketing Requirements Document, MRD). Имеется в виду документ, обобщающий анализ мировой конъюнктуры, проведенный маркетинговой или бизнес-группой. Он предназначен для объяснения благоприятных деловых возможностей и того, как ими можно будет воспользоваться в данном проекте. В одних организациях этот документ носит справочный характер, помогающий обдумывать принимаемые решения. В других он является основой формулировки проекта, используемой в качестве производной для всего остального. Анализ потребностей рынка помогает определить, что собой должен представлять проект.

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

 Технические условия. В них формулируется конечный результат работ для определенной части проекта. Обоснованные технические условия вырабатываются на основе набора требований. Затем они многократно прорабатываются в процессе проектирования (см. главы 5 и 6), в ходе которого изменениям и уточнениям могут подвергаться и исходные требования. Выработка технических условий завершается, когда они обеспечивают работоспособный план, который в процессе разработки и управления проектом может быть использован для удовлетворения требований (степень их детализации должна быть полностью обговорена с разработчиками и управленцами). Технические условия должны унаследовать как можно больше идей, выдвинутых в концептуальных документах. Они определяют для проекта ответ на вопрос «как?», то есть как его реализовать с конструкторской и технической точек зрения. (Сценарии использования и карточки историй, применяемые в большинстве гибких методов, становятся чем-то вроде технических требований и условий.)

 Структурная декомпозиция работ (Work Breakdown Structure, WBS). Технические условия детализируют объем выполняемых работ, а документы структурной декомпозиции работ определяют, как группа разработчиков должна справляться с их выполнением. Что должно быть сделано в первую очередь? Кто этим займется? Что из себя будут представлять все индивидуальные рабочие задания и как можно отслеживать их выполнение? В зависимости от потребностей проекта эти документы могут быть оформлены предельно просто (в виде электронной таблицы) или довольно сложно (в виде диаграмм и средств выполнения). К разработке документов структурной декомпозиции работ относятся главы 7 и 13. Эти документы определяют для проекта ответ на вопрос «как?» с точки зрения группы разработчиков. (В некоторых методах гибкой разработки все задействованные карточки историй показываются на досках заданий, которые становятся чем-то вроде структурной декомпозиции работ.)

 

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

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

ВНИМАНИЕ

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

 

Взгляд бизнесмена

Деловой взгляд фокусируется на понятиях, влияющих на прибыли и убытки (Profit and Loss, P&L), учитываемые организацией. В эти понятия включаются продажи, прибыль, расходы, конкуренция и издержки. Каждый должен разбираться в своей прибыли и убытках – из прибыли выплачиваются зарплаты или оплачиваются контракты. Когда команда разработчиков не знает, как работает бизнес, многие решения, принимаемые руководством, им кажутся нелогичными или неинтересными. Поэтому в интересах тех, кто отвечает за бизнес-планирование, помочь понять всем другим, почему проект имеет право на существование с деловой точки зрения. В технической сфере деловую точку зрения представляют все, чьи должности именуются бизнес-аналитик, специалист по маркетингу, специалист по развитию бизнеса, планировщик номенклатуры изделий или старший менеджер.

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

Хороший деловой взгляд означает, что у команды есть ответы на следующие вопросы:

• Почему этот проект необходим для нашего бизнеса?

• Какие неудовлетворенные потребности или желания имеются у наших клиентов?

• Какие характеристики или услуги мы можем предложить для удовлетворения этих желаний или потребностей?

• Что сможет побудить клиентов приобрести этот продукт или воспользоваться этими услугами? Что станет причиной такого поступка?

• Во что это обойдется (с точки зрения затрат людских и материальных ресурсов)? Сколько на это уйдет времени?

• Каков уровень возможных доходов (или снижения организационных и производственных затрат)? За какой период времени?

• От производства каких изделий нужно отказаться, чтобы справиться с производством данного продукта?

• Сможет ли проект внести вклад в нашу долгосрочную деловую стратегию или защитить другие доходные активы? (Даже некоммерческие или IT-организации придерживаются бизнес-стратегии: они всегда выставляют счета на оплату, стремятся получить доход или имеют для поддержки своей деятельности команды, работающие на извлечение дохода.)

• Как проект поможет нам идти в ногу с конкурентами, обойти или превзойти их?

• На какие рыночные интервалы времени можно нацелить данный проект?

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

Маркетинг – слово совсем не ругательное

Самой несправедливой критике бизнесмены подвергаются в среде «технарей», где их обзывают «торгашами». Я думаю, что маркетинг в данном случае получает удар ниже пояса. В терминологии образовательной программы MBA (Master of Business Administration – магистр делового администрирования) маркетинг можно определить четырьмя «P»: Product (продукция), Price (цена), Placement (распространение продукта) и Promotion (продвижение продукта на рынке). Определение вида продукции и цены – процесс творческий. Его цель состоит в том, чтобы проработать идею продукции, продаваемой с прибылью и отвечающей потребностям определенного покупателя. Чтобы добиться в этом деле успеха, необходимы исследования, анализ и творческая работа. Распространение продукта (третья буква «P») подразумевает способы получения продукта покупателем. (Через веб-сайт? Через супермаркет? Из багажника автомобиля?)

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

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

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

 

Взгляд разработчика

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

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

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

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

• Что именно в соответствии с ним (проектом) требуется сделать?

• Как это будет работать? Как будет работать каждый компонент?

• Как это будет создаваться? Как мы будем проверять, что это работает в соответствии с нашими предположениями?

• Насколько надежны, эффективны, расширяемы и производительны существующие и нами создаваемые системы? Существуют ли пробелы между всем этим и требованиями проекта?

• Какие технологии или архитектуры на данный момент нам полностью доступны? Будем ли мы делать ставку на какую-нибудь новую технологию, которая еще недоступна, но будет вскоре готова к использованию?

• Какие технологические процессы и подходы соответствуют данной команде и данному проекту?

• Какими знаниями и деловым опытом обладают наши специалисты? Работу над чем они приостановят, чтобы заняться данным проектом?

• Чем мы восполним недостаток делового опыта? (Методом проб и ошибок, наймом на работу других специалистов, обучением своих специалистов? Или проигнорируем эти пробелы в надежде, что они волшебным образом исчезнут сами по себе?)

• Сколько времени займет создание продукта и каков при этом будет его уровень качества?

 

Взгляд потребителя

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

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

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

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

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

Потребительский взгляд на проект подразумевает ответы на следующие важные вопросы:

• Чем обычно заняты люди? (Не наши домыслы и не то, что они об этом рассказывают.)

• Какие проблемы они испытывают, стараясь заниматься своим делом? Что их ставит в тупик, смущает или расстраивает?

• Что им нужно или хотелось бы делать, но не представляется возможным?

• Есть ли конкретные возможности сделать продукт проще, безопаснее, быстрее или надежнее для потребителей?

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

• Как можно исследовать подобные идеи? Какие прототипы прикидки или варианты нуждаются в исследовании, чтобы помочь нам осмыслить потенциал проекта?

• Какие основные идеи и концепции должны быть представлены в проекте, чтобы донести информацию до пользователей?

 

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

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

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

Рис. 3.2. Три взгляда на проект

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

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

В прежние годы я и сам порой оказывался втянутым в эти бессмысленные войны. Я был руководителем проекта создания поисковых функций в Internet Explorer 4.0. К нам были назначены два специалиста по развитию бизнеса, которые вели переговоры об использовании основных поисковых машин того времени (Excite, Yahoo! Lycos, AltaVista и т. д.). Мы вели споры с этими экспертами по бизнесу вокруг конструкторских решений, постоянно дебатируя о том, что важнее, интересы клиента или бизнеса. Каждый из нас верил в свою правоту (я выступал за коллектив проектировщиков и разработчиков, а они отстаивали точку зрения бизнесменов). Мы неделями спорили об одном и том же, всегда касаясь конкретных решений и никогда не отступая назад, что позволило бы разглядеть нашу общую скрытую философию, направленную на выпуск качественной продукции. Дела приобрели настолько плохой оборот, что для достижения компромисса пришлось привлечь нашего общего руководителя.

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

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

 

Баланс сил

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

Разумеется, примерное количество людей не определяет объем имеющихся у них полномочий. В армии Наполеона были тысячи солдат, но Наполеон был только один. В команде может быть 10 программистов и 1 специалист по маркетингу (10:1:0), но последний может иметь больше полномочий в рамках проекта, определяющих его роль или старшинство. Это означает, что руководитель в состоянии компенсировать натуральное соотношение, наделяя полномочиями тех, кто должен иметь больше влияние на проект. А поскольку сущность проекта со временем меняется, представители различных взглядов должны в разное время получать различный уровень полномочий. О том, как можно поручать принятие решений для достижения нужного баланса в нужное время, рассказывается в главе 12.

 

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

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

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

• Почему появился этот проект? Почему именно мы подходим для его осуществления? Почему его следует реализовать именно сейчас?

• Что собой представляют три или четыре категории людей, которых можно рассматривать в качестве различных типов потребителей? (Например, для текстового процессора это могут быть студенты, профессионалы и обыкновенные пользователи, для информационной базы данных – продавцы, секретари и руководители.) Как отличаются их потребности и привычки?

• Какая демографическая информация может помочь разобраться в типаже потребителей? (Возраст, заработок, вид компании, профессия, образование, пользование другими программными продуктами или веб-сайтами и т. д.)

• Для каких целей каждой из групп используется программный продукт? В какой степени это соответствует целям покупки? Как это соответствует организации продаж продукта? С какими проблемами они столкнулись при использовании продукта для удовлетворения своих потребностей?

• Кто потенциально может стать новым покупателем и какие характеристики, сценарии работы или типы продукции нам нужно предоставить, чтобы превратить их в реальных покупателей? (Каковы демографические данные этих новых покупателей?)

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

• Можем ли мы создать технологию или набраться опыта для создания продукта, удовлетворяющего этим запросам или решающего эти проблемы? (Да, может быть, нет.)

• Присутствуют ли эти значимые возможности в новом продукте или линейке продуктов? Или связаны ли непосредственно с продуктом (линейкой продуктов) выявленные запросы?

• Существуют ли действенные бизнес-модели для использования нашего делового опыта и технологии в решении выявленных проблем или в удовлетворении запросов? (Смогут ли доходы превысить затраты в обозримом будущем?)

• Какими должны быть сроки выпуска на рынок следующей версии или следующего продукта? В какие благоприятные моменты лучше всего выпустить продукт?

• Чем в этой рыночной нише заняты конкуренты? В чем по нашему мнению заключается их рыночная стратегия и как мы можем с ними конкурировать?

 

Ответы на правильные вопросы

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

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

 

Что делать при дефиците времени?

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

 

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

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

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

Рис. 3.3. Взаимосвязь между уровнями планирования

Черновой вариант каждого входящего в планирование документа должен быть готов как можно раньше, чтобы до выработки окончательной версии включить в него все обратные связи, выработанные командой. Это могут быть простые циклы обратной связи между документами плана, изображенные на рис. 3.3. После создания чернового варианта анализа потребностей рынка – MRD, появится возможность приступить к работе над концептуальным документом, во время которой будут возникать новые вопросы, касающиеся этого анализа, улучшающие документ до его завершения. Эта же схема работы повторяется при разработке всех документов. Таким образом, даже если сроки окончания разработки документов плана поджимают, некоторые перекрытия по времени разработки каждого из них пойдут только на пользу и повысят качество всего процесса. Как показано на рис. 3.4, когда разработка проекта достигает середины (стадии выполнения), распространение вверх по структуре планирования подобных обратных связей дается все труднее, хотя и не исключается. (Можно считать, что рис. 3.4 иллюстрирует работу нанятой по контракту команды, сфера влияния которой ограничена выработкой технических условий и определением характера и объема работ.)

Рис. 3.4. Со временем становится все труднее вносить коррективы в верхние элементы структуры планирования, хотя такая возможность не исключается

 

Повседневная работа

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

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

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

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

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

 

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

Для многих проектов требования являются средством определения их направленности. Требования по определению означают, что команда (с ведома заказчика) к моменту завершения проекта должна их удовлетворить. В наипростейшем смысле определением требований является заказ пиццы с пепперони. Вы объявляете изготовителю пиццы, что вы, собственно, желаете получить. Он может уточнить требования, задавая вопросы («Не желаете ли вы вдобавок минеральной воды?»), или детально обговорить требования («У нас в данный момент нет пепперони, не подойдет ли взамен салями?»). В более сложном случае, при разработке программного продукта, получить качественно выработанные требования намного труднее. Существует множество различных способов интерпретации абстрактных идей, усложняющих процесс выработки требований («Сделайте более высокоскоростной или более отказоустойчивый продукт»).

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

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

В качестве примера далее приводится перечень, полученный в ходе постановки задач по разработке корпоративного веб-сайта:

• С домашней страницы затруднен поиск часто востребуемых разделов.

• Ведомственная информационная страница долго загружается, заставляя пользователя ждать.

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

• Веб-сайт не обеспечивает автоматического доступа к защищенным услугам, а ручной доступ отнимает много времени.

• Результаты поиска трудно просматривать в существующем формате.

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

• Страница состояния не включает информацию об электронной почте, и пользователи не могут узнать, почему их электронная почта не работает.

• Отсутствует способ сохранения предпочтений или вариантов появления домашней страницы.

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

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

 

Проблемы превращаются в сценарии

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

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

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

Итак, возможные характеристики проекта X:

• Часто востребуемые разделы можно будет легко обнаружить на домашней странице.

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

• Веб-сайт обеспечит простой автоматизированный доступ к защищенным услугам.

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

• Ведомственная информационная страница будет загружаться, по крайней мере, так же быстро, как и домашняя страница.

• Интерфейс запросов к базе данных будет по надежности сопоставим с остальными компонентами системы.

• Пользователи получат возможность видеть состояние сервера электронной почты в простом и удобном формате.

• У пользователей будет удобный способ сохранять свои предпочтения при настройке системы.

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

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

 

Объединение деловых и технологических требований

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

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

 

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

Рассмотрение следующих вопросов поможет вам определить структурную сложность и трудоемкость вашего концептуального документа:

• Много ли обоснованных вопросов имеется у самой команды относительно будущей работы? Насколько люди осведомлены о предстоящей работе и о важности ее результатов?

• Сколько разных людей будет вовлечено в реализацию проекта? Сколько различных организаций представляют эти люди? Каким образом вы сможете правильно оценить ожидаемый вклад каждой организации?

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

• В какой мере вы допускаете влияние сторонних организаций на основную направленность проекта?

• Сколько проницательности, компетентности и рассудительности потребуется от руководителя проекта при принятии ключевых проектных решений? (Очевидно, именно эти свойства будут востребованы при выработке концепции.)

• Насколько глубоко команда сможет вмешиваться в стратегию проекта в процессе работы над его реализацией?

• Какие объемы исследований в процессе планирования проекта ожидает от вас руководство? Как вы будете доводить до руководства результаты этих исследований?

• Возникнет ли в последующем необходимость напоминать команде о целях проекта? Склонны ли сотрудники возвращаться к спорам по отдельным положениям, с которыми они совсем недавно согласились?

Чем детальнее и точнее вы ответите на данные вопросы, тем большую ценность приобретет концептуальный документ. Если к вашему проекту относится лишь малая толика вопросов, подход должен быть простым и неформальным. А если вы считаете, что к вашей ситуации подходит большинство вопросов, и при их чтении испытываете какой-то внутренний холодок, значит, вам следует отнестись к ответам на них со всей серьезностью.

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

 

Общекомандные и индивидуальные цели

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

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

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

 Индивидуальные цели. Подраздел общекомандных целей, являющийся сферой ответственности отдельного работника.

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

Рис. 4.2. Три уровня целей

Давайте в качестве примера возьмем некий проект создания корпоративного веб-сайта под названием «Гидра»:

• Концепция. Веб-сайт «Гидра» предоставит удобный доступ к большинству наиболее востребованных источников корпоративной информации (поиск, учет, инвентарь, внутренние ресурсы, перевозки) из единого места с использованием простого и понятного интерфейса.

• Общекомандные цели. Команда А будет отвечать за создание доступных и простых в применении систем поиска и учета. Команда Б будет отвечать за создание систем инвентаризации, учета внутренних ресурсов и перевозок.

• Индивидуальные цели. Фрэд (из команды А) будет заниматься проектированием и разработкой всех функций, необходимых для поисковой системы. Майк (из команды Б) будет курировать все работы по общему устройству веб-сайта и вырабатывать технические условия на создание интерфейса для «Гидры». Боб (из команды Б) будет заниматься проектированием и разработкой всех функций, необходимых для учета внутренних ресурсов и перевозок.

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

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

 

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

 

Простота

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

 

Целенаправленность

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

Для правильной формулировки целей широко используется деловой подход, выражаемый акронимом SMART (Specific, Measurable, Action-oriented, Realistic, Timely – точность, измеряемость, действенность, реалистичность, своевременность). Идея состоит в том, что если цель соответствует этим пяти требованиям, то, скорее всего, она достаточно хорошо определена для дальнейшего использования (тем не менее остаются субъективные рассуждения о том, насколько конкретной или реалистичной должна быть цель). При формулировке цели можно воспользоваться и другим приемом – отнестись к ней максимально придирчиво и задаться вопросом, не провалится ли проект, если его цель будет достигнута в точном соответствии с ее формулировкой. Затем нужно подумать, а нельзя ли более точно сформулировать цель, нет ли какой-нибудь дополнительной, уточняющей информации.

 

Консолидирующая способность

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

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

 

Вдохновляющая способность

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

 

Запоминаемость

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

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

 

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

 

Простота дается не легко

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

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

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

 

У хорошей разработки только один главный автор

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

Каноническим примером единоличного авторства служит Декларация независимости США. В 1776 году Континентальный конгресс сформировал комиссию для выработки этого документа. Комиссия собиралась несколько раз, однако осознав особую важность такой характеристики документа, как доходчивость, поручила разработать проект Томасу Джефферсону. Джефферсон поступил так же, как я рекомендую поступать и команде проектировщиков, – он разработал множество проектов и принял участие в их обсуждении в Конгрессе, по нескольку раз пересматривая некоторые из них. Несколько недель спустя, группа представила Конгрессу окончательный вариант документа. Автор не должен быть постоянно на виду, Джефферсон в процессе работы над Декларацией не занимался сбором подписей и согласованиями. Он просто получил полномочия и использовал свой талант во благо всей группы разработчиков.

 

Качество не определяется объемом

Следует понимать, что ясная мысль не требует многостраничного изложения. Самые действенные руководящие документы в мире не отличались большим объемом. Конституция США, включая Билль о правах, содержит всего лишь 7000 слов (около 6 страниц). Десять заповедей состоят из 300 слов. Великая хартия вольностей – из 5000. Светлые головы способны извлечь из идей самую суть и выразить их намного доходчивее любых описаний, занимающих вдвое больше места. Не следует путать понятия объема и качества. К сожалению, из-за того, что объем дается легче, чем качества, мы иногда поддаемся следующему искушению: «Если ничего хорошего не выходит, то можно выиграть хотя бы за счет объема, а вдруг никто не заметит разницы» (еще одна привычка в работе авторитетных комиссий). Итак, с учетом всего вышеизложенного, вполне уместно спросить меня о том, почему же я не сократил объем этой книги. Виноват, не смог.

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

 

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

Вот примеры вполне удачных концептуальных положений:

• SuperEdit 3.0 – это инструмент редактирования, предназначенный для опытных литературных редакторов, позволяющий облегчить их работу, ведущуюся по пяти самым распространенным сценариям, более надежный и быстродействующий по сравнению с SuperEdit 2.0.

• Superwidgets.com станет ведущим веб-сайтом Интернета, предназначенным для приобретения разного рода небольших приспособлений и устройств снабженцами средних по величине компаний. Он сделает весь процесс приобретения простым, легким и надежным.

• В версии 5.5 Helpdesk Automated Services Site (HASS) будут учтены десять самых распространенных претензий, предъявленных пользователями из числа преподавателей и студентов университета, при этом исключаются любые негативные влияния на среднюю производительность, надежность или на время отклика системы.

В качестве примера удачных целей проекта приводится перечень, использовавшийся разработчиками наладонного органайзера Palm Pilot:

1. Габариты. Устройство должно помещаться в карман рубашки, быть достаточно легким, чтобы не выглядеть громоздким.

2. Стоимость. Устройство должно стоить меньше, чем органайзер элитного класса (около 300 долларов США).

3. Простота. Устройство должно быть в обращении не сложнее бумажного листка, готово к работе сразу после включения и иметь простые элементы управления.

4. Синхронизация с персональным компьютером. Компьютер должен стать основным средством взаимодействия с пользователем.

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

 

Обоснование концептуальных положений и целей

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

 

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

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

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

 

Наглядное представление неочевидных вещей

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

Существует множество способов визуализации идей, сколь бы абстрактными или технократическими они ни казались. Если проект позволит пользователям проводить меньше времени за рабочим столом, нарисуйте рядом с этим столом пустой стул. Если проект ускорит работу базы данных, покажите два демонстрационных ролика, отражающих ее работу до и после. Если отказоустойчивость встроенной системной API-функции повысится на 10 %, предоставьте показания тестовой программы, используемой для измерения данного параметра до и после реализации проекта. Как бы это ни было скучно для команды, но ей нужно дать наглядное представление о границах индивидуальной работы.

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

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

 

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

Рис. 5.1. Проектирование зачастую выглядит как некий таинственный переход от первичного планирования к выработке технических условий

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

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

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

 

Качественные требования и ошибки

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

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

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

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

 Постарайтесь отыскать все ошибочные предположения. Требования нередко основаны на мнимых предположениях о потребностях или желаниях заказчиков или пользователей. Формирование списка возможных требований может вестись по электронной почте или в виде неформальных перечней, и каждый может предположить, что их тщательное исследование и всестороннее рассмотрение проведено кем-то другим. Если вы руководите проектом, то подобных предположений делать не стоит. Вы должны настойчиво задавать уточняющие вопросы, такие как «Зачем это нужно?», «Какую проблему с помощью этого требования можно решить?», «Кто выдвинул это требование?» Подобные вопросы помогают высветить истинную суть предположений. Помните, что людям свойственно заблуждаться или неосознанно распространять ложную информацию.

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

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

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

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

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

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

 

Исследование проекта

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

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

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

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

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

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

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

 

Страх перед просчетами и размышления о прогрессе

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

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

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

 

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

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

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

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

 

С чем сравнивать, хорошо это или плохо?

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

Существует и иной подход к оценке идеи. Открытие формулы E = mc2 стало для Эйнштейна его звездным часом, но для любителя этой формулы, пытающегося свести концы с концами, или для человека, потерявшегося где-то в пустыне Сахара (не говоря уже о тех, кто потерялся в пустыне и при этом испытывает материальные затруднения), это открытие оказалось совершенно бесполезным. Так хороша или нет идея, заключенная в формуле E = mc2? Возможно, она будет хороша, если вы расширите область требований и пространство решения проблем, чтобы включить в них общую идею о совершенствовании ваших знаний о вселенной. А возможно и нет, когда все, что вас тревожит на данный момент, – это судьба друга, затерявшегося где-то в Сахаре. Идеи выглядят хорошими или плохими лишь на фоне различных обстоятельств. Независимо от того, насколько гениальными они представлялись при абстрактной оценке, когда они вносятся в проект, который направлен на создание реальных вещей, предназначенных для решения реальных проблем, ошибки, допускаемые при попытке отличить абстрактный подход от прагматичного, всегда приводят к неприятностям.

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

 

Чтобы избежать выполнения ряда нежелательных требований, предъявляемых в колледже, для получения степени бакалавра я изучал теорию логики и философию. Многое я, конечно, выучил и забыл, но среди того, что запомнилось с тех времен, был и вопрос о том, как задавать хорошие вопросы. У меня было развито чувство логики, но я был единственным новичком в выпускных классах теории логики, поэтому обычно (а точнее, всегда) отставал от остальной группы. Я быстро понял, что нужно задавать однокашникам и профессорам четко сформулированные вопросы, иначе меня завалят грудой непонятной и бесполезной для меня информации. Я обнаружил, что множество инженеров, докторов и других представителей интеллигенции с радостью готовы поделиться своими знаниями независимо от того, о чем я их спрашиваю. Люди порой могут теряться и в собственных знаниях.

Четко заданные вопросы являются одним из способов вести сложные переговоры в нужном направлении. Я могу привести пример из личного опыта общения с профессорами логики, заставлявшими меня обращать пристальное внимание на то, как я задаю вопросы. Все могло начинаться с моего вопроса типа: «Не могли бы вы объяснить вот эту часть теоремы незавершенности Геделя?» Профессор мог ответить следующим образом: «Разумеется. Вы понимаете, все методы доказательств могут быть сведены к основному набору характеристик, определяемых основными рекурсивными первичными функциями». Я мог сказать: «Ну, да. Хорошо. Но не могли бы вы объяснить вот эту строку?» и указать на маленькую строчку доказательства, очерченную толстой красной линией с нарисованным рядом огромным вопросительным знаком. Профессор мог кивнуть головой и сказать: «Ну, конечно <пауза>. Итак, история методики доказательств берет свое начало от замечательной попытки выражать аспекты существования через систему, поддающуюся проверке…» Я мог сказать: «О, боже. Нет, я имею в виду вот это <показываю снова>. Что означает это место? Как оно соотносится с верхней строкой?» Он мог ответить: «Да, да. Понимаете, теория доказательств относится к математической логике, поскольку лемма неосязаемости между наборами неупорядоченных, но бесконечных значений…» В конце концов, я обычно бросал эту затею и направлялся в ближайшую пивную.

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

Творческое решение проблем предполагает три вида вопросов: концентрирующие внимание (хорошие), относящиеся к творческому процессу (тоже хорошие) и риторические (вредные).

 

Вопросы, концентрирующие внимание

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

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

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

Какую именно проблему вы пытаетесь решить?

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

 

Креативные вопросы

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

 

Риторические вопросы

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

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

 

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

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

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

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

 

Хорошие проекты рождаются из множества хороших идей

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

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

 У архитектора два самых главных инструмента: в студии – ластик, на строительной площадке – кувалда (Фрэнк Ллойд Райт).

 Самый важный инструмент физика – мусорная корзина (Альберт Эйнштейн).

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

 Неудач не бывает. Бывают лишь слишком ранние отказы от продолжения работы (Джонас Солк).

 Лучшие способы есть всегда, их только надо найти (Томас Эдисон).

 Неудача. Опять неудача. Почти что удача (Сэмьюэл Бэкет).

 Если хотите достичь успеха, удвойте квоту неудач (Том Уатсон, IBM).

 На одну страницу шедевра у меня приходится 99 страниц мусора (Эрнест Хемингуэй).

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

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

 

С подачи Оука Юксела (Ayca Yuksel) и Ванессы Лонгакрэ (Vanessa Longacre), двух бывших сотрудников компании Microsoft, вся наша троица записалась в общественный колледж в класс импровизационной комедии. После первого же дня я понял, что мой страх выставить себя на посмешище перед командой совершенно не обоснован. Я узнал, что большинство людей, если они учатся замечать что-нибудь вокруг себя (чему нас и учили в этом классе), смогут находить смешное во многих совершенно заурядных ситуациях. Учеба часто позволяет видеть вещи, обычно ускользающие от внимания, и строить взаимосвязи между ними.

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

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

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

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

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

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

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

 

Правила импровизации для генерации идей

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

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

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

1. Да, и вот еще что… Когда кто-нибудь другой предлагает некую мысль, допускается лишь одна реакция: «Да, и вот еще что <далее следует соответствующее продолжение>». Вашим первым побуждением должно стать продолжение его направления мысли. Обычно вы подхватываете его идею или точку зрения и продвигаете их дальше или меняете их направление, к примеру: «Мы можем использовать поисковое поле вот здесь…», «Да, и разумнее было бы после того, как пользователь что-нибудь ввел, перевести его взгляд в нужное место». Или: «Да, и вот еще что, здесь нужно воспользоваться тем самым новым поисковым движком, который мы создаем, и ускорить выдачу результатов». Все внимание направлено на то, чтобы развитие дискуссии шло в позитивном направлении и вырабатывалась привычка прислушиваться к другим участникам, помогая в развитии предложенных ими идей, а не выжидая благоприятного момента для высказывания собственных.

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

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

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

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

 

Другие подходы к генерации идей

Если вы не готовы к импровизационным играм или хотите подойти к генерации идей более прямолинейно, то вам подойдет ряд традиционных предложений:

 Подберите себе книгу по творческому мышлению. Существует немало хороших книг на выбор. Две мои самые любимые – «Thinkertoys» Майкла Майкалко (Michael Michalko) (Ten Speed Press, 1991) и «Six Thinking Hats» Эдварда Де Боно (Edward De Bono) (Back Bay Press, 1999). Существует множество других популярных книг, которые по-своему тоже хороши, но наибольшую пользу я сумел извлечь их этих двух.

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

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

 Купите колоду карт для мозговой атаки, ThinkPak, созданную Майклом Майкалко (Michael Michalko). Эта колода игровых карт разработана для того, чтобы помочь человеку или группе придумывать новые идеи в любой области деятельности. Можно найти и другие подобные наборы, но мне все же больше помог именно этот.

 

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

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

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

Рис. 6.1. Пространство решения проблем по мере приближения к контрольной точке должно сужаться

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

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

Причины этого явления могут быть разными.

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

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

 Обнаруживается конфликт двух решений двух разных проблем, и эти решения при объединении идут во вред друг другу. Это может произойти по разным причинам, касающимся потребительских качеств, деловых интересов или конструкторской несовместимости. У Джо может быть фантастическая конструкция автомобильного двигателя, а у Салли – великолепная конструкция трансмиссии, но когда все это объединяется в единую конструкцию, они видят, что по некоторым показателям их создания конфликтуют друг с другом, например трансмиссия не подходит к двигателю.

 

Изменения вызывают цепную реакцию

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

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

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

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

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

Применительно к практике проектирования, итерация означает два шага вперед, шаг назад. Чем труднее и сложнее работа, тем больше это соотношение стремится к равенству (например, полтора шага вперед на каждый шаг назад). Но пока вы не сделаете этот шаг вперед и не примете какое-нибудь решение («Давайте создавать конструкцию Б!»), вы не сможете вскрыть все проблемы и вопросы. Принятие решений в процессе проектирования, даже если они окажутся неверными, – единственный способ вывести проблемные вопросы на поверхность. Если вы все правильно спланируете, то все равно будете многократно спотыкаться при проектировании, но, пройдя все это, вы значительно повысите свои шансы на успех. Большинство инженерных, конструкторских и научных изысканий следуют тем же принципам, выраженным следующей цитатой Джошуа Ледерберга (Joshua Lederberg), лауреата Нобелевской премии 1958 года:

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

 

Творчество – процесс инерционный

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

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

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

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

Рис. 6.2. Пространство решения проблем расширяется и сужается в процессе проектирования под воздействием непредвиденной инерционности творческого процесса

 

В любом творческом процессе, как только накопится достаточное количество идей, кто-то должен оценить возможности их применения и разложить их по подходящим стопкам. В результате появится возможность осмыслить различные жизнеспособные проектные направления и приступить к рассмотрению имеющихся различий. (Как правило, проще работать с четырьмя или пятью стопками, чем с 30, 50 или 150 отдельными экземплярами. Это правило применимо к идеям, техническим условиям, шаловливым детям, мелким животным, конфетам, назойливым писателям, сочиняющим бессмыслицу и т. д.) Вполне нормально, когда часть идей представлена в виде прототипов, а другая часть – в виде набросков, заметок или неисследованных мыслей. Цель заключается не в отбраковке или уточнении отдельных идей, а в создании вокруг всего этого некой формы и структуры.

Для этого существует масса технологий, но самая простая из тех, что я знаю, – это созданная антропологом Кавакита Джиро (Kawakita Jiro) диаграмма сходства (также известная как KJ-диаграмма). Реализованный в этой диаграмме подход требует наличия четырех составляющих: идей, стены, клейких листочков и команды (хотя пиво с закуской тоже не помешают). В диаграмме сходства каждая идея представляется заметкой из нескольких слов, приклеенной к стене. Идеи могут быть результатом мозговых атак или перечнем, составленным силами одного-двух человек из команды. Может быть от двадцати до ста идей, а то и больше. Круг решаемых проблем и творческие способности людей ведут к невероятному разбросу в количестве идей от проекта к проекту.

Диаграмма сходства позволить расширить ваш взгляд на идеи в целом. Она должна быть похожа на то, что представлено на рис. 6.4. Некоторые идеи близки – такие идеи имеет смысл разместить где-то поблизости друг от друга, чтобы их было легче идентифицировать. Визуальная работа позволяет людям сконцентрироваться на взаимосвязях, а не на том, сколько информации они смогут удержать в собственной голове. Диаграммы сходства обладают также тем преимуществом, что позволяют обсуждать характеристики той или иной идеи. Небольшая группа людей может стоять вместе у стены и комментировать замеченные взаимосвязи, переклеивая листочки с одного места на другое, приходя к новому заключению. Использование в диаграмме сходства клейких листочков обусловлено возможностью их многократного перемещения по стене и простотой получения различных комбинаций.

Рис. 6.4. Когда идей много, справиться с ними нелегко

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

Рис. 6.5. Неплохо было бы сгруппировать идеи

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

• убрать дополнительные элементы управления, которыми никто не пользуется;

• улучшить формат страницы результатов поиска;

• использовать улучшенную поисковую машину HyperX;

• сократить количество одновременно отображаемых результатов;

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

• открывать результаты в новом окне;

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

• провести доводку системы обработки запросов (включить поддержку логического поиска).

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

• Упростить:

• убрать дополнительные элементы управления, которыми никто не пользуется;

• улучшить формат страницы результатов поиска;

• сократить количество одновременно отображаемых результатов.

• Сориентировать на потребителя:

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

• открывать результаты в новом окне.

• Реконструировать архитектуру:

• провести доводку системы обработки запросов (включить поддержку логического поиска);

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

• использовать улучшенную поисковую машину HyperX.

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

 

Оптимизация и расстановка приоритетов

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

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

Последнее, что нужно обдумать, – примерную расстановку идей по приоритетам (вопросы формального деления по приоритетам рассматриваются в главе 12). Какие идеи являются наиболее многообещающими? Обратитесь к концепции проекта и к решаемым проблемам и добейтесь общего понимания реальных оценочных критериев, поскольку в идеи нетрудно влюбиться на основаниях, никак не связанных с целями проекта. Этим процессом должен управлять кто-то один, либо руководитель проекта, либо ведущий проектировщик. Чем неформальнее будет дискуссия, тем меньше времени на нее уйдет. Необязательно составлять сложный контрольный список критериев и оценочных процедур. Перед тем как перейти к разработке прототипа, вам понадобится всего лишь примерная прикидка, какое из направлений представляется более перспективным. Это позволит правильно распорядиться временем в условиях его дефицита.

 

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

 

С чего начинаются прототипы?

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

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

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

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

• Учтите мнение проектировщика: разрешите ему воспользоваться собственным опытом и интуицией для решения, что нужно использовать в первой попытке.

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

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

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

 

Прототипы для проектов с пользовательским интерфейсом

Прототипы должны создаваться последовательно, сверху вниз. Начните с того, что должны видеть пользователи, и в той последовательности, в которой они все это должны видеть. Для получения вполне обоснованных замыслов и предположений с самого начала привлеките к работе своих специалистов по потребительским свойствам и дизайну. Пока не будут созданы несколько экранов, нет смысла тратить дни на выработку структур баз данных и XML-схем – это все равно что возводить стены дома еще до того, как вы узнали его планировку. Если вы это сделаете, потеря качества конечного продукта вам гарантирована – именно от этого и призваны защищать прототипы.

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

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

 

Прототипы для проектов без пользовательского интерфейса

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

 

Прототипы – это опора программистов

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

Вот краткий перечень вопросов, на которые программисты должны ответить в данный период:

• Как в целом мы будем реализовывать все представленное в дизайнерском прототипе (или прототипах)? Существует ли готовый код или технология, которую нужно или можно использовать в этих целях?

• Возможны ли разумные поправки дизайна, сокращающие инженерные затраты, о которых нужно уведомить проектировщика?

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

• В чем заключаются наибольшие технические риски? Какие компоненты труднее или сложнее всего реализовать?

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

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

 

Альтернативные варианты повышают вероятность успеха

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

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