User story и сценарии: как описать, что должен делать сервис, если вы не аналитик

Короткий ответ: user story, или пользовательская история, — это требование, записанное одной фразой от лица пользователя: «Как роль, я хочу действие, чтобы польза». К каждой истории добавляют 2–5 критериев приёмки — проверяемых условий, по которым понятно, что функция готова. Набор таких историй, разложенный по пути пользователя, заменяет заказчику без опыта аналитика толстый документ: из него видно, что делать, что важно и что можно отложить. С этим набором удобно приходить на бриф.

Что такое user story простыми словами?

Это короткая запись того, что конкретный человек хочет сделать в сервисе и зачем. Не «модуль документов», а «как бухгалтер клиента, я хочу скачать акты за квартал одним архивом, чтобы не собирать их по одному». История описывает потребность, а не экран или кнопку: как именно это будет выглядеть, решают вместе с разработчиком.

Формат появился в гибкой разработке. По глоссарию Agile Alliance, шаблон «роль — функция — польза» используется с 2001 года; к тому же году там отнесена модель 3C: карточка, обсуждение, подтверждение (Card, Conversation, Confirmation). Смысл модели простой: история — не исчерпывающий документ. Карточка фиксирует суть, детали проясняются в разговоре с командой, а результат закрепляют критерии приёмки.

Три части истории отвечают на три вопроса, которые разработчик всё равно задаст:

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

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

Признак	User story	Use case
Объём	Одно желание одного пользователя, 1–3 предложения	Полный сценарий взаимодействия с системой, от страницы и больше
Что описывает	Кто, что хочет сделать и зачем	Шаги пользователя и ответы системы, развилки и ошибки
Детали	В критериях приёмки и в разговоре с командой	В самом документе: основной поток, альтернативы, исключения
Кто обычно пишет	Заказчик или владелец продукта вместе с командой	Аналитик
Когда удобнее	Сервис меняется по ходу, работа идёт короткими этапами	Сложные процессы, где важна каждая развилка: деньги, документы, интеграции

Чем user story отличается от use case?

User story — короткое желание пользователя с критериями приёмки, детали уточняются в разговоре. Use case, или сценарий использования, — подробное пошаговое описание взаимодействия человека с системой: основной поток, альтернативы, ошибки. История отвечает на вопрос «что и зачем», use case — «как именно, шаг за шагом».

Понятие use case ввёл Ивар Якобсон, описав, как этот метод применяли в Ericsson; позже сценарии использования стали стандартной частью аналитической работы. Это не конкуренты: на практике одно дополняет другое.

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

Практическое правило для заказчика:

• описывайте весь сервис историями — так видно объём и приоритеты;
• для 2–5 самых рискованных мест, где деньги, документы или обмен с другой системой, просите или пишите подробный сценарий с развилками;
• не пишите use case на очевидные вещи вроде «изменить имя в профиле» — это потраченное время.

Как написать хорошую историю: формула и критерии приёмки

Формула: «Как роль, я хочу действие, чтобы польза», плюс 2–5 критериев приёмки — условий, которые можно проверить «да/нет». Хорошая история закрывает одну законченную задачу пользователя, помещается в одно предложение и проверяется без споров о том, что имелось в виду.

Для проверки качества историй в гибкой разработке есть чек-лист INVEST (Agile Alliance датирует его 2003 годом). В переводе на язык заказчика:

1. Независимая — историю можно сделать отдельно, не дожидаясь пяти других.
2. Обсуждаемая — в ней нет готового решения, которое нельзя оспорить: «хочу уведомление», а не «хочу всплывающее окно красного цвета».
3. Ценная — даёт пользу кому-то конкретному. «Настроить базу данных» — не история, а работа разработчика.
4. Оцениваемая — разработчик понимает её настолько, чтобы назвать объём.
5. Небольшая — укладывается в несколько дней работы, а не в месяц.
6. Проверяемая — у неё есть критерии приёмки.

Критерии приёмки — самая полезная часть для вас как заказчика: именно по ним вы будете принимать работу. Удобно писать их в формате «Дано — Когда — Тогда». Он пришёл из языка Gherkin, где, по справке Cucumber, «Дано» задаёт исходное состояние системы, «Когда» — действие или событие, «Тогда» — ожидаемый результат, видимый снаружи. Пример:

