Заключительная часть о том, как концепция Jobs-to-be-Done меняет принципы создания и улучшения IT-продукта. Третья часть перевода книги «Intercom про Jobs-to-be-Done». Главы с седьмой по девятую.

Первая часть ^[1]
Вторая часть ^[2]

Глава 7. Отказываясь от персон: история о Job stories

Автор: Paul Adams

Мы в Intercom постоянно переосмысливаем внутренние процессы, чтобы создать выдающийся продукт. Поэтому задаемся вопросом: как выстроить процесс создания продукта, чтобы люди считали его ценным и удобным, а также любили его. Основное внимание мы акцентировали на исследованиях, для чего нанимали людей, обладающих исследовательским опытом. При этом каждый член продуктовой команды лично общается с клиентами: менеджеры продукта, дизайнеры и конечно исследователи. Мы также наняли директора по исследованиям, и сделали это намного раньше, чем делают большинство других стартапов. Им стал Sian Townsend, глава команды исследований Google Maps.

Очевидно, что общаться с клиентами надо регулярно, чтобы понимать их самих и их нужды. При этом совершенно не очевидно, какой инструмент для этого подходит. Мы постоянно думали об идеях из первых принципов ^[3] и довольно рано применили их к процессу общения с клиентами.

Мы были большими фанатами Jobs-to-be-Done, но все написанное было применено в основном к молочным коктейлям и шоколадным батончикам. Существовало только одно небольшое исследование, касающееся использования Jobs-to-be-Done для разработки ПО. Так мы создали наш собственный процесс на основе того, что уже знали.

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

Работая в Googlе, я создал сотни, если не тысячи персон для множества проектов. Мы тщательно следовали методу Купера, но в итоге я пришел к выводу об ограниченной ценности персон. Они обычно помогают почувствовать эмпатию далёким от общения с пользователями сотрудникам, но редко ведут к прорывным идеям или свежему взгляду на проблему.

И мы в Intercom больше никогда не использовали персоны.

Ценность персон я впервые поставил под сомнение, когда перешел из Google в Facebook. Там накопили невероятный объём информации о том, как самом деле пользователи взаимодействуют с их продуктом. А общение с дата-саентистами не переставало учить новому.

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

К примеру, мотивы у матери троих детей из США, публикующей фотографии с семейного пикника, в основном такие же, как у корейского подростка, постящего фотки с вчерашней вписки. Цели и детали могут быть абсолютно разными, но мотивация одна. Персоны никогда не приведут к созданию одного и того же продукта для совершенно разных аудиторий. Лучшие в своём роде персоны фокусируются на достижениях, «что движет поведением людей», и на атрибутах. Но на практике большинство персон фокусируются только на атрибутах.

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

Проектирование от мотивации намного лучше проектирования от атрибутов. Это ключевое различие персон от Jobs-to-be-Done. Персоны — про роли и атрибуты, а Jobs-to-be-Done — про ситуации и мотивации. Персоны объясняют, что это за люди, какие они и что делают, но никогда полностью не объясняют, почему люди делают что-либо, хотя это намного важнее.

Так в середине 2013 г. в Intercom мы поняли, что ищем инструмент, который помог бы раскрыть причины, почему клиенты что-либо делают. Мы еженедельно говорили с множеством клиентов, а наша служба поддержки клиентов общалась ещё чаще, создавая тикеты на разработку с учётом проблем и ограничений нашего продукта. Такую прямую связь с клиентами невозможно переоценить, но было два вызова, которые нам предстояло преодолеть:

1. Люди разбираются в своих проблемах, но не в решении. При этом для них более естественно предложить решение в виде запроса на разработку фичи. Описать предлагаемое решение намного легче, чем проблему. Из-за этого приходится возвращаться к клиентам, чтобы задать вопросы и по-настоящему понять их проблему.
2. Отвечая, люди первоначально рассказывают о том, что хотят, на языке атрибутов, но не называют причину, почему это важно для них. Поэтому вам приходится продолжать копать вглубь понимания их мотивации. Главное понять, какую проблему клиенты на самом деле пытаются решить и почему нуждаются в её решении.

Когда проблема клиента уже ясна, как превратить эти инсайты во что-то осязаемое для команды дизайна? Во что-то лаконичное, что легко обсуждать и запоминать. Я не припомню количество всех случаев во время моей работы в Google, когда мы привлекали коллег к исследованиям и к совместному созданию персон, чтобы потом не использовать их. Всё потому, что персоны сложно запомнить, они слишком детализированные, чтобы легко разобраться в них. Персоны недостаточно лаконичны для быстрых продуктовых команд.

