В первой статье мы разобрались с главным: JTBD и Personas не воюют, они просто работают на разных уровнях. Теперь погнали дальше.
И начнём мы с простого вопроса:
Как это применять так, чтобы команда не превратила нормальную методологическую связку в дорогую раскраску персонажей?
Потому что в теории все умные. В теории JTBD про потребности, Personas про контекст, User Stories про механики. В теории даже ретроспективы полезны.
А потом приходит реальный проект. Бизнес требует фичу к концу квартала, продакт хочет доказать, что discovery было не зря, дизайнер уже вайбкодит прототип. И в этот момент все красивые слова про работы, прогресс и персоны начинают потихоньку стекать в бэклог, как твоя зарплата меж пальцев.
Где всё ломается
Вот вам реальная история. 2019-й или 2020-й год, крупная компания развивает сервис для ресторанов. Продуктовая команда формирует приличную с виду User Story:
Как управляющий рестораном, я хочу видеть остатки продуктов на дашборде, чтобы нужные ингредиенты не закончились во время смены.
Вроде всё хорошо. Есть actor, действие и результат. Команда принимается за работу.
На дашборде появляются графики расхода, цветовые индикаторы, прогноз остатков, сравнение с прошлой неделей и отдельный экран для продуктов с критически низким запасом. Дизайнер аккуратно раскладывает карточки, аналитик настраивает витрины данных, разработчики делают обновление показателей почти в реальном времени.
А через месяц выясняется, что управляющий открывает этот дашборд два раза в неделю. Во время смены ему некогда изучать графики, повара сообщают о дефиците уже по факту, а закупщик продолжает заказывать продукты по привычной таблице.
Команда хорошо реализовала механику «смотреть остатки». Но управляющему не хотелось смотреть на остатки. Он хотел, чтобы нужные продукты не заканчивались.
Возможно, задачу лучше решали бы автоматический прогноз закупки, заранее сформированный заказ поставщику или предупреждение ответственному сотруднику. Но эти варианты команда даже не рассматривала: дашборд появился в User Story раньше, чем была сформулирована потребность.
Команда, как часто бывает, приняла механику за потребность. Наблюдение за проблемой — за её решение.
Это первое место в проектном процессе, где User Stories без JTBD начинают делать вид, что команда думает. Хотя на самом деле она просто аккуратно описывает заранее выбранное решение.
Базовый принцип: сначала напряжение, потом механика
Нормальная последовательность такая:
- Находим контекст напряжения и потребность.
- Формулируем Job Story.
- Понимаем уровень цели.
- Проверяем важность работы и удовлетворённость текущими решениями.
- Определяем акторов и персон.
- Выбираем механику.
- Пишем User Story.
- Проверяем результат.
Если вы начинаете с User Story, вы почти всегда уже выбрали механику. Иногда осознанно, чаще нет.
«Как DevOps-инженер, я хочу настроить автоскейлер на своих серверах…»
Автоскейлер — это конкретная механика. Не потребность. Сразу проектировать его настройку — значит искусственно ограничивать пространство решений.
«Как владелец автомобиля, я хочу заполнить заявку…»
И тут тоже уже выбрана механика. Вы уверены, что пользователю нужна именно заявка? Уверены, что иначе никак не закрыть его потребность во владении работающим автомобилем?
«Как владелец домашних цветов, я хочу получить уведомление…»
Пользователю не нужны конкретно уведомления, он просто хочет быть в курсе и не пропустить полив.
Может быть, всё это действительно нужно. Вот только сначала надо понять, какую работу закрывает механика и почему именно эта механика лучше альтернатив. Пользователь не обязан жить внутри вашей схемы. Он не мечтает о формах, фильтрах, вкладках, автоскейлерах и настройках. Он пытается изменить ситуацию с минимальной ценой, риском и когнитивной нагрузкой.
Давайте поподробнее.
Найти ситуацию, в которой человеку уже плохо
JTBD начинается не с вопроса «какую фичу вы хотите?». Нас интересует момент, в котором привычный способ перестаёт справляться с задачей и создаёт давление.
Для примера возьмём человека, который одновременно работает с несколькими проектами. Он на несколько дней выпал из одного из них: заболел, ушёл в отпуск, переключился на другой запуск или просто провёл три дня в бесконечных встречах. Теперь ему нужно вернуться в контекст перед обсуждением, на котором будут приниматься решения.
За это время в проекте появились новые комментарии, документы, задачи, риски и договорённости. Часть обсуждений прошла в чате, часть — на встречах, часть — в таск-трекере. Формально вся информация существует. Практически она размазана по пятнадцати местам, и никто не знает, в каком из них лежит нужная версия правды.
Ищем четыре силы (классика JTBD):
- Давление текущей ситуации.
- Притягательность нового способа.
- Тревогу перед новым способом.
- Силу привычки старого способа.
В нашем примере они будут выглядеть так:
Неудовлетворённость:
Чтобы восстановить контекст, приходится читать сотни сообщений, просматривать историю задач, открывать документы и отдельно спрашивать коллег, что из всего этого действительно важно.
Притягательность нового способа:
Возможность за десять минут получить целостную картину произошедшего вместо часа археологических раскопок по чатам, документам и задачам.
Тревога:
А что, если новый способ пропустит важную деталь? Или перепутает принятое решение с идеей, которую просто обсуждали? Ложное ощущение, что ты всё понял, иногда опаснее честного признания «я вообще не в контексте».
Привязанность:
Ручной способ медленный, но привычный. Можно пролистать чат, спросить знакомого коллегу и самостоятельно проверить первоисточники. Да, это долго. Зато понятно, откуда взялась информация.
Теперь у нас есть напряжение. С ним уже можно работать.
Написать Job Story
Job Story должна удерживать три вещи: контекст, мотивацию и результат.
Формула простая:
«Когда [ситуация], я хочу [мотивация], чтобы [результат]».
Но простая формула не означает простую работу.
Плохая Job Story:
Когда я работаю с проектом, я хочу удобно получать информацию, чтобы быть в курсе.
Это не Job Story, это туман в банке. Из неё можно сделать почти что угодно: дашборд, чат, рассылку, ещё один раздел базы знаний или корпоративный портал, в который никто не заходит.
Нормальная Job Story:
Когда я возвращаюсь к проекту после нескольких дней отсутствия, я хочу быстро понять, что изменилось, чтобы уверенно участвовать в обсуждении и принимать решения.
Здесь есть ситуация: человек выпал из рабочего контекста и возвращается. Есть мотивация: быстро понять изменения. Есть ожидаемый результат: снова участвовать в обсуждении и принимать решения с нормальным пониманием происходящего.
При этом конкретной механики пока нет. И это хорошо. Решением может стать автоматическая сводка, хронологическая лента изменений, журнал решений, список новых рисков, диалог с ассистентом, короткий бриф перед встречей или договорённость внутри команды фиксировать важные изменения в одном месте.
Job Story должна сохранять пространство решений. Как только в неё попадает «получить автоматическую сводку», часть проектирования уже закончилась, хотя команда могла ещё даже не начать думать.
Разобрать цель по уровню
Здесь пригодится иерархия Пауэрса. Без неё, конечно, тоже можно, но зачем? Она очень удобно помогает не смешивать разные уровни цели в одном обсуждении.
В нашей истории можно выделить три уровня.
Цель «быть»:
Сохранять управляемость проектов, даже когда внимание распределено между несколькими направлениями.
Это верхний уровень. Здесь человек говорит о своём состоянии или принципе работы: он хочет оставаться в позиции, где понимает происходящее и может отвечать за решения.
Цель «делать»:
Быстро восстанавливать актуальный контекст после перерыва.
Здесь уже появляется деятельность, которую можно поддержать продуктом.
Цель контроля последствий:
За десять минут понять ключевые изменения, принятые решения и новые риски перед встречей.
Это наблюдаемый результат. Его можно проверить.
Если команда не разделяет эти уровни, участники начинают обсуждать разные задачи, сохраняя полную уверенность, что говорят об одном и том же. Продакт говорит про управляемость проекта, аналитик — про полноту данных, дизайнер — про экран сводки, разработчик — про источники и синхронизацию, а руководитель — про то, почему человек вообще выпал из проекта.
И каждый держит свой кусок слона, периодически требуя признать его слоном целиком
Для каждой Job Story полезно зафиксировать:
- какой верхний принцип или желаемое состояние за ней стоит;
- какое действие должен уметь выполнять пользователь;
- какое наблюдаемое последствие подтверждает успех;
- где заканчивается цель и начинается выбранная механика.
Это занимает меньше времени, чем несколько недель разработки решения, которое аккуратно закрывает задачу нижнего уровня и никак не влияет на проблему верхнего.
Понять, стоит ли вообще решать эту работу
Даже хорошо сформулированная Job Story не получает автоматического права на разработку. Пользователи хотят много всего. Иногда они хотят это редко. Иногда проблема звучит страшно в интервью, но почти не влияет на поведение. Иногда работа важная, однако текущий способ уже закрывает её достаточно хорошо.
Здесь пригодится Opportunity Landscape: сравнить важность желаемых результатов с удовлетворённостью текущими решениями.
В оригинальном ODI на карту наносятся именно outcomes, а выводы подтверждаются количественным исследованием. Ниже я использую упрощённую версию этой логики, а не воспроизвожу весь ODI-процесс.
Нас интересуют три базовых ситуации:
Работа важная, а текущие решения справляются плохо:
Это under-served job. Здесь есть пространство для нового решения.
Работа важная, и текущие решения уже справляются хорошо:
Поддерживать нужно. Устраивать продуктовый крестовый поход — необязательно.
Работа не слишком важная, но закрыта множеством функций:
Скорее всего, пользователь уже перекормлен. Ещё один слой функциональности вряд ли радикально изменит его жизнь.
В нашем примере надо проверить, насколько часто люди выпадают из проектного контекста, сколько времени тратят на возвращение, какие ошибки совершают из-за неполной информации и насколько их устраивает текущий способ. Если человек возвращается к проекту раз в полгода и решает проблему одним сообщением коллеге, отдельный продуктовый контур может оказаться избыточным. Если руководители и продакты каждую неделю тратят часы на восстановление контекста, пропускают договорённости и повторно обсуждают уже принятые решения, работа выглядит гораздо интереснее.
Opportunity Landscape лучше использовать до выбора механики. Иначе возникает удобная ловушка: команда уже придумала красивое решение и теперь старательно доказывает, что проблема достаточно важна для его разработки.
Определить, кто реально действует
Вот здесь возвращаются Personas. Но не в виде «Михаил, 43 года, любит кофе и минимализм». Нас интересуют рабочие персоны: роли, контексты, ограничения, права и поведенческие различия.
Для одной Job Story может быть несколько акторов:
Кто может возвращаться в проект после отсутствия?
- Продакт-менеджер, который ведёт несколько продуктов?
- Руководитель направления перед статусной встречей?
- Аналитик, подключившийся к обсуждению после работы над другой задачей?
- Разработчик, вернувшийся из отпуска?
- Внешний стейкхолдер, который появляется в проекте раз в две недели?
Работа похожая: восстановить контекст. Но нужная информация, уровень детализации и цена ошибки у них разные:
- продакт-менеджеру важны изменения в приоритетах, принятые решения, риски и зависимости;
- аналитику нужны формулировки, данные, ссылки на источники и понимание того, какие выводы подтверждены, а какие пока остаются гипотезами;
- разработчику важны изменения требований, архитектурные решения, новые ограничения и состояние зависимых задач;
- руководителю нужен короткий обзор последствий: что изменилось, где проблема, какое решение требуется от него.
Если написать одну User Story для абстрактного «пользователя проекта», получится усреднённая механика. Она покажет руководителю слишком много деталей, аналитику — слишком мало доказательств, а разработчику сообщит, что «команда продолжает двигаться по плану».
Поэтому Persona в такой связке описывает контур участия.
Для нашего примера возьмём продакт-менеджера:
Короткая персона (не ругайтесь, это пример):
Продакт-менеджер ведёт несколько параллельных проектов, регулярно переключается между ними и отвечает за продуктовые решения. Перед встречей ему нужны изменения в приоритетах, принятые договорённости, новые риски и вопросы, которые требуют решения. Он готов потратить на восстановление контекста около десяти минут, но не готов перечитывать всю переписку. При этом ему важно иметь ссылки на первоисточники, чтобы проверить спорный вывод.
Что фиксировать в персоне:
- Роль в работе.
- Права и ограничения.
- Уровень компетенции.
- Частоту сценария.
- Риски, за которые человек отвечает.
- Критерии успеха.
- Привычные инструменты.
- Страхи и барьеры переключения.
- Отношение к автоматизации.
- То, что персона не будет делать ни при каких условиях (особенно важно в B2B).
Пользователь может быть готов получать автоматические сводки, но не готов принимать по ним решения без ссылок на первоисточники. Готов подключить таск-трекер, но не готов отдавать системе личные переписки. Готов потратить десять минут перед встречей, но не готов проходить отдельное обучение по чтению вашего инновационного дашборда.
Выбрать механику — и не влюбляться в неё заранее
Теперь у нас есть:
- ситуация;
- работа;
- уровень цели;
- приоритетная работа и данные о её значимости;
- конкретная персона.
Только здесь появляется смысл выбирать механику. Для восстановления проектного контекста можно рассмотреть несколько вариантов:
- автоматическая сводка изменений за выбранный период;
- хронологическая лента событий;
- журнал принятых решений;
- список новых рисков и блокеров;
- уведомления только о критичных изменениях;
- диалог с ассистентом по материалам проекта;
- короткий бриф, который готовит ответственный участник;
- обязательная фиксация ключевых решений в отдельном реестре;
- комбинация нескольких механик.
У каждой есть ограничения:
Хронологическая лента показывает всё подряд, но заставляет пользователя самостоятельно отделять важное от шума.
Автоматическая сводка экономит время, но может потерять нюанс или неверно определить значение сообщения.
Журнал решений хорошо работает, если команда действительно его ведёт. Обычно на этом месте где-то тихо смеётся человек, который уже пытался внедрить обязательное документирование.
Диалог с ассистентом удобен для уточнений, но пользователь должен сначала понять, какие вопросы задавать.
Уведомления помогают не выпадать из контекста, однако создают новый поток шума и слабо помогают тому, кто уже вернулся после отсутствия.
Для выбранной персоны разумной гипотезой может быть автоматическая сводка изменений, решений и рисков с обязательными ссылками на источники.
Почему именно она:
- продакт-менеджеру нужен сжатый обзор;
- времени перед встречей мало;
- важны конкретные изменения, а не вся история проекта;
- ссылки позволяют проверить спорные или критичные фрагменты;
- период можно ограничить временем отсутствия.
Это всё ещё гипотеза. Мы выбрали механику на основе контекста и ограничений, но пока не доказали, что она сработает.
Написать User Story с трассировкой
Вот теперь можно писать User Story. Не раньше.
Сперва возвращаемся к исходной Job Story:
Когда я возвращаюсь к проекту после нескольких дней отсутствия, я хочу быстро понять, что изменилось, чтобы уверенно участвовать в обсуждении и принимать решения.
Persona:
Продакт-менеджер, который ведёт несколько параллельных проектов, регулярно переключается между ними и отвечает за продуктовые решения.
Выбранная механика:
Сводка изменений, принятых решений и новых рисков за выбранный период со ссылками на источники.
User Story:
Как продакт-менеджер, который ведёт несколько проектов, я хочу получить сводку изменений, решений и рисков за выбранный период, чтобы восстановить контекст за десять минут до встречи и проверить важные выводы по первоисточникам.
Теперь в User Story есть:
- actor;
- выбранная механика;
- измеримый результат;
- временное ограничение;
- требование к проверяемости;
- связь с исходной работой.
Хорошая User Story не доказывает, что механика сработает. Она делает гипотезу достаточно конкретной, чтобы её можно было проектировать, обсуждать и проверять.
Без трассировки команда видит только задачу «сделать сводку». С трассировкой она понимает:
- откуда появилась потребность;
- для кого создаётся решение;
- почему выбрана именно эта механика;
- какой результат считается успехом;
- какие ограничения нельзя потерять по дороге.
Это уже можно обсуждать с дизайном, аналитикой, разработкой, безопасностью и кем угодно ещё. Теперь эту User Story хотя бы можно защищать аргументами, а не только уверенностью и обаянием автора.
Проверить решение на реальном сценарии
После User Story команда часто хочет сразу открыть Jira и начать раскладывать задачу по спринтам. Это понятное желание, бэклог создаёт ощущение движения. Особенно когда само движение пока не подтверждено ничем, кроме уверенности автора идеи.
Но сначала механику стоит проверить.
Для нашего примера можно собрать прототип сводки на данных нескольких реальных проектов и дать его людям, которые действительно возвращаются в контекст после перерыва. Проверять нужно не «нравится ли вам экран».
Нас интересует, выполняется ли работа:
- смог ли человек за десять минут понять ключевые изменения;
- заметил ли принятые решения;
- увидел ли новые риски;
- понял ли, какие вопросы требуют его участия;
- смог ли проверить важные выводы по ссылкам;
- пришлось ли ему после этого всё равно читать всю переписку;
- возникло ли ложное понимание из-за пропущенной или неверно интерпретированной информации.
Полезные метрики:
- время восстановления контекста;
- доля найденных ключевых изменений;
- количество пропущенных решений и рисков;
- количество дополнительных вопросов коллегам;
- доля переходов к первоисточникам;
- уверенность пользователя в понимании ситуации;
- число ошибок, возникших из-за неполного контекста.
Последняя метрика сложная и редко измеряется идеально. Но хотя бы качественно разбирать такие случаи полезнее, чем считать количество открытий сводки и радоваться растущему engagement. Пользователь может открывать экран каждый день, потому что без него стало ещё сложнее. Высокая посещаемость иногда означает любовь к продукту, а иногда — плохо организованную работу.
Минимальный рабочий процесс
Это ни в коем случае не шаблон пайплайна. Все проекты и продукты разные, команды тоже. Но если бы мне зачем-то стало нужно на абстрактном проекте превратить всё это в процесс команды, я бы собирал так:
Провести 6–8 switch-интервью
Не просто «поговорить с пользователями». Выяснить, когда привычный способ перестал справляться, что подтолкнуло человека искать решение, чего он опасался и что удерживало его в старом сценарии. Делать упор на потребности и те самые 4 силы JTBD.
Сформулировать 10–15 сырых Job Stories
Не надо сразу делать идеально. Сначала собрать материал. Хорошая формулировка рождается после нескольких проходов, а не после мозгового штурма в переговорке под литр кофе и тревожность.
Разложить Job Stories по уровням целей
Отделить желаемое состояние, действие и контролируемое последствие. Если этого не сделать, команда будет спорить о механике, хотя на самом деле ещё даже не договорилась о цели.
Проставить важность и удовлетворённость
Собрать предварительную карту важности и удовлетворённости, выделить плохо закрытые результаты и связанные с ними Job Stories. Для крупных продуктовых решений оценки стоит дополнительно подтвердить количественно.
Выбрать несколько приоритетных Job Stories
Не надо пытаться обработать весь массив пользовательских потребностей. Начните с работ, которые важны, плохо закрыты и соответствуют стратегии продукта.
Определить акторов и персон
Разобраться, кто участвует в работе, кто принимает решение, кто несёт риск и чьи ограничения влияют на механику.
Сформулировать несколько вариантов механик
Именно несколько. Первый пришедший в голову вариант обычно лучше всего отражает опыт команды, а не обязательно потребность пользователя.
Написать User Stories с трассировкой
Каждая User Story должна быть связана с Job Story, Persona и выбранной гипотезой решения. Связь должна быть понятна без участия человека, который три месяца назад всё это придумал.
Сделать story mapping и прототип
Разложить сценарий, зависимости, риски, ограничения и минимальный проверяемый контур. Не превращать User Stories в плоскую очередь задач.
Проверить, запустить и пересобрать
После релиза работа не заканчивается. Если пользовательская ситуация не изменилась, возможно, команда очень качественно реализовала не ту механику.
Что в итоге делать
Не надо выбирать между JTBD, Personas и User Stories. Надо использовать каждый инструмент на том уровне, где он действительно полезен:
- JTBD помогает понять потребность, напряжение и желаемый прогресс.
- Job Story фиксирует контекст, мотивацию и результат, сохраняя пространство решений.
- Иерархия целей помогает не смешивать желаемое состояние, действие и контролируемое последствие.
- Opportunity Landscape помогает увидеть, какие важные результаты плохо закрыты текущими решениями.
- Personas объясняют, кто действует в реальном контуре ограничений, прав и ответственности.
- User Stories переводят выбранную гипотезу в механику, которую можно проектировать, разрабатывать и проверять.
Если связка собрана правильно, команда получает трассировку:
- от ситуации к потребности;
- от потребности к приоритетной работе;
- от работы к роли и ограничениям;
- от роли к выбранной механике;
- от механики к измеримому результату.
Если связки нет, команда получает набор красивых артефактов, которые живут отдельно: персоны в презентации, Job Stories в Miro, User Stories в Jira, а пользователь перед встречей всё ещё читает триста сообщений и пытается понять, почему принятое вчера решение никто нигде не записал.
Здравый смысл не заменяет методологию. Но без здравого смысла методология обращается дорогой в обслуживании религией.