• Дано: у клиента есть неоплаченный заказ на 12 позиций.
• Когда: он нажимает «Оплатить» и успешно платит картой.
• Тогда: статус заказа меняется на «Оплачен», клиенту приходит чек на почту, менеджер видит оплату в CRM.

Хватает и простого списка условий, если в каждом есть проверяемый факт: число, срок, роль, конкретное сообщение. «Работает быстро» — не критерий. «Список заказов открывается не дольше 2 секунд при 5 000 заказов» — критерий.

Сервис	История	Критерии приёмки
Кабинет клиента	Как клиент, я хочу скачать закрывающие документы по заказу, чтобы не просить их у менеджера	В карточке заказа есть список документов; файл скачивается в PDF; документы другого клиента недоступны даже по прямой ссылке
Кабинет клиента	Как клиент, я хочу видеть статус заказа, чтобы не звонить и не спрашивать	Статус меняется вместе с 1С не позже чем через 15 минут; при смене статуса приходит письмо
Telegram-бот	Как покупатель, я хочу записаться на услугу в боте, чтобы не ждать ответа администратора	Бот показывает только свободные слоты; после записи слот пропадает у других; администратору приходит уведомление
Telegram-бот	Как администратор, я хочу отменить запись, чтобы освободить время	Отмена освобождает слот; клиенту приходит сообщение с причиной
CRM	Как руководитель продаж, я хочу видеть сделки без следующего шага, чтобы ни одна не зависла	Фильтр «без задачи» в списке сделок; ежедневная сводка в 9:00 с числом таких сделок по менеджерам
CRM	Как менеджер, я хочу, чтобы заявка с сайта сама становилась сделкой, чтобы не переносить её руками	Сделка создаётся с источником и UTM-метками; дубль по телефону не создаётся, а добавляется в существующую

Примеры для кабинета, бота и CRM

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

Что видно на этих примерах:

• Критерии раскрывают скрытый объём. Фраза «статус меняется вместе с 1С» означает интеграцию. Это отдельная работа, и узнать о ней стоит на этапе историй, чем на приёмке. Если связка сводится к обмену между двумя системами, её по прайсу закрывает тариф интеграций — от 32 000 ₽ и от 2 дней.
• У одной функции несколько ролей. Запись в боте нужна клиенту, а отмена — администратору. Забытая роль — частая причина «а как это поменять?» после запуска.
• Негативные условия важнее, чем кажется. «Документы другого клиента недоступны даже по прямой ссылке» — это требование безопасности, которое легко упустить, если писать только о том, что пользователь должен видеть.

Сам состав кабинета — какие разделы, вход, документы и уведомления там нужны — мы подробно разбирали в статье «Личный кабинет клиента: что должно быть внутри». Здесь важна техника записи: этот состав можно переложить в истории по ролям.

Для ориентира по бюджету: Telegram-бот с меню, сценариями и интеграцией с одной системой — CRM или Google Sheets — по прайсу — от 16 000 ₽ и 1–2 дня; кабинет или CRM на заказ с ролями, базой данных и API — тариф веб-приложения, от 160 000 ₽ и от 10 дней. Точную цену называем после разбора историй и фиксируем в договоре до старта.

Что такое карта историй и как выбрать первую версию?

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

Практику карт историй популяризировал Джефф Паттон, автор книги «User Story Mapping»; на его сайте метод описан как способ говорить о пути пользователя через продукт. Для заказчика это главный инструмент против раздутой первой версии: на плоском списке все истории кажутся одинаково важными, на карте видно, без чего путь просто не работает.

Как собрать карту за пару часов:

1. Выпишите шаги пути главной роли — 5–8 глаголов слева направо. Для кабинета клиента: войти → найти заказ → посмотреть статус → оплатить → получить документы → задать вопрос.
2. Под каждым шагом разложите истории. Сверху — минимум, без которого шаг невозможен; ниже — удобства: фильтры, экспорт, напоминания.
3. Добавьте вторую роль отдельной строкой шагов: менеджер, который отвечает на вопросы и меняет статусы.
4. Проведите первую линию. Выше неё — то, что позволяет пройти весь путь от начала до конца хотя бы самым простым способом. Каждый шаг должен быть закрыт хотя бы одной историей.
5. Проведите вторую и третью линии — следующие этапы. Это ваш план развития, а не список «когда-нибудь».

