Business situation framework что это

В качестве альтернативы мы могли бы использовать регулярное выражение:

Мы предоставим рабочий код для обоих вышеперечисленных методов в следующем разделе.

4.4. Создание и выполнение тестов

Во-первых, мы начнем со структуры JSON, чтобы проиллюстрировать данные, загруженные на сервер по запросу POST и загруженные клиенту с помощью GET. Эта структура сохраняется в поле json String и показана ниже:

Для демонстрации REST API мы используем сервер WireMock:

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

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

Использование API WireMock для заглушения службы REST:

Теперь отправьте запрос POST с содержимым, взятым из поля json String , объявленного выше, на сервер:

Следующий код утверждает, что запрос POST был успешно получен и обработан:

Сервер должен остановиться после использования:

Отправка запроса GET и получение ответа:

Вот реализация этого вспомогательного метода преобразования:

Следующее проверяет весь процесс:

Наконец, остановите сервер, как описано ранее.

5. Параллельное выполнение функций

Cucumber-JVM изначально поддерживает параллельное выполнение тестов в нескольких потоках. Мы будем использовать JUnit вместе с плагином Maven Failsafe для выполнения бегунов. В качестве альтернативы мы могли бы использовать Maven Surefire.

JUnit запускает файлы функций параллельно, а не сценарии, что означает, что все сценарии в файле функций будут выполняться одним и тем же потоком .

Теперь давайте добавим конфигурацию плагина:

Обратите внимание, что:

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

Это все, что нам нужно сделать, чтобы запустить функции Cucumber параллельно.

6. Заключение

В этом уроке мы рассмотрели основы Cucumber и то, как этот фреймворк использует доменный язык Gherkin для тестирования REST API.

Как обычно, все примеры кода, показанные в этом руководстве, доступны на GitHub .

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

Из этой статьи вы узнаете:

С чего начать поиск решения кейса, чтобы не запутаться?

Если дать случайному студенту кейс, то он, скорее всего, будет искать решение максимально хаотично. Это может привести к успеху, в конце концов и в лотерее есть победители. Но мы все-таки советуем использовать подход, который применяют консультанты из McKinsey & Company и Bain & Company. Вам нужно получить от интервьюера всю информацию, а потом попросить несколько минут на ее обработку. За это время вы должны разбить основную задачу на составляющие, подумать над возможными решениями и расставить приоритеты.

Проще всего создать структуру с помощью Issue Tree. На его вершине располагается главная задача, которую вы сформулировали по SMART еще на прошлом этапе решения кейса. Ветви — это уточняющие вопросы, с помощью которых мы детализируем проблему. А в корнях лежат четкие действия, которые нужно совершить. Issue Tree поможет вам не запутаться и, что самое главное, найти рабочие гипотезы — варианты решения бизнес-задачи.

Что делать, если я не понимаю, как решить проблему кейса?

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

• Profitability Framework. Подойдет для кейсов на увеличение прибыли. Идея в том, что прибыль можно увеличить с помощью роста выручки на единицу продукта и количество проданных единиц либо через снижение издержек. Кандидату остается найти подходящее решение
• Business Situation Framework. Подойдет для кейсов о выходе на новый рынок, запуске продукта или изменении позиционирования. Кандидату нужно проанализировать четыре составляющие бизнеса: потребителя, саму компанию, ее продукт и конкурентов. На основе полученных данных будет легко найти источники роста.
• SPECIAL-T. Подойдет для стратегических кейсов. В основе фреймворка лежит мысль о том, что во внешней среде на компанию могут влиять восемь параметров: Suppliers (поставщики), Public (общество), Economy (экономика), Competitors (конкуренты), Industry (отрасль), Auditors (аудиторы), Legislation (законодательство) и Technologies (технологии). С помощью анализа этих параметров и нужно искать решение.
• Marketing Mix (или 5P). Подойдет для маркетинговых кейсов по решению любых проблем, связанных с продуктом. Шаблон предлагает формулировать гипотезу с помощью анализа 5P: продукта (product), упаковки (package), места (place), цены (price) и продвижения (promotion).

