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

• Описания

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

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

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

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

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

Во время разработки TrueCoverage, первого продукта NuMega для отображения результатов исполнения кода, команде снова пришлось искать форму пользовательского интерфейса. Чтобы помочь нам в этом, наш специалист по инженерной психологии (совмещавший эту должность с работой технического писателя) вдвоём с ведущим разработчиком создали бумажный прототип пользовательского интерфейса. Затем мы попросили других участников команды выполнить ряд задач, самых важных, по нашим оценкам. Когда новоявленные пользователи закончили свою работу, мы проанализировали их успехи и неудачи. Мы также собрали их отзывы и опробовали ряд новых подходов, решая проблемы, с которыми они столкнулись. Затем мы попросили поработать с прототипом других сотрудников компании, в частности менеджера по продукции и персонал технической поддержки, и также получили их отзывы. Наконец, мы испытали прототип за пределами компании, чтобы узнать, какое впечатление он произведёт на реальных пользователей. Мы выполняли доводку интерфейса очень быстро, прорабатывая до десятка прототипов в неделю. Действительно, во время проведения фазы тестирования нам удалось обнаружить ряд крупных проблем со слиянием данных. Страшно подумать, сколько времени отнял бы поиск и решение этих проблем обычными методами: наверное, не меньше, чем время полного цикла работы над выпуском, а может и больше. За короткое время (в сумме не больше двух недель) мы закончили проектирование интерфейса. Он не был совершенным, в дальнейшем пришлось вносить небольшие изменения. Но ещё до начала написания кода у нас была готовая на 90%, проверенная пользователями конструкция. Проработанный пользовательский интерфейс позволил точнее спланировать реализацию проекта, а тестировщики и создатели документации смогли если не опробовать программу на деле, то хотя бы разобраться в её особенностях раньше, чем она была написана.

Роль специалиста по инженерной психологии

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

Специалисты по инженерной психологии отвечают за решение следующих задач:

• Формулирование требований к прототипу пользовательского интерфейса

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

• Формулирование требований к прототипу программы установки

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

• Формирование первоначального впечатления от продукта

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

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

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

• Создание графики, изображений, значков и цветовых схем

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

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

• Лицензионное соглашение

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