Как правило, разработчик не может при помощи только воображения определить значимые характеристики будущих пользователей. Или, возможно, ему известны вовсе не те характеристики пользователей, которые могут помочь в разработке интерфейса. К примеру, для разработчика сайта, на котором осуществляется заказ пиццы на дом в режиме он-лайн, не имеет особого значения интенсивность прерываний пользователя, тогда как для разработчика офисного приложения подобная информация крайне важна.
Как узнать характеристики будущего пользователя (построить его модель)? Самым общим методом является опрос людей, являющихся (как вы надеетесь) вашими потенциальными пользователями. Если разрабатываемая программа предназначена для широкого круга пользователей (скажем, редактор web-страниц), можно выбрать наугад пять коллег, друзей, родственников, рассказать им в общих словах о назначении вашей программы. Затем предложите ситуацию: «Ты работаешь над web-страничкой. У тебя есть файл с картинкой под именем Picture1. JPG. Ты хочешь вставить эту картинку на свою страницу. Как ты себе представляешь свои действия?» Далее полезно задавать вопросы по ходу процесса: «Куда делась картинка? Если теперь ты удалишь свой файл Picture1.JPG, сможет ли страница по-прежнему показывать твою картинку?» Можно спросить, где хранятся ярлычки картинок. Конечно, некоторые пользователи не имеют об этом представления и никогда об этом не задумывались, другим все равно, но когда будет обработано много различных мнений, более отчетливо станет решение, которое вас устроит. Просто просите их думать вслух, задавайте вопросы, которые предполагают альтернативные варианты ответов, и попытайтесь построить модель пользователя. Самый часто встречающийся вариант ответа и есть, как правило, нужная характеристика пользователя, важнейшая часть его модели. Так, постепенно варьируя задания и вопросы, можно построить более или менее адекватную модель пользователя.
Следующий этап – проверка сделанных предположений, т.е. предварительной модели. Проверка предположений предполагает обычно создание прототипа ПИ (хотя бы бумажного на этом этапе – см. разд. 4.2.1.) и его апробацию, т.е. первые варианты его юзабилити-тестирования. Попросите группу приглашенных вами пользователей комментировать свои действия во время решения поставленных задач. Цель тестирования заключается в том, чтобы понять, чего они ожидают от программы. Предположим, вы дали задание: вставить картинку. Если вы увидите, что человек пытается мышью затащить картинку в документ, вы поймете, что вам следует поддержать технологию drag-and-drop. Если он остановит курсор на кнопке Вставка панели инструментов, вы поймете, что было бы полезно разместить в этом меню опцию Картинка. Когда же он на панели инструментов будет пытаться заменить слова Тimes New Roman на Вставить картинку, вы сообразите, что вам попался редкий персонаж, который ищет командную строку, будучи совсем не знаком с графическими интерфейсами.
Какое количество пользователей следует привлекать к подобным тестам? Неправильно думать: чем больше, тем лучше. Обычно достаточно пяти-семи человек. Подготовка и проведение тестирования на каждом этапе проектирования ПИ (а иногда и несколько раз внутри одного этапа, ведь тестирование – итерационная процедура) – довольно трудоемкое дело, и если привлекать большее количество людей, то будет наблюдаться скорее всего повторяемость результатов. Важно помнить, что профили пользователей, как правило, не должны быть очень сложными. Догадки обычных пользователей о том, как работает та или иная программа, будут скорее простыми, очевидными и, весьма вероятно, будут отличаться от хитроумных задумок программистов.
В этом разделе рассматриваются два типа моделей пользователя. Первый охватывает характеристики человека, определяемые его социальным и организационным окружением. Эти характеристики представлены с помощью:
• социотехнических моделей, представляющих совместно социальные и технические требования;
• методологии разработки программных продуктов, рассматривающей человеческие и организационные аспекты в едином контексте и в широком смысле;
• совместной разработки, предполагающей непосредственное включение пользователя в процесс работы над проектом.
Второй базируется на когнитивных моделях, т.е. акцент делается на процессах восприятия, памяти, мышления, психологических особенностях. Эти модели представлены:
• иерархической моделью, представляющей задачи пользователя и структуру целей;
• лингвистическими моделями, представляющими единый язык человека и программы;
• физическими моделями, представляющими моторные навыки человека.
Оба типа моделей ставят в центр внимания пользователя: первый тип как бы смотрит на мир вокруг человека, второй – сосредоточен на его индивидуальных особенностях. Сначала же рассмотрим пользовательские профили как наиболее простой тип фиксации характеристик будущего пользователя.
3.2. Пользовательские профили
3.3. Модели, определяемые социальным и организационным окружением пользователя
3.3.1. Социотехнические модели
3.3.2. Методология разработки программных продуктов, рассматривающая в едином контексте человеческие и организационные аспекты
Как узнать характеристики будущего пользователя (построить его модель)? Самым общим методом является опрос людей, являющихся (как вы надеетесь) вашими потенциальными пользователями. Если разрабатываемая программа предназначена для широкого круга пользователей (скажем, редактор web-страниц), можно выбрать наугад пять коллег, друзей, родственников, рассказать им в общих словах о назначении вашей программы. Затем предложите ситуацию: «Ты работаешь над web-страничкой. У тебя есть файл с картинкой под именем Picture1. JPG. Ты хочешь вставить эту картинку на свою страницу. Как ты себе представляешь свои действия?» Далее полезно задавать вопросы по ходу процесса: «Куда делась картинка? Если теперь ты удалишь свой файл Picture1.JPG, сможет ли страница по-прежнему показывать твою картинку?» Можно спросить, где хранятся ярлычки картинок. Конечно, некоторые пользователи не имеют об этом представления и никогда об этом не задумывались, другим все равно, но когда будет обработано много различных мнений, более отчетливо станет решение, которое вас устроит. Просто просите их думать вслух, задавайте вопросы, которые предполагают альтернативные варианты ответов, и попытайтесь построить модель пользователя. Самый часто встречающийся вариант ответа и есть, как правило, нужная характеристика пользователя, важнейшая часть его модели. Так, постепенно варьируя задания и вопросы, можно построить более или менее адекватную модель пользователя.
Следующий этап – проверка сделанных предположений, т.е. предварительной модели. Проверка предположений предполагает обычно создание прототипа ПИ (хотя бы бумажного на этом этапе – см. разд. 4.2.1.) и его апробацию, т.е. первые варианты его юзабилити-тестирования. Попросите группу приглашенных вами пользователей комментировать свои действия во время решения поставленных задач. Цель тестирования заключается в том, чтобы понять, чего они ожидают от программы. Предположим, вы дали задание: вставить картинку. Если вы увидите, что человек пытается мышью затащить картинку в документ, вы поймете, что вам следует поддержать технологию drag-and-drop. Если он остановит курсор на кнопке Вставка панели инструментов, вы поймете, что было бы полезно разместить в этом меню опцию Картинка. Когда же он на панели инструментов будет пытаться заменить слова Тimes New Roman на Вставить картинку, вы сообразите, что вам попался редкий персонаж, который ищет командную строку, будучи совсем не знаком с графическими интерфейсами.
Какое количество пользователей следует привлекать к подобным тестам? Неправильно думать: чем больше, тем лучше. Обычно достаточно пяти-семи человек. Подготовка и проведение тестирования на каждом этапе проектирования ПИ (а иногда и несколько раз внутри одного этапа, ведь тестирование – итерационная процедура) – довольно трудоемкое дело, и если привлекать большее количество людей, то будет наблюдаться скорее всего повторяемость результатов. Важно помнить, что профили пользователей, как правило, не должны быть очень сложными. Догадки обычных пользователей о том, как работает та или иная программа, будут скорее простыми, очевидными и, весьма вероятно, будут отличаться от хитроумных задумок программистов.
В этом разделе рассматриваются два типа моделей пользователя. Первый охватывает характеристики человека, определяемые его социальным и организационным окружением. Эти характеристики представлены с помощью:
• социотехнических моделей, представляющих совместно социальные и технические требования;
• методологии разработки программных продуктов, рассматривающей человеческие и организационные аспекты в едином контексте и в широком смысле;
• совместной разработки, предполагающей непосредственное включение пользователя в процесс работы над проектом.
Второй базируется на когнитивных моделях, т.е. акцент делается на процессах восприятия, памяти, мышления, психологических особенностях. Эти модели представлены:
• иерархической моделью, представляющей задачи пользователя и структуру целей;
• лингвистическими моделями, представляющими единый язык человека и программы;
• физическими моделями, представляющими моторные навыки человека.
Оба типа моделей ставят в центр внимания пользователя: первый тип как бы смотрит на мир вокруг человека, второй – сосредоточен на его индивидуальных особенностях. Сначала же рассмотрим пользовательские профили как наиболее простой тип фиксации характеристик будущего пользователя.
3.2. Пользовательские профили
Наиболее простой и распространенной формой представления характеристик будущего пользователя являются пользовательские профили. Для сбора информации о пользователях используются различные методы: качественные (например, проведение интервью с пользователями конкурирующих продуктов) и количественные (если есть возможность, можно провести формализованное анкетирование пользователей). Кроме непосредственного сбора информации разработчики могут описывать пользователям часть программного продукта на основе своего опыта.
Польза от профилей заключается в том, что впоследствии на их основе отбираются объекты тестирования. Это должно, во-первых, облегчить процесс отбора участников тестирования и, во-вторых, обеспечить валидность результатов тестирования (а тестирование принесет мало пользы, если будет проходить без участия реальных будущих пользователей). В результате работ по определению пользовательских профилей разработчики получают описание главных категорий пользователей, причем часто одна из них может определяться как основная. Точное их количество, разумеется, зависит от системы. Для системы, рассчитанной на массовую аудиторию, количество категорий пользователей будет больше, нежели для системы, предназначенной для использования исключительно специалистами. Например, программа для обработки любительских фотографий должна быть сделана так, чтобы ею могли пользоваться как можно большее количество людей: от программиста с двадцатилетним стажем, у которого постоянно не хватает времени, до вашей бабушки, которая решила привести в порядок семейный фотоальбом. В этом случае категорий пользователей будет, как нетрудно догадаться, несколько больше, нежели при проектировании интерфейса для управления атомной электростанцией.
Каждый из профилей содержит подробное описание характеристик пользователя, существенных для работы с проектируемой системой. Сюда должны входить цели пользователя, его социальные характеристики (пол, возраст, образование, профессия и т.п.), характерные для него модели поведения, условия, в которых он будет использовать систему, навыки пользователя, характеристики его компьютера. Другими словами, все то, что окажет впоследствии значимое влияние на предпочтения пользователя в интерфейсе программы. Ведь создать набор характеристик не проблема. Но нужны именно такие характеристики, которые в дальнейшем станут действительно эффективным средством отбора адекватной целевой аудитории для юзабилити-тестирования.
Пример профиля
1. Социальные характеристики:
• пол;
• возраст;
• образование;
• уровень занимаемой должности;
• использует ли компьютер только он и (или) другие (члены семьи, коллеги).
2. Навыки и умения:
• общий стаж работы с компьютером;
• стаж использования Интернета;
• уровень теоретических знаний об устройстве Интернета;
• уровень практических знаний о внутреннем устройстве Интернета (что конкретно умеет делать).
3. Рабочая среда:
• тип подключения к Интернету;
• размер монитора;
• экранное разрешение;
• быстродействие компьютера;
• используемая операционная система;
• язык операционной системы;
• наиболее часто используемые программные приложения;
• количество времени, проводимого ежедневно за компьютером на работе;
• количество времени, проводимого ежедневно за компьютером дома.
4. Мотивационно-целевая среда:
• цели пользователя вообще;
• мотивация к обучению работе с программой (сайтом).
К определению целей и мотивации пользователей следует подходить особенно осторожно, так как тут вполне можно столкнуться с тем, что наши стереотипы и представления о целях вовсе не совпадают с реальным положением вещей. Важно не путать реальные цели и мотивации пользователей с декларируемыми целями. Основные вопросы и рекомендации, которые следует всегда держать в поле зрения при создании профиля потенциальных пользователей, следующие:
• кто они;
• возможно, они не похожи на вас;
• поговорите с ними;
• наблюдайте за ними;
• используйте ваше воображение.
Кто они
Они молоды или стары, опытные пользователи или новички? Ответ на этот вопрос не очевиден, и его надо задавать снова и снова по мере расширения знаний о системе и ее окружении. Этот вопрос тем более труден, чем более универсальным является ПО, которое разрабатывается. Если это текстовый процессор, то ясно, что будет много разных пользователей с различными целями и характеристиками. Подобная проблема очень остра во многих web-сайтах, которые посещают очень разные люди. При этом появляется соблазн представить некоего универсального пользователя с универсальными навыками и универсальными целями. Однако более правильно в подобных ситуациях думать о нескольких определенных группах пользователей.
Возможно, они не похожи на вас
При разработке любой системы достаточно просто представлять дело так, как будто вы и будете ее основным пользователем. Часто разработчик говорит: «Но ведь очевидно, как надо делать». Это может быть очевидно для него. Например, предпочтения мужчин и женщин могут существенно различаться, а большинство сотрудников, разрабатывающих программное обеспечение, мужчины. Необходимо иметь в виду, что, несмотря на значительный разброс индивидуальных особенностей, женщины в целом лучше понимают других людей и менее эгоцентричны.
Поговорите с ними
Трудно определить, о чем думает другой человек, поэтому лучше спросить его. Это может происходить в разных формах (структурированные опросы о работе и жизни, открытые обсуждения, вовлечение потенциальных пользователей непосредственно в процесс разработки). Последнее называется совместной разработкой. Привлекая пользователей к разработке, можно получить более полные знание контекста работы и их потребностей. Однако существует и недостаток: вы не можете быть уверенными в том, что используемая вами группа полностью и адекватно отражает портреты всех потенциальных пользователей.
Люди могут сказать вам о том, как что-либо происходит в реальности, а не то, как должно происходить, по утверждению компании. Нужно завоевать их доверие, так как часто фактические действия входят в противоречие с корпоративной политикой. Такие противоречия типичны для методов, касающихся организационных аспектов.
Наблюдайте за ними
Несмотря на большую важность того, что люди вам говорят, этого для вас недостаточно. Когда обладатель черного пояса по дзюдо излагает, как он произвел бросок противника, его рассказ, как правило, не соответствует тому, что он в действительности делал. Это тем более очевидно в интеллектуальных видах активности, которые всегда были особенно трудны для интроспекции.
Профессионал имеет прочные практические навыки в своей области и может в ней делать что-то. Академик в той же самой области может не уметь делать практические вещи, но он знает в данной области много. Знания и навыки – не одно и то же. Иногда люди владеют и тем и другим, но не всегда. Лучшие спортивные тренеры могут не быть лучшими атлетами, лучшие живописцы могут не быть лучшими искусствоведами.
Поэтому важно именно наблюдать то, что люди делают, слышать то, что они говорят. Это предполагает наблюдение и регистрацию того, как они работают и вообще проводят день, используя видеокамеру или магнитофон. Такие наблюдения проводятся и над пользователями. Можно, например, попросить их вести записи или через каждые 15 мин подавать звуковой сигнал и просить их записывать, что они делают (структурированная форма отчета побуждает к более точному ответу).
Другой способ узнать, что люди делают, состоит в том, чтобы смотреть, чем они пользуются и что создают. Посмотрите на типичный стол в офисе. Есть газеты, письма, файлы, возможно, степлер, компьютер, разные заметки… Рассмотрение каждого из них по отдельности не поможет понять, почему они все на столе, при решении конкретной задачи. Только пользователь может объяснить их роль. Иначе говоря, наблюдение говорит вам, что именно пользователь делает, а он говорит вам, почему он это делает.
Используйте ваше воображение
Даже если бы вы хотели привлечь множество потенциальных пользователей к вашей разработке, это не всегда будет возможно. Это может быть слишком дорого, или они, возможно, не смогут уделить вам много времени (например, консультант больницы), может быть и так, что их слишком много (например, если вы создаете web-сайт). Однако, не имея возможности привлечь всех реальных пользователей, вы можете, по крайней мере, пробовать вообразить их опыт. Но это довольно опасно. Было бы легко думать: «Если бы я был складским менеджером, я сделал бы то и это». Следует понять не то, что вы бы сделали на месте пользователей, а то, что они сделают. Это требует использования некоторого метода. Вообразите себя складским менеджером. Какой смысл имеет для него опция меню «undo»?
Как показывает опыт, часто бывает полезно «оживить» потенциального пользователя, придумав ему имя, отчество, элементы биографии, определенные черты характера и даже внешний облик. Для этого создаются так называемые персоны (от англ. «persona» – действующее лицо художественного произведения), хотя лучше перевести это на русский как «персонажи». В данном случае персонаж – это конкретное описание воображаемого пользователя, которого мы придумываем сами. Такое описание создается на основе одного из профилей (другими словами, наш персонаж является представителем одной из определенных ранее категорий пользователей). Это помогает более рельефно изобразить себе типичного представителя какой-либо из пользовательских категорий. При помощи такого персонажа гораздо проще понять пользователя, увидеть за набором данных, собранных в профиле, живого человека. Все это не дает разработчику забыть, для кого разрабатывается продукт. Когда дизайнер постоянно смотрит в глаза пользователю (пусть придуманному), деятельность его становится более осмысленной.
Персонажу дают имя, возраст, описывают его цели в зависимости от того, что за систему мы проектируем, кратко описывают либо его рабочий день (если, например, проектируется офисное приложение), либо другой контекст использования системы. При этом если в профиле сказано: «пользователи данного типа работают в условиях частых прерываний основной деятельности», то в профиле будет написано: «на протяжении первой половины дня Владимиру Ильичу приходится часто отвлекаться от редактирования отчета для того, чтобы отвечать на телефонные звонки клиентов». Иногда даже для документа, который описывает персонаж, рисуется небольшой портрет или вставляется фотография. В дальнейшем созданные персонажи могут очень пригодиться для создания пользовательских сценариев.
Ниже приведен пример персонажа Ольги – складского менеджера.
Польза от профилей заключается в том, что впоследствии на их основе отбираются объекты тестирования. Это должно, во-первых, облегчить процесс отбора участников тестирования и, во-вторых, обеспечить валидность результатов тестирования (а тестирование принесет мало пользы, если будет проходить без участия реальных будущих пользователей). В результате работ по определению пользовательских профилей разработчики получают описание главных категорий пользователей, причем часто одна из них может определяться как основная. Точное их количество, разумеется, зависит от системы. Для системы, рассчитанной на массовую аудиторию, количество категорий пользователей будет больше, нежели для системы, предназначенной для использования исключительно специалистами. Например, программа для обработки любительских фотографий должна быть сделана так, чтобы ею могли пользоваться как можно большее количество людей: от программиста с двадцатилетним стажем, у которого постоянно не хватает времени, до вашей бабушки, которая решила привести в порядок семейный фотоальбом. В этом случае категорий пользователей будет, как нетрудно догадаться, несколько больше, нежели при проектировании интерфейса для управления атомной электростанцией.
Каждый из профилей содержит подробное описание характеристик пользователя, существенных для работы с проектируемой системой. Сюда должны входить цели пользователя, его социальные характеристики (пол, возраст, образование, профессия и т.п.), характерные для него модели поведения, условия, в которых он будет использовать систему, навыки пользователя, характеристики его компьютера. Другими словами, все то, что окажет впоследствии значимое влияние на предпочтения пользователя в интерфейсе программы. Ведь создать набор характеристик не проблема. Но нужны именно такие характеристики, которые в дальнейшем станут действительно эффективным средством отбора адекватной целевой аудитории для юзабилити-тестирования.
Пример профиля
1. Социальные характеристики:
• пол;
• возраст;
• образование;
• уровень занимаемой должности;
• использует ли компьютер только он и (или) другие (члены семьи, коллеги).
2. Навыки и умения:
• общий стаж работы с компьютером;
• стаж использования Интернета;
• уровень теоретических знаний об устройстве Интернета;
• уровень практических знаний о внутреннем устройстве Интернета (что конкретно умеет делать).
3. Рабочая среда:
• тип подключения к Интернету;
• размер монитора;
• экранное разрешение;
• быстродействие компьютера;
• используемая операционная система;
• язык операционной системы;
• наиболее часто используемые программные приложения;
• количество времени, проводимого ежедневно за компьютером на работе;
• количество времени, проводимого ежедневно за компьютером дома.
4. Мотивационно-целевая среда:
• цели пользователя вообще;
• мотивация к обучению работе с программой (сайтом).
К определению целей и мотивации пользователей следует подходить особенно осторожно, так как тут вполне можно столкнуться с тем, что наши стереотипы и представления о целях вовсе не совпадают с реальным положением вещей. Важно не путать реальные цели и мотивации пользователей с декларируемыми целями. Основные вопросы и рекомендации, которые следует всегда держать в поле зрения при создании профиля потенциальных пользователей, следующие:
• кто они;
• возможно, они не похожи на вас;
• поговорите с ними;
• наблюдайте за ними;
• используйте ваше воображение.
Кто они
Они молоды или стары, опытные пользователи или новички? Ответ на этот вопрос не очевиден, и его надо задавать снова и снова по мере расширения знаний о системе и ее окружении. Этот вопрос тем более труден, чем более универсальным является ПО, которое разрабатывается. Если это текстовый процессор, то ясно, что будет много разных пользователей с различными целями и характеристиками. Подобная проблема очень остра во многих web-сайтах, которые посещают очень разные люди. При этом появляется соблазн представить некоего универсального пользователя с универсальными навыками и универсальными целями. Однако более правильно в подобных ситуациях думать о нескольких определенных группах пользователей.
Возможно, они не похожи на вас
При разработке любой системы достаточно просто представлять дело так, как будто вы и будете ее основным пользователем. Часто разработчик говорит: «Но ведь очевидно, как надо делать». Это может быть очевидно для него. Например, предпочтения мужчин и женщин могут существенно различаться, а большинство сотрудников, разрабатывающих программное обеспечение, мужчины. Необходимо иметь в виду, что, несмотря на значительный разброс индивидуальных особенностей, женщины в целом лучше понимают других людей и менее эгоцентричны.
Поговорите с ними
Трудно определить, о чем думает другой человек, поэтому лучше спросить его. Это может происходить в разных формах (структурированные опросы о работе и жизни, открытые обсуждения, вовлечение потенциальных пользователей непосредственно в процесс разработки). Последнее называется совместной разработкой. Привлекая пользователей к разработке, можно получить более полные знание контекста работы и их потребностей. Однако существует и недостаток: вы не можете быть уверенными в том, что используемая вами группа полностью и адекватно отражает портреты всех потенциальных пользователей.
Люди могут сказать вам о том, как что-либо происходит в реальности, а не то, как должно происходить, по утверждению компании. Нужно завоевать их доверие, так как часто фактические действия входят в противоречие с корпоративной политикой. Такие противоречия типичны для методов, касающихся организационных аспектов.
Наблюдайте за ними
Несмотря на большую важность того, что люди вам говорят, этого для вас недостаточно. Когда обладатель черного пояса по дзюдо излагает, как он произвел бросок противника, его рассказ, как правило, не соответствует тому, что он в действительности делал. Это тем более очевидно в интеллектуальных видах активности, которые всегда были особенно трудны для интроспекции.
Профессионал имеет прочные практические навыки в своей области и может в ней делать что-то. Академик в той же самой области может не уметь делать практические вещи, но он знает в данной области много. Знания и навыки – не одно и то же. Иногда люди владеют и тем и другим, но не всегда. Лучшие спортивные тренеры могут не быть лучшими атлетами, лучшие живописцы могут не быть лучшими искусствоведами.
Поэтому важно именно наблюдать то, что люди делают, слышать то, что они говорят. Это предполагает наблюдение и регистрацию того, как они работают и вообще проводят день, используя видеокамеру или магнитофон. Такие наблюдения проводятся и над пользователями. Можно, например, попросить их вести записи или через каждые 15 мин подавать звуковой сигнал и просить их записывать, что они делают (структурированная форма отчета побуждает к более точному ответу).
Другой способ узнать, что люди делают, состоит в том, чтобы смотреть, чем они пользуются и что создают. Посмотрите на типичный стол в офисе. Есть газеты, письма, файлы, возможно, степлер, компьютер, разные заметки… Рассмотрение каждого из них по отдельности не поможет понять, почему они все на столе, при решении конкретной задачи. Только пользователь может объяснить их роль. Иначе говоря, наблюдение говорит вам, что именно пользователь делает, а он говорит вам, почему он это делает.
Используйте ваше воображение
Даже если бы вы хотели привлечь множество потенциальных пользователей к вашей разработке, это не всегда будет возможно. Это может быть слишком дорого, или они, возможно, не смогут уделить вам много времени (например, консультант больницы), может быть и так, что их слишком много (например, если вы создаете web-сайт). Однако, не имея возможности привлечь всех реальных пользователей, вы можете, по крайней мере, пробовать вообразить их опыт. Но это довольно опасно. Было бы легко думать: «Если бы я был складским менеджером, я сделал бы то и это». Следует понять не то, что вы бы сделали на месте пользователей, а то, что они сделают. Это требует использования некоторого метода. Вообразите себя складским менеджером. Какой смысл имеет для него опция меню «undo»?
Как показывает опыт, часто бывает полезно «оживить» потенциального пользователя, придумав ему имя, отчество, элементы биографии, определенные черты характера и даже внешний облик. Для этого создаются так называемые персоны (от англ. «persona» – действующее лицо художественного произведения), хотя лучше перевести это на русский как «персонажи». В данном случае персонаж – это конкретное описание воображаемого пользователя, которого мы придумываем сами. Такое описание создается на основе одного из профилей (другими словами, наш персонаж является представителем одной из определенных ранее категорий пользователей). Это помогает более рельефно изобразить себе типичного представителя какой-либо из пользовательских категорий. При помощи такого персонажа гораздо проще понять пользователя, увидеть за набором данных, собранных в профиле, живого человека. Все это не дает разработчику забыть, для кого разрабатывается продукт. Когда дизайнер постоянно смотрит в глаза пользователю (пусть придуманному), деятельность его становится более осмысленной.
Персонажу дают имя, возраст, описывают его цели в зависимости от того, что за систему мы проектируем, кратко описывают либо его рабочий день (если, например, проектируется офисное приложение), либо другой контекст использования системы. При этом если в профиле сказано: «пользователи данного типа работают в условиях частых прерываний основной деятельности», то в профиле будет написано: «на протяжении первой половины дня Владимиру Ильичу приходится часто отвлекаться от редактирования отчета для того, чтобы отвечать на телефонные звонки клиентов». Иногда даже для документа, который описывает персонаж, рисуется небольшой портрет или вставляется фотография. В дальнейшем созданные персонажи могут очень пригодиться для создания пользовательских сценариев.
Ниже приведен пример персонажа Ольги – складского менеджера.
Ольге 37 лет. Она была менеджером склада в течение пяти лет и работала в компании «Воздушные замки» в течение 12 лет. Она не поступила в университет, но училась по вечерам в бизнес-школе. У нее двое детей в возрасте 15 и 7 лет, она не любит работать поздно. Она закончила часть вводного компьютерного курса несколько лет назад, но была вынуждена прервать, когда была назначена на должность, и больше не могла позволить себе тратить столько времени. У нее отличное зрение, но движения правой руки немного ограниченны после несчастного случая на производстве три года назад. Она работает с энтузиазмом, проявляет готовность как делегировать ответственность, так и брать ее на себя, если от управления компании поступает соответствующее распоряжение. Однако она ощущает беспокойство от плана введения новой компьютерной системы.Коллектив разработчиков должен иметь несколько таких персонажей, отражающих различные типы пользователей и их роли. Портрет персонажа основан на результатах изучения реальных пользователей, наблюдения за ними, их профилей и т.д. Когда рассматривается какое-то решение ПИ, разработчики могут спросить: «Как Ольга будет реагировать на это?» Только чувствуя, что Ольга является реальным человеком, разработчики могут вообразить, как она будет себя вести.
3.3. Модели, определяемые социальным и организационным окружением пользователя
3.3.1. Социотехнические модели
В целом этот тип моделей сосредоточен на описании внешних факторов, в частности организационных и социальных, и направлен на совмещение социальных и технических аспектов. Существует целый ряд социотехнических моделей, которые используются при разработке программных продуктов, мы рассмотрим основные из них:
• USTM (User Skill and Task Match – соответствие навыков пользо-вателяи требований задачи) и ее форму для малых предприятий CUS-TOM;
• OSTA (Open System Task Analysis – анализ задач открытой системы);
• ETHICS (Effective Technical and Hyman Implementation of Computer Systems – эффективная реализация технической и человеческой составляющих в компьютерных системах).
USTM/CUSTOM. USTM (User Skill and Task Match – соответствие навыков пользователя и требований задачи) – это схематическое представление структуры задачи со словесным описанием. Этим достигается объединение структурности и человеческого фактора. Модификация USTM для малых предприятий именуется CUSTOM, где упор делается на учете требований совладельцев; при этом предполагается, что совладельцы не являются конечными пользователями системой. Совладельцы определяются как лица, на которых сказываются (которые зависят от) успех либо неудачи системы. Выделяют четыре категории совладельцев:
1) первичные – используют систему;
2) вторичные – непосредственно не используют систему, но получают ее «выход» или могут определять исходные данные для системы (например, те, кто получает отчеты, сгенерированные системой);
3) третичные – не попадают в категории 1 и 2, но на них влияет успех или неудача системы (например, директор, который может получать пользу (прибыль) либо убыток в зависимости от работы системы);
4) обеспечивающие – участвуют в разработке, развитии и сохранении системы.
Пример – система заказов авиабилетов. Первичные совладельцы – это офисы туристических агентств, центральный офис бронирования авиарейсов. Вторичные – это пользователи в этих агентствах (т.е. агенты), менеджмент авиакомпании. Третичные – это конкуренты, гражданские власти, совладельцы авиакомпании. Обеспечивающие – это команда разработчиков, управление департамента информационных технологий.
Модель CUSTOM применяется на начальных этапах разработки: в начале работы над проектом и, возможно, на этапе постановки задачи, когда только определены возможности продукта. Это методология, основанная на заполнении формуляров (готовых форм), которая предполагает определенный набор вопросов на каждой стадии разработки. Краткий пример типичного перечня вопросов в модели CUSTOM таков:
• Чего хотят достичь совладельцы и как измеряется успех?
• Что является источником удовлетворения от работы для совладельцев и что – источником неудовлетворения и стресса?
• Какими знаниями и навыками обладают совладельцы?
• Каково отношение совладельцев к работе и к компьютерным технологиям?
• Имеются ли некоторые групповые предпочтения среди совладельцев, которые будут влиять на приемлемость программного продукта?
• Каковы характеристики задачи совладельцев в смысле ее частоты, фрагментации (или декомпозиции) и выбора действий?
• Встают ли перед совладельцами вопросы, касающиеся конкретной ответственности, безопасности или конфиденциальности (исходя из работы системы)?
• Каковы физические условия работы совладельцев?
Иными словами, определяются и описываются совладельцы (по именам), их роль и функции в работе, их первичные цели, реальное влияние на дела, знания, навыки, готовность к новациям, обычные ежедневные задачи и т.д. Аналогично определяются и описываются рабочие группы, при этом уделяется особое внимание связкам «задача-средство». CUSTOM создает полезную канву для понимания потребностей совладельцев путем использования простых бланков и относительно стандартных вопросов (все это может делаться вручную, так как эта работа не очень трудоемкая).
OSTA (Open System Task Analysis – анализ задач открытой системы) описывает прежде всего организационное окружение технической системы. В OSTA пользовательские аспекты системы, такие, как потребительские свойства и доступность, объединены с техническими аспектами, например с системным функционированием. В OSTA различают восемь стадий:
1) в терминах целей пользователя описывается основная задача, которую технология должна реализовать;
2) определяются способы ввода задач в систему. Эти способы могут иметь разные характеристики, что может явиться некоторым ограничением для разработки;
3) описывается внешнее окружение, в котором могут быть представлены физические, экономические и даже политические аспекты;
4) описываются процессы трансформации внутри системы в терминах выполняемых действий или объектов;
5) проводится социологическое описание пользователей, учитывающее существование рабочих групп и отношения внутри и вне организации;
6) описывается техническая система в терминах ее конфигурации и объединения с другими системами;
7) определяются показатели функционирования, охватывающие и технические, и социальные характеристики системы;
8) точно определяется новая техническая система.
Выходы OSTA представляются в виде описаний, понятных разработчикам (например, схемы, графики и текстовые описания).
ETHICS (Effective Technical and Hyman Implementation of Computer Systems – эффективная реализация технической и человеческой составляющих в компьютерных системах). ETHICS, так же как и OSTA, имеет дело с техническими и человеческими требованиями, но отличается от OSTA тем, что использует две принципиально разные команды разработчиков. Одна направлена на техническое решение вопроса, не вдаваясь в человеческие проблемы, другая заботится в основном об адекватности системы и человеческих проблем, не особо вдаваясь в их программную реализацию. Иначе говоря, модель ETHICS основана на двух параллельных и до какого-то времени независимых частях разработки – человеческом и техническом аспектах. В модели ETHICS соответствующие команды разработчиков работают отдельно и только потом пытаются объединить свои решения. Предполагается, что тем самым уменьшается влияние разных специалистов друг на друга. Суть метода – независимая работа двух команд: человеческих и технических предпочтений. Затем результаты предлагаемых каждой командой проектов пытаются совместить, создавая продукт, удовлетворяющий требованиям обеих команд. В методе ETHICS различают несколько основных стадий:
1) определяется проблема и описываются система, цели и задачи, а также критерии удовлетворительного функционирования. Определяются ограничения системы – как технические, так и эргономические;
2) формируются две команды разработчиков, одна по проверке человеческих аспектов, другая – технических. Цели и задачи, описанные на первой стадии, ранжируются по приоритетности и проверяются на совместимость до того, как принимаются технические и социальные решения;
3) рассматриваются две группы решений – с упором на технические и человеческие аспекты. Эти решения оцениваются по заранее установленному (на первой стадии) критерию, составляется список возможных вариантов, желательно короткий;
4) проверяются на совместимость решения, выделенные на третьей стадии;
5) ранжируются в соответствии с ранее выбранным критерием совместные пары человеко-технических решений;
6) разрабатываются детали проекта.
• USTM (User Skill and Task Match – соответствие навыков пользо-вателяи требований задачи) и ее форму для малых предприятий CUS-TOM;
• OSTA (Open System Task Analysis – анализ задач открытой системы);
• ETHICS (Effective Technical and Hyman Implementation of Computer Systems – эффективная реализация технической и человеческой составляющих в компьютерных системах).
USTM/CUSTOM. USTM (User Skill and Task Match – соответствие навыков пользователя и требований задачи) – это схематическое представление структуры задачи со словесным описанием. Этим достигается объединение структурности и человеческого фактора. Модификация USTM для малых предприятий именуется CUSTOM, где упор делается на учете требований совладельцев; при этом предполагается, что совладельцы не являются конечными пользователями системой. Совладельцы определяются как лица, на которых сказываются (которые зависят от) успех либо неудачи системы. Выделяют четыре категории совладельцев:
1) первичные – используют систему;
2) вторичные – непосредственно не используют систему, но получают ее «выход» или могут определять исходные данные для системы (например, те, кто получает отчеты, сгенерированные системой);
3) третичные – не попадают в категории 1 и 2, но на них влияет успех или неудача системы (например, директор, который может получать пользу (прибыль) либо убыток в зависимости от работы системы);
4) обеспечивающие – участвуют в разработке, развитии и сохранении системы.
Пример – система заказов авиабилетов. Первичные совладельцы – это офисы туристических агентств, центральный офис бронирования авиарейсов. Вторичные – это пользователи в этих агентствах (т.е. агенты), менеджмент авиакомпании. Третичные – это конкуренты, гражданские власти, совладельцы авиакомпании. Обеспечивающие – это команда разработчиков, управление департамента информационных технологий.
Модель CUSTOM применяется на начальных этапах разработки: в начале работы над проектом и, возможно, на этапе постановки задачи, когда только определены возможности продукта. Это методология, основанная на заполнении формуляров (готовых форм), которая предполагает определенный набор вопросов на каждой стадии разработки. Краткий пример типичного перечня вопросов в модели CUSTOM таков:
• Чего хотят достичь совладельцы и как измеряется успех?
• Что является источником удовлетворения от работы для совладельцев и что – источником неудовлетворения и стресса?
• Какими знаниями и навыками обладают совладельцы?
• Каково отношение совладельцев к работе и к компьютерным технологиям?
• Имеются ли некоторые групповые предпочтения среди совладельцев, которые будут влиять на приемлемость программного продукта?
• Каковы характеристики задачи совладельцев в смысле ее частоты, фрагментации (или декомпозиции) и выбора действий?
• Встают ли перед совладельцами вопросы, касающиеся конкретной ответственности, безопасности или конфиденциальности (исходя из работы системы)?
• Каковы физические условия работы совладельцев?
Иными словами, определяются и описываются совладельцы (по именам), их роль и функции в работе, их первичные цели, реальное влияние на дела, знания, навыки, готовность к новациям, обычные ежедневные задачи и т.д. Аналогично определяются и описываются рабочие группы, при этом уделяется особое внимание связкам «задача-средство». CUSTOM создает полезную канву для понимания потребностей совладельцев путем использования простых бланков и относительно стандартных вопросов (все это может делаться вручную, так как эта работа не очень трудоемкая).
OSTA (Open System Task Analysis – анализ задач открытой системы) описывает прежде всего организационное окружение технической системы. В OSTA пользовательские аспекты системы, такие, как потребительские свойства и доступность, объединены с техническими аспектами, например с системным функционированием. В OSTA различают восемь стадий:
1) в терминах целей пользователя описывается основная задача, которую технология должна реализовать;
2) определяются способы ввода задач в систему. Эти способы могут иметь разные характеристики, что может явиться некоторым ограничением для разработки;
3) описывается внешнее окружение, в котором могут быть представлены физические, экономические и даже политические аспекты;
4) описываются процессы трансформации внутри системы в терминах выполняемых действий или объектов;
5) проводится социологическое описание пользователей, учитывающее существование рабочих групп и отношения внутри и вне организации;
6) описывается техническая система в терминах ее конфигурации и объединения с другими системами;
7) определяются показатели функционирования, охватывающие и технические, и социальные характеристики системы;
8) точно определяется новая техническая система.
Выходы OSTA представляются в виде описаний, понятных разработчикам (например, схемы, графики и текстовые описания).
ETHICS (Effective Technical and Hyman Implementation of Computer Systems – эффективная реализация технической и человеческой составляющих в компьютерных системах). ETHICS, так же как и OSTA, имеет дело с техническими и человеческими требованиями, но отличается от OSTA тем, что использует две принципиально разные команды разработчиков. Одна направлена на техническое решение вопроса, не вдаваясь в человеческие проблемы, другая заботится в основном об адекватности системы и человеческих проблем, не особо вдаваясь в их программную реализацию. Иначе говоря, модель ETHICS основана на двух параллельных и до какого-то времени независимых частях разработки – человеческом и техническом аспектах. В модели ETHICS соответствующие команды разработчиков работают отдельно и только потом пытаются объединить свои решения. Предполагается, что тем самым уменьшается влияние разных специалистов друг на друга. Суть метода – независимая работа двух команд: человеческих и технических предпочтений. Затем результаты предлагаемых каждой командой проектов пытаются совместить, создавая продукт, удовлетворяющий требованиям обеих команд. В методе ETHICS различают несколько основных стадий:
1) определяется проблема и описываются система, цели и задачи, а также критерии удовлетворительного функционирования. Определяются ограничения системы – как технические, так и эргономические;
2) формируются две команды разработчиков, одна по проверке человеческих аспектов, другая – технических. Цели и задачи, описанные на первой стадии, ранжируются по приоритетности и проверяются на совместимость до того, как принимаются технические и социальные решения;
3) рассматриваются две группы решений – с упором на технические и человеческие аспекты. Эти решения оцениваются по заранее установленному (на первой стадии) критерию, составляется список возможных вариантов, желательно короткий;
4) проверяются на совместимость решения, выделенные на третьей стадии;
5) ранжируются в соответствии с ранее выбранным критерием совместные пары человеко-технических решений;
6) разрабатываются детали проекта.
3.3.2. Методология разработки программных продуктов, рассматривающая в едином контексте человеческие и организационные аспекты
Методология разработки программных продуктов (Soft Systems Methodology – SSM) – второе направление учета характеристик человека при разработке программных продуктов в целом и ПИ в частности. Мы рассматривали социотехнические модели как средство, позволяющее определить потребности, как человеческие, так и технические. Методология разработки программных продуктов рассматривает человеческий и технический аспекты в рамках единой системы, где и люди, и технология разработки есть лишь ее компоненты. Существо SSM – в акценте на взаимном и совместном понимании проблем всеми разработчиками, как ориентирующимися на технологию, так и теми, кому важнее человеческая адекватность. Эта методология включает несколько стадий. При этом различают стадии, относящиеся к реальному миру, и стадии, относящиеся к системе.
Стадия 1 – осознание проблемы и начало анализа, что сопровождается детальным рассмотрением проблемы. Картина должна включать всех участников, их задачи, интересы, группы, в которые они входят, организационные структуры и процессы и может быть выражена по-разному, но всегда ясно, что здесь нет верных или неверных ответов; она должна отражать все аспекты функционирования системы и быть понятной для разработчиков.
Стадия 2 – это движение от реального мира к миру системы и попытка сформулировать «базовые определения» системы. Таких определений может быть несколько, к примеру отражающих разное понимание системы разработчиками. Базовые определения описываются в терминах CATWOE (Clients, Actors, Trasformations, Weltanschauung, Owner, Environment):
• Clients – те, кто получает продукцию и/или прибыль от работы системы.
• Actors – те, кто работает внутри системы.
• Trasformations – трансформация изменений, произведенных системой. Важнейшая часть базовых определений, так как это ведет к деятельности, которая требует включения в следующую стадию. Чтобы выявить трансформации, рассматривают вход и выход системы.
• Weltanschauung (с нем. – мировоззрение). Как понимается система с позиций конкретного базового определения.
• Owner – собственники, т.е. те, кому принадлежит система, кому она подотчетна и кто вправе санкционировать изменения в ней.
• Environment – внешнее окружение, т.е. мир, в котором функционирует система и который влияет на нее.
Стадия 1 – осознание проблемы и начало анализа, что сопровождается детальным рассмотрением проблемы. Картина должна включать всех участников, их задачи, интересы, группы, в которые они входят, организационные структуры и процессы и может быть выражена по-разному, но всегда ясно, что здесь нет верных или неверных ответов; она должна отражать все аспекты функционирования системы и быть понятной для разработчиков.
Стадия 2 – это движение от реального мира к миру системы и попытка сформулировать «базовые определения» системы. Таких определений может быть несколько, к примеру отражающих разное понимание системы разработчиками. Базовые определения описываются в терминах CATWOE (Clients, Actors, Trasformations, Weltanschauung, Owner, Environment):
• Clients – те, кто получает продукцию и/или прибыль от работы системы.
• Actors – те, кто работает внутри системы.
• Trasformations – трансформация изменений, произведенных системой. Важнейшая часть базовых определений, так как это ведет к деятельности, которая требует включения в следующую стадию. Чтобы выявить трансформации, рассматривают вход и выход системы.
• Weltanschauung (с нем. – мировоззрение). Как понимается система с позиций конкретного базового определения.
• Owner – собственники, т.е. те, кому принадлежит система, кому она подотчетна и кто вправе санкционировать изменения в ней.
• Environment – внешнее окружение, т.е. мир, в котором функционирует система и который влияет на нее.
Пример. Базовые определения для менеджмента пассажирскими авиаперевозками – системы бронирования билетов.Рассматривается некая система бронирования авиабилетов для сотрудников туристических агентств, продающих билеты населению. Эта система принадлежит менеджменту пассажирских авиаперевозок, управляется объединением туристических агентств, работает по всему миру в сети туристических агентств, в рамках международного законодательства в части авиаперевозок:
Конец бесплатного ознакомительного фрагмента