Главная страница
Навигация по странице:

  • 3.2.4. Определение инфраструктуры

  • 3.2.6. Сопровождение разработки

  • 4. МЕТОДЫ СБОРА ТРЕБОВАНИЙ 4.1. Значение качественных исследований

  • 4.2. Виды качественных исследований

  • 4.2.1. Интервьюирование заинтересованных лиц

  • 4.2.2. Интервьюирование экспертов в предметной области

  • 4.2.3. Интервьюирование покупателей

  • 4.2.4. Интервьюирование пользователей

  • 4.2.6. Наблюдение за пользователями

  • А. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурностроительного университета


    Скачать 3.99 Mb.
    НазваниеА. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурностроительного университета
    Дата18.10.2022
    Размер3.99 Mb.
    Формат файлаpdf
    Имя файла30090_be524d6887798c9f1750f09c7ee74f1f.pdf
    ТипДокументы
    #739938
    страница3 из 6
    1   2   3   4   5   6
    3.2.3. Выработка требований
    Методы проектирования, применяемые проектными командами на ста- дии выработки требований, обеспечивают столь нужную связь между поль- зовательскими и всеми прочими моделями и инфраструктурой проекта.
    Здесь используются сценарные методы проектирования с одним важным но-

    19
    вовведением: сценарии концентрируются не на абстрактных задачах пользо- вателей, но прежде всего на достижении целей и удовлетворении потребно- стей конкретных персонажей. Персонажи дают понимание того, какие зада- чи действительно важны и почему, что приводит к созданию интерфейса, минимизирующего число задач (усилий), но при этом увеличивающего от- дачу от них. Персонажи становятся главными участниками этих сценариев, и проектировщики изучают пространство возможных решений посредством своего рода ролевой игры.
    Для каждого интерфейса/ключевого персонажа процесс проектирования на данном этапе включает в себя анализ данных, связанных с персонажем, и анализ функциональных потребностей (выраженный в терминах объектов, действий и контекстов), сформированных и ранжированных с помощью це- лей персонажей, их моделей поведения, а также особенностей взаимодейст- вия с другими персонажами в различных контекстах.
    Такой анализ выполняется посредством последовательного уточнения контекстного сценария. Отправной точкой служит описание «одного дня жизни» персонажа, применяющего продукт, которое намечает высокоуров- невые точки соприкосновения с продуктом, после чего происходит пошаго- вая детализация. Помимо требований, определяемых сценарием, проекти- ровщики рассматривают навыки персонажа и его физические возможности, равно как и вопросы, связанные со средой применения продукта. Происхо- дит также учет и балансирование целей бизнеса, желаемых атрибутов бренда и технических ограничений с целями и потребностями персонажа. На выхо- де этого процесса возникает сбалансированный перечень требований, вклю- чающий в себя пользовательские требования, требования бизнеса и техниче- ские ограничения, которым продукт должен удовлетворять.
    3.2.4. Определение инфраструктуры
    На стадии определения инфраструктуры команда проектировщиков соз- дает общую концепцию продукта, определяя концепцию поведения, графи- ческого оформления и, если требуется, физической формы. Проектировщики взаимодействия синтезируют инфраструктуру взаимодействия при помощи контекстных сценариев в сочетании с еще двумя важнейшими методологи- ческими инструментами.
    Первый инструмент — набор общих принципов проектирования взаимо- действия, которые способствуют определению уместного в контексте раз- личных ситуаций поведения системы.
    Второй важнейший методологический инструмент — это набор шаблонов проектирования взаимодействия, являющихся решением (вариации здесь за- висят от контекста) для соответствующих типов когда-то проанализирован- ных проблем. Шаблоны проектирования взаимодействия выстроены в иерар- хию и эволюционируют с появлением новых контекстов. Их функция — не загнать творчество проектировщика в рамки, а дать ему точку опоры для ре- шения сложных задач, снабдив проверенными знаниями о проектировании.

    20
    Когда информационные и функциональные потребности описаны на та- ком высоком уровне, они преобразуются в элементы дизайна в соответствии с принципами взаимодействия, а затем структурируются при помощи шаб- лонов и принципов в эскизы дизайна и описание поведения. Результатом этого процесса является определение инфраструктуры взаимодействия — устоявшейся концепции проекта, задающей логическую и примерную фор- мальную структуру для последующей детализации. Эта детализация выпол- няется на следующей стадии при помощи последовательных итераций более узко сфокусированных сценариев. Такой подход часто представляет собой баланс проектирования «сверху вниз» (опирающегося на шаблоны) и проек- тирования «снизу вверх» (опирающегося на принципы).
    3.2.5. Детализация
    Стадия детализации схожа со стадией определения инфраструктуры, но в большей степени сосредоточена на подробностях реализации.
    Проектировщики взаимодействия фокусируются на согласованности за- дач, используя ключевые (пошаговые) маршруты, а также проверочные сце- нарии, дающие максимально подробные пути прохождения по пользователь- скому интерфейсу.
    3.2.6. Сопровождение разработки
    Даже очень продуманное и проверенное проектное решение не позволяет предусмотреть все препятствия и технические сложности на пути разработ- чиков. Мы на своем опыте знаем, насколько важно оставаться в контакте с разработчиками, чтобы отвечать на их вопросы, возникающие в процессе создания продукта. Часто требуется корректировать проектные решения, уп- рощать их по мере того, как команда разработчиков назначает приоритетны- ми отдельные фрагменты своей работы и урезает проект, чтобы уложиться в сроки. Если в тот момент, когда возникла нужда в таких решениях, коман- да проектировщиков недоступна, разработчикам приходится самостоятельно искать выход в условиях дефицита времени, что в конечном итоге может не лучшим образом сказаться на целостности продукта.
    Целеориентированное проектирование — мощный инструмент, отвечающий на самые важные вопросы, которые возникают при описании и проектировании цифрового продукта:
    Кем являются пользователи проектируемой системы ПО?
    Чего пытаются достичь пользователи проектируемой системы ПО?
    Что пользователи думают о своих целях сами?
    Какого рода опыт будет для пользователей привлекательным и полезным?
    Как должен себя вести разрабатываемый продукт?
    Как должен выглядеть разрабатываемый продукт?
    Как пользователи будут взаимодействовать с разрабатываемым продуктом?
    Как наиболее эффективно реализовать функции разрабатываемого продукта?
    Как начинающие пользователи будут знакомиться с разрабатываемым про- дуктом?

    21
    Каким образом разрабатываемый продукт сможет придать технологии при- влекательный облик и сделать ее понятной и управляемой?
    Как разрабатываемый продукт может решить проблемы пользователей?
    Как разрабатываемый продукт поможет в достижении целей тем пользовате- лям, которые редко работают с продуктом или имеют мало опыта?
    Каким образом разрабатываемый продукт сможет удовлетворить запросы опытных пользователей, которым нужна функциональная мощь и глубина прора- ботки?
    Контрольные вопросы
    1. Назовите три основных причины возникновения ошибок в проектировании.
    2. Дайте характеристику целеориентированного проектирования.
    3. Какие компоненты должны сочетать методы проектирования?
    4. Назовите основные этапы целеориентированного проектирования.
    5. Сформулируйте основные вопросы, которые возникают при описании и проекти- ровании цифрового продукта.

    22
    4. МЕТОДЫ СБОРА ТРЕБОВАНИЙ
    4.1. Значение качественных исследований
    Оценивать результат усилий по проектированию следует, исходя из того, насколько успешно он отвечает требованиям как пользователей, так и ком- пании — инициатора разработки.
    Если у проектировщика нет ясного и детального представления о пользо- вателях, для которых выполняется проектирование, если у него отсутствует понимание имеющихся ограничений, организационных задач и бизнес- целей, которые являются движущей силой разработки, то шансов на успех остается очень мало — неважно, насколько при этом хороши навыки и твор- ческие способности проектировщика.
    Глубокие знания о потенциальных пользователях можно получить лишь посредством качественных исследований.
    Качественные исследования позволяют изучить: поведение, взгляды, склонности потенциальных пользователей продукта; предметную область — технический и деловой контексты разрабатывае- мого продукта; используемый лексикон и прочие социальные аспекты предметной области; способы применения существующих продуктов.
    Качественные исследования способствуют ходу проектирования, по- скольку: обеспечивают доверие и уважение к команде проектировщиков (так как источник проектных решений можно проследить вплоть до результатов ис- следований); объединяют команду разрабатываемого продукта общим для всех пони- манием особенностей предметной области и проблем пользователей; дают руководителям возможность принимать решения по тем или иным вопросам проектирования продукта на основе данных — вместо догадок и личных предпочтений.
    Качественные методы в сравнении с количественными, как правило, ока- зываются более быстрыми, менее дорогостоящими и с большей вероятно- стью дают верные ответы на важные вопросы, без которых невозможно дос- тичь превосходных результатов.

    23
    Вот эти вопросы:
    Как продукт вписывается в более широкий контекст жизни пользователей?
    Каковы основные цели при работе с продуктом, и какие базовые задачи позволяют достигать этих целей?
    Какой опыт пользователи находят привлекательным? Как этот опыт со- относится с проектируемым продуктом?
    С какими проблемами сталкиваются пользователи при использовании имеющихся технологий для решения своих задач?
    Значение качественных исследований не ограничивается поддержкой процесса проектирования. Время, потраченное на то, чтобы увидеть за поль- зовательской аудиторией человеческие существа, способно принести плоды в виде важных для бизнеса прозрений, к которым невозможно прийти сред- ствами традиционных исследований рынка.
    Далее мы рассмотрим конкретные методы проведения качественных ис- следований, которые служат фундаментом целеориентированного проекти- рования.
    4.2. Виды качественных исследований
    Сосредоточим внимание на тех методиках, которые зарекомендовали себя в практической деятельности в последние годы. При этом постараемся пред- ставить эти техники с прагматической точки зрения, не углубляясь в теорию.
    Вот перечень методик качественных исследований:
    1) интервьюирование заинтересованных лиц;
    2) интервьюирование экспертов в предметной области (ЭПО);
    3) интервьюирование пользователей и покупателей;
    4) анкетирование;
    5) наблюдение за пользователями;
    6) самостоятельное описание требований;
    7) обзор литературы и технической документации;
    8) аудит продукта/прототипа и конкурирующих решений;
    9) совместные семинары.
    Рассмотрим подробнее каждую из методик.
    4.2.1. Интервьюирование заинтересованных лиц
    Исследование, предваряющее проектирование любого нового продукта, должно начинаться с получения представления о техническом окружении и бизнес-контексте продукта. Практически всегда продукт проектируется
    (или перепроектируется) для достижения одной или нескольких конкретных бизнес-целей (как правило, речь идет об извлечении прибыли). Обязанность проектировщиков — создавать решения, не теряя из виду эти бизнес-цели, поэтому крайне важно, чтобы команда проектировщиков начинала работу с изучения возможностей и ограничений, стоящих за краткой спецификаци- ей проекта.

    24
    В общем случае заинтересованное лицо — это любой человек, обладаю- щий полномочиями в отношении проектируемого продукта и/или несущий ответственность за какой-либо его аспект. Говоря более конкретно, заинте- ресованные лица — это ключевые члены организации, инициирующей рабо- ты по проекту.
    Интервьюирование заинтересованных лиц должно проводиться до начала любых исследований пользовательской аудитории, поскольку возникающие обсуждения нередко задают способы проведения пользовательских исследо- ваний.
    От заинтересованных лиц важно получить информацию по следующим вопросам: предварительное видение продукта; бюджет и график проекта; технические возможности и ограничения; потребности бизнеса; представления заинтересованных лиц о пользователях.
    Понимание этих аспектов и того, как они влияют на проектные решения, способствует разработке удачных продуктов. Каким бы притягательным ни был спроектированный продукт для пользователей и клиентов, без учета осуществимости и жизнеспособности предложенного решения нет никаких шансов, что продукт преуспеет.
    4.2.2. Интервьюирование экспертов в предметной области
    На ранних стадиях проектирования неоценимый вклад часто дает выяв- ление и интервьюирование нескольких экспертов в предметной области
    (ЭПО) — людей, сведущих в предметной области, на которую ориентирован проектируемый продукт. Многие ЭПО когда-то сами были пользователями текущей версии продукта или его прежних версий, а теперь могут быть пре- подавателями, менеджерами или консультантами. Часто это не сами заинте- ресованные лица, а нанятые ими эксперты.
    Как и заинтересованные лица, ЭПО способны представить продукт и его пользователей под интересным углом зрения, однако проектировщикам сле- дует проявлять осторожность и понимать, что точка зрения ЭПО в опреде- ленном смысле искажена.
    Некоторые из вещей, которые следует знать о работе с ЭПО:
    ЭПО — это зачастую пользователи-эксперты;
    ЭПО хорошо осведомлены, но они не проектировщики;
    ЭПО необходимы в сложных или специализированных предметных областях, таких как медицина, наука или финансовые службы; с ЭПО понадобится общаться в течение всего процесса проектирования.
    4.2.3. Интервьюирование покупателей
    Очень легко спутать пользователей с покупателями. В случае с потреби- тельскими продуктами покупатель и пользователь часто представлены в од- ном лице, однако в корпоративных и технических областях слова «пользова-

    25
    тели» и «покупатели» редко относятся к одной и той же группе людей. Хотя интервьюировать следует обе группы, у каждой из них будет собственная точка зрения на продукт, которую следует совершенно по-разному учиты- вать при принятии окончательных проектных решений.
    Покупатели продукта — это люди, принимающие решение о его приоб- ретении.
    Если речь идет о потребительских продуктах, покупатели зачастую яв- ляются пользователями продукта. В случае с большинством технических, медицинских и производственных продуктов покупателем оказывается вовсе не пользователь — часто это кто-либо из руководства компании либо ме- неджер по информационным технологиям, имеющий свои цели и потребно- сти, отличные от пользовательских.
    Чтобы сделать продукт жизнеспособным, важно понимать покупателей и их цели. Не менее важно осознавать, что покупатели редко сами пользуют- ся продуктом, а когда все же делают это, то совсем не так, как пользователи.
    В интервью с покупателями необходимо понять: каковы их цели в контексте приобретения продукта; что их не устраивает в существующих решениях; каков процесс принятия решения при покупке продуктов наподобие того, который вы проектируете; их роль в установке, обслуживании и управлении продуктом; проблемы предметной области и особенности используемой терминологии.
    Подобно ЭПО, покупатели могут предлагать множество идей о том, как улучшить продукт.
    4.2.4. Интервьюирование пользователей
    Пользователи продукта в процессе проектирования должны находиться в центре внимания. Именно эти люди (а не их руководители или команда под- держки) лично пытаются добиться каких-то результатов с помощью продукта.
    Если перепроектируется или улучшается существующий продукт, важно общаться не только с нынешними, но и с потенциальными пользователями, то есть с людьми, которые сегодня не пользуются продуктом, однако явля- ются хорошими кандидатами на его использование в будущем, поскольку имеют потребности, удовлетворяемые продуктом, и входят в его целевую аудиторию.
    Интервьюирование обеих категорий позволяет выявить то влияние, кото- рое оказывает на поведение и образ мысли пользователя опыт работы с су- ществующей версией продукта.
    От пользователей необходимо получить следующую информацию: контекст интеграции продукта (или аналогичной системы, если продукт еще не создан) в жизнь или рабочий процесс пользователей — когда, почему и каким образом применяется (или будет применяться) продукт; осведомленность в предметной области с точки зрения пользователя — что необходимо знать пользователям, чтобы делать свою работу;

    26
    существующие задачи и виды деятельности — как те, которые выполня- ются при помощи данного продукта, так и те, которые не поддерживаются им; цели и мотивы использования продукта; ментальная модель — как пользователи думают о своей работе и дея- тельности, а также чего они ожидают от продукта; проблемы и сложности при работе с продуктом (или с аналогичной сис- темой, если продукт еще не создан).
    4.2.5. Анкетирование
    Анкетирование — самый малозатратный для аналитика способ извлече- ния информации, он же — и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.
    Недостатки анкетирования очевидны: респонденты часто бывают неспособны либо слабо мотивированы в том, чтобы хорошо и информативно заполнить анкету; велика вероятность получить неполную или вовсе ложную информацию.
    Преимущество в том, что подготовка и анализ анкет требуют небольшого ресурса.
    Рекомендуется формулировать в анкетах вопросы с замкнутым циклом ответов в одной из следующих трех форм: многоальтернативные вопросы (могут расширяться комментариями рес- пондента в свободной форме); рейтинговые вопросы (представляют предопределенный набор ответов на сформулированные вопросы с использованием таких значений, как «аб- солютно согласен», «согласен», «отношусь нейтрально», «не согласен», «аб- солютно не согласен», «не знаю»); вопросы с ранжированием (предусматривает ранжирование (упорядочи- вание) ответов путем присваивания им порядковых номеров, процентных значений и т. п.).
    4.2.6. Наблюдение за пользователями
    Большинство людей не способны точно описать собственное поведение, особенно когда находятся вне контекста своей деятельности.
    Из этого следует, что интервью, проводимое вне контекста ситуации, ко- торую стремится понять проектировщик, даст менее полные и точные данные.
    Можно обсудить с пользователями их представления о собственном по- ведении, а можно непосредственно наблюдать это поведение. Второй вари- ант дает лучшие результаты.
    Виды наблюдения: пассивное; активное (при активном наблюдении аналитик работает как участник ко- манды, что позволяет улучшить понимание процессов).
    Через наблюдение, а возможно, и участие аналитики получают информа- цию о происходящих день за днем операциях из первых рук. Во время на-

    27
    блюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал документы или разговари- вал с экспертами.
    Недостаток этой стратегии в том, что наблюдатель, как и всякий «изме- рительный прибор», вносит помехи в результаты измерений: сотрудники ор- ганизации, находясь «под колпаком», могут начать вести себя принципиаль- но по-другому, чем обычно.
    Вероятно, наиболее эффективным методом сбора качественных данных о пользователях является сочетание интервьюирования и наблюдения.
    1   2   3   4   5   6


    написать администратору сайта