В статье мы перечислили базовые фреймворки и не углублялись в подробности. Если вам не хватает вводных, читайте наш учебник по решению кейсов. Там мы разбираем каждую букву в аббревиатуре фреймворков. Закрепить теорию лучше всего практикой. Для этого мы придумали Школу Changellenge >> — образовательный интенсив, который за 21 день подготовит вас к кейс-интервью и другим этапам отбора. Вместе с экспертами из Big3 вы будете составлять резюме, решать реальные бизнес-задачи и учиться тому, что остальные осваивают спустя годы практики.

Как правильно сформулировать гипотезу и что с ней делать дальше?

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

Пример плохой гипотезы: «Реклама привлечет новых клиентов».

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

Получите карьерную поддержку

Если вы не знаете, с чего начать карьеру, зашли в тупик или считаете, что совершили какие-то ошибки, спросите совета у специалистов. Заполните заявку и консультанты Changellenge >> окажут вам помощь. Это отличный шанс вместе экспертом проработать проблемные вопросы и составить карьерный план.

Подписаться на карьерную рассылку

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

Рассказываем о применении теории JTBD на практике: как строить исследование, проводить интервью и какие есть фреймворки.

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

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

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

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

• Определяем цель исследования. Для начала нам необходимо определить цель: что мы хотим исследовать и что хотим узнать на выходе.
• Формулируем гипотезы работ. Попытаемся определить работы на основе своего опыта и опыта наших клиентов.
• Проводим интервью. Наблюдаем и собираем инсайты пользователей.
• Анализируем данные. Интерпретируем полученную информацию с помощью фреймворков.
• Создаем Job stories. На основе полученных инсайтов формулируем Job Stories.
• Придумываем решения. На основе полученной информации улучшаем наш продукт или корректируем стратегию.

На этом этапе нужно определить, что мы хотим узнать в ходе исследования. Допустим, мы создаём этичную косметику: у нас в составах только натуральные ингредиенты, продукция не тестируются на животных и не используется пластиковая упаковка. Все наши продукты пользуются спросом, кроме крема для тела. То есть наша цель исследования — понять, почему нет спроса на этот крем.

Вместе с целью нам нужно определить вопросы к исследованию:

• На какие работы пользователи нанимают наш крем?
• Почему пользователи покупают крем?
• Почему пользователям не нравится крем?

После того как мы сформулировали цель и определили вопросы, переходим к следующему шагу.

На этом этапе нам необходимо сформулировать гипотезы по Job Stories, определить наших прямых и непрямых конкурентов и выбрать респондентов, которых будем опрашивать.

Неэтичные косметические марки.

Нам нужно сформулировать гипотезы, на которые пользователи, возможно, нанимают наш продукт. Гипотезы помогут определить «портреты» респондентов, с которыми мы будем проводить интервью.

Формулировать работы будем по Job Stories, которые придумала Intercom и описала их применение в своей книге “Intercom on Jobs-to-be-Done”. Фреймворк выглядит как предложение: “When <situation> I want to <motivation> So I can <outcome>”.

Ситуация — описание контекста, в котором у пользователя возникает проблема.

Мотивация — желаемое решение проблемы.

Ауткам — это тот прогресс, который хочет совершить человек в будущем.

В этом случае нам важно не только, что пользователь хочет, а контекст: какая ситуация повлияла на появление желания.

Гипотезы Job Stories для марки этичной косметики:

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

На этом этапе гипотезы работ могут быть достаточно абстрактными, так как само исследование ещё не было проведено.

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

Для интервью желательно отбирать тех, кто недавно покупал у вас что-то, потому что в их памяти ещё свежи воспоминания, ощущения и эмоции о покупке.

Мы определили цель исследования, сформулировали гипотезы работ, определили релевантных респондентов, теперь нам нужно их опросить.

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

Вспоминаем фреймворк Алана Клемента из первой части статьи. Эта модель описывает, как создаются работы и как эти работы становятся причиной найма и увольнения продуктов.

То есть из интервью нам необходимо узнать:

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

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

Посмотрите на интервью в формате JTBD, которое проводят Крис Спик и Боб Моэста с респондентом о покупке машины. Это поможет вам понять логику интервью и определить примерный пул вопросов.

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

В нашем случае мы хотим узнать, почему продажи крема падают.

Почему вы решили купить крем?

Что стало причиной покупки крема?

Зачем вам понадобился крем?

Почему вы выбрали именно наш крем?

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

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

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