Кроме персон существует другой популярный инструмент — User stories, продвигаемый Agile-сообществом. Мы никогда не использовали User stories, потому что эмпирически они не кажутся обусловленными исследованиями. Они инженерные, и уж точно не обусловлены клиентом. Они созданы для того, чтобы описывать функциональность, а не мотивацию, которой люди обладают.

После размышлений над этой проблемой и отталкиваясь от первых принципов, мы изобрели Job stories. Тогда этот артефакт не имел названия. А позже Alan Klement придумал название для нас. Но процесс был готов и прекрасно нам подходил. Мы впервые опробовали Job stories, сокрушаясь в посте блога о «дриббблизации ^[4]» дизайна. Мы долго и упорно думали о Jobs-to-be-Done, и это вылилось в создание нашего собственного процесса, сфокусированного на ситуациях, мотивациях и результатах:

[Когда ______] [я хочу ______] [то могу ______]

«Когда…» — про ситуацию, «я хочу…» — о мотивации, «то могу…» — про результат. Если мы понимаем ситуацию, при которой люди встречают проблему, мотивацию, заставляющую её решить, и как выглядит конечный результат, то имеем возможность сделать ценный продукт для наших клиентов.

Job stories — теперь наш главный инструмент, гарантирующий обусловленность исследованием, понятность проблемы и представленность в лаконичном виде. Это значит, что наш результат исследования проблемы подходит и для дизайнерской, и для инженерной команды.

Перед тем, как начать любой проект, мы в Intercom создаём очень простой одностраничный бриф, который можно скачать ^[5]. Он очень простой и должен занимать 1 страницу А4. Он включает раздел Job stories, помогающий нам не забывать о проблеме и возможностях, за которые беремся, а также дает возможность быть сфокусированными на протяжении всего проекта.

Персоны определённо имеют место быть. Я считаю их полезными для получения поддержки в политической игре, когда люди только на словах решают реальные потребности клиентов. Персоны также могут создать более сильные связи с текущими пользователями продукта. Но сделать их хорошо — трудоёмкий процесс. Персоны зациклены на различиях между людьми и сложны для запоминания и отсылки к ним. Оказывается, многие люди с различающимися атрибутами имеют очень схожую мотивацию. Её легко понять, как и то, что все, что вы пытаетесь запилить, можно объяснить в серии коротких запоминающихся предложений. Если это не убеждает вас, то вспомните, что персоны искусственно уменьшают размер рынка вашего продукта. Вот почему мы топим за Job stories.

Глава 8. Дизайн фичей с помощью Job stories

Автор: Alan Klement

Когда Дес попросил меня написать для блога «Внутри Intercom», я просто презентовал Jobs-to-be-Done моим партнёрам из Aim, рекламного маркетплейса для недвижимости.

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

А потом меня осенило. Без какой-либо отсылки к Jobs-to-be-Done я стал обращать внимание на наиболее успешные предложения, сделанные кофаундерами. Я рассказал о том, с чем наши клиенты мучаются, и описал, насколько их жизнь будет лучше, когда мы это исправим. Затем показал, чем их предложения хороши для конкретной дизайнерской задачи. В результате я описал работу, которую необходимо выполнить клиенту, и результат, когда работа сделана.

Используя язык Jobs-to-be-Done для коммуникаций, мы смогли утвердить наш первый дизайн всего за несколько минут. Назад пути уже не было.

***

Персоны и User stories имеют место быть, когда клиенты и продуктовые команды очень далеки друг от друга. Но это больше не проблема.

Традиционно ответ на вопросы «Кто является нашим клиентом?» и «Что клиентам нужно?» лежит на маркетинге, бизнес-департаменте или даже на отделе продаж. Когда информация собрана, её следует сформировать в понятный всем формат, а затем забросить в команду продуктовой разработки.

Во время этого водопадного процесса приносятся в жертву нюансы, необходимые для создания хороших продуктов: причины, тревоги и мотивации. Jobs-to-be-Done — это философия фокусирования на этих нюансах. Чтобы донести эту концепцию до конечного продукта, во время дизайна фичей, UI и UX следует использовать Job stories.

Провал персон

Как Дес говорил ранее, персоны обычно определяются через атрибуты, которые не имеют отношения к причинно-следственным связям. К примеру, пол какого-то человека, его возраст, раса и предпочтения на выходные не объясняют, почему он любит Сникерс. Но ситуация, в которой есть только 30 секунд на покупку и употребления в пищу чего-нибудь для утоления голода на следующие 30 минут, всё объясняет.

Провал User stories

«Я как пользователь могу пометить папки так, чтобы они не бэкапились, поэтому мой резервный диск не будет заполнен тем, что не нужно». У этой User story три большие проблемы:

1. Используются персоны.
2. Реализация объединяет мотивацию и ожидания.
3. Игнорируется контекст, обстановка и страхи.

