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

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


[Закрыть]. Это можно сделать самыми разными способами, все зависит от проекта и команды. Рисунок 6.3 иллюстрирует ключевые точки.

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

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

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

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

• Две альтернативы. Исследуйте, изучайте, делайте прототипы и задавайте вопросы, пока не сможете с полной уверенностью сократить число альтернатив до двух. Эти два четких направления и определят последующие решения.

• Один вариант. Исследуйте, изучайте, делайте прототипы и задавайте вопросы, пока не сможете с полной уверенностью выделить одно, конечное направление.

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

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

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

ВНИМАНИЕ!

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

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

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

Для этого существует множество методов[61]61
  Список альтернатив можно посмотреть здесь: http://www.ms.lt/ms/projects/toolkinds/organize.html.


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

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

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

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

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

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

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

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

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

• применить передовой поисковик HyperX;

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

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

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

• исправить ошибки в поисковике;

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

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

1. Упростить:

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

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

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

2. Кастомизация:

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

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

3. Перестроить архитектуру:

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

• исправить ошибки в поисковике;

• применить передовой поисковик HyperX.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прототипы нужно делать сверху вниз. Начните с того, что увидят пользователи, и в той последовательности, в которой они это увидят. Подключите специалистов по проектированию как можно раньше, чтобы получить обоснованные предположения. Нет смысла тратить по несколько дней на планирование базы данных и XML-схемы, пока не готово несколько экранов: это как строить каркас дома до того, как вы ознакомились с планом этажей. Вы потратите свое время и силы зря, а этого следует избегать[62]62
  О вопросе программирования до дизайна см. Alan Cooper, The Inmates Are Running the Asylum (Sams, 2004) (Купер А. Психбольница в руках пациентов. М.: Символ-Плюс, 2005).


[Закрыть].

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

Что касается строительства прототипов, тут нет волшебных секретов. Нужен опыт, чтобы разбираться, какие компоненты достаточно наметить схематично, а какие требуют большей проработки и времени[63]63
  “The Art of UI Prototyping”, http://scottberkun.com/essays/12-the-art-of-ui-prototyping/.


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

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

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


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

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

При наличии проектировщика или МП, который может руководить созданием прототипов, разработчики зачастую жалуются, что им нечего делать[65]65
  Я спорил по этому поводу с другими менеджерами. Им сложно представить, чтобы их блестящие разработчики не писали коды 24 часа в сутки. Хоть здесь есть капелька лицемерия: если время программиста настолько ценно, то его следует тщательно планировать. «Чем же будут заниматься программисты?» – спрашивали они меня. А я отвечал: «Они будут ждать плана, на который стоит тратить время, или помогут нам составить его».


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

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

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

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

• Перечислите пять-шесть основных необходимых компонентов и как они соотносятся друг с другом. Насколько затратно строительство этих компонентов? (Высокие затраты, средние, низкие, неизвестные – такого ответа пока вполне достаточно. Если затраты неизвестны, программист должен изучить этот вопрос.)

• Назовите самые серьезные технические риски. Какие компоненты сложнее всего построить?

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

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

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

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

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

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

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

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

• Каким требованиям удовлетворяет этот прототип? Можем ли мы проверить это? (Простота использования, пользовательские сценарии и т. д.)

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

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

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

• Что мы могли бы предпринять в следующей итерации, чтобы сделать прототип лучше?

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

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

• Какое решение это помогает нам принять?

• На какой открытый вопрос можно дать ответ?

• Подтвердил ли этот проектный замысел существование проблемы, которую нужно исследовать? Или помог решить проблему, которую нужно было решить?

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

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