Предложение «сделаем приложение для записи» уже содержит решение. Но пока не объясняет, что именно должно улучшиться для человека. Возможно, ему трудно выбрать время. Возможно, он не понимает, подтверждена ли запись. Эти проблемы потребуют разных действий команды.
Что такое Jobs to Be Done
Jobs to Be Done, или JTBD, рассматривает выбор продукта через прогресс, которого человек хочет достичь в определённых обстоятельствах. Один и тот же продукт может помогать в разных задачах, а конкурирующие способы решения могут выглядеть совсем не похоже. Такое понимание подхода описывает Christensen Institute.
Для работы над проектом полезен следующий вопрос: «Что должно стать возможным для человека после нашего изменения?» Он помогает проверить, связан ли предлагаемый функционал с желаемым результатом.
Пример JTBD для записи на занятия
Ниже — учебная гипотеза, а не результат проведённых интервью. Родитель вечером выбирает занятие ребёнку. Клуб уже закрылся, администратор ответит завтра, а решение нужно принять сегодня, пока семья обсуждает расписание.
| Часть разбора | Учебный пример |
|---|---|
| Обстоятельства | Вечером нужно согласовать занятие с семейным расписанием; клуб уже закрыт |
| Желаемый прогресс | Выбрать подходящее время и получить уверенность, что место закреплено |
| Текущие способы | Написать администратору, позвонить завтра, поискать другой клуб |
| Препятствие | Неясно, осталось ли место и нужно ли ждать подтверждения |
| Гипотеза решения | Показать актуальные места и дать понятное подтверждение записи |
В такой ситуации большое приложение с личным кабинетом может оказаться избыточным первым шагом. Для проверки гипотезы достаточно более узкого сценария. Но если выяснится, что основная трудность — выбрать подходящую группу по уровню, одна автоматическая запись вопрос не решит.
Как сформулировать JTBD
Для рабочего черновика удобно разделить обстоятельство, действие и желаемое следствие. Это вспомогательная форма записи: она помогает обсуждению, но сама по себе не подтверждает, что потребность существует.
Рабочая формулировка
Когда вечером мы выбираем занятие на следующую неделю, я хочу сразу узнать свободное время и подтвердить место, чтобы согласовать семейные планы без ожидания ответа администратора.
Слабая формулировка — «хочу приложение, чтобы пользоваться приложением». В ней нет причины выбора. Проверьте себя: сможет ли человек добиться того же результата другим способом? Если да, вы начали описывать его задачу, а не только свою функцию.
Какие вопросы задать перед разработкой
- Вспомните последнюю реальную запись: что происходило в тот день?
- Почему вы решили заняться этим именно тогда?
- Как вы действовали и какие варианты рассматривали?
- Где пришлось ждать, уточнять или менять решение?
- По чему вы поняли, что всё получилось?
Просьба рассказать конкретный случай полезнее вопроса «вам было бы удобно наше приложение?». В ответе ищите последовательность действий и обстоятельства выбора. Если разные люди рассказывают разные истории, не объединяйте их автоматически в одну потребность.
Как превратить гипотезу в проект
Разделите желаемый результат пользователя и работу команды. В нашем примере пользователю нужна уверенность в записи. Команде нужно обеспечить актуальность мест, обработку заявки и понятное подтверждение. Это связанные, но разные уровни описания.
- Выберите проверку. Например, предложите узкий сценарий одной группе посетителей.
- Согласуйте признак результата. Сможет ли человек записаться и правильно понять статус без дополнительного обращения?
- Назначьте ответственного за наблюдение. Кто соберёт затруднения и проверит, что происходит после отправки формы?
- Запланируйте решение по итогам. Продолжать, менять сценарий или отказаться от гипотезы.
Здесь пригодятся метрики проекта и понятная постановка задачи. Они связывают исходную идею с тем, что команда действительно будет проверять.
Как JTBD сочетается с выталкивающими таблицами
JTBD помогает уточнить, ради какого изменения стоит работать. Выталкивающие таблицы из книги помогают организовать движение к выбранному результату. В месячном плане можно зафиксировать проверку пользовательского сценария, в недельном — подготовку и запуск проверки, в дневном — конкретные действия участников.
После обратной связи связка работает в обратную сторону: новые наблюдения меняют решение, а решение — ближайший план. Подробнее об этой механике — в разборе выталкивающих таблиц.
У команды появились понятная гипотеза о задаче пользователя, способ её проверить и следующий шаг. Красиво заполненная формулировка без проверки остаётся предположением.