User Story Mapping: как собрать требования к приложению

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

21 сентября 2026 Бизнес 16 мин чтения

---

Что такое User Story Mapping простыми словами

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

Метод описал консультант по продуктовой разработке Джефф Паттон: в статье 2008 года он сравнил плоский список задач с деревом, с которого оборвали листья и сложили их в мешок: листья на месте, но уже не видно, какая ветка за что отвечает. В 2014 году вышла его книга User Story Mapping, и с тех пор карта стала рабочим инструментом бизнес-аналитиков и владельцев продукта.

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

Карта состоит из трёх уровней, а линии срезов делят её на очереди:

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

Зачем карта, если есть список требований

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

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

Карта не заменяет техническое задание и не спорит с ним. Три формата дополняют друг друга:

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

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

Пользовательская история: формат и критерии приёмки

Пользовательская история (user story) — короткое описание функции глазами пользователя. Её записывают по шаблону «Как [роль], я хочу [действие], чтобы [результат]». Шаблон заставляет назвать, кто пользуется функцией и зачем она ему нужна: если третью часть заполнить не получается, функция, скорее всего, лишняя.

Пример для приложения магазина товаров для дома:

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

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

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

Одной фразы истории мало, чтобы разработчик и тестировщик одинаково поняли, когда функция готова. Поэтому к каждой истории добавляют критерии приёмки — проверяемые условия. Их часто пишут в формате «Дано — Когда — Тогда», который пришёл из языка сценариев Gherkin (Given — When — Then): начальная ситуация, действие пользователя и ожидаемый результат.

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

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

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

Для проверки историй используют критерии INVEST, которые в статье 2003 года предложил инженер Билл Уэйк:

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

Как собрать карту пользовательских историй: шесть шагов

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

По нашему опыту, первую версию карты для приложения магазина собирают за одну-две рабочие встречи по 2–3 часа, а доработка, критерии приёмки и согласование занимают ещё несколько дней. Больше всего времени уходит не на саму карту, а на согласование спорных историй между отделами компании.

Частые ошибки при работе с картой

• Карта функций вместо карты действий. Наверху записаны разделы меню — «каталог», «профиль», «корзина», — а не то, что делает пользователь. Такая карта повторяет структуру экранов и не показывает пропуски в сценарии.
• Одна роль на весь продукт. Карта построена только для покупателя, а сборщики заказов, курьеры и операторы поддержки узнают о своих задачах после запуска.
• Все истории над первой линией. В первую версию попадает всё, что назвали на встрече, срок и бюджет растут, а проверка продукта на покупателях откладывается.
• Срез по одной колонке. Первая очередь целиком состоит из каталога с десятью фильтрами, а оформление заказа и доставка остаются на потом.
• Карта без хозяина. После согласования карту никто не обновляет, и через два месяца она расходится с тем, что делает команда.

Другие промахи на стороне заказчика собраны в статье об ошибках заказчика при разработке приложения.

Пример карты для приложения магазина

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

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

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

Как карта превращается в техническое задание и оценку

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

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

Оценка по историям

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

Список задач после согласования

После согласования истории переносят в список задач продукта — упорядоченный перечень работ команды в системе учёта задач. В Руководстве по Scrum 2020 года уточнение такого списка (Product Backlog) описано как постоянная работа: элементы делят на более мелкие и точные, добавляют описание, порядок и размер. Карта при этом остаётся обзорной схемой продукта: к ней возвращаются при планировании каждой очереди, чтобы новые задачи не разрушали путь пользователя.

Инструменты для карты историй

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

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

Сколько стоит и длится работа с требованиями

Карта историй редко заказывается отдельно: она входит в предпроектное исследование или в разработку технического задания. В предпроектном исследовании стандартного объёма приоритизация и карта пользовательских историй занимают 2–3 рабочих дня из 15–20, а срок сильнее всего зависит от скорости, с которой заказчик согласует спорные требования.

На странице разработки технического задания на дату публикации указаны три формата работы: мини-ТЗ от 80 000 ₽ за 2–3 недели включает описание MVP до 20 экранов с пользовательскими историями и каркасами ключевых экранов; стандартное ТЗ от 200 000 ₽ за 3–4 недели — до 50 экранов, интерактивные прототипы, архитектура и план реализации; комплексное ТЗ от 400 000 ₽ за 4–6 недель — для продукта на нескольких платформах с админкой и описанием обмена данными. Во все форматы входят функциональные требования в виде пользовательских историй по ролям с приоритизацией по MoSCoW.

На объём работ влияют:

• число ролей пользователей и сотрудников;
• число сценариев и экранов в первой версии;
• интеграции с учётной системой, CRM, эквайрингом и службами доставки;
• платформы: приложение для iOS и Android, сайт, панель администратора;
• готовность исходных данных — есть ли у заказчика анализ рынка, выгрузки продаж, описания процессов;
• скорость согласования спорных требований внутри компании.

