2015 Secon. Как сделать сервис не для программистов

Как сделать сервис не для программистов, или О роли слов в проекте

Ольга Самарина

2

samarina.olga

[email protected]

Аналитик в КБ «Собака Павлова». Искренне уверена, если думать о пользователях, то получится сделать хороший продукт.

Ольга Самарина

Потребности пользователей

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


Пользовательские сценарии


24


Пойдет в первую итерацию разработки

Истории и сценарии

Подведем итог

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. Я не уверен в качестве написанного / скопированного кода и хочу проверить, не поломает ли он систему.

[email protected]

PavlovaPage

Спасибо!

[email protected]

samarina.olga

2015 Secon. Как сделать сервис не для программистов

Internet