Книга: Сделано
Назад: Пропасть между требованиями и решениями
Дальше: ЧАСТЬ ВТОРАЯ. НАВЫКИ

ГЛАВА ШЕСТАЯ

ЧТО ДЕЛАТЬ С НАЙДЕННЫМИ ИДЕЯМИ

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

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

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

БЕСКОНТРОЛЬНЫЕ ИДЕИ

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

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

В первые месяцы проекта IE 4.0 у нас был полнейший бедлам. Мы одновременно пытались перейти от маленьких команд и релизов (к примеру, версий 2.0 и 3.0) к выпуску главного продукта. Мы находились под давлением из-за конкуренции Microsoft и Netscape, которую пресса представляла как битву не на жизнь, а на смерть. Еще была внутренняя политика революционного и в то же время стратегического продукта. Любому было бы сложно удержать корабль на плаву. И как в большин­стве проектов, именно на этапе перехода от планирования к проектированию происходит столкновение эго и мнений. Людям впервые нужно принять окончательные решения, и они оказываются под прессом обязательств. Сомнения рождают стресс, и лишь одно остается неизменным — дедлайны. Очередная дата маячит на горизонте и приближается с каждым днем .

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

УПРАВЛЕНИЕ ИДЕЯМИ ТРЕБУЕТ ТВЕРДОЙ РУКИ

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

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

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

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

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

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

Перечислим основные причины.

ИЗМЕНЕНИЯ ВЫЗЫВАЮТ ЦЕПНУЮ РЕАКЦИЮ

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

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

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

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

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

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

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

Джошуа Ледерберг, лауреат Нобелевской премии 1958 года

КРЕАТИВНАЯ РАБОТА ОБЛАДАЕТ СОБСТВЕННОЙ ИНЕРЦИЕЙ

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

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

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

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

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

КОНТРОЛЬНЫЕ ТОЧКИ ЭТАПОВ ПРОЕКТИРОВАНИЯ

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

Рис. 6.3. Ключевые проектные точки

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

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

ВНИМАНИЕ!

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

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

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

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

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

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

Рис. 6.4. Много идей (ура!), но с ними сложно управиться (кошмар!)

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

Рис. 6.5. Группировать идеи — хорошая мысль

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

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

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

  1. Упростить:
    • исключить расширенные параметры, которыми никто никогда не пользуется;
    • улучшить макет страницы с результатами поиска;
    • сократить количество результатов, отображаемых на стра­нице.
  2. Кастомизация:
    • позволить пользователям менять настройки внешнего вида страницы;
    • открывать результаты в новом окне.
  3. Перестроить архитектуру:
    • наладить корректную работу системы обработки запросов (булев поиск);
    • исправить ошибки в поисковике;
    • применить передовой поисковик HyperX.

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

СКОРРЕКТИРОВАТЬ И ПРИОРИТИЗИРОВАТЬ

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

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

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

ПРОТОТИПЫ — ВАШИ ДРУЗЬЯ

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

С ЧЕГО НАЧИНАЮТСЯ ПРОТОТИПЫ

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

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

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

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

ПРОТОТИПЫ ДЛЯ ПРОЕКТОВ С ПОЛЬЗОВАТЕЛЬСКИМ ИНТЕРФЕЙСОМ

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

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

Что касается строительства прототипов, тут нет волшебных секретов. Нужен опыт, чтобы разбираться, какие компоненты достаточно наметить схематично, а какие требуют большей проработки и времени . Старайтесь получить необходимую информацию, прилагая минимум усилий. Для дизайна прототипа можно использовать любой инструмент — Flash, HTML, VB или даже листок бумаги. Навыки и таланты проектировщика и / или разработчика прототипа тут главнее, чем техника или инструмент.

ПРОТОТИПЫ ПРОЕКТОВ БЕЗ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

ПРОТОТИПЫ ПОМОГАЮТ ПРОГРАММИСТАМ

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

Приведем краткий список вопросов, на которые должны ответить программисты на этом этапе работы.

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

АЛЬТЕРНАТИВЫ ПОВЫШАЮТ ВЕРОЯТНОСТЬ УСПЕХА

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

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

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

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

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

Перечислим вопросы для первых итераций прототипов.

А вот несколько вопросов по прототипам на более поздних этапах процесса.

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

СПИСОК ОТКРЫТЫХ ВОПРОСОВ

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

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

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

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

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

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

РЕЗЮМЕ

УПРАЖНЕНИЯ

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

Б. Идеи нужно упорядочивать открыто или в единоличном порядке? Кто из вашей проектной команды должен иметь доступ к тому, чтобы а) видеть список идей; б) вносить изменения; в) добавлять или удалять идеи?

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

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

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

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

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

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

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

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

Назад: Пропасть между требованиями и решениями
Дальше: ЧАСТЬ ВТОРАЯ. НАВЫКИ