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

Что произойдет, если добавить AJAX[4]4
  AJAX (от англ. Asynchronous JavaScript and XML, асинхронный JavaScript и XML) – использование «фонового» обмена данными браузера с веб-сервером в интерактивных пользовательских интерфейсах веб-приложений (позволяет ускорить и повысить удобство работы). Термин появился в 2005 году. Прим. ред.


[Закрыть] или другое приложение RIA (Rich Internet Applications – многофункциональные интернет-приложения)? Все начнет разваливаться на части, причем быстро. Ни техническое задание, ни аннотированные каркасные представления не могут отразить правила взаимодействий и переходов.

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

Это дало многим разработчикам повод заявить, что парадигма страницы мертва, а новая парадигма – экран или состояние.

Переходы и анимация – еще одна проблема. Пытались ли вы описать самоисправляющийся переход в AJAX?[5]5
  Подробнее см.: http://developer.yahoo.com/ypatterns/richinteraction/transition/selfhealing.html. Прим. науч. ред.


[Закрыть] Мое самое удачное описание, дополненное пассами фокусника и взмахами воображаемой волшебной палочки, вызвало удивление и непонимание у публики.

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

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

Возьмите 60-страничное техническое задание. Посадите в комнате 15 человек. Раздайте им документ. Пусть они его прочтут. Спросите у них, что именно вы разрабатываете. Скорее всего, вы получите 15 разных ответов. Теперь представьте, что в документе 200 страниц. Результат будет еще хуже.

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

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

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

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

• Техническое задание объемом 60–200 страниц никто не захочет читать. Это не приносит удовольствия.

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

• Документация не дает возможности увидеть картину в целом. Приходится читать строчку за строчкой.

• Слова слишком часто можно истолковать по-разному.

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

• Вы испытываете работу системы, а не просто читаете о ней.

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

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

«У нас нет времени создавать прототип».

«Мы не можем позволить себе прототип. У нас на это нет средств».

Сколько раз вам приходилось слышать такие фразы от клиента, одного из ваших начальников или даже коллег-разработчиков?

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

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

Прототипирование сокращает объем напрасного труда

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

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

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

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

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

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

4. Неправильное понимание. Количество неправильно понятых мест в техническом задании объемом 60–200 страниц нередко значительно. Непонимание ведет к затратам времени на переделку и отсрочке выпуска продукта.

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

6. Слишком позднее обнаружение ошибок. В техническом задании сложно обнаружить ошибки, пока система не начнет работать. Чем позже ошибка обнаружена, тем дороже ее исправление.

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

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

2. Выживание наиболее приспособленных. Генерируется и испытывается множество идей, «выживают» сильнейшие из них.

3. Адаптивность. Прототипы могут быть доработаны с учетом новых возможностей и требований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть] или интегратор CMS.

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

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

Андерс Рэмси

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Марк Сандерс, изобретатель складного велосипеда Strida, описывает на YouTube процесс, который он использовал при создании своего «детища»[7]7
  См.: http://www.youtube.com/watch?v=j5tFFIBDzVs.


[Закрыть]. Когда я смотрел это описание, я отметил следующее:

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

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

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

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

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

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

• оценку;

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

• испытание.

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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


[Закрыть]

Совет

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

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

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

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

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


[Закрыть]

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

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

Совет

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

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

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

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