Фичи часто не удаются. Если фича была определена с помощью User story, понять, почему она провалилась, будет непросто. Так случается, когда в решении были объединены мотивация и ожидания. Из-за этого объединения невозможно понять, что именно было ошибочным — проблема в реализации или в предположении о мотивации.

Введение в Job stories

Job stories, впервые упомянутые Полом Адамсом в блоге Intercom-а ^[6] и разработанные здесь ^[7], — это совершенно другой подход к разработке фичей. Но как командам внедрить их в свой рабочий процесс?

Вот один из подходов:

1. Начинаем с высокоуровневой работы.
2. Определяем более мелкие работы, помогающие выполнять высокоуровневую работу.
3. Наблюдаем, как люди решают проблему сейчас. Это работа, которую они выполняют.
4. Используем Job story для определения причинно-следственных связей, тревог и мотивации того, что люди делают сейчас.
5. Создаём решение, которое решает эту Job story.

Для примера рассмотрим процесс проектирования продуктовой командой профиля продавца в рамках продукта, помогающего продавцам автомобилей оформить клиентам кредит.

Дизайн профиля

На раннем этапе создания дизайна команда обсуждает, как должен выглядеть профиль пользователя и какими фичами он должен быть наполнен. Для начала Сара, член команды, встаёт и рисует простой макет на доске. Указывая на него, она говорит: «Это профиль продавца».

Команда не впечатлена её решением. Задаётся серия вопросов «почему» про каждую часть макета. Даже после всех этих вопросов команда не принимает и не отвергает эту идею. Вот эти вопросы: «Зачем продукту этот профиль?», «Почему профиль должен находиться здесь, а не в другом месте?», «Какую информацию он должен показывать?», «В каких ситуациях он полезен?», «Какую работу выполняет этот профиль?»

Чтобы ответить на эти вопросы, описание фичи было переоформлено с помощью Job story.

Начинаем с высокоуровневой работы

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

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

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

Используем Job story, чтобы определить причинно-следственные связи, тревоги и мотивации того, что люди делают сейчас:

1. Когда продавцы машин и их клиенты взаимодействуют посредством продукта…
2. … клиенты хотят доверять компании, процессу и продавцу.
3. Продавцы хотят быть уверенными, что процесс комфортный для клиента…
4. …и он может в безопасности вводить свою финансовую информацию.

Это написано на языке Job story. Можно конкретизировать, добавив больше ситуационного контекста: когда и где всё это заполняется, дома или в дилерском центре. А также страхи каждой из сторон, связанные с профилем и его заполнением.

Создаём решение, которое выполняет эту Job story

Команда решает, какой дизайн у профиля должен быть, чтобы клиент выполнил свою работу. Отображение слишком малого объёма информации в профиле не решит изначальную работу, а большой её массив может привести к негативным последствиям. В итоге команда решает:

1. Во время использования продукта профиль продавца будет постоянно виден на экране, чтобы покупатель не испытывал страха по поводу того, что находится не рядом с продавцом.
2. В профиле должна быть фотография продавца, его должность, количество проданных автомобилей и стаж работы в компании, чтобы не возникало сомнений в надежности продавца и его опыте.
3. В профиле должны быть указаны способы связи с продавцом: номер телефона, e-mail и кнопка «задайте вопрос», чтобы клиент не опасался, что может заполнить форму неправильно.

Вот пример решения:

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

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

Обоснованный дизайн для людей
Создание успешных продуктов означает наблюдение за реальными людьми, решающими свои проблемы, исследование контекста ситуации, в которой они оказались, и понимание причинно-следственных связей, страхов и мотивации.

Абстрактные атрибуты, объединение реализации с мотивацией и ожиданиями сводит команды с ума. Если команда копает глубоко и изучает работу клиента, то создает решения более эффективно. Job stories лучше всего подходят для дизайна продукта.

Глава 9. Спрашивать «почему» — правильно

Автор: Dan Ritzenthaler

Пока я не проникся Jobs-to-be-Done, то с трудом определял корневую проблему так, чтобы она сводилась к простому утверждению. Как я могу просто и ясно выразить её перед членами команды? Нужно рассматривать проблему под разными углами для лучшего её понимания. И задавать вопрос «Почему?» — один из лучших способов погрузиться глубже в то, что клиенты пытаются сделать.

Существует много абстрактных советов и исследований относительно способов раскрытия причинно-следственных связей. Например, техника «Пять почему». В данной главе расскажем о стремлении к золотой середине, о том, как двигаться вглубь сквозь уровни разговора, но не слишком быстро, чтобы не потерять ценные инсайты. Главное — находить уникальные инсайты на каждом уровне «почему» перед тем, как двигаться дальше.

