Прототипирование. Практическое руководство

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

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

7. Снижение рисков. Прототипирование помогает снизить риски, уменьшая вероятность неправильного понимания и выявляя проблемы на ранних этапах.

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

Прототипирование показывает реальные ценности

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

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

• На разработку прототипа и 16-страничного дополнительного документа требуется меньше времени и сил, чем на написание 200-страничного техзадания.

• Точность оценки стоимости проекта и его продолжительности повысилась на 50%.

• Количество уточняющих запросов от команды разработчиков сократилось на 80%.

• Количество переделок и исправлений ошибок после выпуска продукта уменьшилось до 25% от уровня предыдущих проектов.

• Вся команда согласилась, что прототипирование проще, чем традиционная модель.

Практический пример: прототипирование при жестких бюджете и сроках

Джонатан Бейкер-Бейтс

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

Мы решили, что с первого же дня будем разрабатывать функциональный HTML-прототип всего сайта на платформе Axure. Мы надеялись показать почти все необходимые требования с таким уровнем детализации, чтобы они были ясны всем и каждому, будь то СЕО[6] или интегратор CMS.

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

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

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

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

Резюме

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

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

• прототипирование продуктивно;

• прототипирование дает возможность показать и рассказать;

• прототипирование снижает вероятность неправильного восприятия;

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

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

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

Глава 2

Процесс прототипирования

В проектировании архитектуры и продукта прототипирование – данность. Но это не обязательно верно для разработки программных продуктов.

Андерс Рэмси

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

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

• Все эти процессы относятся к проектированию.

• Для коммуникации при разработке используются искусственно созданные объекты.

• Конечный результат – вещественный объект, который люди могут испытывать и использовать.

Я думаю, дело в первую очередь в том, что в создании программного обеспечения акцент часто ставится на разработке, а не проектировании (представители отрасли называют этот процесс не «проектированием», а «разработкой программ»).

При создании программного обеспечения о проектировании часто задумываются слишком поздно. Акцент делается на технологиях или функциональности. А в архитектурном или промышленном проекте – именно на проектировании. Форма следует за функциями.

Кроме того, разработка программ воспринимается как производственный процесс, а архитектурное и промышленное проектирование – как ремесло, умение.

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

Отсутствие дизайнерской студии

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

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

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

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

На что похож процесс прототипирования

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

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

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

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

Марк Сандерс, изобретатель складного велосипеда Strida, описывает на YouTube процесс, который он использовал при создании своего «детища»[7]. Когда я смотрел это описание, я отметил следующее:

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

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

• Эскизы использовались только до этого этапа. Чтобы убедиться в работоспособности идей, ему приходилось создавать модели или прототипы.

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

В своем видео Марк описывает достаточно типичный процесс прототипирования, включающий следующие элементы:

• создание эскизов;

• оценку;

• создание модели;

• испытание.

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

• создание эскизов (набросков на демонстрационных досках или бумаге, программного кода);

• демонстрация и критическая оценка;

• моделирование (прототипирование);

• тестирование.

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

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

^{РИС. 2.1. Диаграмма итеративного процесса разработки и критических оценок}

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

Теперь давайте подробно рассмотрим наш процесс прототипирования, начиная с создания наброска.

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

Я предпочитаю устанавливать рамки для «времени делать наброски». Это заставляет сотрудников работать быстро и не вдаваться в детали.

Цель создания набросков – не конкретизация идей (этим мы занимаемся на стадии разработки прототипа), а определение концепций, «вытаскивание» их из головы максимально быстро и переход к следующей стадии.

Совет

Количество важнее качества

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

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

^{РИС. 2.2. Набросок модуля настроек для видео на Vimeo, демонстрирующий толщину линий и пометки}[8]

Совет

Быстрый и яростный

Установите ограничения времени на создание набросков.

Я предпочитаю отводить на это 10–30 минут, а затем переходить к показу и критической оценке. Такой короткий период заставляет фокусироваться на продуктивных идеях, не вдаваясь в подробности.

Большинство наших набросков делается на бумаге с использованием специальных планшетов. Планшет – просто лист бумаги с набором небольших окошек-шаблонов. Он подобен планшету для раскадровки.

Вот как выглядит один из наших планшетов для набросков (рис. 2.3).[9]

^{РИС. 2.3. Пример планшета с несколькими набросками}

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

Совет

