User Story — универсальный артефакт, который у нас в Creonit красной линией проходит через все этапы разработки продукта. Рассказываем, что такое пользовательские истории и как с ними работать.
Что такое User Story
User Story (пользовательская история) — это краткое описание функции продукта, написанное от лица пользователя. Её цель — понять и зафиксировать сценарии, по которым клиенты будут использовать систему. Это помогает сфокусироваться на потребностях и целях пользователей, а не количестве фичей и инновациях.
Стандартная пользовательская история — короткая, длиной всего в одно предложение. В ней прописывают пользователя, его действие и желаемый результат.
Пример
Важно: User Stories нужно писать простым и понятным языком. Они не касаются технических деталей проекта.
Для чего нужны User Stories
Дисклеймер: в продуктовой разработке множество подходов, артефактов и методологий, которые видоизменяются в зависимости от типа и целей проекта. Возможно, вы или ваши коллеги работаете с user stories по-другому. Это нормально.
User Story — это инструмент, который помогает командам смотреть на продукт глазами пользователя и не терять его из виду из-за множества операционных процессов.
Пользовательские истории помогают:
синхронизировать команды разработки и заказчика: все, кто участвует в создании продукта, будут понимать контекст его использования;
выделить ключевую функциональность, приоритизировать функции в бэклоге и построить roadmap;
прописать сценарии для юзабилити-тестирований;
прописать тест-кейсы для QA-инженеров;
сформулировать критерии приёмки;
подготовить техническое задание;
описать элементы бэклога;
спроектировать интерфейс, отрисовать прототипы и многое другое.
Как мы используем User Stories в проектах
Подготовка: анализируем задачи бизнеса, пишем глоссарий, выделяем пользовательские роли.
В Creonit мы используем User Stories для проектирования будущего продукта. Перед их написанием нужно провести подготовительную работу.
Когда приходит новый проект, мы собираем данные о бизнесе, его структуре и целях, аудитории. Для этого используем разные методы: интервью с командой заказчика, анкеты и опросы, конкурентный анализ, бенчмаркинг — поиск лучших решений у конкурентов. На основе этой информации мы формулируем функциональные и бизнес-требования к будущему продукту.
Следующим этапом мы формируем глоссарий, чтобы все участники проекта говорили на одном языке и не возникало недопониманий. В глоссарии даём определения всем сущностям проекта.
При разработке User Stories важно учитывать интересы всех, кто будет пользоваться продуктом и на кого он повлияет: разные сегменты аудитории, сотрудников, контрагентов и так далее. Чтобы не описывать сценарии использования только для одного типа юзеров, мы выделяем роли пользователей. Например, мы делаем интернет-магазин, в нём будут покупать оптовики и розничные покупатели, а менеджеры компании будут собирать клиентскую базу. Нужно написать User Stories отдельно для каждой группы пользователей.
Пример: как оптовый покупатель, я хочу видеть оптовую цену на товары, чтобы совершать покупки на выгодных условиях.
Пишем User Stories
Когда собраны все функциональные и бизнес-требования, сформирован глоссарий, пользователи разделены на роли — наконец-то можно писать User Stories.
Формируется команда: аналитик, менеджер проекта, технический директор, разработчики. По возможности мы приглашаем представителей бизнеса со стороны заказчика, либо даём им дополнить уже готовые User Stories. Благодаря наличию разных специалистов, мы можем на старте проговорить, какие есть сложности в реализации фич и какое примерное время понадобится на их разработку. Наша цель — определить, какие функции являются наиболее сложными в разработке и какие — более простыми.
Пишем критерии приёмки
User Story недостаточно, чтобы разработчик понял, что конкретно нужно сделать, а тестировщик мог проверить результат. User Story нужно дополнять критериями приёмки — подробными пунктами с требованиями к создаваемой функциональности. Пользовательская история описывает основную цель новой фичи — как она поможет пользователям. Критерии приемки перечисляют способы работы функциональности с технической точки зрения.
Можно использовать два типа критериев приёмки:
1. Основанные на сценариях. Описание на основе конкретного поведения или последовательности действий пользователя.
Например: При добавлении нового сотрудника Администратор должен заполнить форму — все поля обязательные для заполнения. ЕСЛИ Администратор не заполнил хотя бы одно поле, ТОГДА пользователь не создаётся, внесённые данные должны сохраняться до закрытия формы/закрытия раздела системы.
2. Критерии, как функция должна выглядеть и работать.
Например: 1. Все кнопки должны быть синего цвета. 2. Кнопка «Вход» должна перенаправлять пользователя в Личный кабинет.
Критерии приёмки позволяют любому участнику продакшн-команды проверить, что фича реализована точно так, как мы и задумывали. Так мы формируем единый документ для разработчиком, менеджеров, дизайнеров и QA-инженеров.
С помощью этого документа заказчику проще изучать полученный продукт — не придётся скроллить все экраны приложения вручную или вчитываться в техническое задание. Можно удостовериться, что пользователь сможет выполнить целевое действие в сервисе на основе прописанных User Stories и критериев приёмки.
Приоритезируем фичи
Результат командной работы — несколько десятков пользовательских сценариев. Их количество может варьироваться в зависимости от объёма проекта, может доходить и до сотни.
Их нужно сгруппировать по:
важности для бизнеса;
сложности реализации функций;
важности для удобства пользователей.
Мы разбиваем группы пользовательских сценариев на этапы дальнейшей работы. Решаем, в какой последовательности будем реализовывать функции, что отложим в бэклог.
На основе групп User Stories мы составляем roadmap — карту, которая позволит спланировать разработку и выделить необходимые функции для MVP. С помощью дорожной карты проекта менеджеры планируют, какая команда и какой объём работ будет делать на соответствующем спринте по неделям.
Делаем прототипы
Когда у нас на руках есть сгруппированные User Stories, мы отрисовываем кликабельный прототип и передаём заказчику в виде проекта в Figma. Изучить несколько десятков текстовых сценариев — сложно, особенно, когда в согласование вовлечено несколько стейкхолдеров. Прототипы позволяют в короткие сроки визуализировать User Stories.
Прототипы — это только верхнеуровневая визуализация, в них нет ярких картинок и анимаций. Цель прототипа — показать, что пользователь может достигнуть целевого действия, корректно расставить смысловые блоки и акценты внутри одного экрана. Далее на основе прототипов дизайн-команда разрабатывает полноценный дизайн.
Пишем техническое задание
В финале все требования вместе с User Stories собираются в техническое задание. Здесь мы документируем каждый элемент из прототипа: откуда он появляется и что происходит по его нажатию, какие в продукте есть формы и как они должны работать.
Также прописываем такие вещи, как:
принцип работы с оптимизацией;
протокол интеграций;
структуру баз данных;
описание IT-инфраструктуры;
UML-диаграммы;
вставляем скрины прототипов по необходимости;
другое.
ТЗ нужно, чтобы задокументировать логику разработки. Здесь мы собираем всё необходимое, чтобы убедиться, что у нас хватает данных для перехода к ней. Если архитектура проекта сложная, нужно сразу продумать, как это будет выглядеть с точки зрения IT-инфраструктуры. Так в момент разработки у команды будет возникать минимум вопросов.
Также техническое задание помогает защититься от появившихся новых требований в процессе разработки. Для новой функциональности, которую захотелось разработать в середине проекта, нужно написать отдельное техническое задание и дополнительное соглашение.
Ещё одна важная часть ТЗ — тест-кейсы, по которым мы будем проверять, корректно ли реализована функциональность.
Тест-кейсы — это алгоритм действий, по которому QA-инженеры тестируют софт или продукт. В нём подробно прописаны шаги для проверки и ожидаемый результат.
Ведём разработку
User Stories у нас проходят через всё флоу разработки: от формирования задачи до её выполнения в таск-трекере.
Мы берём первый этап разработки, он включает, например, 30 User Stories. Каждую пользовательскую историю декомпозируем на технические задачи. Задачи добавляем на kanban-доску разработчикам. У задач видно, к какой User Story они принадлежат.
Например, у фронтендера стоит задача перекрасить кнопку из красного цвета в голубой. Разработчик думает, что его грузят какой-то ерундой. Но задача прикреплена к пользовательской истории, поэтому он может прочитать и понять, зачем это. Например, пользователей раздражает красный цвет и они уходят с сайта (все примеры выдуманы).
Почему мы используем User Stories
1. Безотходное производство: все артефакты из разных этапов проектирования живут на протяжении всего проекта. User Stories с критериями приёмки целиком попадают в техническое задание, по ним же мы потом ведём разработку. Разработка технического задания занимает в разы меньше времени, если писать всё с нуля.
2. Формулировки User Stories— короткие и доступные. Их понимают все: стейкхолдеры, разработчики, дизайнеры, менеджеры, смежные продакшн-команды. Заказчик сам может подключаться и активно участвовать в создании User Stories. Всем участникам проще ориентироваться на достижение пользователем цели. Такой подход хорош для развития продукта и синхронизации всех команд.
3. В команде, которая пишет User Stories, есть и технические специалисты, поэтому мы можем на старте выяснить, какие сложности есть в реализации функциональности.
Выводы
Самая важная задача проектирования — сформировать у заказчика понимание, что мы предлагаем. Чтобы стейкхолдеры понимали все артефакты, которые мы им показываем, и могли принимать активное участие в их проработке. Если мы даём человеку User Stories, ему сразу станет понятна логика взаимодействия с его продуктом. Заказчик может предложить свои User Stories или дополнить критерии приёмки. Если дать ему техническое задание на 300 листов, как часто происходит на нашем рынке, — он не поймёт и половины.
User Story — многофункциональный инструмент, который у нас в Creonit красной линией проходит через все этапы проектирования продукта.
С его помощью команда разработки и стейкхолдеры со стороны заказчика могут говорить на одном языке и заботиться о нуждах пользователей, а не просто релизить фичи.
Примеры, как мы работали с User Stories на проектах, можно почитать в кейсах:
Сеть кофе-баров
Мобильное приложение для крупнейшей сети кофе-баров в России
Сеть кофе-баров
Faberlic
Спроектировали сервис для управления ценообразованием
Свяжусь с вами в течение дня, чтобы уточнить детали проекта и сориентировать по стоимости разработки. После этого обсудим цели проекта, требования к нему и начнём работу.
Свяжусь с вами в течение дня, чтобы уточнить детали проекта и сориентировать по стоимости разработки. После этого обсудим цели проекта, требования к нему и начнём работу.
