Текст книги "Время — деньги. Создание команды разработчиков программного обеспечения"

Автор книги: Эд Салливан

сообщить о нарушении

Текущая страница: 13 (всего у книги 19 страниц)

Оценка технологий

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

О чём пойдёт речь

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

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

Как это делается

Оценивая технологию, нужно дать ответы на следующие вопросы.

• Возможности технологии: обладает ли новая технология возможностями, необходимыми для реализации проекта?

• Качество: приемлем ли уровень качества технологии?

• Совершенство: обеспечивает ли технология должную производительность, масштабируемость и устойчивость?

• Поддержка: обеспечена ли новая технология адекватной поддержкой?

• Простота использования: не слишком ли сложна новая технология в использовании и при отладке?

• Профессионализм команды: хватит ли у команды мастерства для применения этой технологии?

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

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

• использовать сформулированные критерии при оценке: объективно оценивайте результаты, опираясь на факты, а не на мнения;

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

Моделирование

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

О чём пойдёт речь

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

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

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

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

Из собственного опыта

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

Как это делается

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

• Определите ключевые факторы риска

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

• Составьте план экспериментов

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

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

• Попробуйте сымитировать конечный результат

Одно из ключевых требований, выполнив которое, можно считать создание прототипа завершённым, – имитация конечного результата. Для этого придётся заглянуть в будущее, чтобы увидеть программу в окончательном виде и попытаться заранее смоделировать её ключевые составляющие, Чтобы преуспеть в этом, придётся ограничиться созданием модели на основе набора временных компонентов и API, имитирующих готовую программу. Возможно, часть функций придётся запрограммировать жёстко, для других вообще написать заглушки, а реальные данные заменить имитационными. Все это допустимо на данном этапе – ведь создаётся всего лишь эмулятор реальной программы. Главная задача сейчас – создать «скелет» программы, а «мясом» он обрастёт позже.

• Используйте существующие наработки

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

• Оценивайте результаты

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

• Документируйте результаты.

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

Из собственного опыта

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

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

Типичные проблемы и их решение

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

Не торопитесь

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

Не увлекайтесь моделированием отдельных функций

Часто возникает искушение создать прототип какого-либо компонента без учёта контекста, не принимая во внимание характер его применения. Хотя сосредоточиться на узкой задаче много проще, в этом таится большая опасность. Моделирование не должно концентрироваться на отработке какого-то одного компонента, важно отработать совместную работу всех критически важных компонентов. Я очень рекомендую создавать общесистемные прототипы, в которых собраны воедино все критически важные фрагменты системы, даже если при этом приходится использовать искусственные данные, жёстко прошивать вызовы API или подменять их заглушками. Тем не менее в этом случае удастся составить хорошее представление о проблемах с интеграцией компонентов и убедиться в проектных решений на уровне системы.

Не оставляйте анализ производительности напоследок

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

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

Глава 10
Пользовательский интерфейс

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

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

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

Прототип пользовательского интерфейса

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

Почему прототип необходим?

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

Прототип даёт команде разработчиков множество преимуществ.

• Возможность сосредоточиться на решении ключевых задач.

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

Из собственного опыта

Когда в NuMega решили создать TrueTime, новую программу-профайлер, было ясно, что интерфейс для неё придётся создавать «с нуля». Но на что должен быть похож новый интерфейс? Какие действия наиболее важны для пользователя? Ознакомившись с положением в отрасли, мы обнаружили массу хороших продуктов, в целом составляющих весьма развитый набор ПО. Однако все существующие программы перегружали пользователя информацией, что, с нашей точки зрения, является недостатком, так как это очень затрудняет выполнение самой важной задачи продукта – поиск проблем с производительностью программ. Теперь мы знали, к чему стремиться: нужно сделать так, чтобы поиск проблем с производительностью с помощью нашей программы требовал не больше трёх щелчков. Вся команда сообща работала над созданием интерфейса, чтобы решить эту просто сформулированную, но такую трудную задачу. Мы решили не усложнять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую таятся проблемы с производительностью. В результате первый выпуск TrueTime принёс нам премию «Best of Show», присуждаемую журналом Comdex/Byte Magazine. Основным фактором успеха была концентрация усилий команды на решении определённых задач.

• Точность

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

• Планирование

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

• Документация

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

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

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

Создание прототипа

Возможно, дочитав до этого места, вы спросите: «Все это здорово, но как создать прототип?» Подход к созданию прототипов пользовательского интерфейса, который исповедует NuMega, основан на трёх простых принципах. Сначала мы определяем наиболее важные задачи, которые приходится решать пользователям. Затем мы быстро моделируем эти задачи на ранних стадиях работы над проектом, ещё до подготовки плана проекта в окончательном виде: это увеличивает шансы правильно оценить объём предстоящей работы. Наконец, мы очень быстро доводим прототип, внося в него ряд последовательных изменений, демонстрируя как внутренние, так и внешние его особенности. Такой подход позволяет тестировать прототип вместе с пользователями. Возможность быстрой доработки прототипа – ключевой фактор успеха, позволяющий как можно раньше привести его к окончательному виду.

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

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

Определение ключевых задач

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

• Задачи, которые скорее всего придётся решать новым пользователям программы

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

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

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

Виды прототипов

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

• Прототипы на бумаге

Для создания такого прототипа нужно просто нарисовать фрагменты пользовательского интерфейса на бумаге. Чтобы облегчить художникам и пользователям работу с таким прототипом, рисовать каждый элемент интерфейса надо на отдельном листе бумаги соответствующего размера. Расположите нарисованные меню, панели инструментов, командные кнопки, поля и другие элементы так, чтобы результат напоминал пользовательский интерфейс программы. Например, каждый раскрывающийся список и каждое диалоговое окно в этом случае будет на своём кусочке бумаги. Не обязательно добиваться точности воспроизведения – достаточно, чтобы эти кусочки бумаги давали чёткое представление об элементах пользовательского интерфейса.

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

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

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

Из собственного опыта

Бумажные прототипы могут быть чрезвычайно эффективны, но если команда не верит в результативность этой методики, использовать её нельзя. Чтобы побороть эту проблему в NuMega, мы отправили всю команду на однодневный методический курс, который читали в институте UEI (Usability Engineering Institute). Особое внимание в этом курсе уделялось работе с бумажными прототипами. Это был замечательный способ продемонстрировать участникам команды, насколько важны и эффективны могут быть прототипы на бумаге. Этот курс изменил наши представления о разработке ПО.

• Инструменты RAD

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

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

• Описания

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

Повторная оценка и доводка

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

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

Сколько времени занимает доводка интерфейса? Обычно немало. Приходится до 20 раз менять структуру интерфейса в зависимости от приложения. Следует вносить столько изменений, сколько потребуется, и доводить дизайн, пока не будет достигнут значительный прогресс. Помните: идея в том, чтобы быстро проработать множество вариантов дизайна, пока форма прототипа не станет более-менее постоянной. Полное представление о прогрессе прототипа дают результаты тестов. Удалось ли облегчить работу пользователей? Уменьшилось или увеличилось среднее время, которое пользователь тратит на решение некоторой задачи? Смогла ли последняя партия пользователей легко и быстро выполнить свои задачи или они столкнулись с проблемами? Ответы на эти вопросы позволят выяснить, как обстоят дела в работе над программой и сколько ещё предстоит сделать.