Personas и JTBD: разные этажи одного здания

• Все статьи цикла:
• Personas и JTBD: разные этажи одного здания (вы здесь)
• Personas и JTBD: от Job Story к User Story (coming soon)

С персонами обычно случается одна из двух проблем: их либо превращают в декоративные карточки с фото, возрастом, любимым кофе и прочей этнографической хернёй, либо торжественно выбрасывают из проекта после первого знакомства с JTBD:

Всё, мы теперь взрослые. Больше никаких «Марина, 27 лет, любит скидки». Теперь только работы, прогресс, switch-интервью и священная дрель, которой на самом деле никто не хотел владеть.

Проблема в том, что это ложный конфликт.

JTBD и Personas не должны и не могут конкурировать, они просто отвечают на разные вопросы. И если использовать их как инструменты, а не как религии, они вполне эффективно живут вместе. Более того, без этой связки команда часто получает либо красивые потребности без механик, либо аккуратный бэклог без понимания его цели.

Ничего не понятно? Давайте разбираться.

1. Кажется, что JTBD отменяет Personas

На поверхности конфликт выглядит логично:

Personas говорят:

Опишите тип пользователя, его контекст, задачи, особенности поведения, ограничения и потребности.

JTBD говорит:

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

На этом месте обычно кто-нибудь радостно делает вывод: раз JTBD против сегментации по пользователям, значит персоны устарели. Можно выкидывать.

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

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

Плохая персона отвечает на вопрос:

• кто этот человек;
• сколько ему лет;
• где он работает;
• насколько он «продвинутый»;
• что он якобы хочет в продукте.

Хорошая персона помогает понять другое:

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

Вот здесь и начинается нормальная связка с JTBD.

JTBD помогает не спутать потребность с механикой, которой эта потребность удовлетворяется.

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

2. На каком уровне работает JTBD

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

Классический пример с дрелью потому и живучий, что больно простой. Человек как будто просто покупает дрель. Но если копнуть глубже, оказывается, что ему нужна вовсе не дрель. Потом оказывается, что ему и дырка-то в стене не нужна. Ему нужна даже не сама полка. Ему нужно место для книг, а если ещё глубже, то возможность читать больше и чувствовать себя умнее, собраннее, лучше.

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

JTBD в этом смысле полезен не потому, что даёт красивую формулировку, а потому, что вытаскивает команду из механики на уровень причины.

В нормальном JTBD-анализе нас интересуют несколько вещей:

1. Какая реальная потребность стоит за действием.
2. В каком контексте эта потребность возникает.
3. Как пользователь сейчас закрывает эту работу.
4. Какие конкуренты закрывают ту же работу иначе.
5. Что мешает пользователю переключиться.
6. Как он сравнивает старое и новое решение.
7. Какие потребности продукт закрывает плохо или вообще не видит.
8. Как донести новую пользу так, чтобы пользователь вообще понял, что теперь можно жить иначе.

Это просто способ не начинать продуктовую работу с придумывания формы, фильтра, wizard’а, автоскейлера, личного кабинета или ещё одного «давайте добавим AI».

3. Причём здесь иерархия Пауэрса

Уильям Пауэрс начал развивать теорию перцептивного контроля в конце 1950х — начале 1960х годов. Его иерархия описывает структуру целей человека от абстрактных к конкретным, связывает высокие стремления с реальными действиями. Она помогает понять, что за каждым действием стоит цель, состоящая из трех уровней: принцип (быть), программа (сделать) и действие (моторный контроль).

Если упростить, есть верхние уровни: образ желаемой системы, принципы, цели «быть». Есть средние уровни: программы поведения, цели «делать». Есть нижние уровни: конкретные последствия и цели контроля.

В B2B это может выглядеть так:

Все эти вещи связаны, но это не одно и то же. И вот здесь JTBD и Personas начинают нормально раскладываться по полочкам.

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

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

Если сказать совсем грубо:

• JTBD помогает понять, зачем вообще нужна работа;
• Persona помогает понять, кто и как именно будет выполнять эти действия в реальной системе;

Или вот вам в сторях (подробнее в следующей статье цикла):

• Job Story обрисовывает контекст и потребности;
• User Story фиксирует механику и результат для разработки.

И всё. Никакой священной войны. Просто разные этажи одной системы.

4. Почему персоны всё-таки нужны

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

