Методы вовлечения пользователей проект на этапе конструирования

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

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

• Количество элементов в списке, возвращаемом в результате операции поиска.

• Первоначальное время отклика при вызове изображения.

• Непредусмотренное поведение.

• Необычные форматы печати.

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

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

Методы вовлечения пользователей в проект на этапе оценки продукта

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

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

Лучшие практические приемы

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

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

• Предоставьте возможность пользователям вмешиваться и давать указания.

• Как можно быстрее предоставляйте в распоряжение пользователей конкрет­ную визуализацию проектных решений (быстрое проектирование и прототипирование).

• Как можно быстрее удовлетворяйте потребности пользователей (эффективные итерации/эволюция).

• Общайтесь друг с другом (обучайте, слушайте, внимайте и отвечайте).

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

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

• Документируйте все ваши действия.

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

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

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

Некоторые, полезные правила

Будучи довольно простым, метод вовлечения пользователей в проект через BUG-группу требует значительных усилий со стороны ориентированной на пользователей проектной бригады и пользователей. Чтобы сохранить у пользователей желание про­должать совместную работу в надежде получить отдачу, следует принять во внимание множество факторов.

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

• Не спрашивайте у пользователей: "Что вы хотите?". Большинство пользо­вателей могут не знать, как ответить на этот вопрос, многие стараются просто отделаться от ответа. Взамен дайте пользователям возможность выразить свои нужды с помощью таких вопросов: "Какие задачи вы выполняете чаще всего?", "Какие задачи наиболее трудны для вас?" и "Что, по-вашему, следовало бы улучшить?".

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

• Нельзя недооценивать участие пользователей в проекте. Следует признать важность исходной информации, предоставляемой пользователями, и поблаго­дарить их за потраченное время и усилия. С пользователями следует встреча­ться регулярно (один-два раза в неделю; на совещание необходимо отводить до двух часов), а их круг должен оставаться устойчивым (ядро + остальные).

• Не следует приходить на совещание с конечными пользователями непод­готовленным. Будьте подготовленным и последовательным (повестка дня, тезисы, экраны, изображения на прозрачной подложке и т.д.), поощряйте в пользователях любопытство, следите ха ходом событий и держите его под контролем.

Для надлежащего выполнения типичного цикла работы с BUG-группой может потребоваться несколько дней (рис. 6.3).

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

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

• Не слишком держитесь за проектные решения в процессе их пересмотра.

Проводите пересмотр, ориентированный на сценарий/поток задач, предлагая множество альтернатив. Для этого используйте вопросы типа: "Что вы думаете об этом проекте?", "Что вам нравится/не нравится?", слушайте и делайте заме­чания, стараясь быть объективным. ^:

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

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

• Не принимайте проектных решений сходу. Необходимо тщательно продумы­вать проектные решения и понимать их последствия. Следует возвращаться к проектным решениям, имея спектр альтернатив, показывать впечатление и ощущение от ПИ, замечать, что требует объяснений, предоставлять пользо­вателям практическую интерактивную модель или прототип, а иногда давать пользователям возможность "порулить".

• Не пренебрегайте обратной связью с пользователями. Выделяйте достаточ­но времени для анализа каждого вопроса; документально фиксируйте инфор­мацию, полученную по обратной связи, и предположения пользователей неза­висимо от того, что говорят/делают пользователи и как они это гово­рят/делают; быстро исправляйте положение (устранение ошибок или ответы на вопросы).

• Не переоценивайте ваши идеи. Помогите пользователям понять значение существующих методов, сущность компромиссов (например, требования к боль­шим объемам информации или заполнение пространства экрана) и говорите с ними с одного голоса (т.е. все члены ориентированной на пользователя проектной бригады отправляют пользователям общие сообщения).

• Не злоупотребляйте временем пользователей. Ответственно относитесь к использованию времени пользователей, добавляйте ценность их ПО, основы­ваясь на их исходной информации, стремитесь строить коллективную работу с пользователями.

Продолжение обсуждения проекта: вовлечение пользователей

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

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

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

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

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

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

Наверное, прежде чем идти держать ответ, неплохо провести небольшое исследо­вание.

Вопросы?

Ссылки

Beyer H., and Holtzblatt К. Contextual Design, Morgan-Kauffman: San Francisco, 1998. Carmel E. et al. PD and Joint Application Design: A Transatlantic Comparison, Communications

of the ACM, June 1993.

Muller M. et al. Taxonomy ofPD Practice: A Brief Practitioner's Guide, Communications of the ACMJune 1993.

Torres R. et al. Case Study in Participatory Design, UPA Conference Proceedings, 1998.