1 мая 2026 г.

Jobs Stories vs User Stories: что выбрать продакту

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Откуда взялись эти форматы

User Story появилась в Agile-движении в начале 2000-х. Цель — заменить громоздкие требования на короткие карточки, которые команда могла обсуждать. Формат "как X, я хочу Y, чтобы Z" стал стандартом в Scrum, Jira и почти всех продуктовых процессах.

Jobs Story возникла позже, в середине 2010-х, как ответ на проблему: User Story слишком сильно завязана на персону. Если персона нечёткая, история превращается в бессмысленный шаблон. Алан Клемент и команда Intercom предложили формат "когда X, я хочу Y, чтобы Z" — без упоминания роли, с акцентом на ситуацию.

Это не "один лучше другого", это про разные задачи. User Story сильна там, где роль чётко зафиксирована и важна. Jobs Story — там, где важнее ситуация и контекст, чем тип пользователя.

Шаблон User Story

Классический формат:

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

Пример:

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

Сильные стороны:

  • Простой, привычный, заходит командам.
  • Ясно, для кого делаем.
  • Хорошо ложится на персон.

Слабые стороны:

  • Фиксирует роль, даже если она сильно меняется по контексту.
  • Часто превращается в формальность ("как пользователь, я хочу" — пустота).
  • Не описывает триггер: когда возникает потребность.
  • Не учитывает эмоциональный и социальный контекст.

User Story работает, когда команда уже знает свою персону, и история нужна для разработки конкретной фичи. Если персона размыта — формат превращается в карго-культ.

Шаблон Jobs Story

Формат:

Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].

Пример:

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

Сильные стороны:

  • Ставит во главу угла ситуацию, а не роль.
  • Триггер делает потребность конкретной.
  • Не зависит от качества персоны.
  • Лучше работает, когда продукт нужен разным типам пользователей в одной ситуации.

Слабые стороны:

  • Команды непривычны к формату.
  • Сложнее писать — нужно копать в jobs to be done.
  • Может казаться абстрактным, если ситуация описана плохо.

Jobs Story сильна там, где роль вторична, а контекст первичен. Например, такси нужно и студенту, и топ-менеджеру в одной и той же ситуации "опаздываю на встречу".

Когда какой формат работает лучше

Простое правило: насколько роль определяет потребность?

User Story лучше, когда:

  • Роли в продукте чёткие и стабильные (админ, модератор, ученик, преподаватель).
  • Команда уже работает с персонами и знает их хорошо.
  • Фича связана с правами доступа, ролевой логикой, специфичными для роли действиями.
  • Заказчик ждёт привычный формат бэклога.

Jobs Story лучше, когда:

  • Один и тот же человек попадает в разные ситуации, и продукт реагирует по-разному.
  • Сегментация по ролям слабая, а по поведению — сильная.
  • Делаете discovery, ещё не выбрали персону.
  • Хочется выйти за рамки текущего решения и посмотреть на глубинную задачу.

В реальности команды часто миксуют. Discovery идёт через jobs stories, а в бэклог фичи попадают как user stories. Это нормально и продуктивно.

Как переписать User Story в Jobs Story

Алгоритм:

  1. Взять User Story.
  2. Найти ситуацию, в которой роль начинает делать действие.
  3. Заменить "как [роль]" на "когда [ситуация]".
  4. Углубить мотивацию и ожидаемый результат.

Пример.

User Story:

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

Что не так: слишком общо. Когда пользователю важен темп? Не всегда.

Jobs Story:

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

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

Частые ошибки

  • User Story с пустой ролью. "Как пользователь, я хочу..." — это не история, это шаблон. Роль должна быть конкретной.
  • Jobs Story без триггера. "Когда я хочу что-то купить" — это не ситуация. Нужен конкретный момент: "когда я увидел рекламу со скидкой и у меня есть час до встречи".
  • Слишком много историй. Командам кажется, что чем больше карточек — тем лучше. Лучше 5 точных, чем 50 поверхностных.
  • История = решение. Хорошая история описывает, что хочет пользователь, не как именно мы это сделаем. Решение — отдельная работа.
  • Игнорируют эмоции. В Jobs Story эмоциональная и социальная составляющая важны не меньше функциональной. "Не хочу выглядеть глупо перед коллегами" — это часть job.
  • Формат ради формата. Если карточки никто не читает — отказывайтесь от формата, ищите другой способ работать с потребностями.

Связанные темы

FAQ

Можно ли использовать оба формата в одной команде?

Да. Discovery — через jobs stories, бэклог фичи — через user stories. Это нормальный микс.

Jobs Story — это то же самое, что JTBD?

Не совсем. JTBD — это методология. Jobs Story — это формат записи историй в рамках JTBD.

Подходят ли Jobs Stories для B2B?

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

Сколько историй нужно на эпик?

Обычно 5–10. Если меньше — эпик слишком маленький, если больше — пора декомпозировать на подэпики.

Должна ли история проходить через клиента?

Должна. Любой формат — это гипотеза, пока не подтверждена custdev или данными.

Как презентовать stories команде разработки?

Не списком в Jira, а на planning через обсуждение: что за ситуация, какой результат ждёт пользователь, как мы будем это мерить.

Готовишься к продактовому собесу? Открой тренажёр Карьерника — задачи на JTBD, продуктовую логику и метрики.

Тренироваться в Telegram