Одна и та же работа может выполняться разными людьми с разными ограничениями. «Быстро получить дополнительную вычислительную мощность» может хотеть дата-саентист, ML-инженер, DevOps, руководитель R&D, технический директор или вообще внешний подрядчик.

У всех будет один общий прогресс: получить усиление мощностей в срок и не вылететь за пределы бюждета. Вот только механики у них будут разными.

Дата-саентисту нужен быстрый запуск типового GPU-кластера из интерфейса, без тонких настроек и заморочек.

DevOps будет думать про инфраструктурные политики, лимиты, безопасность, мониторинг и то, кто потом будет тушить пожар.

Финансовый контролёр вообще не хочет запускать никакие кластеры. Он хочет понимать, почему счёт за облако снова похож на ипотеку в центре Москвы.

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

Так появляются продукты, где все функции как будто кому-то нужны, но целиком система нормальную работу не выполняет.

5. Где конфликт на самом деле

Конфликт не между JTBD и Personas. Конфликт между потребностями и механиками.

Потребность — это то, что пользователь пытается изменить.

Механика — это способ, которым продукт помогает это сделать.

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

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

Формат «как пользователь, я хочу действие, чтобы результат» слишком быстро тащит команду в механику. Он удобен для бэклога, но плох как единственный источник продуктовой логики.

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

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

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

6. Как они помогают друг другу

Нормальная связка выглядит не как спор, а как трассировка.

Сначала JTBD вытаскивает потребность и прогресс. Потом иерархия целей помогает понять уровень этой потребности: это цель «быть», цель «делать» или нижний контроль конкретного последствия. Затем Job Story фиксирует контекст, мотивацию и результат. После этого Persona добавляет исполнителя, ограничения, права, компетенции и реальные условия использования. И только потом User Story превращает всё это в механику, которую можно проектировать, оценивать, класть в бэклог и проверять метриками.

Давайте на примере.

Job Story:

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

Здесь есть контекст, мотивация и результат, но ещё нет конкретной механики. Дальше команда спрашивает: кто это делает и каким способом?

Персона (разумеется, упрощённо):

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

User Story:

Как дата-саентист в R&D-команде, я хочу запустить на 2 часа кластер из 4×A100, чтобы сократить обучение модели с десяти до двух часов и уложиться в 100$.

Вот теперь появляется механика: нам нужно простое и быстрое управление GPU-кластерами с прогнозируемым бюджетом и таймингом каждого.

У этой механики есть источник: джоба. Есть actor: персона. Есть домен: обучение модели. Есть результат: время и бюджет. Есть проверяемость: можно измерить, насколько сценарий реально сокращает время и не раздувает счёт.

Таким образом, Personas вовсе не противоречат JTBD. Они помогают довести его до конкретных требований без потери смысла.

7. Практическая рамка

Если нужно подружить JTBD и Personas, я бы советовал вам держать такую рамку:

7.1. Начинаем не с персон и фичей, а с ситуаций

Ищем моменты, где пользователь испытывает напряжение: старое решение не справляется, новое кажется привлекательным, но страшным, привычки держат, последствия непонятны.

7.2. Формулируем сырые Job Stories

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

7.3. Раскладываем цели по уровням

Где здесь цель «быть»? Где цель «делать»? Где конкретный контроль последствия? Если всё сложено в одну фразу, команда потом будет спорить о кнопках, хотя спор на самом деле про уровень потребности.

7.4. Определяем акторов

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

7.5. Собираем Personas вокруг поведения и ограничений

Не вокруг возраста и «любимых брендов». Персона должна объяснять, почему один и тот же job превращается в разные механики для разных ролей.

7.6. Переводим Job Story в User Stories

Только после этого. Не раньше. Об этом, как я уже говорил, будет следующая статья цикла.

7.7. Проверяем трассировку

У каждой User Story должен быть источник в Job Story. У каждой механики должен быть объяснимый вклад в результат. У каждого результата должна быть метрика или хотя бы наблюдаемый критерий.

Если трассировка не сходится, начинайте копать, почему.

8. Что в итоге

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

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

Методологии не противоречат друг другу, пока вы не заставляете одну делать работу другой. Проблемы начинаются не от JTBD, не от персон и не от User Stories. Проблемы начинаются там, где команда перестаёт различать потребность, роль, механику и результат.

• Все статьи цикла:
• Personas и JTBD: разные этажи одного здания (вы здесь)
• Personas и JTBD: от Job Story к User Story (coming soon)