1. Создание дорожной карты проекта
Используйте JTBD, чтобы направить задачи в дорожной карте продукта и удостовериться – ваша деятельность связана с потребностями клиента. Дорожная карта не должна спускаться с высокого уровня абстракции с неопределенными датами выполнения каждого этапа, чтобы давать направление работы, не касаясь конкретных дат.
• Определить путь развития решения.
• Определить потребности клиента.
• Установить сроки и последовательности.
• Объединить усилия по разработке и дорожную карту.
От средней до высокой. Создание первоначальной структуры и средств распространения вначале потребует некоторых усилий. Но после этого расширение дорожной карты займет всего несколько часов. Такая карта обычно включает входные данные, полученные от ряда заинтересованных лиц – от ключевых лиц, принимающих решения, до команд, которые займутся внедрением предложения. Согласование всей информации отнимает время и силы.
Дорожные карты часто путают с подробными планами проектов, где определены сроки выполнения работ. Вместо этого считайте дорожную карту наброском, фиксирующим последовательность действий. Также не забывайте, что дорожные карты меняются. Вы захотите обновлять их примерно раз в квартал.
Сделайте черновик дорожной карты разработки вашего решения в следующем квартале. Посмотрите, сколько вы успеете за час или два. Используйте систему JTBD, чтобы связать темы дорожной карты с последовательностью действий.
• C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (Sebastopol, CA: O’Reilly, 2017).
2. Связать команды с историями работы
Истории работы дают стандартный формат, чтобы представить более мелкие работы, которые нужно сделать. Вычлените их из карты работы и JTBD-интервью. Поскольку истории содержат информацию об обстоятельствах выполнения работы и ее этапах, они могут существовать сами по себе, давая командам возможность воспользоваться ими при необходимости. В то же время истории работы дают уверенность, что характеристики и функции продукта основаны на удовлетворении потребности.
• Понять этапы работы и сопутствующие обстоятельства.
• Сформулировать истории работы.
• Раскрыть истории работы.
Низкая. Закончив исследование JTBD, создав карту работы и имея дорожную карту продукта, сгенерировать набор историй работы достаточно просто.
Истории работы могут иметь самые разные форматы, их применение также обычно различается. Главное – разработать постоянный формат, подходящий к вашей ситуации. Слово «история» подразумевает, что истории работы способны заменить истории пользователей в гибкой методологии разработки. Но в большинстве ситуаций этого не происходит: при гибкой разработке по-прежнему приходится измерять сгорание задач, используя традиционные истории пользователей.
Рассмотрите работы, которые нужно сделать, в связи с конкретными усилиями, которые вы предпринимаете в данный момент. Сформулируйте 6–12 историй в одном формате, основываясь на данных исследований. Поделитесь этими историями для обсуждения. Затем сделайте их заметными на собраниях, семинарах и дизайн-сессиях, чтобы связать свою деятельность с потребностями клиентов.
• Alan Klement, Replacing the User Story with the Job Story, JTBD.info (блог), 12 ноября 2013 года; 5 Tips for Writing a Job Story, JTBD.info (блог), 12 ноября 2013 года; Designing Features Using Job Stories, Inside Intercom (блог).
• Maxim van de Keuken, Using Job Stories and Jobs-to-be-Done in Software Requirements Engineering, (диссертация, Утрехтский университет, 2017).
3. Разработать структуру решения
В разработке программного обеспечения структура решения, будь то продукт или услуга, может рассматриваться независимо от пользовательского интерфейса. Вам нужно сделать основой макета решения работы, которую нужно сделать. Тогда ваше предложение просуществует дольше и получит больше шансов на принятие клиентами. Существует несколько связанных методов, показывающих, как это сделать в различных ситуациях. Один из них – дизайн пользовательской среды (User Environment Design, UED).
• Понять пользователей и их работу.
• Определить области фокусировки.
• Смоделировать структуру решения.
От средней до высокой. Создание концептуальных моделей структуры решения состоит из нескольких циклов и должно обновляться с течением времени. Чем сложнее решение, тем труднее эта задача. Моделирование обширного программного обеспечения или веб-сайтов может занять несколько недель исследований и потребовать разработки в последующих процессах, к примеру в UED.
Моделирование структуры решения – это абстрактная деятельность. Иногда его путают с технической архитектурой, с одной стороны, или разработкой интерфейса, с другой. Не объединяйте обсуждения базовой модели с уровнем реализации.
Возьмите цифровой продукт, например программу для редактирования фотографий или почтовый клиент, и попытайтесь воссоздать ее структуру. Вначале составьте список всех навигационных точек и функциональных возможностей и объедините их в группы. Затем создайте простую диаграмму внутренней структуры и подпишите компоненты модели, которую вы вывели.
• Hugh Beyer and Karen Holtzblatt, Contextual Design (San Francisco: Morgan Kaufmann, 1998).
• Indi Young, Structure Derivation, Chap. 13 in Mental Models (New York: Rosenfeld Media, 2008).
4. Проверить предположения
Даже самые тщательные исследования JTBD не дают гарантий, что созданное вами предложение примут клиенты. Запланируйте эксперименты и проверки вашего решения, чтобы убедить в наилучшем соответствии продукта рынку.
• Сформулировать гипотезы.
• Подтвердить или не подтвердить гипотезы экспериментально.
• Сделать выводы из того, что вы узнали, и двигаться вперед.
Высокая. Чтобы понизить неопределенность и понять, что ваше решение двигается в правильном направлении, потребуется несколько подходов. Вы можете много раз возвращаться к началу, что потребует много времени и сил на создание правильного продукта.
В коммерческих условиях очень трудно изолировать переменные в экспериментах. Вы можете получить обратную связь, которая уведет не в ту сторону или не покажет прямых причинно-следственных отношений. Часто встречаются ложноположительные и ложноотрицательные результаты.
• Travis Lowdermilk and Jessica Rich, The Customer-Driven Playbook (Sebastopol, CA: O’Reilly, 2017).
• Ash Maurya, Running Lean (Sebastopol, CA: O’Reilly, 2012).
• Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. – М.: Альпина Паблишер, 2014.
• Бланк С. Четыре шага к озарению. Стратегия создания успешных стартапов. – М.: Альпина Паблишер, 2014.
• Michael Schrage, The Innovator’s Hypothesis (Cambridge: MIT Press, 2014).
Доставка ценности
1. Создать карту пути клиента
Карты пути клиента показывают взаимодействие клиентов с вашим брендом или предложением. Цель такой карты – проиллюстрировать потребительские работы клиента. Они фундаментально отличаются от карты работы, показывающей, чего исполнитель работы пытается добиться независимо от решения. Карты пути дают ценную информацию, как люди находят, приобретают и используют ваше решение.
• Начать проект создания карты пути клиента.
• Исследовать этапы потребления.
• Проиллюстрировать путь клиента с помощью диаграмм.
• Создать связи вокруг пути потребителя.
От средней до высокой. Если вы уже провели исследование, которое может стать основой карты пути клиента, вам предстоят достаточно простые действия. Проведение предварительного исследования потребует времени и усилий.
Убедитесь, что карта работы существует независимо от карты пути клиента. Между ними есть очень важное отличие: карты работы показывают этапы выполнения основной работы, а карты пути – отношения клиента с предложением компании. Также не забывайте вовлекать в работу других людей – старайтесь понять путь клиента вместе. Для достижения цели вам потребуются обсуждения внутри команды.
• Lance Bettencourt, Service Innovation (New York: McGraw-Hill, 2010).
• Tony Ulwick and Frank Grillo, Can Bricks and Mortar Compete with On-Line Retailing? (аналитический доклад, Harte Hanks, 2016).
• Калбах Дж. Путь клиента. Создаем ценность продуктов и услуг через карты путей, блупринты и другие инструменты. – М.: Манн, Иванов и Фербер, 2022.
2. Дать клиентам хороший старт
Принятие клиентов на обслуживание – важный фактор долговременного успеха. JTBD предоставляет согласованный способ увидеть, насколько цели, которых пытается достичь клиент, не зависят от используемого им решения. Эта информация помогает организовать деятельность по сопровождению клиентов. В конечном счете вы хотите, чтобы клиент не просто использовал ваш продукт, но и выполнял свою работу.
• Узнать клиентов и разделить их на несколько групп в соответствии с уровнем знаний и типом обучения.
• Определить оптимальную последовательность задач для каждого типа обучения.
• Создать опыт сопровождения.
От средней до высокой. В процессе принятия клиентов есть много методов взаимодействия и множество деталей, которые следует учесть. Повторение и совершенствование программы сопровождения клиентов на начальном этапе требует значительных усилий и временны́х затрат.
У клиентов, относящихся к разным типам, на начальном этапе пользования продуктом или услугой возникают различные потребности. Могут возникнуть сложности при разделении пользователей на группы и обеспечении наиболее подходящего для них опыта адаптации.
Рассмотрите текущий поток пользователей, недавно ставших клиентами компании, и действия, которые вы предпринимаете, и сравните свой рабочий поток с описанием подхода к различным типам обучения в этом сценарии. Закончив анализ, найдите способы улучшить свой рабочий поток.
• Alan Klement, Design for Switching: Create Better Onboarding Experiences, JTBD News (июль 2014 года).
• Samuel Hulick, Applying Jobs-to-Be-Done to User Onboarding, with Ryan Singer, UserOnboard (блог), 2016.
3. Довести до максимума сохранение клиентской базы
В сложившейся экономической ситуации сервисы с подпиской играют все большую роль. Хотя предприниматели часто делают ставку на привлечение новых пользователей, сохранение имеющихся отношений с клиентами критически важно для успеха бизнеса. Поиск момента, когда у пользователя возникает первая мысль об отмене подписки, проливает свет на то, что можно предпринять ради предотвращения оттока клиентов.
• Провести интервью после аннулирования договора, используя метод переключения.
• Найти повторяющиеся моменты в причинах ухода.
• Устранить коренные проблемы, чтобы предотвратить отток клиентов и увеличить процент их удержания.
Средняя. Можно сделать большие открытия, проведя всего несколько интервью после аннулирования договора, но чем больше участников вы найдете, тем лучше. Изучение данных в любом случае потребует некоторых усилий.
Найти и привлечь к участию в интервью покинувших компанию клиентов бывает трудно. Скорее всего, они потребуют вознаграждения. В некоторых случаях очень сложно найти участников интервью, чтобы реконструировать причины ухода. Особенно это относится к ситуациям B2B, где принимать решение могут много людей.
Найдите друга или коллегу, недавно отменившего какую-либо подписку. Используйте метод переключения и проведите интервью, реконструируя процесс принятия решения. Найдите момент, когда возникает первая мысль об уходе. Подумайте об этом вместе и найдите работу, которую нужно было сделать. Затем задайте вопрос: «Что мог предпринять поставщик услуги, чтобы предотвратить отмену подписки?»
• Ruben Gamez, Doing SaaS Cancellation Interviews (the Jobs-to-be-Done Way), Extends Logic (блог), 2015.
4. Обеспечить адекватную поддержку
В ситуациях, когда людям приходится обращаться в службу поддержки, они не обязательно напрямую спрашивают о том, что им нужно. Прежде всего они могут использовать неправильные слова. Кроме того, случается, что они уже мысленно нашли решение проблемы и просят сделать другую работу. Сотрудники службы поддержки должны уметь распознавать реальный запрос до попытки исправить проблему клиента. JTBD поможет найти наилучшее решение.
• Слушать и искать работу.
• Уточнять и оценивать намерение клиента.
• Решить проблему.
Низкая. Достаточно просто проинструктировать сотрудников службы поддержки о способах искать работу клиента. Требуются активное слушание и эмпатия.
На уровне микроработ мысли о работе могут перемешиваться с решением. Их трудно разделить, но сделать это можно. Потребуются некоторые усилия, чтобы натренировать сотрудников службы поддержки мыслить в терминах работы, а не задач продукта.
Возьмите выборку из прошлых обращений в службу поддержки и попытайтесь определить в каждом из них работу, которую нужно сделать. Сформулируйте положение о работе, используя правила JTBD, о которых говорилось в главе 2 «Основные идеи JTBD».