После первой покупки Люба вернулась к нам, чтобы купить шампунь, но не не стала покупать крем. Мы решили узнать почему. Оказалось, что крем всё ещё не закончился. Мы были рады услышать, что крем получился экономичным.

Но пообщавшись с Любой подольше, мы выяснили, что крем не закончился, потому что его было сложно наносить из-за текстуры: он был в твёрдом виде. Поэтому когда Любе лень тратить много времени на использование экологичного крема, она использует мамин «Лотос и восточные травы».

Мы провели десять таких интервью. Теперь у нас на руках много полезной информации. Что мы делаем с этим дальше? Прослушиваем записи, анализируем и начинаем интерпретировать их. Как раз тут нам помогут фреймворки JTBD, чтобы найти работы, определить контексты, понять struggle moments.

Анализировать и интерпретировать полученную информацию будем с помощью нескольких фреймворков.

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

Что было толчком к принятию решения о покупке? То, что Люба стала экоактивисткой.

Что привлекает Любу в новом решении? Что она будет красива и свежа и при этом останется экогёрл.

Что удерживает Любу в текущем состоянии? У Любы много учёбы и подработки, она не успевает ходить по разным эколавкам, ей не нравится делать заказы в интернете, потому что она хочет пощупать косметику перед покупкой.

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

Теперь мы понимаем, за что переживает Любовь и какой она хочет совершить прогресс. Идем дальше.

Все наши приобретённые вещи и решения проходят путь от «первой мысли» до «удовлетворения новым решением» или «разочарования в новом решении». Если мы разочаровались в новом решении, мы начинаем заново проходить путь.

Таймлайн помогает определить, когда произошла первая мысль о покупке, что произошло в «Событии № 1», что заставило нас начать активный поиск, что произошло в «Событии № 2», когда мы приняли решение о покупке, и так далее.

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

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

Первая мысль. У Любы появилась идея о приобретении экологичной косметики после того, как она стала больше узнавать о проблеме загрязнения.

Job Story помогает понять, когда и в каких условиях у клиента закралась первая мысль о покупке продукта (то есть то, что случилось ещё до начала его использования).

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

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

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

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

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

Существует два способа сегментации: по контекстам и по работам. По контекстам — когда у опрошенных схожие ситуации: много людей сталкиваются с одинаковыми проблемами, но у них совершенно разные желания. По работам — когда у опрошенных разные ситуации (проблемы), но они в целом хотят одного и того же (схожий ауткам).

После того как мы просегментировали Job Stories, самое время проанализировать, какие изменения в продукте потребуются, и заняться улучшениями!

Если вам интересно почитать, что пишет Дима про JTBD, вот его блог на Medium, а это канал в Telegram.

Зачастую за понятием «фреймворк» кроется методология проектной работы — инструмент, помогающий командам оценивать актуальность продукта для рынка и реализовывать сложные бизнес-проекты. А еще — генерировать больше полезных идей, которые действительно будут востребованы клиентами. Своим опытом внедрения фреймворка Jobs to be done в крупной B2B-компании (и разработки с его помощью проекта для HR) с нами поделился Юрий Бранковский, продакт-менеджер с успешным опытом работы в компаниях Planner 5D, VCV, Mego.travel.

Юрий Бранковский
Продакт-менеджер, ментор и член жюри хакатонов Emerge и Epam engineering jam

— Фреймворк — это программа или методология, облегчающая разработку и объединение различных частей одного большого или сложного проекта. Ниже я расскажу, как мы внедряли фреймворк Jobs to be done (далее по тексту — JTBD) для B2B-компании, которая занималась разработкой специальных видеоинтервью. Этот продукт был необходим для эффективной работы HR-отделов, поскольку отчасти заменял классические собеседования в компаниях, что позволяло:

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

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

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

Выяснилось, что HR используют видеоинтервью по-разному, на разных этапах и для разных вакансий. Так мы поняли, что метод создания персон не подходит для решения этой конкретной задачи.

Поэтому мы решили применить фреймворк Jobs to be done, который использует, в частности, компания Intercom, также работающая в B2B-сегменте.