***

Я не смогу перестать задавать вопрос «почему?» на каждое ваше заявление, а затем… я опять спрошу «почему?». Это профессиональная деформация.

Вот, к примеру, вы купили электродрель. Почему? Да потому что хотите повесить пару фотографий в рамке. А почему вы хотите повесить фотографии? Наверное, чтобы сделать свой дом более обжитым. А почему это важно для вас?

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

Это особенно актуально для интервью с клиентами. Не спешите, и посвятите время каждому уровню «почему?», проверяя множество разных идей. Тогда проведённое с клиентом время станет более продуктивным — полученные инсайты будут гораздо интереснее и полезнее.

Продуктивные уровни разговора

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

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

1. Во-первых, уровень пользы: что вы непосредственно делаете с вещью? Я использую дрель, чтобы сверлить дырки.
2. Во-вторых, уровень удобства: какой результат вы получаете? Я сделал дырки, чтобы повесить фотографии.
3. В-третьих, уровень желаний: что изменилось, когда я завершил мою работу? Я повесил фотографии и теперь у меня более обжитой дом.

Сказанное вне этих трёх уровней трудно отнести к продукту. К примеру, спрашивая: «Почему вы хотите более обжитой дом?», вы вряд ли получите важные для производителей дрелей ответы.

Но в любом случае вы узнаете о персоне больше, а также о том, что ею движет — это всегда полезно. Но для меня это слишком не конкретно, и редко когда может быть применено незамедлительно.

Уровень пользы

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

Где должны быть просверлены дырки? В бетоне? В дереве? В металле? Какого размера они должны быть: это должны быть узенькие дырочки для маленьких винтиков или широкие дыры для больших болтов?

Каким образом это может поменять свойства дрели? Другая мощность, крутящий момент, скорость? Может, выбор скоростей? Или разные размеры дрели? А, быть может, наличие съёмных свёрел?

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

Уровень удобства

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

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

Как это поменяло бы свойства дрели? Может, понадобились бы маленькие батарейки, так как она не часто используется? Или, возможно, нужен меньший мотор и корпус для снижения веса? Должно ли быть больше предустановок для домашних стен, чтобы уменьшить тревожность?

Эти вопросы раскрывают возможности дрели и способы сделать её более удобной. Но, к сожалению, они не раскрывают методов сделать дрель более привлекательной.

Уровень желания

Следующий уровень использования дрели — сделать ваш дом более уютным. Если результатом использования дрели становится более обжитой дом, вы можете углубиться, и узнать, как сделать дрель более привлекательной.

Насколько важно, чтобы дрель была готова к использованию, когда вы приходите домой с новой картиной в рамке? Куда вы кладёте дрель, когда завершаете работу? Находится ли она у всех на виду?

Как это меняет свойства дрели? Нужна ли док-станция, чтобы было легко убрать её? Или она должна висеть на стене, чтобы быть всегда наготове? Должна ли дрель иметь привлекательный внешний вид, когда лежит на столе или на полке?

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

Не торопитесь

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

Заключение

Изначально мы в Intercom сделали большую ставку на Jobs-to-be-Done как на средство информирования о нашей продуктовой стратегии. А позже использовали его для выхода на рынок. Пять лет спустя эта концепция всё ещё находится в основе нашей продуктовой и маркетинговой стратегии. Мы построили всю компанию вокруг идеи, заключающейся в том, что люди сталкиваются с проблемами в жизни или работе, а для их решения покупают продукты.

Я не знаю ни одного направления нашего бизнеса, которое не изменил бы Jobs-to-be-Done. Продукт, маркетинг, продажи и поддержка сильно выиграли от концентрации на этой концепции. Изначально мы принимали решения на основе интуиции о разных причинах, по которым люди должны купить Intercom, но примерно через год провели исчерпывающее исследование о работах наших клиентов.

Это исследование проводится так же легко, как и беседа с клиентом, успешно прошедшим онбординг вашего продукта. Если интересно, как вам обратиться к определённым пользователям, вам поможет Intercom ^[8]. Когда вы решите собирать фидбек, не забудьте сфокусировать вашу компанию на решении реальных потребностей клиентов.

Наше единение с Jobs-to-be-Done всё ещё эволюционирует. Данная книга — это начало, коллекция лучших на данный момент наших размышлений над теорией. С ростом нашей компании и расширением потребностей клиентов, мышление ^[9] тоже развивается. В течение пяти лет мы бы хотели написать несколько книг, в которых будут содержаться советы и мнения.

Если у вас имеется похожий опыт использования стратегий из книги, я был бы счастлив узнать об этом. Напишите мне на des@intercom.com

Спасибо, что прочитали.

Автор: Александр Иванов

Источник ^[10]