Статьи Sadko

Размышления о сценариях взаимодействия пользователя с продуктом

Блог про аналитику

Сегодня выступала для Product University.

Говорила об анализе и о UC, в итоге немного затронула при подготовке продуктовую разработку и продакт-менеджеров.

Делюсь своими определенными размышлениями на эти темы.

У всех проектов, вне зависимости от того, является ли разработка заказной или продуктовой, есть изначальный старт в виде потребности.

Все проекты, так или иначе, проходят стадии Стратегия – Реализация решения– Оценка решения.

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

На этапе реализации, помимо цикла разработки софта (Анализ-Проектирование-Разработка-Тестирование-Внедрение), есть цикл разработки требований Выявление- Анализ и моделирование – Верификация- Валидация- Документирование- Согласование.

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

Но когда дело касается этапа реализации, цикл разработки софта никуда не уходит, он такой же (Анализ-Проектирование-Разработка-Тестирование-Внедрение), как и цикл разработки требований Выявление- Анализ и моделирование – Верификация- Валидация- Документирование- Согласование.

Разработка требований – сугубо аналитическая работа. И если даже на вашем проекте нет выделенной роли бизнес-аналитика, аналитические работы никуда не денутся, просто части работ лягут на разных участников команды. Одним из таких участников, который может взять на себя аналитическую работу по разработке требований может быть и product manager. Хотя есть ! минусы, но сейчас не об этом.

Когда речь идет о том, какие функции будут в вашем продукте, и как выявлять эти функции, техники выявления: анализ документов, наблюдение, анализ интерфейсов (и пользовательских, и системных), опросы, фокус-группы, интервью, семинары и пр., которые работали в заказной разработке, в продуктовой приобретают другие черты. К примеру, к процессу интервью в продуктовой разработке подход более глубинный, а технику анализ документов можно будет применять в случае, если необходимо удостовериться, что функция соответствует каким-либо законодательным пунктам, технику анализ системных интерфейсов можно использовать в случае если нужно прикрутить оплату на сайте (ведь никто не будет изобретать велосипед заново, хоть речь и идет о продуктовой разработке).

Сегодня предлагаю обсудить сценарии взаимодействия пользователя с продуктом. Есть много форматов описания сценариев.

Когда речь идет о продуктовой разработке, при работе с требованиями, продактов обучают писать Job Stories, обучают синтаксису Gherkin, обучают многим очень интересным техникам (подробнее настойчиво рекомендую читать в Agile Extension to the BABOK ® Guide, V2), но при этом совсем забывают о добрых Use case, тем более сейчас (Use case 2.0).

Сегодня я хочу поднять тему обычных Use case. Как это смешно бы не звучало.

Давайте посмотрим на картинку из (Карл Вигерс и Джой Битти, Разработка требований к программному обеспечению, V3).

Use case (или варианты использования) способ описания задачи, которые пользователям нужно выполнять посредством системы, или взаимодействия пользователя и системы, которые дадут полезный результат для того или иного заинтересованного лица.

User story (или пользовательская история) тоже способ описания пользовательского требования.

Use case дополняется сценарием, а user story дополняется критериями приемки.

На мой взгляд никто не мешает совмещать эти две техники, и дополнять User story сценариями наподобие тех, что описываются в Use case.

Понятно первично то, что в продуктовой разработке User story лидирует, потому что есть свои плюсы: нет необходимости описывать заранее взаимодействие продукта и пользователя, можно оставить это на обсуждение команды, когда доберетесь до реализации.

И вот подходит момент реализации, команда берет сторю в анализ. Что если взаимодействие пользователя и продукта предполагает большое количество шагов и итераций? Что если взаимодействие предполагает много разветвлений? Да конечно UX\UI специалист может нарисовать вам мокапы с переходами. Но будет ли этого достаточно для команды разработчиков. А вы спросите самого UX\UI специалиста, будет ли ему удобно без описанных шагов взаимодействия?

Никто не говорит, что писать формализованные сценарии обязательно и необходимо. Хотя сложно уложить все в одном посте, стоит отметить момент, что пост документация после стабилизации требований необходима и точка.

Вместе с описанием сценария удобно предоставлять диаграмму деятельности UML, которая моделирует сам сценарий.