Что такое История пользователя

История пользователя

(англ. user story) — это краткое описание функции продукта, сформулированное с точки зрения конечного пользователя

Главная особенность историй в том, что они описывают ценность — не только техническое воплощение. Например, вместо «сделать кнопку сброса пароля» ➡️ «дать человеку возможность восстановить доступ». Это смещает фокус с того, как делать, на то зачем делать.

Пользовательские истории создаются на протяжении всего гибкого проекта. Обычно в начале проводится встреча по написанию пользовательских историй, в котором участвует вся команда. Цель — сформировать бэклог продукта, который полностью описывает функциональность, планируемую добавить в ходе проекта или в рамках трёх—шестимесячного цикла релизов.

Пример использования термина

Пример 1:

«На одном из спринтов нам поставили задачу — добавить поиск по архиву заказов. Изначально в техзадании было просто: «реализовать фильтр по номеру телефона». Но потом продакт-менеджер переформулировал это как историю пользователя: «Как менеджер по продажам, я хочу находить заказы по телефону клиента, чтобы не тратить 10 минут на ручной поиск, когда звонят с вопросами о прошлых заказах». Всё встало на свои места. Мы поняли, что важно не добавить ещё одно поле в интерфейс, а сэкономить время менеджеров в стрессовых ситуациях. Кстати, после внедрения менеджеры тратят на такие запросы на треть меньше времени».

Пример 2:

«Когда тестировщик проверял новую функцию, он ориентировался не на техническое задание, а на историю пользователя. Вместо сухого «проверить валидацию поля» он представлял себя клиентом: «Вот я ввожу email с опечаткой, и система должна подсказать, что нужно исправить, а не просто выдать ошибку». Такой подход помог найти три недочёта, которые в ТЗ не упоминались».

Что ещё нужно знать про Историю пользователя

Какое значение имеет в управлении проектами

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

Разбивает сложное на простые шаги. Любую большую задачу проще решать по частям. Истории как раз описывают эти части, то есть отдельные функции. Условно, при разработке платформы для онлайн-обучения не нужно сразу создавать полный курс с видео, тестами, чатом и сертификатами. Сначала можно реализовать самое необходимое — ученик входит в личный кабинет. Затем создать простой модуль с уроками, где можно выложить текст и картинки. Потом добавить тесты с выбором ответа, чтобы проверить знания. И только после этого — интерактивные элементы: чат с преподавателем, видео-лекции или систему выдачи сертификатов.

Помогает расставлять приоритеты. Если чётко определить, что ищет клиент, можно в соответствии с этим выстроить работу. Сначала закрыть его первостепенные потребности и дать максимальную ценность при минимальном сроке.

Позволяет говорить с бизнес-заказчиками на одном языке. Технические специалисты и нетехнические стейкхолдеры начинают понимать друг друга. Раньше приходилось объяснять, что такое «рефакторинг модуля аутентификации». Но можно показать историю: «Делаем вход через соцсети, чтобы 30% юзеров не бросали корзину на шаге регистрации».

Даёт гибкость в планировании. Истории пользователей широко применяются в Scrum и других гибких методологиях разработки для управления бэклогом продукта. Гибкость формата позволяет быстро реагировать на изменения. Так, команда избавляется от необходимости перерабатывать объёмные спецификации.

Из чего состоит и по каким принципам строится

Каждая история строится по схеме, которая помогает команде понять, что именно нужно сделать:

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

Теперь подробнее.

Заголовок. Короткая и ясная фраза, которая сразу говорит о сути. Например, «Добавление товара в «Избранное»».

Для кого. Указывается, кто будет этим пользоваться: «Как неавторизованный посетитель сайта».

Что нужно. Здесь описывается само действие: «Я хочу добавлять товары в специальный список «Избранное» прямо сейчас».

Зачем это нужно. Самая важная часть — объяснение цели: «Чтобы не потерять понравившиеся товары и легко вернуться к ним позже, даже без регистрации».

Как проверить (критерии приёмки). Конкретные условия, при которых задача считается выполненной: «Товар сохраняется в списке при закрытии браузера, список доступен с любого устройства по ссылке, а кнопка «В избранном» меняет свой вид после клика».

Итого получаем такую историю:

Добавление товара в «Избранное»

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

Критерии приёмки:

Товар сохраняется в списке при закрытии браузера

Список доступен с любого устройства по ссылке

Кнопка «В избранном» меняет свой вид после клика

Создают пользовательские истории как раз на основе этих составляющих: определяют юзера, описывают действие и то, какая потребность закрывается, добавляют критерии приёмки.

При составлении нужно ориентироваться на INVEST-критерии качественной User Story:

Независимая (Independent) — может реализовываться отдельно

Обсуждаемая (Negotiable) — оставляет пространство для диалога

Ценная (Valuable) — приносит пользу

Оцениваемая (Estimable) — можно понять объём работ

Маленькая (Small) — реализуется за один спринт

Тестируемая (Testable) — можно проверить результат

👍 Истории особенно хорошо работают в связке с персонами — собирательными образами типичных пользователей. Когда команда знает, что делает функцию «для Ольги, бухгалтера 45 лет, которая не очень дружит с техникой», решения становятся более человечными

Практические рекомендации

Уточнять истории пользователя в процессе работы. То, что на старте выглядело как «добавить уведомления», после обсуждения может разбиться на несколько конкретных историй: «уведомлять о новых сообщениях», «показывать предупреждение об истечении срока подписки» и «отправлять email с итогами месяца».

Это полезно не только в IT. Например, в отделе поддержки можно сформулировать задачу так: «Как клиент, я хочу получить ответ на вопрос в течение часа, чтобы не откладывать решение проблемы». Это сразу делает цель понятной для всех — и для менеджеров, и для разработчиков, улучшающих систему тикетов.

Приоритизировать. Истории пользователя живут в бэклоге продукта и упорядочиваются по приоритету. Самые ценные и срочные оказываются наверху. Именно их команда берёт в работу в следующем спринте. Перед началом спринта истории уточняются, обрастают критериями приёмки и техническими деталями. Некоторые компании со временем адаптируют формат под себя — упрощают шаблон, добавляют свои критерии или визуализируют User Story в виде комиксов. Важно сохранять суть: делаем продукт для людей, должны понимать их нужды.

Держать истории маленькими. Качественная история должна умещаться в один спринт. Если задача кажется большой, лучше разбить её на несколько независимых частей. Например, вместо «Сделать личный кабинет» можно выделить «Настройки профиля», «Историю заказов» и «Список избранного».

Использовать INVEST-критерии как чек-лист. Проверять каждую историю по шести пунктам, которые мы называли выше в статье. Если хоть один пункт не выполняется, историю стоит переписать или уточнить.

Обсуждать истории вместе с командой. Недостаточно просто записать задачу в бэклог. Нужно провести короткую сессию уточнения, где разработчики, тестировщики и дизайнеры зададут свои вопросы.

Связывать истории с бизнес-целями. Рядом с каждым сценарием кратко указать, как он продвигает продукт к ключевым метрикам. Это помогает команде видеть смысл в своей работе и правильно расставлять приоритеты.