Если аналитик подключается к идущему проекту, работу оплачивают по отработанным часам по модели Time & Materials со сметой и оценкой перед стартом задачи. Разница между моделями разобрана в статье о Time & Materials и Fix Price, ставки специалистов опубликованы на странице тарифов. FITTIN — федеральная команда с центром разработки в Воронеже: распределённая модель позволяет держать эффективные ставки без потери качества.

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

• Интеграция. Единоразовая настройка платформы под ваш бренд.
• Лицензия. Ежемесячные лицензионные платежи, в которые уже включены затраты на техподдержку команды FITTIN.
• Доработки. Новый функционал по Time & Materials со сметой и оценкой по часам перед стартом задачи.

Подробнее модель описана на странице мобильного приложения для интернет-магазина.

Что спросить у подрядчика о сборе требований

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

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

Кто за что отвечает в проекте, описано в материале о составе команды разработки, а как проверить подрядчика целиком — в чек-листе заказа разработки. Если требования нужно собрать для уже работающего приложения, начинают с аудита мобильного приложения или аудита UX/UI: они показывают, на каких шагах пути покупатель сталкивается с трудностями.

Кейсы: требования из пользовательских задач

Три проекта FITTIN, в которых требования к приложению складывались из задач пользователей и сценариев ниши. Цифры приведены со страниц кейсов.

Другие проекты собраны в разделе кейсов.

Итог: User Story Mapping на одной странице

Сводка для встречи с аналитиком или подрядчиком.

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

Материалы по теме:

• Работа до старта разработки: предпроектное исследование, анализ рынка и конкурентов, UX-исследования.
• Первая версия продукта: MVP мобильного приложения, POC и пилот.
• Срок и бюджет: оценка проекта разработки, чек-лист по бюджету и срокам разработки.

Что делать дальше:

• Собрать требования и документ для договора — разработка технического задания и бизнес-аналитика для IT-проектов.
• Прикинуть бюджет первой очереди — калькулятор стоимости и тарифы.
• Выпустить первую версию — разработка MVP или приложение для стартапа; обсудить проект — контакты или форма ниже.

Часто задаваемые вопросы

Что такое User Story Mapping простыми словами?

User Story Mapping, или карта пользовательских историй, — способ собрать требования к продукту в виде схемы. По горизонтали идёт путь пользователя: крупные активности и шаги от первого запуска до результата. Под каждым шагом по вертикали записывают функции по убыванию важности. Горизонтальные линии делят карту на очереди разработки: над первой линией остаётся минимальная версия, которая проводит пользователя через весь путь. Метод описал Джефф Паттон, консультант по продуктовой разработке.

Чем карта пользовательских историй отличается от CJM?

Карта пути клиента (CJM) описывает опыт покупателя целиком, в том числе вне продукта: откуда он узнал о магазине, что чувствует на каждом этапе, где сталкивается с трудностями. Карта пользовательских историй описывает, какие функции продукта помогают пройти каждый шаг и в какой очереди их делать. CJM отвечает на вопрос «что происходит с клиентом», карта историй — «что мы делаем и в каком порядке». Выводы CJM часто становятся основой для верхнего уровня карты историй.

Как написать пользовательскую историю?

Историю записывают по шаблону «Как [роль], я хочу [действие], чтобы [результат]», например: «Как покупатель, я хочу сохранить несколько адресов доставки, чтобы не вводить их при каждом заказе». К истории добавляют критерии приёмки в формате «Дано — Когда — Тогда»: начальная ситуация, действие и ожидаемый результат, отдельно — исключения. Качество проверяют по критериям INVEST: история независимая, обсуждаемая, ценная, оцениваемая, небольшая и проверяемая. Слишком крупную историю делят на части.

Кто должен участвовать в составлении карты историй?

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

Чем пользовательская история отличается от технического задания?

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

Сколько времени занимает составление карты историй?

По нашему опыту, первую версию карты для приложения магазина собирают за одну-две рабочие встречи по 2–3 часа. Ещё несколько дней уходит на критерии приёмки, проверку пропусков и согласование спорных историй с отделами компании. В предпроектном исследовании стандартного объёма приоритизация и карта пользовательских историй занимают 2–3 рабочих дня. Срок растёт, если в продукте много ролей и интеграций или внутри компании долго согласуют требования.

Можно ли составить карту историй для уже работающего приложения?

Да. На карту раскладывают существующие функции по шагам пути пользователя и отмечают, какие шаги проработаны хуже остальных. Карту сверяют с данными аналитики: шаг, на котором теряется больше всего пользователей, и жалобы в отзывах подсказывают приоритеты следующей очереди. Такая карта помогает планировать развитие продукта и не раздувать приложение функциями, которые не связаны с основным сценарием покупки. Начать удобно с аудита приложения или аудита UX/UI.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Стоимость и сроки разработки технического задания приведены по странице услуги на сентябрь 2026 года. Miro, Figma, Jira, Linear, Confluence и Notion — товарные знаки соответствующих правообладателей; упоминаются для описания инструментов.