User Story: самая недооценённая вещь в командах

User Story — вроде бы азбука, но раз за разом натыкаешься на команды, где её не понимает никто, включая тех, у кого в подписи гордое «senior». Разбираю, что это такое, зачем оно нужно и как писать так, чтобы история работала, а не пылилась в бэклоге.

User story — что это на самом деле

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

Звучит примитивно. И в этом весь смысл. Хорошая user story намеренно проста, потому что её задача — не описать реализацию, а зафиксировать потребность. Реализацию придумает команда. А вот потребность, если сформулировать её криво, потянет за собой кривой продукт.

Для аналитика это база — то, в чём положено плавать как рыба в воде. Для джуна — фундамент, с которого начинается вся профессия. И да, я лично встречал сеньоров, которые искренне не понимали, что от них хотят, когда речь заходила про user story. Так что если ты сейчас читаешь и думаешь «ну это же элементарно» — отлично, но проверь, элементарно ли это для всей твоей команды.

Как это выглядит

Классическая формула умещается в одну строку:

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

Несколько примеров, чтобы поймать ритм:

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

Обрати внимание: ни слова про то, какой фреймворк, какая база и где рисовать кнопку. Только пользователь, его действие и его мотив. Всё остальное — зона ответственности команды.

Три вопроса, которые всё решают

Вся конструкция держится на трёх словах: кто, что, зачем.

Кто — «Как [тип пользователя]». Здесь важно не написать абстрактное «как пользователь» на всё подряд. Администратор, покупатель, гость, контент-менеджер — у каждого своя оптика и свои потребности. Чем точнее ты назовёшь роль, тем понятнее, что на самом деле нужно.

Что — «я хочу [действие]». Одно действие. Не «зарегистрироваться, залогиниться, восстановить пароль и заодно поменять аватар» — это уже эпик, который надо дробить.

Зачем — «чтобы [цель или причина]». Вот эту часть чаще всего и выкидывают, а зря. Именно «зачем» отличает осмысленную историю от списка хотелок. Пример: «Как студент, я хочу видеть свои оценки онлайн, чтобы быть в курсе своей успеваемости». Убери вторую половину — и непонятно, зачем вообще эта фича, какие у неё границы и как понять, что она удалась.

Критерии приёмки — то, без чего история не работает

Сама по себе user story — это обещание разговора, а не спецификация. Чтобы её можно было закрыть, нужны критерии приёмки: условия, при которых история считается выполненной.

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

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

• Пользователь может добавить товар в избранное.
• Пользователь может посмотреть список избранных товаров.
• Пользователь может удалить товар из избранного.

Без этого блока начинается классика жанра — тот самый сломанный телефон: заказчик имел в виду одно, аналитик услышал другое, разработчик собрал третье, а тестировщик проверил вообще четвёртое. Критерии приёмки — попытка разорвать эту цепочку. Не идеальная, но рабочая.

Хорошее правило: если критерий нельзя однозначно проверить руками или тестом, он написан зря. Формулируй так, чтобы на каждый пункт можно было честно ответить «да» или «нет» — без «ну, вроде работает». И держи их рядом с самой историей, а не в отдельном файле, до которого никто не долистает.

Зачем всё это вообще нужно

Почему индустрия так держится за эти истории, если можно просто написать «сделайте регистрацию»? Три причины.

Фокус на пользователе. Формулировка через «как <кто>, чтобы <зачем>» физически не даёт забыть, для кого ты всё это строишь. Команда думает не про кнопку, а про человека за ней.

Упрощение планирования. Большой неподъёмный проект распадается на десятки маленьких управляемых кусков. Каждый кусок можно оценить, приоритизировать, взять в спринт — или отложить без ущерба для остального.

Коммуникация. User story — общий язык для аналитика, разработчика, тестировщика и заказчика. Все смотрят в одну формулировку и, что важнее, в одни критерии приёмки. Меньше поводов для «а я думал…».

Частые грабли (из практики)

Раз уж база разобрана, вот на чём спотыкаются чаще всего.

Пишут историю как техзадание. «Как пользователь, я хочу, чтобы система делала POST-запрос на /auth с JWT-токеном» — это не user story, это кусок реализации, натянутый на шаблон. Пользователю плевать на POST и JWT, ему надо войти в аккаунт.

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

Раздувают одну историю до эпика. Если в «я хочу» больше одного глагола и торчит союз «и» — почти наверняка пора дробить. Маленькие истории проще оценивать, проще закрывать и приятнее двигать по доске.

Пишут критерии приёмки, которые невозможно проверить. «Система должна работать быстро» — это не критерий, это пожелание. «Список избранного открывается» — вот это проверяемо: да или нет.

Короче

User story — не бюрократия ради бюрократии и не ритуал из книжки по Agile. Это инструмент, который заставляет всех — аналитика, разработку, тестирование и заказчика — говорить на одном языке и держать в голове пользователя, а не абстрактные «фичи».

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

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП