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

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

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

О каком продукте пойдёт речь

REpublic — это релизный портал в Ozon, который помогает разработчикам и тестировщикам с процессом установки релизов в production. Его основная цель — это уйти от понятий коммит, ветка, пайплайн, тег и оперировать понятием релиз. Этот сервис предоставляет удобный интерфейс для простого и понятного процесса установки и отката релизов.

В общем, это такой центр управления полётами.

С его интерфейсом и тем, как мы над ним работали, вы можете ознакомиться в статье моей коллеги.

С чего начинался продукт

Этот продукт начинался как data mining-сервис. На первом этапе нашей задачей было научиться собирать данные об устанавливаемых релизах. REpublic собирал данные о том, что происходит в Gitlab и Jira, и отображал это в своём интерфейсе. 

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

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

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

А что же делать дальше?

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

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

К нам приходили пользователи с запросами на доработки, и самыми «показательными» стали два:

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

2. от команд логистики — добавить возможность создавать и «проходить» по чек-листу при установке релиза.

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

Оба эти запроса никак не связаны с манипуляциями с ветками, тегами, пайплайнами или запуском джоб. 

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

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

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

Поиск ценности продукта

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

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

Для поиска этой ценности я решил использовать подход JTBD, в основе которого лежит понятие «работа».

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

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

Я провёл два десятка интервью с фронтенд- и бэкенд-разработчиками, было несколько тестировщиков и несколько тимлидов.

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

Верхнеуровневые работы описываются по определённому шаблону, вот пример одного описания из исследования:

когда

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

хочу

- выкатить завершённую задачу в production

чтобы

- почувствовать удовлетворение от выполненной работы и что моя работа не бесполезна

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

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

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

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

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

• запускаю создание релиза;

• автоматически стартует пайплайн по его установке на stage;

• перехожу по ссылке в интерфейс Gitlab на страницу пайплайна и постоянно обновляю страницу, чтобы видеть, как проходят джобы.

На вопрос, какого результата он хочет достичь этим, пользователь ответил, что он ответственно относится к установке релиза и переживает за этот процесс. И он хочет контролировать этот процесс максимально пристально.

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

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

Пробуем чинить проблемы

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

У нас в Ozon действительно хорошо построен процесс CI/CD, и в нём много автоматизации и механизмов, которые помогают разработчикам выкатывать релизы. Тем не менее, если обобщить и даже «укрупнить» шаги, то обычно они выглядят так:

• взять задачу в работу в Jira;

• создать ветку от мастера;

• написать код, запушить в ветку;

• пройти код-ревью от команды;

• перейти в Gitlab и выкатить свои изменения в dev-окружение;

• протестировать в dev;

• создать релизную ветку и вмержить в неё свои изменения;

• перейти в Gitlab и выкатить свои изменения на stage;

• протестировать задачу на stage;

• перейти в Gitlab и получить апрув на MR в мастер от команды;

• создать тег и начать выкатывать релиз в production;

• открыть: дашборд в мониторинге, логи, трейсы, если нужны;

• если всё хорошо — завершить релиз;

• Profit!

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

Я ещё раз повторю мысль — большинство разработчиков не видит проблем с процессом установки релизов. 

В такой ситуации, если идти стандартным путём развития продуктов — искать и пробовать чинить проблемы пользователей, то в данном случае непонятно, как развивать продукт, т.к. у пользователей нет проблем. Это и показывали наши метрики.

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

Я предлагаю создавать ценность — упростить задачу выкатки релиза на production.

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

Визуализация результатов исследования

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

В итоге получилась вот такая схема:

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

• разработка,

• тестирование,

• установка,

• после установки.

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

На этом этапе работы превратились вот в такие карточки:

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

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

Другое решение — другие проблемы. Поэтому не было смысла сильно фокусироваться на проблемах пользователей с Gitlab, ведь мы предлагаем другое решение для их работ. 

Зачем нужна визуализация?

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

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

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

Примеры работ и продуктовых решений для них:

• перейти в список пайплайнов и найти пайплайн тега в Gitlab — убили — у нас все пайплайны на одной странице;

• получить апрув на MR в мастер — не стали выполнять — мы сознательно не хотим конкурировать с Gitlab в части работы с кодом;

• перевести задачу в нужный статус — начали выполнять — больше не нужно идти для этого в Jira, можно сделать на странице релиза.

Ещё примеры выполнения работ в интерфейсе:

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

Хорошее понимание того, что и зачем должна делать наша страница релиза, позволило нам на этапе дизайна уже заниматься именно им и значительно меньше тратить сил на выявление сценариев поведения пользователей.

Также формулирование задач как работ, позволило не отвлекаться на какие-то «хотелки» и фичи ради фич, достаточно просто задать вопрос: «Какую работу выполняет эта „хотелка“?» Если ответа на этот вопрос нет, можно не обращать на неё внимание, по крайней мере пока.

Схема — это граф

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

Наличие этих связей можно определить по ответу на вопросы: 

• зачем пользователь что-то делает?

• чтобы что? 

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

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

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

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

• хочу получить ссылку на MR;

• хочу выбрать разработчика для апрува;

• хочу видеть статус апрува MR’а.

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

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

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

• выходить на предыдущую работу;

• выполнять работы выше уровнем;

• выполнять больше работ одним решением и многие другие.

Фиксирование формулировок работ позволяет выстраивать коммуникацию с пользователями на уровне ценностей, которые несёт продукт. О них можно узнать задавая вопрос «зачем?».

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

Сейчас мы начали ещё одно исследование — работ по координации команд и релизов, это средняя часть на схеме. 

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

Ключевые выводы

1. При развитии внутренних продуктов необходимо проводить исследования и интервью с пользователями. Знания о ценности продукта лежат в головах наших пользователей.

2. JTBD отлично справляется с задачей поиска точек приложения сил в разработке продукта. Но тут, как и с любой методологией, кроме теории, важен и «фреймворк», т.е. как это применять на практике. Я специально пошёл на курс Вани Замесина «Как делать продукт», и это очень сильно помогло в проведении и анализе результатов исследования.

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

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

5. Использование формулировок работ помогает выстраивать коммуникацию с пользователями на языке ценностей продукта для них. Формулировки из «зачем» можно использовать в маркетинговых материалах.

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