Jobs to be done — это теория о поведении пользователей, которая помогает понять, как и почему люди принимают решение (например, о первой покупке). С помощью JTBD мы можем делать прогнозы о востребованности продукта (или его фичей — ключевых особенностей) на рынке. В основе метода лежит необходимость правильно сформулировать задачу пользователя (покупателя) и определить, насколько фича продукта подойдет для ее решения.

Пример. Видеоинтервью является удобным инструментом для решения задачи первичного скрининга кандидатов по сравнению с очным (оно требует присутствия кандидата и занимает больше времени) или телефонным интервью (вы не видите кандидата).

Задачи те же, а инструмент для рекрутера — новый. Но если инструмент подходит рекрутеру по ряду параметров, то он готов его приобрести.

Задачи, которые должны быть сделаны на этапе разработки продукта

1. Поймите, почему вообще ваш продукт «нанимают»?

Для этого есть шаблон ответа:

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

2. Найдите истинных конкурентов

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

Ищите тех, кто решает те же самые задачи, что и ваш продукт.

Ваши конкуренты «прячутся» в трех категориях:

3. Задайте вопросы пользователям

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

Вот как он может выглядеть:

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

Эти вопросы позволят лучше понять контекст использования инструмента — как вашего, так и конкурентов.

4. Определите четыре силы

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

• Импульс происходящего: «Мы не успеваем просмотреть всех кандидатов за отведенный период времени. Нам приходится увеличивать период подбора»
• Тяга нового решения: «Если мы приобретем сервис интервью, который позволит просматривать больше кандидатов, мы сможем сократить время подбора и качество кандидатов»
• Сила беспокойства от того, что может случиться: «А что если новый инструмент не будет интегрирован так хорошо, как нам хочется? Мы попробовали уже три инструмента, и ни один не справился хорошо»
• Сила принадлежности к тому, что уже есть, к прошлому: «У нас уже настроены воркфлоу и интеграции, и будет болезненно настраивать все заново».

5. Продумайте переключение на продукт для клиентов компаний

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

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

Что мы сделали:

1. Наряду с настройкой классической системы продаж подготовили наглядную демонстрацию продукта.

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

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

6. Проработайте период размышления клиента (Consideration set)

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

Есть вопросы, которые помогают понять, в каком конкретно состоянии находится пользователь в этот период:

• Когда вы принимали решение о приобретении старого продукта, вы изучали, какой инструмент подходит для вашей компании лучше?
• Вы были единственным, кто искал решение в то время?
• Где вы впервые услышали об инструменте, которым воспользовались?
• Можете вспомнить, как вы пришли к решению заплатить за инструмент?
• Во время поиска вы или кто-либо другой пробовали другие инструменты? Какие?
• Кто принял решение использовать инструмент? Эти люди еще работают в компании? Какие у них роли сегодня?
• Сколько прошло времени с начала поиска, прежде чем вы купили старый продукт?
• Когда компания начала использовать продукт?

Что мы сделали:

1. Прописали четкие вопросы для клиентов.

2. Для менеджеров по продажам разработали список «железных» аргументов по каждому вопросу.

3. В CRM прописали конкретные скрипты, которые использовали, чтобы помочь клиенту принять решение о покупке.

7. Сделайте обоснование выбора

Итак, первой из причин для выбора JTBD стало преимущество перед методом «персон».

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

Третьей причиной стала проблема — ранее мы не могли проводить количественные исследования (что характерно для многих B2B-продуктов).

Да, продукт изначально был нацелен на рекрутеров. Но среди них были:

• Нанимающие менеджеры (рекрутеры)
• Директоры по подбору персонала (HR)
• Лица, принимающие решения о выделении бюджета (ЛПР).

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

Внедрение фреймворка JTBD в компании

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

Что мы для этого сделали:

1. Заручились поддержкой стейкхолдера. Объяснили ему, для чего нужен фреймворк и как он поможет разработке продукта, достижению метрик. В частности — что использование фреймворка будет полезным ввиду долгого цикла продаж продукта (условно говоря, вы можете понять, что клиент продлил контракт благодаря какой-то фиче только спустя год после ее релиза, когда перезаключается договор).

2. Взяли преимущества JTBD из «обоснования выбора» и использовали их в качестве аргументов при презентации фреймворка сотрудникам.

3. Проговорили с командой процесс добавления нововведений и объяснили их причины. Это сделали, поскольку внедрение фреймворка связано с определенной шаблонизацией Product Requirements Document (PRD) — документа с требованиями к продукту (аналог технического задания).

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

