Хорошие идеи даются нелегко, но еще труднее ими правильно распорядиться. Как только проекту дан полный ход, концептуальный документ составлен и могучие творческие силы рвутся в бой, должен наступить следующий этап размышлений: как превратить замыслы и идеи проектировщиков в конкретные решения? Даже если удачные замыслы и идеи проходят тщательные исследования и люди всецело увлечены этой работой, сложности со сведением всех предыдущих наработок к техническим условиям все равно остаются. Если переход к окончательным проектным решениям своевременно не состоится и не будет должным образом направлен руководством, ждите беды. По ряду причин именно здесь начинаются все проектные неудачи.
Если команда все еще бьется над тем, чтобы выдать свои важные решения в тот самый день, когда технические условия, точнее решения, которые в них содержатся, должны попасть на стол к программистам, то будет задан тон всей остальной работе над проектом: пойдут задержки, недоделки, и люди не смогут проявить свои лучшие качества. Куда тревожнее, если все завершается в срок, но качество идей, отражаемых в конструкции проекта, оказывается низким, тогда эта своевременность просто ни к чему. В зависимости от целей проекта качество реализации идей может значить ничуть ни меньше, если не больше, чем соблюдение сроков.
По этим причинам период времени между завершением первичного планирования и составлением технических условий всегда и на любой стадии работы дается нелегко. Команды, естественно, испытывают крайнее напряжение, когда на горизонте замаячит первый основной контрольный срок (то есть срок сдачи технических условий). Даже если люди не говорят об этом, многие понимают, что не все пока еще обсуждаемые идеи могут выжить. Может не хватить времени, средств или людей для создания всего, что находится в сфере обсуждения. Люди начинают задумываться о способах, которые позволили бы снять с себя ответственность или сгладить углы. Хуже того, некоторые идеи и замыслы могут конфликтовать друг с другом. У автомобиля может быть только один двигатель, а у дома – лишь одна крыша, и если предлагаются три разных варианта, понятно, что большинство из них не пройдет.
Идеи выходят из-под контроля
С данным периодом времени связано одно довольно грустное наблюдение: в воздухе витает масса хороших идей, которым, вероятно, так и не суждено будет где-нибудь приземлиться. Возможно, самым худшим, что было в моей карьере на данном этапе проекта, связано с созданием Internet Explorer 4.0. (Если вам не интересно в очередной раз читать про войну, можете сразу переходить к следующему разделу.)
Помню, я сидел в своем офисе, уставившись на доску для набросков. Вместе с другим руководителем проекта мы нарисовали диаграмму расширенной проектной команды и всех текущих разработок. Как только мы считали диаграмму завершенной, как вспоминались какие-нибудь новые требования, которые нужно было добавить или изменить. Когда мы закончили диаграмму, она занимала все пространство доски. Внезапно мой коллега заторопился на какую-то встречу, а я остался в офисе один на один с этой запутанной диаграммой.
Я проделал уйму работы, но все равно сидел и всматривался в диаграмму. Я ничего не мог понять. Масштабность и взаимопроникновение всех проблем, которые мы пытались решить, не позволяли мне удержать в голове общую картину. Мне нравилась моя команда и работа, которой мы занимались, но это не спасало меня от нарастающего чувства отчаянья. Я не мог понять, как нам удастся завершить начатое. Хотя это нагромождение на доске было многообещающим и содержало массу разумных вещей, тем не менее все выглядело слишком беспорядочно. Один из сотрудников команды просунул голову в дверь моего офиса, увидел выражение моего лица и диаграмму, на которую я уставился, и все сразу понял. Он сочувственно бросил: «Эй, почувствуй себя влюбленным!» – и эта фраза стала нашим своеобразным девизом на все оставшееся время работы над проектом.
В первые месяцы существования проекта IE 4.0 мы получили настоящий вал программ. Параллельно мы пытались перейти от небольших команд и релизов (а-ля IE 2.0 и 3.0) к выпуску главного продукта. Мы были вовлечены в гонки, развернувшиеся между компаниями Microsoft и Netscape, из которых пресса раздула войну не на жизнь, а на смерть. А затем наш продукт перешел в разряд стратегических уже в соответствии с внутренней политикой компании. В таких условиях любому было бы нелегко удержать судно на плаву. И, как и в большинстве проектов, стоило только наступить переходному моменту от планирования к разработке, как возникло столкновение мнений и амбиций. Людям пришлось принимать первые трудные для себя решения, они почувствовали груз ответственности. На фоне явного нарастания неуверенности и напряженности одно оставалось неизменным – сроки. На горизонте нетерпеливо маячила очередная календарная дата, приближавшаяся с наступлением каждого следующего дня.[35]
Решение, которому посвящена данная глава, заключается в умении грамотно разобраться в пространстве возможных замыслов. Кто-то должен спланировать работу и поэтапно провести команду по пути от исследований к выработке технических условий. Если под рукой нет ни одного корифея проектирования или разработки (в предыдущей главе мы говорили, что это было бы наилучшим выходом из положения), бремя этой работы придется взвалить на плечи первого попавшегося руководителя проекта. Подхватывая эстафету у главы 5, мы возвращаемся к тому моменту, когда идея уже родилась, и продолжаем путь по направлению к выработке технических условий (которые станут темой следующей главы).
Управление идеями требует твердой руки
Наиболее распространенной ошибкой является представление процесса проектирования в виде своеобразного рубильника, который можно включать и выключать, когда захочется. Развивая эту фантазию, можно представить следующий ход событий: однажды вы обнаруживаете, что сроки поджимают, а в вашем распоряжении еще слишком много идей и замыслов (и слишком мало готовых решений), но вы говорите команде: «Итак, с идеями мы покончили. Берите проект и приступайте к программированию. Вперед!» Даже если представить, что в вашем распоряжении вполне зрелый проект (чего на самом деле быть не может), подобное непредсказуемое поведение собьет с толку и дезориентирует всю команду. Вплоть до этого момента все занимались проектом, для окончательной готовности которого требовалось время. Без указания конкретной даты у них могло сложиться впечатление, что они имеют право принимать важные решения вплоть до 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. Пространство решения проблем расширяется и сужается в процессе проектирования под воздействием непредвиденной инерционности творческого процесса
Контрольные точки фаз проектирования
Чтобы наилучшим образом распорядиться идеями, нужно начинать любой серьезный проект с расстановки четких контрольных точек, задающих распределение времени. Перед тем как творческий процесс пойдет в полную силу, в дополнение к двум контрольным точкам, моменту окончания выработки требований (формулировки проблем) и моменту выдачи технических условий, нужно определить еще ряд промежуточных точек. Расставить эти точки во времени (и убедить всех в их пользе) – задача руководителя проекта, хотя, может быть, лучше, чтобы проектировщики и разработчики сами определили, где именно их следует расставить и какими должны быть критерии их достижения.[36] Для этого существует масса различных способов, и лучшие из них варьируются от проекта к проекту и от команды к команде. Однако, исходя из практического опыта, на временной шкале можно рекомендовать несколько ключевых точек (рис. 6.3).
Концепция и доказательства ее состоятельности. Если концептуальный документ подкреплен соответствующим прототипом, проектирование и творческие усилия получат мощный стартовый рывок. Замысел проектировщиков и концепция разработчиков будут уже готовы к проведению исследований и принятию рабочего варианта (или отказа от него, но на основе углубленного осмысления проблемы). Если концепция в свое подтверждение не имеет хотя бы весьма приблизительного прототипа, она не может считаться хорошей.
Группировка идей (составление перечня). После первоначального всплеска новых идей и возможных подходов кому-то нужно привести их в порядок и объединить. Для этого должен быть назначен ожидаемый командой срок, с прицелом на который она сможет строить свою работу.
Три альтернативных варианта. После того как будет пройдена половина пути, придется сузить пространство возможных замыслов в направлении трех-пяти альтернативных вариантов. Чем сложнее проект, тем больше должно быть альтернативных вариантов. Насколько каждый вариант отличается от других, зависит от агрессивности (или консервативности) проекта, от уверенности проектировщиков в своих силах и от характера проблем, решаемых в рамках проекта.
Два альтернативных варианта. Проведение исследований, изысканий, создание прототипов и постановка вопросов продолжаются по всем направлениям, пока не появится возможность с полной уверенностью свести все к двум альтернативным вариантам. Должно быть два четких направления, которые определяют самое главное из оставшихся решений.
Единый замысел. Проведение исследований, изысканий, создание прототипов и постановка вопросов продолжаются, пока не появится возможность выбрать окончательное направление.
Технические условия. Происходит документальное оформление единственного принятого замысла. Оставшееся время следует использовать для исследований, обдумываний и принятия решений по второстепенным проектным разногласиям.
Рис. 6.3. Контрольные точки процесса проектирования
Все контрольные точки должны быть определены командой примерно ко времени готовности концептуального документа. При напряженном графике работ уменьшите число контрольных точек или пропустите несколько промежуточных точек. А если ресурсов для всех указанных контрольных точек не хватает, остановите выбор на наиболее важных задачах проектирования.
Важно понять, что эти контрольные точки используются не только для управления процессом. Они также служат средством управления командой, позволяют разделить работу на управляемые части и дают руководителю проекта средство определения его текущего состояния. Когда возникают какие-нибудь изменения, контрольные точки служат всем основой для обсуждения, что именно и почему произошло. К примеру, после того как все свелось к трем альтернативным вариантам, могут появиться новые идеи или сведения, временно расширяющие пространство альтернативных вариантов до четырех или пяти. Это может означать, что интерес к проектированию еще не утрачен и проект усиливается новым осмыслением. Но это также может означать, что исследуются совершенно ненужные направления. Контрольные точки заставляют команду разобраться в ситуации и понять, когда пространство расширяется больше допустимого. Контрольные точки создают естественную возможность для руководителей проектов и руководимых ими команд обсудить, насколько агрессивны или консервативны они должны быть в последующих решениях, чтобы выдержать график реализации проекта.
ПРИМЕЧАНИЕ
Подобные контрольные точки могут использоваться на уровне проекта или для проработки любого отдельного вопроса проектирования, от особенностей до алгоритма. На них строится тактика ведения работы, применимая в любых масштабах.
По собственному опыту я знаю, что с самыми ранними контрольными точками очень трудно угадать, а специалистам их проще всего игнорировать. Если вы сможете справиться с первыми шагами, будет сформирована здоровая основа для остальной части творческого процесса. Люди оценят все по достоинству и втянутся в процесс. Поэтому обратите особое внимание на несколько первых контрольных точек. Для особо неуправляемых команд упрощение процесса до трех контрольных точек – формулировки проблем, рассмотрения трех вариантов и выработки технических условий – на первое время может стать вполне реальным компромиссом (в главе 10 вопросы формирования и утверждения процесса командной работы рассмотрены более подробно).
Как объединить идеи
В любом творческом процессе, как только накопится достаточное количество идей, кто-то должен оценить возможности их применения и разложить их по подходящим стопкам. В результате появится возможность осмыслить различные жизнеспособные проектные направления и приступить к рассмотрению имеющихся различий. (Как правило, проще работать с четырьмя или пятью стопками, чем с 30, 50 или 150 отдельными экземплярами. Это правило применимо к идеям, техническим условиям, шаловливым детям, мелким животным, конфетам, назойливым писателям, сочиняющим бессмыслицу и т. д.) Вполне нормально, когда часть идей представлена в виде прототипов, а другая часть – в виде набросков, заметок или неисследованных мыслей. Цель заключается не в отбраковке или уточнении отдельных идей, а в создании вокруг всего этого некой формы и структуры.
Для этого существует масса технологий,[37] но самая простая из тех, что я знаю, – это созданная антропологом Кавакита Джиро (Kawakita Jiro) диаграмма сходства (также известная как KJ-диаграмма). Реализованный в этой диаграмме подход требует наличия четырех составляющих: идей, стены, клейких листочков и команды (хотя пиво с закуской тоже не помешают). В диаграмме сходства каждая идея представляется заметкой из нескольких слов, приклеенной к стене. Идеи могут быть результатом мозговых атак или перечнем, составленным силами одного-двух человек из команды. Может быть от двадцати до ста идей, а то и больше. Круг решаемых проблем и творческие способности людей ведут к невероятному разбросу в количестве идей от проекта к проекту.
Диаграмма сходства позволить расширить ваш взгляд на идеи в целом. Она должна быть похожа на то, что представлено на рис. 6.4. Некоторые идеи близки – такие идеи имеет смысл разместить где-то поблизости друг от друга, чтобы их было легче идентифицировать. Визуальная работа позволяет людям сконцентрироваться на взаимосвязях, а не на том, сколько информации они смогут удержать в собственной голове. Диаграммы сходства обладают также тем преимуществом, что позволяют обсуждать характеристики той или иной идеи. Небольшая группа людей может стоять вместе у стены и комментировать замеченные взаимосвязи, переклеивая листочки с одного места на другое, приходя к новому заключению. Использование в диаграмме сходства клейких листочков обусловлено возможностью их многократного перемещения по стене и простотой получения различных комбинаций.
Рис. 6.4. Когда идей много, справиться с ними нелегко
Целью составления диаграммы сходства является достижение картины, похожей на ту, что изображена на рис. 6.5. Тот же самый «сырой» перечень идей теперь сгруппирован в пять областей, представляющих большинство доступных идей. Способ группировки довольно прост. Кто-то подходит к стене и начинает перемещать идеи. Ведущий проектировщик, руководитель проекта или небольшая команда берет на себя инициативу и пытается объединить идеи. Как только кто-нибудь предпримет первую попытку внести изменения, другим сразу станет легче перемещать идеи между группами, менять названия групп или определять, что некоторые идеи дублируют друг друга и могут быть удалены. По мере того как люди из команды будут вносить коррективы, диаграмма претерпит по форме множество интересных изменений. (Один совет: потрудитесь периодически делать цифровые снимки, если хотите сохранить варианты группировки, придуманные вашими людьми.) В конце концов, диаграмма сходства стабилизируется и появляются варианты группировки, которые можно использовать в следующих этапах.
Рис. 6.5. Неплохо было бы сгруппировать идеи
В случае если я дал слишком абстрактное описание работы над диаграммой сходства, вот вам пример, трактующий изображенное на рис. 6.5 несколько иначе. Скажем, одной из целей проекта было упрощение использования результатов поиска на корпоративном веб-сайте. Мы встретились, провели мозговую атаку, попили пиво и навыдумывали длинный перечень идей. На следующее утро у людей появился еще ряд идей, которые мы тоже включили в перечень. Мы проанализировали этот перечень, исключили дубликаты, посмеялись, наталкиваясь на идеи, в которых никто из нас не мог разобраться, и получили исходный перечень идей для работы:
• убрать дополнительные элементы управления, которыми никто не пользуется;
• улучшить формат страницы результатов поиска;
• использовать улучшенную поисковую машину HyperX;
• сократить количество одновременно отображаемых результатов;
• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;
• открывать результаты в новом окне;
• устранить ошибки, замедляющие работу поисковой машины;
• провести доводку системы обработки запросов (включить поддержку логического поиска).
После пересмотра перечня и использования клейких листочков или иного метода группировки идей мы потратили полчаса на их упорядочение. Мы перемещали их с места на место, пробовали различные варианты группировки и остановились на списке, который представился нам наиболее подходящим.
• Упростить:
• убрать дополнительные элементы управления, которыми никто не пользуется;
• улучшить формат страницы результатов поиска;
• сократить количество одновременно отображаемых результатов.
• Сориентировать на потребителя:
• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;
• открывать результаты в новом окне.
• Реконструировать архитектуру:
• провести доводку системы обработки запросов (включить поддержку логического поиска);
• устранить ошибки, замедляющие работу поисковой машины;
• использовать улучшенную поисковую машину HyperX.
Представленная здесь группировка элементарно проста, и поскольку в ней всего восемь идей, она безупречна. Но если бы она состояла из 40 или 50 идей, не все пошло бы столь гладко. В списках отражаются предположения о линейных и иерархических зависимостях, поэтому с длинными списками справиться намного труднее. Позднее, в процессе разработки, списки придают процессу неплохое ускорение, но на ранних стадиях диаграммы сходства намного эффективнее. Они помогают людям рассматривать идеи в качестве подвижных и осязаемых объектов, способных к перемещениям и перегруппировкам. Эта подвижность позволяет людям подвергать сомнению их предположения, видеть новые перспективы и воспринимать мысли других. Для команд, не искушенных в творческом мышлении (особенно в составе группы), диаграмма сходства является великолепным выходом из положения. Позднее вы, как руководитель проекта, можете воспользоваться списками для своих собственных целей, но сначала дайте команде поработать над сходствами. Я убежден, что такая работа помогает людям втянуться в процесс и отыскать больше удачных идей.
Оптимизация и расстановка приоритетов
Не старайтесь добиться наилучшего варианта группировки, лучшее – враг хорошего. Существует немало вариантов группировки даже небольшого количества идей, и многие из них дают хорошие результаты. Целью должно быть создание четырех или пяти групп, охватывающих различные области или обозначающих различные направления. Некоторые идеи просто не укладываются ни в одну из групп, но вам все равно следует поработать над ними в полную силу.
Следует помнить, что если понадобится, позже можно будет вернуться к идеям и перегруппировать их заново. Как только вы найдете вполне приемлемый вариант, идите дальше. Вам же не нужно предоставлять диаграммы сходства или списки идей конечному пользователю, поэтому и не стоит перенапрягаться.
Последнее, что нужно обдумать, – примерную расстановку идей по приоритетам (вопросы формального деления по приоритетам рассматриваются в главе 12). Какие идеи являются наиболее многообещающими? Обратитесь к концепции проекта и к решаемым проблемам и добейтесь общего понимания реальных оценочных критериев, поскольку в идеи нетрудно влюбиться на основаниях, никак не связанных с целями проекта. Этим процессом должен управлять кто-то один, либо руководитель проекта, либо ведущий проектировщик. Чем неформальнее будет дискуссия, тем меньше времени на нее уйдет. Необязательно составлять сложный контрольный список критериев и оценочных процедур. Перед тем как перейти к разработке прототипа, вам понадобится всего лишь примерная прикидка, какое из направлений представляется более перспективным. Это позволит правильно распорядиться временем в условиях его дефицита.
Прототипы – ваши друзья
В главе 5 я объяснил, почему проектирование является исследовательским процессом. Чтобы понять, какие альтернативные варианты существуют, вам необходимо исследовать пространство проблем. Хороший проектный замысел зависит от знания альтернативных вариантов, поскольку чем больше информации о проблемах и решениях находится в вашем распоряжении, тем проще принимать правильные решения. Подготовка прототипов является следующим естественным шагом процесса проектирования. Они вбирают в себя все, что было изучено, и используют этот багаж для решения проблем, причем без рисков, свойственных полноценной реализации. Прототипы следуют плотницким принципам – семь раз отмерь, один раз отрежь, повышая продуманность проекта, перед тем как команда сверстает план. И, как я объясню чуть позже, прототипы не нуждаются в тщательной проработке или затрате существенных средств, как и не требуют много времени. Если вы скептически относитесь к ценности прототипов, прочтите сначала раздел «Прототипы – это опора программистов».
С чего начинаются прототипы?
Создание хороших прототипов возможно при наличии четырех-пяти групп идей. Наряду с тем, что люди с более развитыми творческими навыками могут заранее увидеть альтернативные направления, группировка идей поможет команде определить количество имеющихся вариантов. При наличии двадцати-тридцати идей существуют сотни способов их комбинирования, не считая вариантов интерпретации каждой отдельно взятой идеи.
У опытного проектировщика вырабатываются здоровые инстинкты относительно того, с чего начать работу. Он легко сможет отсортировать имеющиеся идеи и принять решение по поводу тех, на основе которых создавать первый прототип (абстрагируясь от того, как именно это делать). Но если проектирование ведется без участия опытного специалиста, для выбора основы для прототипа можно воспользоваться несколькими простыми приемами.
• Выберите наиболее многообещающую идею из каждой группы и попытайтесь скомбинировать эти идеи в единый замысел.
• Создайте небольшие прототипы для каждой группы и посмотрите, к чему это приведет. Можно ли решить все необходимые проблемы путем модернизации архитектуры или добавления средств настройки? Посмотрите, насколько каждое из направлений соответствует замыслу.
• Учтите мнение проектировщика: разрешите ему воспользоваться собственным опытом и интуицией для решения, что нужно использовать в первой попытке.
• Создайте перечень наиболее сложных или важных вопросов проектирования и создайте прототип или несколько прототипов, помогающих на них ответить.
Как правило, чем сложнее будет прототип, тем сложнее вопросы, на которые с его помощью можно будет ответить. Эскиз на обороте салфетки подойдет лишь для ответа на самые предварительные и приблизительные вопросы, а если вам требуется узнать кое-что специфическое и быть уверенным при ответе на заданный вопрос, нужно нечто более существенное.
При создании первых прототипов станет ясно, какими идеями можно воспользоваться дополнительно, не создавая проблем, а какие идеи в них больше не вписываются. Как и в мозаике, какие-то элементы подходят друг другу по смыслу больше, чем другие, но для поиска соответствий приходится действовать методом проб и ошибок. Поскольку мы имеем дело с массой деталей и точек зрения (пользовательских, деловых, технологических), предсказать, какие направления окажутся работоспособными, а какие нет, невозможно. Но именно для этого и предназначены прототипы: учиться на ошибках, исправлять их и двигаться дальше.
Прототипы для проектов с пользовательским интерфейсом
Прототипы должны создаваться последовательно, сверху вниз. Начните с того, что должны видеть пользователи, и в той последовательности, в которой они все это должны видеть. Для получения вполне обоснованных замыслов и предположений с самого начала привлеките к работе своих специалистов по потребительским свойствам и дизайну. Пока не будут созданы несколько экранов, нет смысла тратить дни на выработку структур баз данных и XML-схем – это все равно что возводить стены дома еще до того, как вы узнали его планировку. Если вы это сделаете, потеря качества конечного продукта вам гарантирована – именно от этого и призваны защищать прототипы.[38]
Лучше подождите появления обещанных эскизов или моделей пользовательского интерфейса (которые лучше всего определяются после изучения потребительских свойств или воспроизведения всех решений, которые должен будет принимать пользователь в процессе работы с каждым экраном). Затем разработчики должны исследовать вопрос, как все это может быть реализовано на практике. Если подобные дискуссии начались на ранней стадии проекта, то они будут легко и естественно продолжены.
Что касается самого создания прототипов, то тут не существует никакой волшебной тайны. Чтобы понять, какие составляющие могут быть сымитированы или приукрашены, а какие потребуют дополнительных осмысления и затрат,[39] требуется лишь некоторый опыт. На практике основной принцип заключается в том, чтобы добыть требуемую информацию с наименьшим показателем трудозатрат. Основой прототипа может послужить любое средство – Flash, HTML, VB и даже бумага. В этом деле важнее искусство дизайнера и(или) создателя прототипа, чем используемая для его создания технология или инструментарий.
Прототипы для проектов без пользовательского интерфейса
Даже если проект изначально не имеет пользовательского интерфейса или отношения к Интернету, он все равно нуждается в прототипе.[40] Вместо вопросов дизайна пользовательского интерфейса нужно взять наиболее трудные или сложные технические проблемы и создать прототипы их решения. Подтвердите действенность основных алгоритмов, соответствие основным тестовым показателям или набору критериев производительности. Цель создания прототипов не зависит от типа проекта – эта работа позволяет понять, можно ли в отведенное время реализовать рассматриваемый вами примерный подход (или подходы) и обеспечивает ли он фактическое решение обозначенных проблем. Это шанс оценить риски еще до начала создания самого продукта и узнать, что нужно сделать до перехода к его созданию.
Прототипы – это опора программистов
В ситуации, когда дизайнер или руководитель проекта ведет работу по созданию прототипов, программисты и инженеры часто жалуются на свою незанятость.[41] Они могут также говорить, что данный процесс – пустая трата времени (такие заявления часто касаются всего, что не связано с созданием программного кода). В противовес этому я думаю, что программисты получают больше пользы от создания прототипов, чем кто-либо из команды. Удачно созданные прототипы значительно повышают вероятность взвешенности и высокого качества продуктов, моделируемых с их помощью. Возможно, для руководителя проекта более важным является то обстоятельство, что в период разработки прототипов у программистов появляется время на исследование новых технических подходов, которые необходимо будет применить. Если они разумно распорядятся временем, отведенным на проектирование, качество произведенного ими программного кода значительно возрастет.
Вот краткий перечень вопросов, на которые программисты должны ответить в данный период:
• Как в целом мы будем реализовывать все представленное в дизайнерском прототипе (или прототипах)? Существует ли готовый код или технология, которую нужно или можно использовать в этих целях?
• Возможны ли разумные поправки дизайна, сокращающие инженерные затраты, о которых нужно уведомить проектировщика?
• Какие пять-шесть компонентов для всего этого понадобятся и как они будут сочетаться друг с другом? Во что, по большому счету, обойдется создание этих компонентов? (Здесь подойдет вариант высоких, средних, незначительных или не поддающихся оценке затрат. Последний вариант служит поводом для программистов для начала исследований.)
• В чем заключаются наибольшие технические риски? Какие компоненты труднее или сложнее всего реализовать?
• Какие элементы взаимодействия (и между какими компонентами) наиболее сложны или имеют наибольшую склонность к отказам? (На это лучше всего сможет ответить опытный специалист по тестированию или контролер качества продукции.)
Как для проектировщика создание проектного прототипа – единственный способ уверенно ответить на сложные вопросы проекта, так и для разработчика не существует способов ответить на сложные инженерные вопросы без создания технологического прототипа (вопреки тому, что он может сказать по этому поводу). Если когда-либо возникнет потребность в создании множества прототипов, их следует создавать скоординировано. Лучше если ведущий дизайнер и ведущий разработчик потратят время на переговоры друг с другом, на расспросы и помощь друг другу в принятии верных решений. Усилия этих двух специалистов по созданию прототипов должны направляться по пути, который их, в конечном счете, концептуально объединит: идеи разработчиков и дизайнеров должны соответствовать друг другу.
Альтернативные варианты повышают вероятность успеха
Применительно к пользовательскому интерфейсу и веб-дизайну, большинство прототипов, в которые я вносил свой вклад или разрабатывал самостоятельно, имели множество братьев и сестер. При большом запасе идей, высветившихся на ранней стадии творческого процесса, возникало множество альтернативных вариантов, в равной степени казавшихся подходящими. Испытание некоторых вариантов было единственным способом понять, какой из них лучше. Проектировщикам или разработчикам, имеющим опыт по созданию прототипов, предоставляется возможность вносить изменения в пользовательский интерфейс, внешний вид и другие детали в одной из многочисленных конфигураций (хорошим примером этому служат языки CSS и HTML, в которых разные уровни можно модифицировать независимо друг от друга). Легко модифицируемый прототип может сократить дискуссии и ускорить принятие решений, поскольку он избавляет людей от необходимости держать все в голове.
Я по собственному опыту знаю: независимо от того, насколько реально впечатление взаимного согласия, если все люди не смотрят на одно и то же изображение, ни о какой согласованности не может быть и речи. Каждый человек может иметь собственное, совершенно отличное от других представление, и когда он соглашается с другими, на самом деле он думает о чем-то своем. Позже в создавшейся неразберихе, скорее всего, будет обвинен проектировщик или руководитель проекта. Прототипы являются действенным средством избежать подобной ситуации, потому что они реально существуют и могут быть продемонстрированы, а впоследствии на них можно сослаться. «Вы видите это? Вы с этим были согласны, и все присутствовавшие в этой комнате видели, что вы согласились именно с этим дизайном». При этом вы должны конкретно указать на характерные особенности прототипа или на созданные дизайнером экранные копии.
Вопросы относительно последовательного приближения
С первым же прототипом возникнет масса новых идей и вопросов, включая предложения кое-что изменить, улучшить или попробовать новые задумки. Если вы имеете дело с ранним прототипом, то создание его следующего варианта может быть направлено на исследование существенных идей или значительных изменений. Если речь идет об одном из поздних прототипов, то его следующий образец может быть создан только для того, чтобы сузить пространство проектирования и помочь принять верные решения. Если собрать вместе все последовательно созданные образцы, появится возможность для новой дискуссии о прогрессе в проектировании. Лучшей основой для такой дискуссии станет набор вопросов, помогающих провести оценку проекта и направить обсуждение в конструктивное русло.
Вот часть вопросов, относящихся к ранним образцам прототипов:
• Каким требованиям отвечает данный образец? Можно ли в этом убедиться? (Исходя из его потребительских качеств, примеров использования и т. д.)
• Каковы сильные и слабые стороны данного образца в отношении проблем, предположительно решаемых с его помощью? (Все за и против со всех точек зрения: потребителя, бизнесмена, разработчика.)
• Какими данными мы должны располагать при оценке этого образца? (Возможно, полученными в результате изучения потребительских запросов, неформального анализа возможностей реализации, проведенного программистами, анализа рыночной ситуации, мнений специалистов и т. д.)
• Что поучительного, пригодного для следующей версии прототипа содержал данный образец? Можно ли его уничтожить?
• Что нужно попробовать сделать в следующем образце, чтобы добиться лучшего результата?
• Есть ли в этой же группе или в других прототипах какая-нибудь другая идея, которой мы можем воспользоваться?
А вот ряд вопросов для более поздних прототипов:
• Какое решение с его помощью мы можем принять?
• Какие спорные вопросы он поможет нам закрыть?
• Подтверждается ли данным образцом существование проблемы, подлежащей исследованию? Решается ли эта проблема с его созданием?
• Что следует попробовать сделать в следующем образце, чтобы приблизиться к составлению технических условий?
Ответив на эти вопросы, проектировщик получит достаточно сведений для создания следующей версии прототипа, возможно, путем объединения двух альтернативных вариантов или расчленения образца на два новых. Что бы вы ни делали, пока это, в конечном счете, приближает проект хотя бы на один шаг к завершению, не должно быть никаких ограничений на то, что разрешено, и на то, что нет.
Список открытых проблем
По мере сужения пространства возможных вариантов у руководителя проекта появляется еще одна обязанность: составление списка открытых проблем. Под открытой понимается проблема, которую нужно решить или очертить, но сделать это пока не представляется возможным. По существу, это список вопросов, в котором перечислено все, что нужно сделать, в порядке, соответствующем степени потенциального влияния на разработку. Не так важна форма этого перечня, как качество внесенных в него вопросов и старательность человека, ведущего команду к их решению. Для составления перечня я использовал выделенную часть классной доски или электронную таблицу Excel и не могу сказать, что выбор инструмента на что-либо существенно повлиял. Я не думаю, что за этим списком нужен особый контроль или им нужно управлять, как при создании исходного кода (если, конечно, политика или культура труда в вашей организации не принуждают к этому), чем проще инструмент создания списка, тем лучше.
Этот список можно начать с весьма приблизительного перечня вопросов, оставшихся без ответа, и дел, оставшихся не сделанными («Какую схему данных мы будем использовать, А или Б?» или «Когда нужно забрать у Салли окончательный вариант дизайна пользовательского интерфейса»), но он должен наполняться подробностями по мере приближения дня сдачи технических условий. Рядом с каждым вопросом должна стоять фамилия человека, ответственного за его решение. А руководитель проекта должен оповестить всех ответственных за решение проблем и затем периодически напоминать им об этом и отслеживать результаты.
Всю ответственность за технические вопросы и исследования должны нести программисты, но если есть особо сложные проблемы, за которые лучше взяться руководителю проекта, он так и должен поступить. Как правило, руководитель проекта курирует вопросы, не имеющие технической специфики, но способные воспрепятствовать разработке, такие как согласования со специалистами по маркетингу, учет интересов пользователя, разработка бренда и визуальное проектирование, поскольку эти вопросы влияют на технические условия больше, чем на саму разработку (в чем здесь разница, мы выясним в следующей главе).
Мудрый руководитель проекта делит список открытых проблем по срочности решения на две части: на то, что должно быть решено до выдачи технических условий, и на то, что может быть отложено на более поздний срок. Естественнее всего расположить по приоритетам те проблемы, которые потенциально могут помешать разработке и, возможно, всему проекту. Все проблемы, попавшие во вторую часть списка (относящуюся к периоду после выдачи технических условий), должны быть уточнены с участием разработчиков, потому что только они могут проверить, какие решения или сведения можно пока отложить. (Как и почему их можно отложить, пока не появятся технические условия, мы рассмотрим в следующей главе.)
Все неопределенности, к которым рано или поздно придется вернуться, должны быть отражены в списке. Ни у кого, кроме руководителя проекта, не возникнет потребности заглянуть в этот список, и разумеется, не сразу. Но по прошествии времени список может послужить поводом для сбора команды или проведения обсуждений «на ходу». Цель не в том, чтобы испортить людям настроение, просто им нужно иногда напомнить о том, что осталось нерешенным, и помочь понять, какие проблемы нужно решить специалистам команды. Поскольку работа руководителя проекта касается всех, вывешивание списка на видном месте позволит людям сотрудничать в решении проблем: «А этот пункт и меня касается. Кто им займется, ты или я?» По этой причине я держу список проблем на доске в своем офисе или коридоре. (Может сработать и wiki-технология, но никто, кроме составителя, туда не заглядывает. Обычные невиртуальные и неформальные места срабатывают куда лучше.)
Когда люди заходили в мой офис и спрашивали, как продвигаются наши дела, я указывал на список и говорил: «Вот так и продвигаются. Пока список не будет исчерпан, я не смогу закончить составление технических условий». Хотя этот список – не показатель производительности и не объект, подлежащий строгим измерениям в течение длительного времени, состояние списка проблем, находящегося у руководителя проекта, и круг вопросов, в него включенный, являются существенным показателем того, насколько хорошо идут дела. Если список достаточно длинный, но состоит из сугубо специфических и узкоспециальных проблем, все идет хорошо. А если он короткий, но его вопросы пугают своей основательностью, например: «Какую проблему мы пытаемся решить?» или «Какой язык программирования мы используем?», то проект, что называется, еще толком и не сдвинулся с места.
Выводы
• Идеи обладают собственной инерционностью. Доминирование идей в творческом процессе продлится дольше ваших ожиданий. Изменения влекут за собой цепную реакцию во всем проекте.
• Для отслеживания хода творческого процесса и управления им следует установить контрольные точки. В число обычных контрольных точек включаются: доказательство состоятельности концепции, группировка идей, три альтернативных варианта, два альтернативных варианта, единый замысел.
• Для объединения идей используйте диаграмму сходства.
• Прототипы позволяют проекту противостоять разногласиям на ранней стадии и учиться на ошибках без существенного риска.
• Для ответов на вопросы, оценки степени прогресса и принятия решения о том, что делать дальше, делайте новые версии прототипов или обновляйте существующие.
• Для отслеживания вопросов, требующих разрешения до составления технических условий, составьте список открытых проблем.
Упражнения
1. Как вы составляете свой список текущих дел, по личным задачам или по задачам работы? Можете ли вы применить такую же систему для приведения в порядок, отслеживания или управления своими идеями? Почему «да» или почему «нет»?
2. В каком режиме должно вестись управление идеями, в закрытом или открытом? Кто в вашей проектной команде должен иметь доступ к: а) просмотру; б) изменению; в) добавлению или удалению идей?
3. Представьте, что вы близки к завершению проекта и поняли, что есть великолепная идея, способная радикально улучшить то, что вы делаете. Каковы способы сохранить эту идею, чтобы при запуске планирования следующего выпуска работы ею можно было воспользоваться? Можете ли вы придумать способ сбора подобных идей для всей команды?
4. Проведите сутки, занимаясь записью любых, услышанных от кого-то или самостоятельно придуманных идей. Сколько идей вам удастся собрать? Больше или меньше ожидаемого количества?
5. Возьмите список из предыдущего упражнения. Сколько различных способов группировки идей по категориям можно придумать? (Если вы поленились выполнить предыдущее упражнение, воспользуйтесь любым списком – покупок, людей, которых вам хотелось бы увидеть в голом виде, всего, что угодно.)
6. Что является тревожным признаком работы над проектом, для которого сгенерировано слишком много идей? Есть ли какое-нибудь разумное соотношение количества идей к отведенному времени, количеству сотрудников или к сложности проекта?
7. Управление творческим процессом требует определенных навыков, которые могут быть невостребованы при других этапах управления проектом. Каковы преимущества или опасности привлечения разработчиков или проектировщиков к руководству творческой стадии проекта?
8. Представьте, что вы работаете над проектом в середине этапа планирования. Никто не представил никакого прототипа, и в вашем распоряжении только письменные документы. Вы понимаете, что на некоторые вопросы невозможно получить ответы, используя лишь эти документы. Что вам делать? Изготавливать прототип самостоятельно? Привлечь к этой работе какого-нибудь другого специалиста команды? Кому вы покажете прототип? Какую реакцию вы от него ожидаете?
9. Представим, что в предыдущем упражнении вы решили изготовить прототип. Вы показали его команде, и он ей понравился. То есть он ей настолько понравился, что команда согласилась прекратить всю другую проектировочную работу и оснащение ради того единственного созданного вами прототипа. Вы знаете, что прототип создает массу предположений, требующих проверки, но их это мало волнует. Как убедить их в необходимости другого прототипа? Что можно сделать до показа прототипа, чтобы свести к минимуму шансы подобного развития событий?
10. Как расценить действия руководителя проекта, если он требует, чтобы список открытых проблем был пуст? Кому вы больше станете доверять, тому руководителю, у которого пять, или тому, у которого пятьдесят записей в списке открытых проблем? Испытываете ли вы какие-нибудь опасения насчет слишком больших затрат времени на отслеживание хода сокращения открытых проблем?