Написала здесь об артефактах в эпоху ИИ и важности фиксации контекста и поймала себя на мысли: а как мы вообще описываем контекст, в котором эти артефакты рождаются? Первым в очереди оказался метод Jobs To Be Done. О нём и расскажу.

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

Сначала о контексте. BABOK определяет контекст так: “Обстоятельства и условия, которые влияют на изменение, которые находятся под влиянием изменения, или которые способствуют пониманию изменения.“ Дальше в стандарте большое перечисление факторов, включая настроение человека и демографию. Здесь есть нюанс. Могут ли внутренние поиски человека рассматриваться как контекст? Всегда ли именно демография (пол, возраст, местность) исчерпывающе говорит о поведении людей?

JTBD говорит, что люди выбирают решения не обязательно из-за своего пола или возраста, а из-за того, какую задачу им нужно решить. И настроение человека, безусловно, влияет на то как он принимает решения, но как однозначную характеристику его сложно определить и измерить - например, выбрать всех, кому грустно. Поэтому JTBD опирается на ситуацию, а контекст чаще описывается внешними обстоятельствами. Петя съел бургер не потому, что ему 30 лет, а потому что это удобный способ перекусить на бегу между встречами.

Работа в JTBD - это изменение к лучшему, на которое человек рассчитывает в определенных обстоятельствах. Формулировка “Играть в приставку по вечерам” - это не описание работы во всех смыслах (смайл), потому что мы не видим обстоятельств и изменений. Чтобы задать работу нужно определить обстоятельства и ожидаемые улучшения. Важно, что при формулировке работы отсутствует решение. Работа описывается достаточно абстрактно, чтобы на нее можно было нанять разные продукты. Есть известное высказывание Клейтона М. Кристенсена: «Людям не нужна дрель на четверть дюйма. Им нужно отверстие такого же размера.» Здесь вспоминается самый частый сценарий в работе аналитика: заказчик приходит с готовым решением, со временем это решение может оказаться неработающим, потому что контекст потерян или определен ошибочно. Метод JTBD предлагает сместить фокус с функции на задачу в конкретных обстоятельствах.

Что не так в User Story? Классическая постановка через «я как пользователь хочу…» фокусируется на том, кто просит. Это не ответ на вопрос «почему и в какой момент». Анализирует ли вашу постановку ИИ-агент или коллега - без этого знания он не сможет предложить релевантные варианты или оценить, подходит ли предложенное решение.

User Story: «Как менеджер, я хочу видеть статусы заявок, чтобы контролировать процесс» Job Story: «Когда я получаю неожиданный вопрос от руководителя о статусе проекта, я хочу собрать сводку по заявкам за 10 секунд, чтобы ответить уверенно, не перерывая чаты и почту»

Во втором случае видим ситуацию - человек отвечает на внезапный вопрос, у него нет времени, ему нужна мгновенная сводка. Именно это определяет, какой интерфейс ему нужен.

Как это работает? Чтобы описать контекст задачи и передать его другим (включая ИИ), можно задать вопросы для выяснения ситуации и социальной, эмоциональной, функциональной ценности изменений. - Что триггерит задачу? - Какую именно задачу пользователь пытается решить сейчас (не функционально, а в целом)? - Есть ли существующее решение или обходной путь? Почему оно не устраивает? - Что удерживает от перехода на новое решение? Страх риска, привычка?

Результат применения JTBD - Job Story, короткое описание, которое можно использовать как основу для требований. Формат обычно выглядит так:

Когда [ситуация], я хочу [мотивация/цель], чтобы получить [ожидаемый результат]

Пример: Когда в команду приходит новый аналитик, я хочу дать ему не 50-страничный регламент, а короткую памятку с ответами на самые частые вопросы и схемой основных процессов, чтобы он начал работать самостоятельно уже на второй день. Если такая информация предназначена ИИ можно добавить ограничения и допущения для более достоверного ответа.