Хорошая идея не приходит одна

Использование планшета для набросков – отличный способ выдать несколько идей. Небольшое пространство стимулирует обдумывание отдельных элементов интерфейса. Такой планшет также подойдет для небольшой раскадровки, если необходимо описать проект AJAX или RIA.

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

Рассмотрим преимущества и недостатки набросков на бумаге, лекционных досках и в программном коде.

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

Одно из преимуществ набросков в коде – возможность их превращения в прототип. В условиях роста числа JavaScript-библиотек, CSS-фреймворков и шаблонизаторов вроде Ruby on Rails создавать наброски в коде становится все легче.

Преимущества

• Делать наброски в коде все легче, поскольку инструментов для этого становится больше.

• Наброски «оживают» – их можно опробовать на практике.

• Это дает возможность эффективно использовать написанный код.

Недостатки

• Не каждый умеет писать код.

• Для этого необходим компьютер.

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

• Это занимает больше времени, чем создание набросков на бумаге или лекционной доске.

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

Преимущества

• Обеспечивает возможность совместной работы.

• На лекционной доске может рисовать каждый.

• Одновременно могут участвовать несколько человек.

• Не нужен компьютер.

• Внести изменения очень просто: достаточно стереть рисунок и изобразить что-то новое.

Недостатки

• Перенести лекционную доску сложнее, чем код или лист бумаги.

• Наброски статичны.

• Перенести наброски с доски на рабочие материалы иногда сложно[10].

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

Преимущества

• Обеспечивает возможность совместной работы.

• На бумаге может рисовать каждый.

• Может участвовать несколько человек одновременно.

• Не нужен компьютер.

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

• Этим можно заниматься когда угодно и где угодно.

• Наброски легко перемещать.

Недостатки

• Наброски статичны.

Демонстрация и критика – вероятно, наиболее важная часть процесса прототипирования. На этой стадии мы сосредоточиваемся на качестве.

Метод демонстрации и критики я освоил в студенческие годы, когда изучал графическое проектирование. И хотя потом я выбрал специальность «английский язык и когнитивная психология», я никогда не забывал ценные уроки демонстрации и критики.

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

Представляя наброски на обсуждение, мы часто крепим их к стене, как показано на рис. 2.4.

^{РИС. 2.4. Показ набросков в ходе их критического разбора в дизайнерской студии}

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

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

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

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

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

К началу этой стадии процесса вы набросали свои идеи, показали и обсудили их, отобрали только самые сильные варианты. Их прототипы вы и будете создавать.

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

Когда я создаю прототип, то рассматриваю следующие вопросы:

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

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

• каким временем я располагаю;

• какая степень точности необходима.

На деле способ прототипирования не важен. Большинство моих прототипов созданы с помощью HTML и AJAX, но это объясняется характером моей работы и потребностями клиентов. Я делал прототипы с помощью Flash, Keynote и на бумаге.

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

Совет

Проект и набросок

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

Я делю тестирование на две категории: тестирование с клиентами и тестирование с конечными пользователями.

Тестирование с клиентами сочетает в себе показ, критическое обсуждение и создание набросков. Встречи длятся обычно 1,5–3 часа в зависимости от сложности прототипа.

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

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

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

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

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

Тестирование с конечными пользователями – стандартный тест на удобство использования: 8–12 участников, 5–6 сценариев, аудио– и видеозапись, анализ, а после тестирования – сообщение о результатах. В главе 12 подробнее рассказано о тестировании прототипов.

При любом тестировании я учитываю полученную в его ходе информацию в следующей версии прототипа.

Резюме

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

Прототипирование – процесс, а не продукт, средство достижения цели. Вот несколько важных моментов, о которых нельзя забывать:

• создание набросков – ключевая часть процесса прототипирования;

• используйте метод дизайнерской студии: составление набросков; показ и критическое обсуждение. Это помогает быстро и последовательно улучшать прототип;

• начинайте с количества, исследуя множество идей. Качество придет позже.

В следующих двух главах я рассмотрю 5 различных способов прототипирования и 8 руководящих принципов его выполнения.

Глава 3. Пять моделей прототипирования

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

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

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

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

Модель № 1: коммуникация

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

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

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

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

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

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

Совет

Используйте возможность сотрудничества

Прототипирование в сотрудничестве с коллегами – отличное упражнение для создания команды. Опробуйте этот подход.

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

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

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

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