Страница:
Оказалось, на разработку прототипа требуется меньше времени и усилий, чем на создание подробного технического задания и аннотированных каркасных представлений.
Я знаю несколько причин, по которым документация оставляет больше возможностей для неправильного истолкования:
• Техническое задание объемом 60–200 страниц никто не захочет читать. Это не приносит удовольствия.
• Если вы не сможете убедить людей прочесть задание, те не смогут до конца его понять.
• Документация не дает возможности увидеть картину в целом. Приходится читать строчку за строчкой.
• Слова слишком часто можно истолковать по-разному.
Кроме того, прототипы имеют ряд преимуществ, которые помогают снизить вероятность неправильного толкования:
• Вы испытываете работу системы, а не просто читаете о ней.
• Прототипы поощряют игровое поведение. Когда вы даете человеку возможность поиграть с прототипом, повышается вероятность, что тот поймет, как должно работать ваше «детище».
Прототипирование позволяет сэкономить время, усилия и деньги
Прототипирование сокращает объем напрасного труда
Прототипирование показывает реальные ценности
Резюме
Глава 2
Создание прототипов – обычная практика во многих областях проектирования, например архитектуре или промышленном дизайне. Она не просто допустима, но ожидаема.
Почему бы не использовать ее и в разработке программного обеспечения? В конце концов, эта область имеет много общего с архитектурным и промышленным проектированием, в том числе следующие характеристики:
• Все эти процессы относятся к проектированию.
• Для коммуникации при разработке используются искусственно созданные объекты.
• Конечный результат – вещественный объект, который люди могут испытывать и использовать.
Я думаю, дело в первую очередь в том, что в создании программного обеспечения акцент часто ставится на разработке, а не проектировании (представители отрасли называют этот процесс не «проектированием», а «разработкой программ»).
При создании программного обеспечения о проектировании часто задумываются слишком поздно. Акцент делается на технологиях или функциональности. А в архитектурном или промышленном проекте – именно на проектировании. Форма следует за функциями.
Кроме того, разработка программ воспринимается как производственный процесс, а архитектурное и промышленное проектирование – как ремесло, умение.
Возможно, все дело в способе обучения в разных областях деятельности. Обучение компьютерным наукам сосредоточено на преподавании технологий. В архитектурном и промышленном проектировании студентов учат принципам проектирования, включая то, что иногда называют дизайнерской студией.
Отсутствие дизайнерской студии
На что похож процесс прототипирования
Часть 1: создание наброска
Наброски в коде
Создание набросков на лекционной доске
Создание набросков на бумаге
Часть 2: демонстрация и критика
Рекомендации по демонстрации и критике
Часть 3: прототип
Я знаю несколько причин, по которым документация оставляет больше возможностей для неправильного истолкования:
• Техническое задание объемом 60–200 страниц никто не захочет читать. Это не приносит удовольствия.
• Если вы не сможете убедить людей прочесть задание, те не смогут до конца его понять.
• Документация не дает возможности увидеть картину в целом. Приходится читать строчку за строчкой.
• Слова слишком часто можно истолковать по-разному.
Кроме того, прототипы имеют ряд преимуществ, которые помогают снизить вероятность неправильного толкования:
• Вы испытываете работу системы, а не просто читаете о ней.
• Прототипы поощряют игровое поведение. Когда вы даете человеку возможность поиграть с прототипом, повышается вероятность, что тот поймет, как должно работать ваше «детище».
Прототипирование позволяет сэкономить время, усилия и деньги
«У нас нет времени создавать прототип».
«Мы не можем позволить себе прототип. У нас на это нет средств».
Сколько раз вам приходилось слышать такие фразы от клиента, одного из ваших начальников или даже коллег-разработчиков?
Я слышал их десятки раз. Да, они имеют под собой некоторые основания. Разработка прототипа не бесплатна, но его преимущества перевешивают затраты, а главное, потери от неиспользования прототипирования.
Поговорите с любым человеком, перешедшим с процесса проектирования и разработки без прототипирования на процесс с прототипированием, и он скажет вам, что за счет этого он сэкономил кучу времени и избавился от множества проблем. Прототипирование не только дает возможность быстрее реализовать и испытать проект, но и сокращает напрасные потери времени.
«Мы не можем позволить себе прототип. У нас на это нет средств».
Сколько раз вам приходилось слышать такие фразы от клиента, одного из ваших начальников или даже коллег-разработчиков?
Я слышал их десятки раз. Да, они имеют под собой некоторые основания. Разработка прототипа не бесплатна, но его преимущества перевешивают затраты, а главное, потери от неиспользования прототипирования.
Поговорите с любым человеком, перешедшим с процесса проектирования и разработки без прототипирования на процесс с прототипированием, и он скажет вам, что за счет этого он сэкономил кучу времени и избавился от множества проблем. Прототипирование не только дает возможность быстрее реализовать и испытать проект, но и сокращает напрасные потери времени.
Прототипирование сокращает объем напрасного труда
Традиционно в процессе проектирования составляется техническое задание и передается дизайнеру или разработчику. Те изучают требования и создают нечто, основываясь на своем восприятии спецификаций.
Теоретически техническое задание призвано снижать напрасные затраты времени. Главная цель – чтобы все занимались одной и той же задачей. Если все находятся на одном и том же этапе, напрасные затраты времени должны сократиться. Звучит потрясающе.
Правда, только в теории. На практике все иначе. Процесс проектирования и разработки на основе технического задания имеет ряд недостатков, которые и приводят к потерям времени:
1. Задание написано не для «тех» людей. Дизайнеры и разработчики редко участвуют в создании технического задания. Его пишет бизнес-аналитик или другой специалист, не имеющий достаточных технических знаний. Поэтому нередко приходится несколько раз переделывать задание.
2. Слишком много времени и усилий. Количество времени, потраченного на создание, рецензирование и пересмотр технических заданий, весьма значительно. При разработке сложных систем этот процесс иногда занимает 3–9 месяцев, а иногда и больше. За это время многое может измениться.
3. Неокончательная финальная версия. Теоретически техническое задание – окончательный документ. На практике же требования постоянно меняются, даже после того как их составление «завершено».
4. Неправильное понимание. Количество неправильно понятых мест в техническом задании объемом 60–200 страниц нередко значительно. Непонимание ведет к затратам времени на переделку и отсрочке выпуска продукта.
5. Несущественные детали. Техническое задание нередко заполнено описанием малозначимых или незначимых функциональных возможностей. На их создание и тестирование требуется время. Результат – потеря времени на их описание в техзадании, их внедрение и тестирование (часто такие возможности вообще впоследствии не используются).
6. Слишком позднее обнаружение ошибок. В техническом задании сложно обнаружить ошибки, пока система не начнет работать. Чем позже ошибка обнаружена, тем дороже ее исправление.
Любой из перечисленных факторов сам по себе приводит к напрасным тратам времени и сил. Но обычно процесс разработки по техническому заданию грешит сразу несколькими из них, что порождает значительную неэффективность. Прототипирование помогает сократить напрасные траты времени и сил и дать следующие выгоды:
1. Решения принимаются правильными людьми. Дизайнеры и разработчики могут использовать свои опыт и знания и принимать грамотные решения.
2. Выживание наиболее приспособленных. Генерируется и испытывается множество идей, «выживают» сильнейшие из них.
3. Адаптивность. Прототипы могут быть доработаны с учетом новых возможностей и требований.
4. Снижение вероятности неправильного понимания. Прототип – визуальное, а иногда и физическое представление системы. Его сложнее понять неправильно, чем бумажный документ объемом 60–200 страниц. Снижение вероятности неправильного понимания сокращает количество переделок. Результат – меньшие затраты и более ранний выход на рынок.
5. Точность. При использовании прототипирования создаются продукты, более точно соответствующие желаемым характеристикам. Результат – меньшие потери при проектировании, разработке и переделках.
6. Раннее обнаружение несоответствий. Прототипирование помогает обнаружить несоответствия на ранних стадиях проектирования и разработки. Чем раньше будут выявлены проблемы, тем дешевле обойдется их исправление.
7. Снижение рисков. Прототипирование помогает снизить риски, уменьшая вероятность неправильного понимания и выявляя проблемы на ранних этапах.
Прототипирование не может решить всех проблем разработки по техническому заданию, но способно снизить уровень неэффективности и непроизводительных затрат.
Теоретически техническое задание призвано снижать напрасные затраты времени. Главная цель – чтобы все занимались одной и той же задачей. Если все находятся на одном и том же этапе, напрасные затраты времени должны сократиться. Звучит потрясающе.
Правда, только в теории. На практике все иначе. Процесс проектирования и разработки на основе технического задания имеет ряд недостатков, которые и приводят к потерям времени:
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% от уровня предыдущих проектов.
• Вся команда согласилась, что прототипирование проще, чем традиционная модель.
После этих изменений в компании заметили ряд существенных улучшений:
• На разработку прототипа и 16-страничного дополнительного документа требуется меньше времени и сил, чем на написание 200-страничного техзадания.
• Точность оценки стоимости проекта и его продолжительности повысилась на 50%.
• Количество уточняющих запросов от команды разработчиков сократилось на 80%.
• Количество переделок и исправлений ошибок после выпуска продукта уменьшилось до 25% от уровня предыдущих проектов.
• Вся команда согласилась, что прототипирование проще, чем традиционная модель.
История, рассказанная Джонатаном, не уникальна. Такие же истории я слышал от многих из тех, с кем беседовал во время подготовки этой книги, от десятков людей, посещавших мои лекции о прототипировании, и от участников опросов.Практический пример: прототипирование при жестких бюджете и сроках
Джонатан Бейкер-Бейтс
У нас имелось меньше четырех месяцев на создание «неформального» сайта для одного из ведущих разработчиков компьютерных игр, сильная концепция визуального дизайна, ряд требований к контенту и функциональности и команда, разбирающаяся в CMS. Но бюджет был стесненным, а рамки проекта – неопределенными. К тому же мы в первый раз сотрудничали с этим клиентом, и он был не из тех, кто готов изучать длинные документы (которые нередко доходили до 200 страниц в похожих проектах). Требовалось заинтересовать участников и с самого начала четко определить, что мы собираемся сделать.
Мы решили, что с первого же дня будем разрабатывать функциональный HTML-прототип всего сайта на платформе Axure. Мы надеялись показать почти все необходимые требования с таким уровнем детализации, чтобы они были ясны всем и каждому, будь то СЕО[6] или интегратор CMS.
Конечно, прототип не мог показать все. Нефункциональные элементы, некоторые экраны, появляющиеся при определенных условиях, и исключения приходилось записывать отдельно, так же как и заметки о реализации. Мы вынесли их в дополнительный документ объемом около 20 страниц. Однако в нем были отражены только те моменты, которые явно не показаны в прототипе. Это позволяло предупредить возможность перегруженности документа и его выхода из-под контроля.
Мы сразу обратили внимание на то, что при создании прототипа отпала необходимость в длинных «вводных» описаниях и обсуждениях. Те, кто его видел, понимали, что мы старались сделать, за несколько минут, а не часов или дней. Поэтому мы могли перейти к обсуждению деталей. Это дало нам ряд выгод. Во-первых, точность оценок продолжительности работы оказалась очень высокой. Во-вторых, мы потратили на обсуждение проекта (в том числе возможных проблем) в целом примерно на 80% меньше времени, чем обычно. Наконец, интеграция и тестирование прошли гладко, а количество отклонений от спецификаций было примерно на 25% меньше, чем обычно. Бюджетные и временны́е ограничения никуда не делись, но прототип позволял быстро показать, как сгладить требования, чтобы получить согласие клиента.
Этот подход оказался успешным. Но хочу напомнить читателям, что все проекты разные и в других обстоятельствах этот метод может быть не лучшим решением. Стоит также отметить, что позже, когда сайт начал работу и требовалось постепенно вносить улучшения, мы вернулись к более традиционному процессу, основанному на документах. Но без прототипа мы, скорее всего, не смогли бы уложиться в заданные сроки.
Резюме
Прототипирование действительно помогает сократить сроки разработки на несколько месяцев и даже лет. Так чего же вы ждете?
Теперь вы знаете ценность прототипирования и должны суметь получить согласие на него от клиентов или руководства. Но не забывайте о следующем:
• прототипирование продуктивно;
• прототипирование дает возможность показать и рассказать;
• прототипирование снижает вероятность неправильного восприятия;
• прототипирование позволяет сэкономить время, усилия и деньги;
• прототипирование создает быструю цепь обратной связи, в результате снижаются риски.
В следующей главе будет рассмотрен быстрый интерактивный процесс прототипирования, которым пользуюсь я.
Теперь вы знаете ценность прототипирования и должны суметь получить согласие на него от клиентов или руководства. Но не забывайте о следующем:
• прототипирование продуктивно;
• прототипирование дает возможность показать и рассказать;
• прототипирование снижает вероятность неправильного восприятия;
• прототипирование позволяет сэкономить время, усилия и деньги;
• прототипирование создает быструю цепь обратной связи, в результате снижаются риски.
В следующей главе будет рассмотрен быстрый интерактивный процесс прототипирования, которым пользуюсь я.
Глава 2
Процесс прототипирования
В проектировании архитектуры и продукта прототипирование – данность. Но это не обязательно верно для разработки программных продуктов.
Андерс Рэмси
Создание прототипов – обычная практика во многих областях проектирования, например архитектуре или промышленном дизайне. Она не просто допустима, но ожидаема.
Почему бы не использовать ее и в разработке программного обеспечения? В конце концов, эта область имеет много общего с архитектурным и промышленным проектированием, в том числе следующие характеристики:
• Все эти процессы относятся к проектированию.
• Для коммуникации при разработке используются искусственно созданные объекты.
• Конечный результат – вещественный объект, который люди могут испытывать и использовать.
Я думаю, дело в первую очередь в том, что в создании программного обеспечения акцент часто ставится на разработке, а не проектировании (представители отрасли называют этот процесс не «проектированием», а «разработкой программ»).
При создании программного обеспечения о проектировании часто задумываются слишком поздно. Акцент делается на технологиях или функциональности. А в архитектурном или промышленном проекте – именно на проектировании. Форма следует за функциями.
Кроме того, разработка программ воспринимается как производственный процесс, а архитектурное и промышленное проектирование – как ремесло, умение.
Возможно, все дело в способе обучения в разных областях деятельности. Обучение компьютерным наукам сосредоточено на преподавании технологий. В архитектурном и промышленном проектировании студентов учат принципам проектирования, включая то, что иногда называют дизайнерской студией.
Отсутствие дизайнерской студии
В архитектурном и промышленном проектировании дизайнерская студия – процесс, а не просто некое пространство. Этот процесс преподается в каждой солидной программе обучения проектированию. Однако сложно найти дизайнерскую студию в компьютерной науке.
В студии вы создаете проект или прототип и показываете его товарищам по учебе. Они критикуют вашу работу, показывая ее сильные и слабые стороны.
Проектирование, представление результата и критику нужно воспринимать как совместный, быстрый, итеративный процесс. В ходе этого процесса вы делитесь идеями, успехами и неудачами со своими товарищами.
Дизайнерская студия – главный элемент архитектурного и промышленного проектирования. Прототипирование – главная часть обучения. Поэтому студенты рано осваивают этот навык и используют его регулярно. Прототипирование становится обычным инструментом в процессе проектирования.
В студии вы создаете проект или прототип и показываете его товарищам по учебе. Они критикуют вашу работу, показывая ее сильные и слабые стороны.
Проектирование, представление результата и критику нужно воспринимать как совместный, быстрый, итеративный процесс. В ходе этого процесса вы делитесь идеями, успехами и неудачами со своими товарищами.
Дизайнерская студия – главный элемент архитектурного и промышленного проектирования. Прототипирование – главная часть обучения. Поэтому студенты рано осваивают этот навык и используют его регулярно. Прототипирование становится обычным инструментом в процессе проектирования.
На что похож процесс прототипирования
Не существует общего процесса сверхпрототипирования, единого рецепта, как у кока-колы. Однако есть ряд опробованных на практике принципов, которым можно следовать независимо от того, над чем вы работаете.
Не важно, какой процесс прототипирования вы решите использовать. Процесс – это способ закончить работу. Одним из наиболее распространенных подводных камней оказывается чрезмерная вовлеченность. Если вы нацелены на выполнение процесса, а не на достижение конечной цели, вам не удастся добиться успеха.
К тому же в хорошем процессе соблюден баланс между структурой и гибкостью. Он обеспечивает твердую основу, в то же время давая возможность гибко вносить корректировки и адаптироваться к изменениям графика или обстоятельств.
Наконец, хороший процесс ведет к успеху. Если выбранный процесс ограничивает возможности достижения успеха, его необходимо пересмотреть.
Марк Сандерс, изобретатель складного велосипеда Strida, описывает на YouTube процесс, который он использовал при создании своего «детища»[7]. Когда я смотрел это описание, я отметил следующее:
• Сандерс не думал о том, какие идеи хорошие, а какие плохие. Он создавал эскизы, чтобы исследовать все возможные идеи.
• Когда эскизов накапливалось много, он оценивал их, исходя из первоначальных целей создания продукта. Так отбирались лучшие идеи.
• Эскизы использовались только до этого этапа. Чтобы убедиться в работоспособности идей, ему приходилось создавать модели или прототипы.
• Эскизы сыграли решающую роль в усовершенствовании проекта и разработке модели Strida2.
В своем видео Марк описывает достаточно типичный процесс прототипирования, включающий следующие элементы:
• создание эскизов;
• оценку;
• создание модели;
• испытание.
В моей компании Messagefirst используется подход, подобный описанному Марком, но с небольшими отличиями. Мы берем страницу из книги дизайнерской студии и применяем модель с демонстрацией проекта и его критической оценкой. Так что наш видоизмененный процесс выглядит так:
• создание эскизов (набросков на демонстрационных досках или бумаге, программного кода);
• демонстрация и критическая оценка;
• моделирование (прототипирование);
• тестирование.
Одна из наших целей – быстрый цикл последовательных итераций и развития. Поэтому мы устанавливаем довольно короткую продолжительность первых двух стадий – создания эскизов; демонстрации и критической оценки. Это обеспечивает развитие процесса, повышает нашу производительность и эффективность прототипирования.
Наш процесс прототипирования также итеративен и эволюционен. Мы делаем набросок, показываем и критически оцениваем его, создаем прототип, показываем и критически оцениваем его, снова создаем прототип, а затем проводим тесты (рис. 2.1). Затем мы повторяем эту цепочку действий снова.
РИС. 2.1. Диаграмма итеративного процесса разработки и критических оценок
Вероятно, вы обратили внимание на циклический характер и неоднократное повторение двух шагов: создания наброска; демонстрации и критики. Наброски создаются и обсуждаются на протяжении всего процесса прототипирования. Фактически, когда мы показываем и оцениваем наши прототипы (как в компании, так и с привлечением клиента), мы делаем набросок наших исправлений.
Теперь давайте подробно рассмотрим наш процесс прототипирования, начиная с создания наброска.
Не важно, какой процесс прототипирования вы решите использовать. Процесс – это способ закончить работу. Одним из наиболее распространенных подводных камней оказывается чрезмерная вовлеченность. Если вы нацелены на выполнение процесса, а не на достижение конечной цели, вам не удастся добиться успеха.
К тому же в хорошем процессе соблюден баланс между структурой и гибкостью. Он обеспечивает твердую основу, в то же время давая возможность гибко вносить корректировки и адаптироваться к изменениям графика или обстоятельств.
Наконец, хороший процесс ведет к успеху. Если выбранный процесс ограничивает возможности достижения успеха, его необходимо пересмотреть.
Марк Сандерс, изобретатель складного велосипеда Strida, описывает на YouTube процесс, который он использовал при создании своего «детища»[7]. Когда я смотрел это описание, я отметил следующее:
• Сандерс не думал о том, какие идеи хорошие, а какие плохие. Он создавал эскизы, чтобы исследовать все возможные идеи.
• Когда эскизов накапливалось много, он оценивал их, исходя из первоначальных целей создания продукта. Так отбирались лучшие идеи.
• Эскизы использовались только до этого этапа. Чтобы убедиться в работоспособности идей, ему приходилось создавать модели или прототипы.
• Эскизы сыграли решающую роль в усовершенствовании проекта и разработке модели Strida2.
В своем видео Марк описывает достаточно типичный процесс прототипирования, включающий следующие элементы:
• создание эскизов;
• оценку;
• создание модели;
• испытание.
В моей компании Messagefirst используется подход, подобный описанному Марком, но с небольшими отличиями. Мы берем страницу из книги дизайнерской студии и применяем модель с демонстрацией проекта и его критической оценкой. Так что наш видоизмененный процесс выглядит так:
• создание эскизов (набросков на демонстрационных досках или бумаге, программного кода);
• демонстрация и критическая оценка;
• моделирование (прототипирование);
• тестирование.
Одна из наших целей – быстрый цикл последовательных итераций и развития. Поэтому мы устанавливаем довольно короткую продолжительность первых двух стадий – создания эскизов; демонстрации и критической оценки. Это обеспечивает развитие процесса, повышает нашу производительность и эффективность прототипирования.
Наш процесс прототипирования также итеративен и эволюционен. Мы делаем набросок, показываем и критически оцениваем его, создаем прототип, показываем и критически оцениваем его, снова создаем прототип, а затем проводим тесты (рис. 2.1). Затем мы повторяем эту цепочку действий снова.
Вероятно, вы обратили внимание на циклический характер и неоднократное повторение двух шагов: создания наброска; демонстрации и критики. Наброски создаются и обсуждаются на протяжении всего процесса прототипирования. Фактически, когда мы показываем и оцениваем наши прототипы (как в компании, так и с привлечением клиента), мы делаем набросок наших исправлений.
Теперь давайте подробно рассмотрим наш процесс прототипирования, начиная с создания наброска.
Часть 1: создание наброска
Создание наброска – производительная часть прототипирования, и ваша цель на этой стадии – «вытащить» идеи из головы и материализовать их.
Я предпочитаю устанавливать рамки для «времени делать наброски». Это заставляет сотрудников работать быстро и не вдаваться в детали.
Цель создания набросков – не конкретизация идей (этим мы занимаемся на стадии разработки прототипа), а определение концепций, «вытаскивание» их из головы максимально быстро и переход к следующей стадии.
РИС. 2.2. Набросок модуля настроек для видео на Vimeo, демонстрирующий толщину линий и пометки[8]
Вот как выглядит один из наших планшетов для набросков (рис. 2.3).[9]
РИС. 2.3. Пример планшета с несколькими набросками
Главная разница между планшетом для раскадровки и планшетом для набросков в том, что первый используется для последовательного изложения некой истории, а второй, наоборот, содержит набор идей, а их последовательность не имеет значения.
Рассмотрим преимущества и недостатки набросков на бумаге, лекционных досках и в программном коде.
Я предпочитаю устанавливать рамки для «времени делать наброски». Это заставляет сотрудников работать быстро и не вдаваться в детали.
Цель создания набросков – не конкретизация идей (этим мы занимаемся на стадии разработки прототипа), а определение концепций, «вытаскивание» их из головы максимально быстро и переход к следующей стадии.
СоветНаброски обычно делаются начерно, иногда они неполны и откровенно схематичны, как видно из рис. 2.2. Не старайтесь сделать все без изъяна. Попытайтесь материализовать ваши идеи.
Количество важнее качества
При создании наброска не старайтесь разделить идеи на хорошие и плохие. В данный момент ваша цель – изучить идеи. На стадии создания набросков количество важнее качества. Качество придет позже.
СоветБольшинство наших набросков делается на бумаге с использованием специальных планшетов. Планшет – просто лист бумаги с набором небольших окошек-шаблонов. Он подобен планшету для раскадровки.
Быстрый и яростный
Установите ограничения времени на создание набросков.
Я предпочитаю отводить на это 10–30 минут, а затем переходить к показу и критической оценке. Такой короткий период заставляет фокусироваться на продуктивных идеях, не вдаваясь в подробности.
Вот как выглядит один из наших планшетов для набросков (рис. 2.3).[9]
Главная разница между планшетом для раскадровки и планшетом для набросков в том, что первый используется для последовательного изложения некой истории, а второй, наоборот, содержит набор идей, а их последовательность не имеет значения.
СоветБольшинство наших набросков делается на бумаге, но иногда мы выполняем их на демонстрационных досках или в программном коде. Выбирайте среду, которая вам удобна, – лишь бы был результат.
Хорошая идея не приходит одна
Использование планшета для набросков – отличный способ выдать несколько идей. Небольшое пространство стимулирует обдумывание отдельных элементов интерфейса. Такой планшет также подойдет для небольшой раскадровки, если необходимо описать проект AJAX или RIA.
Рассмотрим преимущества и недостатки набросков на бумаге, лекционных досках и в программном коде.
Наброски в коде
Наброски можно делать не только на бумаге или лекционных досках. Разработчики часто делают их в привычной им среде – программном коде (это тоже возможно).
Одно из преимуществ набросков в коде – возможность их превращения в прототип. В условиях роста числа JavaScript-библиотек, CSS-фреймворков и шаблонизаторов вроде Ruby on Rails создавать наброски в коде становится все легче.
Преимущества
• Делать наброски в коде все легче, поскольку инструментов для этого становится больше.
• Наброски «оживают» – их можно опробовать на практике.
• Это дает возможность эффективно использовать написанный код.
Недостатки
• Не каждый умеет писать код.
• Для этого необходим компьютер.
• Возможностей для совместной работы меньше, чем при использовании бумаги или лекционной доски.
• Это занимает больше времени, чем создание набросков на бумаге или лекционной доске.
Одно из преимуществ набросков в коде – возможность их превращения в прототип. В условиях роста числа JavaScript-библиотек, CSS-фреймворков и шаблонизаторов вроде Ruby on Rails создавать наброски в коде становится все легче.
Преимущества
• Делать наброски в коде все легче, поскольку инструментов для этого становится больше.
• Наброски «оживают» – их можно опробовать на практике.
• Это дает возможность эффективно использовать написанный код.
Недостатки
• Не каждый умеет писать код.
• Для этого необходим компьютер.
• Возможностей для совместной работы меньше, чем при использовании бумаги или лекционной доски.
• Это занимает больше времени, чем создание набросков на бумаге или лекционной доске.
Создание набросков на лекционной доске
Одно из главных преимуществ создания набросков на лекционной доске – возможность совместной работы. Кто угодно может принять участие в обсуждении и предложить собственный вариант.
Преимущества
• Обеспечивает возможность совместной работы.
• На лекционной доске может рисовать каждый.
• Одновременно могут участвовать несколько человек.
• Не нужен компьютер.
• Внести изменения очень просто: достаточно стереть рисунок и изобразить что-то новое.
Недостатки
• Перенести лекционную доску сложнее, чем код или лист бумаги.
• Наброски статичны.
• Перенести наброски с доски на рабочие материалы иногда сложно[10].
Преимущества
• Обеспечивает возможность совместной работы.
• На лекционной доске может рисовать каждый.
• Одновременно могут участвовать несколько человек.
• Не нужен компьютер.
• Внести изменения очень просто: достаточно стереть рисунок и изобразить что-то новое.
Недостатки
• Перенести лекционную доску сложнее, чем код или лист бумаги.
• Наброски статичны.
• Перенести наброски с доски на рабочие материалы иногда сложно[10].
Создание набросков на бумаге
Создание набросков на бумаге остается моим излюбленным методом. Это обеспечивает примерно такие же возможности для совместной работы, как и лекционные доски. Однако листы бумаги очень легко перемещать и работать на них можно где угодно.
Преимущества
• Обеспечивает возможность совместной работы.
• На бумаге может рисовать каждый.
• Может участвовать несколько человек одновременно.
• Не нужен компьютер.
• Внести изменения просто – достаточно добавить в рисунок нужные элементы или взять другой лист бумаги.
• Этим можно заниматься когда угодно и где угодно.
• Наброски легко перемещать.
Недостатки
• Наброски статичны.
Преимущества
• Обеспечивает возможность совместной работы.
• На бумаге может рисовать каждый.
• Может участвовать несколько человек одновременно.
• Не нужен компьютер.
• Внести изменения просто – достаточно добавить в рисунок нужные элементы или взять другой лист бумаги.
• Этим можно заниматься когда угодно и где угодно.
• Наброски легко перемещать.
Недостатки
• Наброски статичны.
Часть 2: демонстрация и критика
Демонстрация и критика – вероятно, наиболее важная часть процесса прототипирования. На этой стадии мы сосредоточиваемся на качестве.
Метод демонстрации и критики я освоил в студенческие годы, когда изучал графическое проектирование. И хотя потом я выбрал специальность «английский язык и когнитивная психология», я никогда не забывал ценные уроки демонстрации и критики.
Цель на этой стадии – найти лучшие идеи. Вы показываете сильные стороны своей концепции, а ваши коллеги обращают внимание на области, которые требуют большей ясности или доработки. В этом и заключается суть стадии: обсудить, оценить и двигаться дальше.
Представляя наброски на обсуждение, мы часто крепим их к стене, как показано на рис. 2.4.
РИС. 2.4. Показ набросков в ходе их критического разбора в дизайнерской студии
Метод демонстрации и критики я освоил в студенческие годы, когда изучал графическое проектирование. И хотя потом я выбрал специальность «английский язык и когнитивная психология», я никогда не забывал ценные уроки демонстрации и критики.
Цель на этой стадии – найти лучшие идеи. Вы показываете сильные стороны своей концепции, а ваши коллеги обращают внимание на области, которые требуют большей ясности или доработки. В этом и заключается суть стадии: обсудить, оценить и двигаться дальше.
Представляя наброски на обсуждение, мы часто крепим их к стене, как показано на рис. 2.4.
Рекомендации по демонстрации и критике
Будьте кратки. Как я упоминал ранее, демонстрация и критика – вторая стадия, для которой мы устанавливаем жесткие рамки. Фактически на нее выделяется еще меньше времени, чем на набросок. Я стараюсь ограничивать время демонстрации двумя минутами, а обсуждение – тремя.
Не тратьте слишком много времени. Я знаю, что это звучит отчасти парадоксально. Но цель здесь – быстро получить результат и двигаться дальше. Вы сможете детализировать свои идеи позже.
Три минуты на демонстрацию идеи. Лимит времени в три минуты на демонстрацию идеи означает, что вы должны будете сосредоточиться на сильных сторонах. А если вы не можете объяснить суть идеи за это время, вероятно, что-то с вашей идеей не так.
Две минуты на критику. Ваши коллеги получают две минуты на критику вашей идеи. В это время они должны показать две-три сильные и одну-две слабые ее стороны.
Делайте заметки. Пишите прямо на набросках прототипа. Используйте критические замечания ваших коллег, чтобы уточнить и усилить вашу концепцию.
Не тратьте слишком много времени. Я знаю, что это звучит отчасти парадоксально. Но цель здесь – быстро получить результат и двигаться дальше. Вы сможете детализировать свои идеи позже.
Три минуты на демонстрацию идеи. Лимит времени в три минуты на демонстрацию идеи означает, что вы должны будете сосредоточиться на сильных сторонах. А если вы не можете объяснить суть идеи за это время, вероятно, что-то с вашей идеей не так.
Две минуты на критику. Ваши коллеги получают две минуты на критику вашей идеи. В это время они должны показать две-три сильные и одну-две слабые ее стороны.
Делайте заметки. Пишите прямо на набросках прототипа. Используйте критические замечания ваших коллег, чтобы уточнить и усилить вашу концепцию.
Часть 3: прототип
К началу этой стадии процесса вы набросали свои идеи, показали и обсудили их, отобрали только самые сильные варианты. Их прототипы вы и будете создавать.
Именно на стадии прототипирования вы начинаете детализировать свои проекты и выяснять, какие из них действительно жизнеспособны.
Именно на стадии прототипирования вы начинаете детализировать свои проекты и выяснять, какие из них действительно жизнеспособны.