Документ обсуждает важность анализа потребностей пользователей при разработке продуктов, акцентируя внимание на понимании их функциональных нужд. Он представляет методы, такие как пользовательские истории и сценарии, для выявления ключевых требований и приоритетов, а также модель Канос для оценки характеристик продукции. В заключение подчеркивается необходимость выявления уникального функционала для конкурентных преимуществ и качества продукта.

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

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

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

4. 4
!
Анализ пользовательских потребностей поможет:
определить в каком функционале действительно нуждаются
пользователи;
решить на разработку какой функциональности тратить время в
первую очередь;
выявить конкурентные преимущества.
Потребности пользователей

5. 5
!
Потребности пользователей
Инженер считает, что
важнее всего:
мощность всасывания;
уровень шума;
ионизатор воздуха.
Пользователь ищет
способ легко убрать
дома шерсть своих
питомцев.

6. 6
!
Потребности пользователей
Ищу ноутбук, чтобы
работать с документами,
общаться в скайпе и
фильмы смотреть.
Процессор — Core i3
Частота процессора — 1500 МГц
Оперативная память — 4 Гб
Объем накопителя — 128 Гб
Размер экрана — 11.6 "
Видеопроцессор — Intel GMA HD

7. Внимание на пользователя
7
!

8. Пользовательские
истории
vs
пользовательские
сценарии
8

9. 9
!
Пользовательские истории
Пользовательская история — краткое описание возможностей,
реализация которых необходима для получения пользователем
пользы от системы. Помогает понимать, что должна делать система.
Для описания пользовательской истории подходит шаблон:
Мне как <роль> необходимо <решить задачу>, чтобы <достичь цель>.

10. 10
!
Пользовательские истории
Как администратор я хочу иметь возможность создания
замещающих объектов, расширяющих свойства родителя.
Например:

11. 11
!
Пользовательские истории
Задача 3
Задача 2
Задача 1
Пользовательские
истории

12. 12
!
Пользовательские сценарии
Пользовательские сценарии — запросы, с которыми пользователи
приходят в систему. Запросы касаются системы и взаимодействия с
ней. Пользовательские сценарии могут группироваться по ролям,
ситуациям и задачам.

13. 13
!
Пользовательские сценарии
Из-за изменившегося законодательства я должен хранить
в системе дополнительный реквизит о заказчиках (старых и
новых). Мне надо обновить карточку заказчика в CRM так, чтобы
изменения распространились на всю систему.
.
Например:

14. 14
!
Пользовательские сценарии
1. Я хочу отредактировать поля в выбранном объекте и добавить новые.
2. Я хочу поделиться созданным объектом с коллегами из другого филиала таким образом, чтобы
они могли просто сохранить его в свою систему и начать сразу использовать.
3. Мне надо загрузить в систему присланный объект. Я хочу убедиться, что он не поломает связи
между объектами.
4. Я вношу изменения в систему и хочу удалить объект, который больше не будет использоваться.
5. Мне надо проверить, что я везде заменил старый объект на новый.
У основного сценария появляются дополнительные.

15. 15
!
Пользовательские сценарии
Из-за изменившегося законодательства я должен идентифицировать всех новых клиентов в CRM
при помощи их паспортных данных. Мне надо добавить в карточку клиента поля для хранения:
• номера паспорта;
• даты и места его выдачи;
• скана титульной страницы;
• типа документа (загран, внутренний или иностранный).
Эти поля надо сделать обязательным для заполнения у всех новых клиентов, обратившихся к нам
после 1 июня 2015 года.
Добавив данные, получаем задание для тестирования системы.

16. !
Истории и сценарии
Задача 3
Задача 2
Задача 1
Пользовательские
истории
Пользовательские
сценарии
Кейс 1 Кейс 2 Кейс 3
16

17. Сценарии,
потребности и
этапы реализации
17

18. 18
!
Ранжирование сценариев
Ранжирование сценариев помогает оценить значимость пользовательских потребностей.
Необходимо указать приоритет каждого сценария для каждого портрета пользователя. Для этого на
пересечении сценарий/пользователь выставляется цифра от 1 до 3 (1 – низкий приоритет,
2 – средний приоритет, 3 – высокий приоритет).
Количество оценок низкого приоритета (1) для каждого пользователя должно быть > 20%.
Количество оценок среднего приоритета (2) для каждого пользователя должно быть < 20%.
Количество оценок высокого приоритета (3) для каждого пользователя должно быть < 20%.
При суммировании баллов отбираются самые важные и отсеиваются неважные потребности.

