Когда роль не объясняет поступок
Job story связывает ситуацию, мотивацию и желаемый результат человека.
Два человека с одинаковой должностью могут вести себя по-разному, потому что оказались в разных обстоятельствах. Один спокойно выбирает занятие на месяц вперёд, другой застрял в дороге и пытается изменить запись за час до начала. Название роли само по себе не объясняет, какое решение будет полезно.
Формат job story помогает начать с контекста: «Когда [ситуация], я хочу [мотивация или действие], чтобы [нужный результат]». Ниже — авторский учебный пример мастерской. Мы не выдаём придуманную историю за интервью или подтверждённый пользовательский инсайт.
- Ситуация
Планы изменились, я уже в дороге и не могу говорить по телефону.
- Мотивация
Хочу понять, можно ли изменить запись без звонка.
- Результат
Хочу сохранить возможность попасть на занятие и не потерять договорённость.
Заполненный пример без преждевременной функции
Здесь ещё нет кнопки, чат-бота и личного кабинета. Решением может стать понятное письмо с правилами, страница изменения записи или связь с организатором. История сначала объясняет, почему человеку вообще понадобилось действие.
Если сразу написать «хочу нажать кнопку переноса», команда рискует обсуждать удобство кнопки, не проверив главную неопределённость: разрешён ли перенос так поздно и на каких условиях. Иногда полезнее честно показать ограничение и предложить другой вариант, чем красиво автоматизировать невозможное обещание.
Конкретность ситуации важнее драматичности. Не нужно сочинять биографию человека или добавлять эмоциональные детали без основания. Достаточно обстоятельств, которые меняют его выбор: мало времени, нельзя звонить, неизвестны правила, есть риск потерять место.
Job story и user story: что выбрать
| Формат | На чём делает акцент | Пример |
|---|---|---|
| User story | Кто хочет получить возможность и зачем | Как записанный участник, хочу изменить сеанс, чтобы прийти в доступное время. |
| Job story | В какой ситуации возникает потребность | Когда планы изменились перед занятием, хочу понять варианты переноса, чтобы выбрать допустимое решение. |
Это не соревнование правильного и неправильного шаблона. User story удобна для краткого описания потребности определённого участника. Job story помогает сильнее проявить обстоятельства и причину выбора. Роли при этом не исчезают: права организатора и посетителя всё равно различаются.
Если команда уже понимает ситуацию, смена формата не обязана улучшить работу. Если же одинаковая роль скрывает несколько разных мотивов, история с контекстом может выявить полезные различия. Выбирайте формат по вопросу, который пока остаётся неясным.
Как написать user story — отдельный разбор роли, потребности и критериев.
Гипотеза — не результат исследования
Наша история пока предположение. Чтобы проверить её, поговорите с людьми, которые действительно переносили или пропускали занятие. Просите восстановить конкретный случай: что изменилось, где искали информацию, какие варианты рассматривали, чем всё закончилось.
- Что произошло перед тем, как вы решили изменить запись?
- Как вы сначала пытались решить вопрос?
- Какая информация была непонятна или недоступна?
- Почему выбранный вариант показался приемлемым?
- Что случилось в итоге и что осталось нерешённым?
Вопрос «вам была бы полезна кнопка переноса?» уже подсказывает решение и собирает мнение о будущем. Рассказ о состоявшемся эпизоде даёт другой материал: последовательность действий и ограничения. Он тоже не становится абсолютной истиной, но позволяет проверить исходную гипотезу.
Сохраняйте отдельно наблюдение, интерпретацию и решение. «Человек искал правила в письме» — наблюдение из конкретного рассказа. «Правила нужно добавить в письмо» — возможное решение. Между ними ещё стоит вопрос, насколько ситуация повторяется и подходит ли решение другим участникам.
Из истории — к вариантам решения
Допустим, в учебном разборе выяснилось: главная трудность не в самом переносе, а в неизвестности. Человек не понимает, потеряет ли оплату и кому писать. Тогда первая проверка может быть небольшой: показать правила и доступный канал связи в подтверждении записи.
- Информация
Понятные условия и контакт в письме: человек знает, что возможно.
- Самообслуживание
Изменение записи без звонка, если правила и свободные места позволяют.
- Помощь
Короткий запрос организатору, когда требуется индивидуальное решение.
Сравните варианты по тому, устраняют ли они препятствие, а не по технологической эффектности. Для редкой сложной ситуации ручная помощь может быть разумной. Для частого стандартного действия она может создавать очередь. Без наблюдений нельзя честно выбрать универсально лучший вариант.
Затем сформулируйте критерий проверки гипотезы. Например, участник в тестовом сценарии способен найти допустимые варианты и объяснить следующий шаг. Это проверяет понятность решения, но ещё не доказывает изменение реального поведения после запуска.
Частые ошибки формулировки
Слишком общий контекст — «когда пользуюсь сайтом» — почти ничего не добавляет. Слишком готовое решение — «хочу чат-бота» — закрывает альтернативы. Слишком абстрактный итог — «чтобы было удобно» — не показывает, какую неопределённость человек пытается снять.
Исправляйте по одному слою. Сначала уточните событие, которое вызвало потребность. Затем опишите то, чего человек пытается добиться. После — назовите наблюдаемый полезный итог. Не нужно помещать в одно предложение всю исследовательскую работу: подробности могут лежать рядом.
Где сохранить рабочий результат
В Sinqly можно создать задачу «Проверить гипотезу о переносе записи» и добавить в описание job story, вопросы к реальным случаям и выбранный способ проверки; регистрация бесплатная.
Как использовать историю после исследования
Обновите формулировку, если реальные случаи отличаются от первоначального сценария. Не защищайте удачно написанное предложение от фактов. Иногда обнаруживается другая задача: человеку нужен возврат, возможность передать место или просто подтверждение, что организатор увидел сообщение.
Сохраните ссылку на основание и обозначьте степень уверенности. История, подтверждённая несколькими наблюдениями, и идея автора могут выглядеть одинаково аккуратно, но имеют разный вес для решения. Именно эта прозрачность делает job story рабочим инструментом, а не красивой подписью к уже выбранной функции.
Что ещё стоит уточнить
Job story относится к Jobs to Be Done?
Да, формат связан с подходом, который рассматривает прогресс, ради которого человек выбирает решение. Одна история не заменяет полноценное исследование.
Можно ли написать job story без интервью?
Можно как гипотезу. Нужно явно обозначить, что ситуация придумана или предполагается, и проверить её до уверенных выводов.
Нужно ли убирать роль пользователя?
Нет. Роль и права могут оставаться важными. Формат просто переносит акцент на ситуацию, мотивацию и результат.
Помогло разобраться?
Оцените статью и расскажите, чего не хватило. Отзыв увидит редакция Sinqly — он не появится на сайте.
Источники и примечания
- Intercom: происхождение job stories
- Предлагаемый порядок — редакционная практика, а не обещание одинакового результата для всех.
User story: как написать пользовательскую историю, с примерами
Формула user story, три исправленных примера и история записи на мастер-класс: отделяем потребность от функции, добавляем критерии приёмки и делим слишком большую задачу.
Бриф: что это и как заполнить его перед началом проекта
Какие вопросы включить в бриф, как разбирать расплывчатые ответы и что согласовать перед оценкой проекта. Заполненный пример для небольшой digital-задачи.
User story mapping: как собрать карту пользовательских историй
Карта пользовательских историй на примере мастерской: путь посетителя, карточки действий, первый сквозной выпуск и ошибки нарезки релизов.