Подход Jobs to Be Done занимает практически то же место в производственном цикле, что и процессы дизайн-мышления, но имеет радикально иную природу. Подход был популяризирован гарвардским профессором Клейтоном Кристенсеном.

…стремление узнавать все больше и больше о пользователях уводит компанию по неправильному пути. В действительности ей следует сфокусироваться на том, чего хочет достичь клиент в заданных обстоятельствах – к чему он надеется прийти. Это и есть «работа к выполнению» (Jobs to Be Done).

‹…› Когда мы покупаем продукт, то в сущности «нанимаем» его, чтобы он помог нам сделать некую работу. Если продукт хорошо себя показал, в следующий раз в тех же обстоятельствах мы будем склонны нанять этот продукт опять. Если продукт сработал некачественно, то мы «увольняем» его и ищем альтернативы{9}.

В своих статьях и выступлениях Клейтон описывает процесс потребления продукта как результат конкуренции за «наем». При этом в моделировании ситуации потребления (см. подробнее главу 6, раздел «Моделирование персон») прежде всего делается акцент на общем контексте, а не на общих характеристиках потребителей.

Несмотря на интуитивность рассуждений и чистоту примеров, долгое время было тяжело приспособить фреймворк к разработке цифровых продуктов. Роль основного двигателя в этом вопросе играла компания Intercom. Пол Адамс, популяризатор JTBD для разработки цифровых продуктов, в своей статье{10} описывает Job Story как альтернативу User Story.

Алан Клемент в своих статьях сравнивает User Story и Job Story

Место персон из User Story в шаблоне Job Story занимает жизненная ситуация (Situation); блок мотивации (Motivation) вертится вокруг найма/увольнения, а совершаемое действие заменено на ожидаемый результат (Outcome).

Обычно команда испытывает большое облегчение, когда описание функциональных требований переходит c формата сценариев использования (Use Cases) на пользовательские истории (User Story). Участники получают большую свободу и автономию – они самостоятельно ищут способы реализации, максимально эффективные с точки зрения как дизайна, так и кода. Но на практике я часто сталкиваюсь с тем, что красивая история заходит в бэклог (см. главу 4, раздел «Фактор 13») в подобном виде:

А после декомпозиции и обсуждения в команде превращается в такое:

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

Так что здесь Job Story может быть действительно более качественным пограничным объектом, чем User Story.

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

Подход Jobs to Be Done подразумевает значительную трансформацию классических дизайн-процессов в компании, но вместе с тем может дать очень конкурентоспособный результат.