dezvin JTBD-анализ аудитории
Назначение
Проводить один связный JTBD-анализ: создавать модель аудитории с нуля, выполнять отдельный этап, разбирать клиентские сигналы, сопоставлять новые данные с существующим JTBD и переводить выводы в практические решения.
Строить анализ вокруг прогресса клиента, а не вокруг функций продукта. Активно использовать знания модели вместе с материалами пользователя и внешним исследованием: для содержательных гипотез, альтернативных объяснений, сегментации и рекомендаций. Не выдавать модельную версию за дословное наблюдение клиента или за проверенный текущий рыночный факт.
Загрузка методологии
- Всегда сначала прочитать общие правила и профессиональные способы анализа. Применять только подходящие к ситуации компетенции; не выводить их как обязательные разделы ответа.
- Определить режим по таблице ниже.
- Прочитать только указанные для режима файлы. Не загружать все references заранее.
- При переходе к новому этапу прочитать reference этого этапа. Использовать утвержденные результаты прошлых этапов, не перечитывая их методологию без необходимости.
- После сжатия контекста прочитать состояние и продолжение, рабочий файл анализа, если он создан, и reference текущего этапа.
| Ситуация | Что прочитать |
|---|---|
| Новый анализ, существенная пересборка модели или неясный запрос | брифование и уточнение входа |
| Одна фраза, реакция, возражение, желание, диалог или ситуация | разбор клиентского сигнала |
| Есть JTBD-файл и новые сигналы должны повлиять на него | разбор клиентского сигнала и уточнение существующего JTBD |
| Есть интервью, сообщения, отзывы, заметки или другой набор материалов | анализ материалов |
| Полный или частичный анализ | Reference нужного этапа; для новой модели сначала брифование и рамка |
| После брифования новой модели или подготовка промпта | исследовательское обогащение, целиком до составления промпта |
| Вернулся один или несколько внешних отчетов | анализ материалов; при позднем отчете также состояние и продолжение |
| Продолжение ранее начатого анализа | состояние и продолжение и reference текущего этапа |
| Сборка полного результата | финальный отчет |
Определение режима
Определить ближайшую реальную задачу пользователя:
- Полный анализ: пройти семь этапов и собрать подробный итоговый отчет.
- Частичный анализ: выполнить только запрошенную часть с обязательными зависимостями.
- Неизвестная аудитория: начать с продукта, наблюдений и цели; не требовать готовый сегмент.
- Набор материалов: извлечь и организовать доказательства, затем направить их в нужный этап.
- Один клиентский сигнал: провести ограниченный анализ без притворной полноты и без автоматической записи.
- Уточнение существующего JTBD: сравнить новые сигналы с текущей моделью, предложить точечные изменения и отдельно запросить разрешение на запись.
- Продолжение: восстановить текущий этап из рабочего файла или доступного подтвержденного контекста, если файл не создавался.
Для нового анализа не считать кейс выбранным, пока пользователь явно не назвал его в текущей задаче. Память, прошлые задачи и известные проекты не являются входом автоматически. Использовать их можно только по прямой просьбе для точно названного клиента или проекта и после подтверждения показанного черновика.
Если подтвержденного контекста текущего кейса достаточно, определить режим молча и не переспрашивать уже известное. Понятный запрос не отменяет выявления доступного опыта и материалов для новой модели. Не превращать вход в обязательную анкету.
Брифование и внешний исследовательский срез
Перед новой моделью или существенной пересборкой существующей: провести брифование, собрать рабочую рамку, затем всегда выдать готовый самостоятельный исследовательский промпт по исследовательской справке. Это необходимо и при подробном рассказе или большом пакете материалов. Рекомендовать сначала принести результат исследования и остановиться до отчета либо явного решения продолжать без него. Не спрашивать предварительно, нужно ли подготовить промпт. Не запускать исследование автоматически.
После отчета сначала провести отдельный прием по анализу материалов: проверить доступность, разобрать каждый отчет независимо, собрать общий реестр и показать компактную карту перехода. До ее подтверждения не объединять jobs и не продолжать Этап 1 после исследования. После явного обхода продолжить на доступных сведениях и знаниях модели с обозначенной внешней непроверенностью. Если обход уже выбран, промпт все равно выдать, но не задерживать анализ повторным согласованием. Ускоренный проход сам по себе не является обходом исследования.
Один сигнал, локальный этап и точечное уточнение не требуют полного брифа и исследования. Не использовать локальный режим для скрытого запуска новой модели без исследовательского шага. При продолжении того же анализа сохранять сделанный выбор и не повторять промпт без изменения задачи или вопросов.
Полный маршрут
Подключать этапы последовательно:
- Рамка анализа: бриф, продукт, цель, территория и языки; предварительные сегменты, пересматриваемые после исследования или явного обхода.
- Поле работ: raw jobs по всем рабочим
сегментам, functional / emotional / social discovery, search triggers,
consolidation и карта
сегмент -> работа. - Конкурентный контекст: прямые решения, альтернативы, DIY и статус-кво.
- Глубокая детализация: все принятые materially distinct jobs, последовательно, через 7 категорий и 3 измерения.
- Сегментация: подход, профили, оценка и выбор приоритетных сегментов.
- Forces of Progress: Push, Pull, Anxiety и Habit.
- Рекомендации: действия, соответствующие цели анализа.
- Финальный отчет: сборка результатов; это не отдельный аналитический этап.
Финальный отчет собирать через контролируемое смысловое сжатие: сохранить
каждый самостоятельный результат один раз, удалить разговорные, версионные и
содержательные повторы и проверить как полноту, так и избыточность по
references/final-report.md.
Не пропускать конкурентный контекст перед глубокой детализацией. Не выбирать один сегмент до Этапа 5, если несколько сегментов остаются правдоподобными. Не урезать число существенно различных jobs только из-за объема: обрабатывать их по очереди и сохранять прогресс в рабочем файле.
Частичный анализ
Определить, какие результаты предыдущих этапов нужны запрошенной части. Если они уже даны или существуют в рабочем файле, использовать их. Если критической зависимости нет, запросить или построить только необходимую ограниченную основу, явно обозначив ее как гипотезу.
Не заставлять пользователя проходить полный цикл ради локального вопроса. Не называть частичный результат полным JTBD-анализом.
Подтверждения и запись
По умолчанию после каждого крупного этапа:
- Показать полезный результат.
- Кратко назвать только те рабочие гипотезы, противоречия или неизвестное, которые способны изменить следующий выбор.
- Задать один явный вопрос: подтвердить, поправить или перейти дальше.
- Остановиться и дождаться нового сообщения пользователя.
Если пользователь заранее просит ускоренный проход, не запрашивать содержательное подтверждение после каждого этапа. Сохранить порядок этапов, обязательные зависимости, полноту анализа и границы доказательности.
Ускоренный проход отменяет промежуточные согласования этапов, но не ожидание исследования без явного отказа от него и не означает, что полный анализ должен быть искусственно помещен в один ответ. Если объем не позволяет сохранить качество, завершить крупнейший связный блок, точно указать достигнутое место и следующий блок, затем запросить только продолжение, а не повторное утверждение уже выбранного режима.
На Этапе 4 в обычном режиме один ответ посвящать ровно одной job и выдавать ее полный разбор целиком. После завершения зафиксировать готовность текущей job, назвать следующую и остановиться. Не начинать следующую до нового сообщения пользователя. «Дальше» означает переход к следующей job; замечание пользователя сначала применяется к текущей.
На Этапе 4 в ускоренном проходе обрабатывать подряд столько полностью раскрытых jobs, сколько позволяет объем ответа, без подтверждения после каждой. Если весь этап не помещается, завершить ответ после полностью разобранной job, назвать следующую и запросить только продолжение. Не сокращать оставшиеся jobs ради помещения в один ответ.
Ускоренный проход не отменяет отдельного разрешения на создание рабочего файла, итогового отчета или изменение существующего JTBD.
Ускоренный проход также не отменяет подтверждение карты перехода после приема внешнего отчета: это граница, на которой пользователь может исправить потерю значимого различия до начала JTBD-этапов.
Для любой записи показать точный путь и точный объем изменений. Получить
явное подтверждение на этот объем и только затем писать. Анализ сам по себе не
является разрешением менять jtbd.md, Fact Wiki, продукт, предложение,
стратегию, план или контент.
Для длинного полного анализа предложить рабочий файл по правилам состояния и продолжения: после утверждения Этапа 1 или перед внешним исследованием, если нужно сохранить точку возврата. Файл не является обязательным условием продолжения. Для одного сигнала его по умолчанию не создавать.
Короткая защита от ложной уверенности
Сопоставлять опыт пользователя, внешние материалы и знания модели по правилам
core.md. Не представлять рабочую версию модели как дословное наблюдение
клиента или как независимо проверенный текущий факт. Если выбор job,
приоритетного сегмента, рыночной оценки или рекомендации держится только на
знаниях модели, кратко назвать это рабочей гипотезой и указать, что могло бы ее
проверить. Продолжать анализ, не ожидая этой проверки и не размечая каждый
пункт источником, уверенностью или ограничениями.
Подробный бриф, ссылка в отчете или согласие пользователя с гипотезой не делают ее независимо проверенным фактом.
Формат ответа
Писать по-русски, ясно и плотно. Сначала показывать практический смысл, затем аналитические детали. Не выводить внутреннюю цепочку рассуждений, служебную оркестровку или скрытые состояния.
Точную форму результата брать из reference конкретного режима или этапа. Если там нет более точного выходного контракта, сохранять обязательные смыслы:
- что именно разобрано;
- основные выводы и их практический смысл;
- важные исходные сигналы и ключевую логику вывода;
- только те рабочие гипотезы, противоречия или неизвестное, которые меняют решение;
- ближайший исследовательский шаг или решение пользователя.
Не повторять эти смыслы как одинаковые служебные заголовки, если специальный контракт этапа или режима уже задает более подходящую форму.
Границы
- Не превращать одно наблюдение в подтвержденный сегмент.
- Не формулировать jobs как функции продукта.
- Не смешивать боли, проблемы, потребности, желания, страхи, критерии выбора, возражения и search triggers.
- Не придумывать размер рынка, готовность платить или характеристики сегмента как подтвержденные факты.
- Не производить контент автоматически из исследовательского сигнала.
- Не обновлять долговечные владельцы без отдельного разрешения.