Метод «Value Conflict Mapping +»
В работе аналитика нередки ситуации, когда по разным причинам важные бизнес-требования или противоречия в требованиях заинтересованных лиц выясняются уже после выработки функциональных требований. В лучшем случае дело ограничивается незначительными изменениями в дизайне решения. Однако бывает, что введение новых условий ведет к необходимости вернуться на этап выяснения бизнес-требований и, возможно, впоследствии проектировать систему с нуля. Естественно, это вызывает удорожание проекта и сдвиг сроков, что приводит к вполне обоснованной неудовлетворенности заказчика.
Андрей Курьян в своем докладе представил достаточно интересный метод “Value Conflict Mapping +” (далее — VCM+), предназначенный для выявления противоречий в требованиях заинтересованных лиц, а также для поиска скрытых требований. То есть данный метод предназначен для решения вышеуказанной проблемы на начальном этапе. Каждая система делится на две части — «полезную» и «вредную» подсистемы. Полезной называется та, которая проектируется и разрабатывается с целью принесения пользы. Вредная подсистема — та, которая возникает вследствие создания полезной системы и оказывает нежелательное влияние. Такая система возникает сама по себе и является неотъемлемой частью полезной системы. Как правило, это является результатом несогласованности требований заинтересованных лиц. Иначе говоря, одно и то же решение может нести пользу одному представителю заказчика, но вред другому. Суть метода VCM+ сводится к тому, чтобы выявить вредную систему и принять шаги по ее устранению или минимизации негативного эффекта.
Используя знание о вредных и полезных системах, аналитик должен произвести следующие действия при проектировании решений:
- Определить решения для наиболее важных бизнес-требований.
- Для каждого решения определить так называемый «основной параметр» и его значение.
- Инвертировать значение параметра и сформировать инвертированное решение.
- Наконец, найти тех заинтересованных лиц, которым инвертированное решение важнее, чем изначальное.
Андрей продемонстрировал реальный случай совместного существования вредной и полезной систем. Одна логистическая компания установила на свои автомобили датчики GPS для контроля местоположения грузов. Данные, которые получали менеджеры, можно было использовать для контроля расхода топлива в режиме реального времени. Через некоторое время датчики стали выходить из строя. В результате проверки выяснилось, что водители автомобилей преднамеренно ломали датчики. С помощью метода VCM+ можно было бы в самом начале выявить противоречие в интересах двух сторон: менеджеры требовали четких данных о расходе топлива, а водители были крайне незаинтересованны в том, чтобы кто-то узнал о случаях хищения топлива.
В рассмотренном примере хорошо видна ценность данного метода: после выявления противоречий аналитик получает достаточно информации для улучшения решения. И для ранее незаинтересованной стороны недостаток превратится в достоинство. Чтобы разрешить конфликт интересов, было принято решение о премировании водителей в размере сэкономленного топлива, а бизнес перестал нести убытки, связанные с ремонтом или заменой датчиков.
Разберем данный пример подробнее с указанием шагов. Основным бизнес-требованием (1) является желание менеджеров получать точную информацию о расходе топлива в режиме реального времени. Решением (1) становится использование тех самых датчиков. В данном случае, основной параметр (2) уже сформулирован в требованиях — объем фактически потребленного топлива. Основные участники — менеджеры — заинтересованы в том, чтобы расход был как можно меньше. Инвертируя значение параметра (3) мы определяем, что обратным значением является высокий уровень расхода топлива. Наконец, мы начинаем искать (4) тех, кто заинтересован в том, чтобы менеджеры получали информацию о высоком расходе топлива, т.е. ложную, и не могли это информацию проверить. Имея представление и о круге лиц, взаимодействующих с решением, вывод напрашивается сам собой.
Несмотря на очевидную полезность VCM+, он имеет один недостаток — невозможность использования на ранних этапах сбора требований, до создания функциональных требований. Дело в том, что выявление серьезных противоречий может привести к необходимости вернуться на стадию разработки новой версии решения или даже на этап сбора требований. Это особенно болезненно для крупных систем, где полную картину зачастую можно увидеть только после проектирования большей части решения. По этой причине использование мтодики представляется более эффективным при разработке с нуля небольших и средних по величине систем, где проектирование решения занимает меньше времени и, соответственно, цена ошибки меньше. При разработке с нуля крупных систем, потребуется применение других методов, которые позволяют выявить противоречия на этапе сбора требований; тем не менее, использование метода при доработке уже существующих систем также может оказаться весьма эффективным.
В связи со спецификой одного из наших проектов, мы планируем воспользоваться методом VCM+ для поиска противоречий в требованиях между заказчиками и конечными пользователями внутренней автоматизированной системы, которая в ближайшие полгода поступит в эксплуатацию. О результатах наших исследований мы напишем отдельную статью.
Метод “Customer Journey Mapping”
Также, стоит упомянуть о докладе Юрия Веденина, в котором рассматривался метод Customer Journey Mapping (далее — CJM). CJM предназначен для выявления опыта пользователя, получаемого при взаимодействии с какой-либо системой (в том числе информационной), с момента первого контакта, в процессе пользования и дальнейшего обслуживания. В целом, метод позволяет понять, в каких точках предоставляемый сервис вызывает у пользователя положительные эмоции, а в каких его еще нужно улучшать. Метод не имеет жестко регламентированной нотации, что предоставляет возможность быстрого освоения и пространство для кастомизации под конкретный проект.
Построение CJM состоит из следующих базовых рекомендуемых шагов:
- Выбор пользователя и его подробное описание. Сюда необходимо поместить любую информацию о пользователях системы, которая может оказаться полезной: возраст, статус, пол, семейное положение, что любит или ненавидит и т.д.
- Фиксация целей пользователя и бизнеса. При построении карты, необходимо определить, как легко пользователь достигает своих целей и как при этом достигаются цели бизнеса.
- Описание последовательности этапов, которые пользователь проходит, прежде чем достичь своих целей.
- Фиксация конкретных шагов на каждом из этапов.
- Построение графика удовлетворенности пользователя каждым из шагов по какой-либо оценочной шкале. Данный график дает возможность визуализировать все болевые точки, через которые необходимо пройти, чтобы достичь указанной цели.
Ниже представлены несколько примеров карт.
Рисунок 1. CJM от Temkin Group:
Рисунок 2. Пример CJM в онлайн-сервисе uxpressia.com:
Карту можно и нужно использовать в случаях:
- Когда требуется понять опыт различных групп пользователей.
- Когда необходимо найти и устранить причины неудовлетворенности пользователей при работе с системой.
- Для изыскания возможностей по улучшению эффективности работы системы.
- При расстановке приоритетов разработки или улучшения системы.
- Когда требуется предоставить пользователю наглядный результат того, что было, и как улучшился процесс. В данном случае потребуется наложение двух карт — «было» и «стало».
Таким образом, CJM имеет следующие преимущества:
- Позволяет выявить наиболее болезненные для пользователя моменты в пользовании системой.
- Предоставляет единый вид пользовательского опыта при соприкосновении с системой
- При вовлечении конечных пользователей и / или заказчика, снижает вероятность проектирования неверных решений.
Один из наших крупных проектов по автоматизации бизнес-процессов как раз подходит к этапу внедрения. И мы планируем воспользоваться методом CJM, а именно построением графика пользовательского удовлетворения. Тем самым мы хотим наглядно сравнить те проблемы, с которыми пользователи сталкивались не имея системы, и как мы эти проблемы решили.
По нашему мнению, на начальном этапе проекта метод CJM может быть эффективно использован в совокупности с реверсивным анализом требований разработанных HTML-прототипов.
Реверсивный анализ HTML-прототипов
Доклад Николая Киреева нам также показался заслуживающим внимания. В нем была поднята тема разработки динамических HTML-прототипов для реверсивного анализа требований, используемого вместо создания функциональных спецификаций или кодирования.
По мнению автора доклада, выявление и детализация функциональных требований на старте проекта сопряжены со значительными рисками: пропуском требований, добавлением в решение излишней функциональности, несоответствием требований через некий промежуток времени в связи с изменением процессов. По этой причине, окончательный вердикт о полноте решения выносится фактически на этапе внедрения системы. В таком случае, цена ошибки может оказаться колоссальной. Для решения данной проблемы Николай предлагает альтернативный вариант проектирования системы: с помощью инструмента Axure создать динамический прототип, имитирующего функциональность системы.
Разработка прототипа начинается с определения пользовательских ролей и бизнес-требований, которые пользователи будут выполнять в системе. Затем производится проектирование системы путем разработки прототипа согласно приоритетам, расставленным на этапе определения бизнес-требований. Тестируя разработанный прототип, проектировщик вначале сам, а затем со всеми заинтересованными лицами, отрабатывает основной и альтернативные потоки в системе. Таким образом на самом раннем этапе выявляются неэффективные решения, когда цена ошибки меньше. Только после создания прототипа составляется минимально необходимая функциональная спецификация. Такой подход предоставляет возможность при необходимости вернуться обратно к бизнес-требованиям, уточнить их и выявить новые. А это, в свою очередь, позволяет выявить несовершенство существующих бизнес-процессов при их автоматизации.
Динамические прототипы наиболее целесообразны при выявлении требований в следующих случаях:
- При создании приложений с высоконагруженными графическими интерфейсами.
- При проектировании систем, где цена пользовательской ошибки очень высока и необходимо исключить риски возникновения таких ошибок.
- При проектировании систем, не имеющих близких аналогов.
- При неясных, нестабильных и часто изменяющихся требованиях.
Использование динамического прототипа может значительно снизить стоимость таких проектов, избавив от переработки системы на поздних этапах, когда заказчик наконец получает систему в пользование и его ожидания не совпадают с реальностью.
Рассмотренный метод проектирования систем имеет свои недостатки:
- По сравнению с созданием статических макетов, разработка прототипа занимает значительное время.
- Достаточно сложно «продать» заказчику прототип, который, по его мнению, в будущем практически не принесет никакой пользы.
Однако, на наш взгляд, указанные недостатки перекрываются ощутимыми преимуществами:
- Прототип дает пользователям или заказчику возможность «пощупать» систему на очень раннем этапе, что способствует получению ценных отзывов. Кроме того, процесс взаимодействия с прототипом вовлекает пользователя в проект и повышает его лояльность.
- Относительная легкость внесения изменений после отзывов заказчика или пользователей.
- Раннее проектирование UX позволяет уменьшить количество пользовательских ошибок.
При поддержании в актуальном состоянии в ходе реализации проекта, прототип может быть использован при обучении первых пользователей.
Наш опыт это подтверждает, ранее мы использовали реверсивный анализ на основании HTML-прототипов в одном из проектов по автоматизации внутри компании. Основная проблема проекта заключалась в наличии большого количества заинтересованных лиц и противоречивости их требований, которые, к тому же, довольно часто менялись. Особое место в данном процессе занимало согласование требований с конечными пользователями системы. Поскольку процесс утверждения функциональных спецификаций оказался недостаточно эффективным — заинтересованные лица не имели возможности вчитываться в большие объемы документации — мы решили создать динамический прототип в Axure и продолжить выявление и утверждение требований с его помощью. Благодаря возможности заинтересованных лиц «пощупать» продукт на раннем этапе, нам удалось выявить множество скрытых требований и согласовать детали решения между всеми участниками проекта. Однако, это уже тема отдельной статьи.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий