что такое user story и use case
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
CJM словарь
Часто в команде мы применяем специальные термины для того, чтобы обозначить разные инструменты, которые помогают разобрать по полочкам, или наоборот обобщить пользовательский опыт. Один из самых популярных инструментов — это CJM или карта пути пользователя. У этой аббревиатуры много соседей, самым близким из которых мы решили дать определения. Надеемся, наш небольшой словарик будет полезен и другим проектировщикам.
User Experience
Пользовательский опыт создается не только в цифровой среде. Это весь комплекс тактильных ощущений, эмоций и впечатлений, который получает человек от общения с продуктом или сервисом в самых разных сервисных каналах и жизненных ситуациях.
Persona
Персона — это созданный на основе реальных людей персонаж, который обладает своими поведенческими особенностями. Другими словами, персона — это описание одной из групп пользователей с их отличительными потребностями, задачами, жизненными сценариями и ситуациями.
Персона собирается на основе проведенных качественных и, возможно, количественных исследований. Обязательный компонент таких исследований — прямой контакт исследователя с пользователями изучаемого им продукта или сервиса, или просто с людьми, которые сталкиваются с изучаемой исследователем жизненной ситуацией. Поэтому персоны ни в коем случае не придумываются, а лишь являются обобщением находок человеко-ориентированных исследований. Таким образом, это не сухое описание каких-то фактов, а напротив, живое, вовлекающее читателя описание архетипа, которое часто сопровождается цитатами из исследований, фотографиями, и богатой нарративной частью.
Персоны нужны для того, чтобы упаковать находки исследований в более ёмкую форму, которая при этом не потеряет своей актуальности. Ознакомление с персонами должно эффективно погрузить участника рабочего процесса в особенности жизни изучаемых людей и помочь проявить эмпатию.
User story
Пользовательская история — простое и короткое описание жизненной или профессиональной ситуации, в которой человеку нужно воспользоваться той или иной функцией вашего решения. Часто истории могут быть взяты из интервью с пользователями (цитаты из историй), или же написаны ими самими.
Вот такая, например, пользовательская история: “После завершения приема у моего врача деньги по умолчанию списываются с моей карты и мне не нужно возвращаться в регистратуру или кассу, чтобы оплатить посещение. Это очень удобно!”
Часто для того, чтобы не упустить здравый смысл и ценные находки проектировщиков. Тогда сервисные истории звучат скорее как “сухие” блоки описания последовательности действий.
Когда наша команда Wonderfull делала прототип мобильного приложения для туристов в Москве, которые пребывают на чемпионат мира, описание пользовательской истории в Техническом задании для разработчиков было, например, таким:
Use Case
Случай использования того или иного решения / функции. Он имеет свою длительность и как правило связан с одним целевым действием. Например, юзкейсом или случаем использования банковского мобильного приложения может быть “удаленное пополнение счета мобильного телефона” или “блокирование потерянной банковской карточки”. Если продолжить нашу историю про прием в медицинской клинике, то юзкейсом сервисного сценария может быть “автоматическое списание денег с банковской карты пациента”.
CJM / Customer Journey Map
Карта пользовательского пути — описание истории, которая случилась с человеком в процессе взаимодействия с продуктом или сервисом. Карта CJM помогает не только зафиксировать последовательность шагов, но также отметить время, которое потратил пользователь на каждый шаг и создать эмоциональную кривую полученных впечатлений.
Service Blueprint
Сервисный сценарий. Он радикально отличается от CJM / карты пользовательского пути, так как создан не для фиксации текущего опыта пользователя, а для проектирования нового сервисного решения. Сервисный сценарий состоит из двух базовых частей — “надводной” и “подводной”, то есть видимого и невидимого для пользователя пространства сервисных процедур. На примере банковского офиса к видимой части сервисного сценария относится зона для посетителей, в которой у стоек обслуживания сотрудники банка общаются с посетителями. В невидимую часть попадают все процедуры банковского сервисного процесса, которые делают работники бэкофиса для того, чтобы обработать документы и совершить заказанные пользователем банковские процедуры.
Service Solution Blueprint
Сценарий сервисного решения. Если Service Blueprint / сервисный сценарий может быть создан для всего сценария обслуживания клиента от старта до завершения процесса обслуживания, то сценарий сервисного решения касается только лишь одного юзкейса или одной пользовательской истории. Например, service solution blueprint может быть составлен для “автоматического списания денег с банковской карты пациента” из нашей предыдущей истории про медицинскую клинику. В этом сценарии сервисного решения будут прописаны действия пациента, действия врача, ответная реакция и поведение цифровой системы, а также действия сотрудника сервисного центра в случае, если что-то пошло не так.
Проще говоря, сервисный сценарий — это про весь сервис (макроуровень сервисного проектирования), а сценарий сервисного решения только лишь про одно решение, а возможно даже, про один канал взаимодействия с пользователем (микроуровень сервисного проектирования).
Service сhannel
Канал обслуживания — это формат, в рамках которого происходит взаимодействие пользователя с сервисом, или, как говорят, “пользователю оказывают услугу”. Формат может быть как цифровым, так и нецифровым. Например, офис клиники или банка — это канал обслуживания. Канал обладает такой важной характеристикой, как пропускная способность в единицу времени (то есть, сколько клиентов мы можем обслужить в этом канале за определенное время). А вот мобильное приложение — это не только канал обслуживания, но и точка контакта пользователя с сервисом. В сервисном проектировании понятия “точка контакта” и “канал” часто используются как синонимы.
Service touchpoint
Точка контакта — это конкретное “место встречи” пользователя и сервиса. Единица или сервисный “атом” в канале обслуживания. “Встретиться” со своим пользователем сервис может в транспорте, дома, или на работе, в кафе, в самолете, или в процессе регистрации на авиарейс и во множестве других мест и ситуаций.
Точкой контакта с банковским сервисом может быть интернет-банк, мобильное приложение, банкомат, окно обслуживания в офисе, и даже сам сотрудник часто выступает в роли “живой точки контакта”.
Именно в точке контакта возникает сервисное взаимодействие и рождается пользовательский опыт. Как правило, точкам контакта пользователи как раз и присваивают удовлетворительные или неудовлетворительные характеристики.
Если в вашем сервисе для прохождения процедуры регистрации нужно открыть большой экран стационарного компьютера и потратить 30 минут сосредоточенного внимания, а ваш пользователь по умолчанию находится в постоянном режиме цейтнота, применяет только мобильные устройства и может потратить не больше 1 минуты на регистрацию, то ваша точка контакта, скорее всего, будет обладать очень неудовлетворительными пользовательскими характеристиками.
Сбор живых пользовательских историй о точках контакта поможет вам понять, какие точки контакта работают хорошо, какие из них совсем не нужны или невостребованны пользователем, а какие должны появиться в ответ на боли или возможности людей.
Разница между User Stories, Use Cases и Scenarios
Прежде, чем отвечать, нужно сделать паузу и признать, что в сегодняшней терминологии есть некоторая путаница — под Сториз, Сценариями или Юзкейсами могут понимать разные инструменты.
Авторы культовой Designing Interactive Systems — People, Activities, Contexts, Technologies выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории (сториз), концептуальные сценарии, конкретные сценарии и варианты использования (юзкейсы).
Важно заметить, что есть еще Эджайловские Юзер сториз товарища Паттона, что описываются по шаблону As a <>, I want <> so that <> и находятся где-то между Concrete Scenario и Use case.
Зависимость содержания деталей
Сториз, они про потребность пользователя. Raw user needs.
Юзкейсы же про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности. What the software needs to do.
Сториз пишутся человеческим языком = легко читаются и бизнесом и разработчиками. Express understanding of User needs.
Написание Юзкейсов это designing a functional solution.
Разберемся на примерах
User story
Стартуем с самого масштабного уровня, уделяем внимание контексту и всем поведенческим особенностям. Рассказ ведется не от лица абстрактного пользователя, и даже не от лица персонажа, а от лица реального человека (либо от лица того, кто ведет наблюдение/проводит интервью).
Выиграли билеты на концерт Radiohead в Риме, сборы проходили в последний момент, нанервничались и чуть не поругались 🙂 Решили, лететь налегке.
Когда поехали в аэропорт, то очень торопились и решили не заезжать на заправку, чтобы сэкономить время. В тот момент нам казалось, что бензина достаточно и хватит добраться до аэропорта, но в наши планы вмешались непредвиденные обстоятельства.
Вообщем встряли в пробку и, спустя некоторое время, загорелась лампочка низкого уровня топлива. Пришлось спешно искать заправки поблизости. Как назло, нашу машину можно заправлять только 98-ым бензином, что только добавило накала страстей.
По итогу, нам повезло — заправку нашли, в аэропорт успели, но пришлось сильно поволноваться. Благо Том Йорк сгладил впечатления о поездке, да и Рим крут.
Conceptual scenario
Снижаем планку контекста и движемся к конкретике за счет абстрагирования. Conceptual scenario важны для генерации идей и поиска ответа на вопрос «Как улучшить существующий опыт?».
Алан Купер рекомендует представить, что интерфейс волшебный и в нем можно реализовать всё, что угодно, чтобы выйти за рамки привычного.
Люди в стрессовых ситуациях нуждаются в дополнительном внимании и заботе. В процессе ввода в навигатор конечного адреса маршрута можно определять расстояние до финиша, проверять текущий уровень топлива с учетом актуального среднего расхода и определять, хватит ли нам топлива добраться до заданной точки. Если нет, оповещать об этом водителя.
Если же лампочка низкого уровня топлива уже загорелась, то показывать в навигаторе ближайшие заправки (с возможностью сортировки голосовыми командами, например по октановому числу).
Concrete scenario
Concrete scenarios пополняются деталями реализации и используются для проектирования, в них появляются технические подробности. Пишутся они от лица конкретного персонажа, дабы проявить эмпатию.
Когда Сергей вводит адрес в навигатор, то он хочет быть уверенным, что ему хватит топлива доехать до указанной точки. Если нет, то автомобиль предупредит об этом Сергея.
Если в момент движения, Сергей отклонится от маршрута и поедет другим путем (или будет ехать очень быстро), то с включением лампочки низкого уровня топлива, он увидит на карте навигатора ближайшие заправки и сможет выбрать подходящую по особенностям топлива.
Во время движения соединение с интернетом может прерываться.
Agile User story
Примерно на этом уровне находятся и Эджайловские Юзер стори.
Я, как водитель, в момент включения лампочки низкого уровня топлива, хочу заправить свою машину на ближайшей заправке.
Use case
Далее уже можно написать Юзкейсы, описывающие все взаимодействия системы с пользователем. Пишутся они от лица абстрактных пользовательских ролей.
Из всех видов сценариев Юзкейс — наиболее технический и напоминающий алгоритм, а не историю.
Я, как пользователь-водитель (с включенной лампочкой низкого уровня топлива) смогу:
У Юзкейсов есть свой стандартизированный шаблон:
Потом собираете вместе ваши Сценарии, Сториз и Юзкейсы в один документ, рисуете Флоу и получаете полное описание каждого взаимодействия между пользователем и продуктом, которое вы планируете создать.
Когда и что использовать?
Все виды сценариев придуманы в угоду определения требований: что система должна делать в принципе и как она должна вести себя для того, чтобы удовлетворить запросы пользователей.
Конечно это требует дополнительных усилий и времени, поэтому на простых информационных продуктах можно пожертвовать сценариями, а без вариантов использования можно обойтись там, где взаимодействие достаточно прямолинейно, отсутствуют альтернативные и исключительные сценарии (или их проще и быстрее продемонстрировать в прототипе).
Но чем сложнее взаимодействие, тем желательнее начинать с контекста и поведенческих особенностей, двигаясь к конкретике по решениям. Иначе, есть риск вложить 80% усилий в 20% сценариев, с которыми пользователи будут работать мало и редко, а внимание дизайнера будет размазано по всем возможным сценариям, что снизит их качество.
WEBURSITET.RU
Онлайн-курсы профессиональной разработки ПО
Сравнение методов разработки пользовательских требований
Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.
Мы с вами познакомились с несколькими методами разработки пользовательских требований. На самом деле, методов было два: это Use cases (юзкейсы) и User stories. И плюс дополнительный метод — наверное, не столько разработки, сколько выявления пользовательских требований: персонажи. он называется Personas, а на русский язык его обычно переводят как «персоны» или «персонажи».
У нас была сравнительная табличка, когда мы сравнивали ролевые модели методов Use cases и User stories. Я здесь добавил ещё одну табличку. Иногда возникает вопрос: какой метод лучше применим в нашем проекте, каким из них воспользоваться? Для того, чтобы эту оценку правильно сделать, нужно сравнить их достоинства и недостатки. Мы о них говорили достаточно много в процессе курса, начиная с самых первых вебинаров, и более детально, когда мы изучали эти методы. Здесь, на этой табличке, подведен итог.
Если сравнивать юзкейсы и user stories, то, первое и, наверное, самое существенное отличие состоит в том, что метод юзкейсов требует достаточно долгой фазы предварительного анализа для проработки целей, которые мы будем автоматизировать, и разработки сценариев. То есть он приближает нас в к водопаду. Конечно, их тоже можно разрабатывать итерационно, но, тем не менее, в каждой итерации нужна отдельная большая работа аналитиков для того, чтобы эти юзкейсы для очередной итерации подготовить. Поэтому в тех местах, где используются юзкейсы как метод, итерации довольно длинные. От одного месяца до максимум трёх месяцев (если итерация длится больше 3 месяцев, то уже само понятие итерации утрачивает свой смысл). Но это не недельные или двухнедельные спринты, как в Agile. Это связано с тем, что здесь требуется более глубокий и детальный анализ.
Отличие user stories в том, что, как правило, этот формат можно применять практически сразу. Не погружаясь в детализацию, потому что сам формат предполагает, что он будут использоваться для дальнейшего обсуждения. То есть мы сначала user story формулируем достаточно коротко, обсуждаем с заказчиком, и затем в команде обсуждаем детальную реализацию. И поэтому он такой, более лёгкий, более быстро его можно использовать в коротких итерациях, чем, собственно, практически все и пользуются.
Различия в модели требований, о которой мы тоже говорили с самого начала. Юзкейсы предполагают, что мы создаём практически полное описание нашего продукта в терминах юзкейсов, за исключением, может быть, его нефункциональных аспектов, которые не описываются сценариями. А user stories — это постоянно меняющаяся модель продукта. То есть мы каждый раз сосредотачиваемся именно на том, что нужно сделать в данный момент.
По поводу хороших требований. Мы, опять же, в начале курса говорили, что для user stories разработан фактически свой способ оценки качества историй: INVEST. А для юзкейсов применяется другой метод, больше похожий на те, что изначально было сформулированы для требований при их разработке в виде спецификации. Главное отличие — это полнота требований. Не буду повторяться, я просто подвожу итог: критерии качества для юзкейсов и user stories различаются, и я надеюсь, что у вас уже сложилось представление о том, почему это так, и почему не нужно набор критериев качества одного метода применять к другому.
И очень важное различие, которое иногда неочевидно для аналитиков, состоит в том, что при разработке юзкейсов большую часть работы выполняют те, кто разрабатывают сценарии, и эти юзкейсы потом можно как полную модель продукта передавать в команду, чтобы они их программировали. В случае с user story формат сам по себе — это только повод для обсуждения, и самые важные решения о реализации, о том, как эти user stories правильно реализовать в продукте, принимает команда разработки. Это её неотъемлемое право, и ей нельзя навязать определенные методы.
Глядя на этот список, может быть, вы теперь более чётко представляете, в какой ситуации какой метод применим. По итогам курса это представление должно у вас уже окончательно сложиться: для каких ситуаций какие методы лучше подходят.
Что в этой книге предлагается? Как адаптировать метод юзкейсов для разработки в коротких итерациях, которыми, в первую очередь, и отличается Agile. Я несколько картинок просто приведу, потому что в двух словах объяснить это довольно просто. Ну, а если придётся применять это на практике, тогда, собственно, вот в этой книге и написано, как это лучше сделать. Сам Айвар Якобсон периодически проводит вебинары, на которых объясняет разные нюансы и суть этого метода.
Я много слышал от разных тренеров об этом методе, потому что он такой, концептуально красивый. Но, честно говоря, пока не видел людей, которые применяют его на практике. Но, может быть, вам повезёт его применять.
Вот ещё одна табличка. Эта табличка у нас в курсе уже была, но я добавил в неё третью колонку. Здесь подытожено различие ролевых моделей при использовании юзкейсов, user stories и метода персонажей.
В случае с user stories, которые появились, в первую очередь, в ответ на вызов со стороны интернета в связи с появлением массовых пользователей, роли выделяются по другим признакам. Мы анализируем некоторый набор целей пользователей по отношению к нашему продукту (это то, чем мы занимались при разработке концепции) и разбиваем их, например, по интересам, по ожиданиям от продукта, по частое использования и по уровню подготовки, и у нас появляются такие кластеры пользователей, которые мы можем использовать как роли в user stories.
Это такой подход, который вполне могут использовать аналитики или, в случае Agile, вся команда, выявляя свои представления о том, кто будет пользователем продукта, и фиксируя эти представления в виде такого набора ролей. При этом одна роль представляет группу пользователей. Роль в user story — это не участник процесса, а модель типичного пользователя нашей системы, при том что эти типичные пользователи разбиты на группы.
По поводу персон можно сказать, что это дальнейшее развитие метода user stories. Главная особенность или отличие в том, что персонажи появляются по результатам достаточно серьёзных исследований. Это, конечно, оправданно только в случае, если чёткое выделение этих персон даёт вам понятную выгоду при создании вашего продукта. Алан Купер постоянно говорит: если вы придумали персон без исследования, то это, скорее всего, будут стереотипы пользователей, что больше похоже на предыдущий вариант ролей в user stories.
Одна персона представляет собой не группу пользователей, а так называемый архетип, то есть характерного представителя, и фактически моделирует при этом конкретную личность. Для этого и дают персонам имена и фотографии: для того, чтобы команда не просто использовала абстрактного мёртвого человечка, как часто называют картинки на диаграмме вариантов использования, а представляла себе конкретную личность, проникалась к ней эмпатией и сочувствием. И тогда появляется возможность оценивать с точки зрения этой личности те сценарии, которые мы для неё реализуем.