Частая ошибка — выбирать первую версию по разделам: «сделаем сначала заказы целиком, потом документы». В итоге через месяц есть идеальный раздел заказов, а пользоваться сервисом всё ещё нельзя. Карта заставляет резать по-другому: весь путь, но в простом виде. О том, как определить объём первой версии и когда она не нужна, — в статье «MVP или полная версия: с чего начать разработку сервиса».

Как истории связаны с ТЗ, оценкой и приёмкой?

Истории — исходный материал для ТЗ и сметы, а критерии приёмки — готовый список проверок для сдачи работы. Разработчик превращает истории в экраны, модель данных и интеграции, оценивает каждую, и вы видите, из чего складывается цена. На приёмке вы идёте по критериям, а не вспоминаете, что обсуждали месяц назад.

Как это выглядит в нашей работе по тарифу веб-приложения:

• Бриф и ТЗ. Истории группируем по ролям, уточняем критерии, отмечаем интеграции. Пошаговая форма брифа помогает не забыть роли и системы, с которыми нужен обмен.
• Прототип. По историям первой версии рисуем экраны. По прайсу в тарифе веб-приложения до 2 раундов правок на прототипе и до 2 на готовой сборке — дешевле всего менять решения на прототипе.
• Приёмка. По договору на проверку результата у заказчика 5 рабочих дней; критерии приёмки превращают её в чек-лист, а не в спор о вкусах.

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

Типичные ошибки в описании требований

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

• «Хочу кнопку». «Как менеджер, я хочу кнопку экспорта» — это решение. Спросите себя «зачем?»: если ответ «чтобы раз в неделю отправлять директору отчёт», возможно, нужна автоматическая сводка, а не кнопка.
• Истории-эпики. «Как клиент, я хочу управлять заказами» — это десяток историй. Пока её не разделили, оценка будет приблизительной.
• Только счастливый путь. Что если оплата не прошла, файл слишком большой, клиент ввёл чужой номер заказа? Хотя бы по одной истории на основные ошибки.
• Забытые служебные роли. Кто заводит пользователей, меняет тексты писем, смотрит журнал действий? Без этих историй сервис после запуска обслуживает разработчик.
• Технические истории. «Как система, я хочу хранить данные в базе» — не история пользователя. Технические задачи разработчик запишет сам.
• Критерии «на глаз». «Удобно», «быстро», «красиво» не проверяются. Заменяйте на числа, сроки и конкретные сообщения.

Когда user story вам не нужны?

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

Ещё два случая:

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

Во всех остальных случаях 15–40 историй с критериями приёмки и простая карта — самый короткий путь от идеи к точной оценке. Писать их идеально не нужно: черновик в таблице, где на строку одна история, уже экономит время на брифе.

Короткие ответы на частые вопросы

Кто должен писать user story — заказчик или разработчик?

Черновик стоит писать заказчику: только вы знаете, кто ваши пользователи и что им мешает. Разработчик задаёт вопросы, дополняет критерии приёмки, делит крупные истории и оценивает их. Хорошая история получается после одного-двух разговоров, а не с первой записи.

Сколько историй нужно, чтобы оценить проект?

Для первой оценки небольшого сервиса обычно хватает 15–40 историй, сгруппированных по ролям и шагам пути пользователя. Важнее полнота пути от входа до результата, чем количество: пропущенный шаг потом превращается в доработку.

Можно ли заменить ТЗ набором user story?

Для небольшого сервиса с короткими этапами — часто да: истории с критериями приёмки и прототип экранов закрывают большую часть вопросов. Для крупных проектов, тендеров и госзаказа ТЗ остаётся, а истории становятся его разделом о функциях.

На каком языке писать истории — по-русски или по шаблону на английском?

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

Что делать, если история не помещается в одно предложение?

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

Услуги и кейсы по теме: цены и сроки