5. Переписали задачи из бэклога. Так мы показали преимущества JTBD-разработчикам и объяснили на конкретных примерах, как это работает. Вдобавок тем самым мы провели дополнительный груминг (причесывание бэклога).

6. После определенного периода «обкатки» провели митап, на котором рассказали про фреймворк всей компании и раскрыли этапы процесса создания Job Story (истории) и в дальнейшем — фичи продукта. Это сняло окончательные вопросы и синхронизировало разработку и продажи.

А вот как мы использовали фреймворк при работе над проектом.

Внедрение Job Stories

В процессе работы над проектом каждую задачу мы называем Job и прописываем ее путь-формулу, которая называется Job Story. Вот как выглядит ее структура:

[ Когда _____ ] [ Я хочу _____ ] [поэтому мне необходимо _____ ].

Для того чтобы задача выполнялась максимально четко, на каждом этапе Job Story добавляем фокусировку:

[Когда ____ (фокусируется на ситуации)], [Я хочу ____ (фокусируется на мотивации)], и [поэтому мне необходимо ____ (фокусируемся на результате)].

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

Когда мы поняли ситуацию, в которой столкнулись с проблемой, требующей решения, поняли мотивацию к ее решению и выяснили, какова выгода — мы стали увереннее в том, что создаем ценный для клиентов продукт. Вдобавок эти истории можно использовать в отделе продаж для создания контраргументов, скриптов и работы с разными сегментами пользователей (рекрутеры, директоры HR и ЛПР).

Настройка процесса работы

Мы начинали с высокоуровневой задачи. Затем определяли более мелкую, которая помогала решить верхнеуровневую. Для этого совершали три действия:

1. Смотрели, как на данный момент люди решают проблему (какую работу для этого выполняют).
2. Определялись с Job Story, которая исследует причины, беспокойства и мотивацию относительно того, что пользователи сейчас делают.
3. Предлагали решение, которое выполняет эту работу.

Задача в трекере может выглядеть следующим образом:

• Какую проблему мы решаем и почему
• Job Story
• Как мы измеряем успех (результат)
• Что необходимо сделать (список работ заполняется совместно с разработчиками).

При этом в заголовке задачи мы сразу прописывали Definition of Done (DOD) — критерии, которые определяют, сделано ли то, что было целью разработки. Для чего также использовали Job Story.

Пример. DOD пользователь может сделать то-то и то-то согласно макетам.

Дизайн на основе Job Story

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

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

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

1. Useful. Что именно я делаю, когда использую конструктор страниц?
Я создаю персонализированное описание, добавляю фото офиса и видеозапись с рассказом генерального директора о нашей компании и о продукте.

2. Usable. Какой результат от использования?
Персональный лендинг, который подробно описывает вакансию и улучшает отношение к бренду.

Таким образом, алгоритм настройки процесса работы выглядит так:

• Презентуем фреймворк стейкхолдерам
• Презентуем фреймворк команде и коллегам
• Создаем шаблоны для упрощения процесса проведения job interview
• Создаем шаблоны PRD
• Регулярно проводим интервью с клиентами и собираем обратную связь от менеджера продаж (в идеале — уже в формате Job Story)
• Регулярно наблюдаем за тем, как пользователи применяют наш продукт (например, мы сами подбирали персонал при помощи видеоинтервью, смотрели скринкасты клиентов, наблюдали, как рекрутеры используют продукты конкурентов).

Заключение

Фреймворк JTBD подходит для использования в B2B-продуктах, так как позволяет работать с разными сегментами пользователей и фокусироваться на проблемах, которые решает для них продукт.

Как и любой фреймворк, JTBD требует внедрения и оптимален, когда вся компания мыслит в одном контексте. Если это так — менеджеры продаж присылают вам готовые Job Story (что ускоряет процесс проверки гипотез и сбора обратной связи), а разработчики мыслят проблемами, а не фичами.

Читайте также:

  
• Гугл хром игра 5 отличий
  
• Почему файлы не скачиваются архивом
  
• Текласт м40 планшет или т 40 плюс
  
• Нет значка ethernet в сетевых подключениях
  
• Почему звук отстает от видео на планшете