Контекст решает всё. JTBD для аналитикаПосле того как написала здесь об артефактах в эпоху ИИ и важности фиксации контекста, я поймала себя на мысли: а как мы вообще описываем контекст, в котором эти артефакты рождаются?
Перерыла стандарты, заглянула в старые конспекты с курсов по CX и собрался список подходов, которые стоит разобрать. Первым в очереди оказался метод Jobs To Be Done. О нём и расскажу.
JTBD - не новая наработка, это обобщение практик, которое давно рассматривается в маркетинге. В ИТ-индустрии этот термин чаще звучит в управлении продуктом, но с точки зрения анализа и описания контекста есть вещи, которые важно понимать и аналитику.
Сначала о контексте. BABOK определяет контекст так: “Обстоятельства и условия, которые влияют на изменение, которые находятся под влиянием изменения, или которые способствуют пониманию изменения.“ Дальше в стандарте большое перечисление факторов, включая настроение человека и демографию. Но здесь есть нюанс. Могут ли внутренние поиски человека рассматриваться как контекст? Всегда ли именно демография (пол, возраст, местность) исчерпывающе говорит о поведении людей?
JTBD говорит, что люди выбирают решения не обязательно из-за своего пола или возраста, а из-за того, какую задачу им нужно решить. И настроение человека, безусловно, влияет на то как он принимает решения, но как однозначную характеристику его сложно определить и измерить - например, выбрать всех, кому грустно. Поэтому JTBD опирается прежде всего на ситуацию, а контекст чаще описывается внешними обстоятельствами. Петя съел бургер не потому, что ему 30 лет, а потому что это удобный способ перекусить на бегу между встречами.
Работа в JTBD - это изменение к лучшему, на которое человек рассчитывает в определённых обстоятельствах. Формулировка “Играть в приставку по вечерам” - это не описание работы во всех смыслах, потому что мы не видим обстоятельств и изменений 😊 “Внедрить выбор из списка”, “Настроить топик” - тоже не говорит о контексте и работе. Чтобы задать работу нужно определить обстоятельства и ожидаемые улучшения.
Важно, что при формулировке работы отсутствует решение. Работа описывается достаточно абстрактно, чтобы на неё можно было нанять разные продукты. Есть известное высказывание Клейтона М. Кристенсена: «Людям не нужна дрель на четверть дюйма. Им нужно отверстие такого же размера.» Здесь мне вспоминается самый частый сценарий в работе аналитика: заказчик приходит с готовым решением, со временем это решение может оказаться неработающим или не масштабируемым, потому что контекст потерян или определён ошибочно. Метод JTBD как раз предлагает сместить фокус с функции на задачу в конкретных обстоятельствах.
Что не так в User Story? Классическая постановка через «я как пользователь хочу…» фокусируется на том, кто просит. Это не ответ на вопрос «почему и в какой момент». По сути не так важно анализирует ли вашу постановку ИИ-агент или коллега - без этого знания он не сможет предложить релевантные варианты или оценить, подходит ли предложенное решение.
User Story: «Как менеджер, я хочу видеть статусы заявок, чтобы контролировать процесс».
Job Story: «Когда я получаю неожиданный вопрос от руководителя о статусе проекта, я хочу собрать сводку по заявкам за 10 секунд, чтобы ответить уверенно, не перерывая чаты и почту».
Во втором случае мы видим человека в конкретной ситуации - он отвечает на внезапный вопрос, у него нет времени, ему нужна мгновенная сводка. Именно это определяет, какой интерфейс ему нужен.
Какие вопросы задать для хорошей job story? Как это работает?Чтобы описать контекст задачи и передать его другим (включая ИИ), можно задать вопросы для выяснения ситуации и социальной, эмоциональной, функциональной ценности изменений.
📍Когда возникает потребность? Что триггерит задачу?
📍Какую именно задачу пользователь пытается решить сейчас (не функционально, а в целом)?
📍Есть ли существующее решение или обходной путь? Почему оно не устраивает?
📍Что удерживает пользователя от перехода на новое решение? Страх риска, привычка, непонятная выгода?
Результат применения JTBD - Job Story, короткое описание, которое можно использовать как основу для требований. Формат такого описания обычно выглядит так:
Когда [ситуация], я хочу [мотивация/цель], чтобы получить [ожидаемый результат].
Например:
Когда в команду приходит новый аналитик,
я хочу дать ему не 50-страничный регламент, а короткую памятку с ответами на самые частые вопросы и схемой основных процессов,
чтобы он начал работать самостоятельно уже на второй день.
Если такая информация предназначена ИИ можно добавить к этому описанию ещё ограничения и допущения, чтобы получить более достоверный ответ. Например: «Я предполагаю, что данные всегда доступны, но бывают задержки синхронизации”
Что почитать:-
Что такое Jobs to Be Done (JTBD): как понять, какой продукт нужен клиенту -
Jobs To Be Done концепция - как привлечь новых пользователей -
Заменяем User Story на Job Story #инструменты