19. 19
!
Метод «модель Кано»
«Модель Кано» — используется для оценки реакции пользователей на отдельные характеристики
продукции. Полученные с его помощью результаты позволяют выявлять функционал, который
должен войти в первые итерации разработки, и управлять удовлетворенностью пользователей.

20. 20
!
Метод «модель Кано»
Функционал системы оценивается по трем свойствам.
1. Восхищающие (привлекательные) свойства, если они присутствуют в продукте, вызывают чувства
удовлетворения и восторга (балл = 5). Однако, если этих характеристик нет, пользователи не
испытывают неудовлетворения (балл = 0).
2. Желательные свойства вызывают удовлетворение, если они есть (балл = 1), или
неудовлетворение, если их нет (балл = −1).
3. Базовые свойства относятся к группе тех качеств, которые обязательно должны присутствовать
в продукте (балл = 0). Отсутствие функций вызывает неприязнь (балл = −5).

21. 21
!
Метод «модель Кано»

22. 22
!
Метод «модель Кано»

23. 23
!
Метод «модель Кано»
На основе полученных данных строится график,
показывающий, какой функционал вызовет
wow-эффект и отсутствие какого функционала
скажется негативно на реакции пользователей.

24. !
Задача 3
Задача 2
Задача 1
Пользовательские
истории
Пользовательские
сценарии
Кейс 1 Кейс 2 Кейс 3
24
Кейс 1 Кейс 2 Кейс 3
Пойдет в первую
итерацию разработки
Истории и сценарии

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

26. 26
!
Работая с пользовательскими сценариями, можно:
выявить важные для пользователей потребности и реализовать их;
найти функционал, которого нет ни у кого из конкурентов;
оценить качество продукта.
Итог

27. Потренируемся?

28. #
28
Пользовательская история:
Я как администратор хочу вести версионность объектов: сохранять
версии, загружать старые версии.
Пользовательский сценарий:
Мне заказали обновить старую систему. Мне нужно проверять кто и
что в команде программистов сделал.
Пример № 1

29. #
29
Дополнительные сценарии
1. Я хочу отменить изменения объекта, сделанные другим пользователем, т.к. он все поломал.
2. Я настраиваю системе новые объекты и не хочу, чтобы кто-нибудь помешал моей работе с ними.
3. Я хочу, чтобы система автоматически защищала объекты от изменения другими пользователями,
пока я работаю с ними.
4. Я разработал сложный объект и не хочу, чтобы кто-нибудь нечаянно его изменил и все сломал.
5. Мне надо написать правила для автоматического формирования нумерации документации,
принятой в компании.
6. Я хочу прокомментировать сложный объект для будущих поколений, т.к. он важен для нашей
системы и его очень легко сломать.
7. Я нечаянно создал объект и хочу удалить его.
8. Я случайно что-то удалил (даже не помню что) и хочу это вернуть, чтобы ничего не сломалось.
Пример № 1

30. #
30
Пользовательская история:
Я как администратор хочу посмотреть, кто и когда создал/изменил
объект.
Пользовательский сценарий:
Компания развивает новое направление, и мне надо определить,
что потребуется изменить в системе и ее компонентах.
Пример № 2

31. #
31
Дополнительные сценарии
1. Я хочу знать, к кому из коллег обратиться с вопросами по поводу объекта, давно ли «трогали» этот
объект, кто и что именно в нем изменял последним.
2. Я хочу найти все созданные мной объекты.
3. Я хочу найти объекты, созданные коллегой.
4. Я ищу объект по названию, он относится к CRM, и мне не нужны объекты, не относящиеся к
другим системам.
5. Я хочу найти объект определенного типа (справочник, сервисный класс и т.п.).
6. Я изменяю объект и хочу найти все его дочерние / связанные с ним объекты.
7. Я ищу объекты с определенными полями.
Пример № 2

32. #
32
Пользовательская история:
Я как администратор хочу использовать дебаггер для объектов
разных типов.
Пользовательский сценарий:
Хочу сделать рассылку по участникам моей группы в социальной
сети, которые еще ничего у нас не заказывали. Надо, чтобы в
систему загружались все контакты из аккаунта в социальной сети.
Пример № 3

33. #
Пример № 3 33
Дополнительные сценарии
1. Мне надо создать объект со сложными правилами использования. Я думаю, что мне будет проще
написать код.
2. Я нашел код где-то в Интернете и хочу изменить объект с помощью этого кода.
3. Я не уверен в качестве написанного / скопированного кода и хочу проверить, не поломает ли он
систему.

34. sobaka@pavlova.cc
PavlovaPage
Спасибо!
samarina@pavlova.cc
samarina.olga