Метод Jobs to Be Done. Проектирование клиентоориентированного продукта

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

Главный элемент методологии – приложение усилия к отдельным единицам работы. Истории пользователей – короткие описания характеристик и функционала, написанные с точки зрения конечного пользователя. Это позволяет командам сосредоточиться на маленькой части целого и контролируемо продвигаться вперед.

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

Хотя в конкретных случаях детали и стиль могут отличаться, типичная история пользователя похожа на следующий текст:

В качестве [роль] я могу [возможность], так что [выгода].

Примеры историй пользователей в этом формате:

• Как системный администратор я могу определить файлы и папки для резервного копирования, основываясь на их размере, дате создания и дате изменения.

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

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

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

Истории работы

Хотя истории пользователей годятся для разбивания работы на части, обычно они не могут связать создаваемое решение с потребностями пользователя. В них не хватает указания, почему некто ведет себя определенным образом и что ему нужно, чтобы выполнить работу. На самом деле истории пользователей проистекают из создания функциональной возможности, а не из наблюдения за реальным поведением.

Альтернатива историям пользователей – истории работы. Они следуют традиции разделения усилий на небольшие части, но делают это сквозь призму JTBD.

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

Пол Адамс, менеджер по продукту в Intercom, писал о первом применении историй работы так: «Мы оформили каждую задачу проектирования как работу, сосредоточившись на инициирующем событии или ситуации, мотивации, цели и желаемом результате»[36].

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

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

Примеры историй работы:

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

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

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

Автор и лидирующий специалист по JTBD Алан Клемент сделал бо́льшую часть работы по оттачиванию формата историй[37]. Он считает, что добавление подробностей об обстоятельствах лучше показывает причинно-следственную связь. Сосредоточенность на контексте переключает внимание с человека на ситуацию. Клемент советует избегать описания неопределенных ситуаций, но, насколько это возможно, придерживаться конкретики.

Например, рассмотрим три возможные ситуации в качестве первого элемента истории работы:

• Когда я голоден…

• Когда я заблудился…

• Когда я хочу проверить электронную почту…

Вместо этого Клемент рекомендует более детально описывать обстоятельства.

• Когда я голоден и при этом куда-то опаздываю, не уверен, когда мне удастся поесть в следующий раз, и беспокоюсь, что скоро потеряю силы и начну раздражаться из-за голода…

• Когда я заблудился в городе, где никогда раньше не бывал, не знаю местного языка и беспокоюсь, что потеряю время там, где не хочу находиться…