2015 secon. Как сделать сервис не для программистов
TRANSCRIPT
Как сделать сервис не для программистов, или О роли слов в проекте
Ольга Самарина
2
samarina.olga
Аналитик в КБ «Собака Павлова». Искренне уверена, если думать о пользователях, то получится сделать хороший продукт.
Ольга Самарина
Потребности пользователей
3
4
!
Анализ пользовательских потребностей поможет:
определить в каком функционале действительно нуждаются
пользователи;
решить на разработку какой функциональности тратить время в
первую очередь;
выявить конкурентные преимущества.
Потребности пользователей
5
! Потребности пользователей
Инженер считает, что
важнее всего:
мощность всасывания;
уровень шума;
ионизатор воздуха.
Пользователь ищет
способ легко убрать
дома шерсть своих
питомцев.
6
! Потребности пользователей
Ищу ноутбук, чтобы
работать с документами,
общаться в скайпе и
фильмы смотреть.
Процессор — Core i3
Частота процессора — 1500 МГц
Оперативная память — 4 Гб
Объем накопителя — 128 Гб
Размер экрана — 11.6 "
Видеопроцессор — Intel GMA HD
Внимание на пользователя
7
!
Пользовательские истории vs пользовательские сценарии
8
9
! Пользовательские истории
Пользовательская история — краткое описание возможностей,
реализация которых необходима для получения пользователем
пользы от системы. Помогает понимать, что должна делать система. Для описания пользовательской истории подходит шаблон:Мне как <роль> необходимо <решить задачу>, чтобы <достичь цель>.
10
! Пользовательские истории
Как администратор я хочу иметь возможность создания
замещающих объектов, расширяющих свойства родителя.
Например:
11
! Пользовательские истории
Задача 3
Задача 2
Задача 1
Пользовательские истории
12
! Пользовательские сценарии
Пользовательские сценарии — запросы, с которыми пользователи
приходят в систему. Запросы касаются системы и взаимодействия с
ней. Пользовательские сценарии могут группироваться по ролям,
ситуациям и задачам.
13
! Пользовательские сценарии
Из-за изменившегося законодательства я должен хранить
в системе дополнительный реквизит о заказчиках (старых и
новых). Мне надо обновить карточку заказчика в CRM так, чтобы
изменения распространились на всю систему. .
Например:
14
! Пользовательские сценарии
1. Я хочу отредактировать поля в выбранном объекте и добавить новые.
2. Я хочу поделиться созданным объектом с коллегами из другого филиала таким образом, чтобы
они могли просто сохранить его в свою систему и начать сразу использовать.
3. Мне надо загрузить в систему присланный объект. Я хочу убедиться, что он не поломает связи
между объектами.
4. Я вношу изменения в систему и хочу удалить объект, который больше не будет использоваться.
5. Мне надо проверить, что я везде заменил старый объект на новый.
У основного сценария появляются дополнительные.
15
! Пользовательские сценарии
Из-за изменившегося законодательства я должен идентифицировать всех новых клиентов в CRM при помощи их паспортных данных. Мне надо добавить в карточку клиента поля для хранения:
• номера паспорта; • даты и места его выдачи; • скана титульной страницы; • типа документа (загран, внутренний или иностранный).
Эти поля надо сделать обязательным для заполнения у всех новых клиентов, обратившихся к нам после 1 июня 2015 года.
Добавив данные, получаем задание для тестирования системы.
! Истории и сценарии
Задача 3
Задача 2
Задача 1
Пользовательские истории
Пользовательские сценарии
Кейс 1 Кейс 2 Кейс 3
16
Сценарии, потребности и этапы реализации
17
18
! Ранжирование сценариев
Ранжирование сценариев помогает оценить значимость пользовательских потребностей.
Необходимо указать приоритет каждого сценария для каждого портрета пользователя. Для этого на
пересечении сценарий/пользователь выставляется цифра от 1 до 3 (1 – низкий приоритет,
2 – средний приоритет, 3 – высокий приоритет).
Количество оценок низкого приоритета (1) для каждого пользователя должно быть > 20%.
Количество оценок среднего приоритета (2) для каждого пользователя должно быть < 20%.
Количество оценок высокого приоритета (3) для каждого пользователя должно быть < 20%. При суммировании баллов отбираются самые важные и отсеиваются неважные потребности.
19
! Метод «модель Кано»
«Модель Кано» — используется для оценки реакции пользователей на отдельные характеристики
продукции. Полученные с его помощью результаты позволяют выявлять функционал, который
должен войти в первые итерации разработки, и управлять удовлетворенностью пользователей.
20
! Метод «модель Кано»
Функционал системы оценивается по трем свойствам.
1. Восхищающие (привлекательные) свойства, если они присутствуют в продукте, вызывают чувства
удовлетворения и восторга (балл = 5). Однако, если этих характеристик нет, пользователи не
испытывают неудовлетворения (балл = 0).
2. Желательные свойства вызывают удовлетворение, если они есть (балл = 1), или
неудовлетворение, если их нет (балл = −1).
3. Базовые свойства относятся к группе тех качеств, которые обязательно должны присутствовать
в продукте (балл = 0). Отсутствие функций вызывает неприязнь (балл = −5).
21
! Метод «модель Кано»
22
! Метод «модель Кано»
23
! Метод «модель Кано»
На основе полученных данных строится график,
показывающий, какой функционал вызовет
wow-эффект и отсутствие какого функционала
скажется негативно на реакции пользователей.
!
Задача 3
Задача 2
Задача 1
Пользовательские истории
Пользовательские сценарии
Кейс 1 Кейс 2 Кейс 3
24
Кейс 1 Кейс 2 Кейс 3
Пойдет в первую итерацию разработки
Истории и сценарии
Подведем итог
26
!
Работая с пользовательскими сценариями, можно:
выявить важные для пользователей потребности и реализовать их;
найти функционал, которого нет ни у кого из конкурентов;
оценить качество продукта.
Итог
Потренируемся?
#
28
Пользовательская история: Я как администратор хочу вести версионность объектов: сохранять версии, загружать старые версии.
Пользовательский сценарий: Мне заказали обновить старую систему. Мне нужно проверять кто и что в команде программистов сделал.
Пример № 1
#
29
Дополнительные сценарии 1. Я хочу отменить изменения объекта, сделанные другим пользователем, т.к. он все поломал. 2. Я настраиваю системе новые объекты и не хочу, чтобы кто-нибудь помешал моей работе с ними. 3. Я хочу, чтобы система автоматически защищала объекты от изменения другими пользователями,
пока я работаю с ними. 4. Я разработал сложный объект и не хочу, чтобы кто-нибудь нечаянно его изменил и все сломал. 5. Мне надо написать правила для автоматического формирования нумерации документации,
принятой в компании. 6. Я хочу прокомментировать сложный объект для будущих поколений, т.к. он важен для нашей
системы и его очень легко сломать. 7. Я нечаянно создал объект и хочу удалить его. 8. Я случайно что-то удалил (даже не помню что) и хочу это вернуть, чтобы ничего не сломалось.
Пример № 1
#
30
Пользовательская история: Я как администратор хочу посмотреть, кто и когда создал/изменил объект.
Пользовательский сценарий: Компания развивает новое направление, и мне надо определить, что потребуется изменить в системе и ее компонентах.
Пример № 2
#
31
Дополнительные сценарии 1. Я хочу знать, к кому из коллег обратиться с вопросами по поводу объекта, давно ли «трогали» этот
объект, кто и что именно в нем изменял последним. 2. Я хочу найти все созданные мной объекты. 3. Я хочу найти объекты, созданные коллегой. 4. Я ищу объект по названию, он относится к CRM, и мне не нужны объекты, не относящиеся к
другим системам. 5. Я хочу найти объект определенного типа (справочник, сервисный класс и т.п.). 6. Я изменяю объект и хочу найти все его дочерние / связанные с ним объекты. 7. Я ищу объекты с определенными полями.
Пример № 2
#
32
Пользовательская история: Я как администратор хочу использовать дебаггер для объектов разных типов.
Пользовательский сценарий: Хочу сделать рассылку по участникам моей группы в социальной сети, которые еще ничего у нас не заказывали. Надо, чтобы в систему загружались все контакты из аккаунта в социальной сети.
Пример № 3
#
Пример № 3 33
Дополнительные сценарии 1. Мне надо создать объект со сложными правилами использования. Я думаю, что мне будет проще написать код.
2. Я нашел код где-то в Интернете и хочу изменить объект с помощью этого кода. 3. Я не уверен в качестве написанного / скопированного кода и хочу проверить, не поломает ли он систему.
