В этом модуле вы узнаете, что такое Job Map и Job Story, на какие этапы согласно Тони Ульвику можно разбить процесс выполнения работ пользователем, как с помощью карты работ искать точки роста продукта и как правильно описывать Job Story.
Job Map
Напомню, что Тони Ульвик работает с трактовкой Job-as-Activity. Однако Job Map можно применять и для трактовки Job-as-Progress. Ульвик утверждает, что при выполнении работы человек проходит ряд универсальных этапов (они не зависят от работы или решения), в рамках которых выполняет свои небольшие работы и получает желаемые выгоды.
Вот этот список этапов:
- Define
- Locate
- Prepare
- Confirm
- Execute
- Monitor
- Modify
- Conclude
В рамках составления карты, вы раскладывает работу по этапам и смотрите, где ваш продукт или фича что-то закрывает, а где — нет. Где у вас есть точки роста. Где вы можете придумать что-то совсем новое, что закроет как можно больше этапов. Ульвик часто приводит в качестве примера работу listening to music while out for a run. Давайте ее немного видоизменим до работы «Слушать фоновую музыку, пока работаешь над конкретной задачей».
Представим, что мы делаем простой стриминговый сервис с музыкой. Раньше людям надо было самим выбирать музыку для работы. Кто-то составлял плейлисты и гонял их часами. Людям самим надо было заниматься изменением таких листов. Если мы разложим работу по Job Map, то увидим, что наш сервис помогает людям только на некоторых этапах. Мы можем придумать фичу типа «умный плейлист» или «подборки под ситуации», которая (фича) закроет гораздо больше этапов в карте:
- человеку не надо будет подбирать музыку;
- человеку не надо будет самостоятельно обновлять эти листы;
- человеку станет проще вносить изменения (за счёт простого механизма лайков/дизлайков).
То есть разложив основную работу по этапам, мы смогли найти точки роста в продукте и придумать решение, которое ещё сильнее подсадило человека на наш сервис. Ничего не напоминает? 😉 Посмотрите на историю развития стриминговых сервисов.
Для каждого этапа мы также определяем набор желаемых результатов, которых человек хочет достичь.
Такая детальная проработка ключевой работы помогает нам искать точки роста продукта. Несколько лет назад я придумал набор стратегий для работы с Job Map:
- Захват территории
- Стать лучшими на каком-то этапе
- Оптимизация этапов
- Плавный переход между этапами
- Стратегия вытягивания этапов
- Захват связанных работ
- Стратегия вытягивания выгод
- Работа с ожиданиями
- Захват несвязанных работ
Эти стратегии помогают выбирать пути развития вашего продукта в зависимости от текущего контекста продукта. Если они вам интересны, то пишите в Slack. Можно будет договориться о небольшом вебинаре, на котором я на примерах разберу эти стратегии.
Job Story
Я поделюсь своим опытом использования такого формата. В моей картинке мира это один из способов описывать работы, когда вам нужно донести только суть, опустив лишние детали. Помните, выше мы раскладывали работу по шаблону и все довольно подробно расписывали? Job Story поможет рассказать другим о той работе, которая есть у вашего пользователя.
Job Story описывается по формуле
Когда <…> я хочу <…> для того, чтобы <…>
Смотрите как легко собрать Job Story, если у вас уже проработаны детали работы:
Когда <…> — это текущая ситуация с описанием затруднений и напряжения, которые возникают у человека (и которые подталкивают человека к совершению прогресса).
я хочу <…> — это описание работы, то есть прогресса, который человек хочет совершить.
для того, чтобы <…> — а вот тут могут быть вариации. Разные авторы по-разному описывают эту часть. Тут может быть:
описание лучшей жизни, к которой стремится человек;
ключевой желаемый результат (или несколько), которого хочет достичь человек;
Лично я чаще использую описание ключевого желаемого результата.
Формат Job Story отлично подходит, когда вам нужно сделать конкретный и точечный фокус на работе: донести информацию до других или загрузить в себя ключевую информацию (чтобы каждый раз не перечитывать детали работы). Плюс это еще один формат для унифицированного описания потребностей пользователей внутри команды или компании.
Однако, как говорится, «нельзя так просто взять и написать Job Story». Я видел много примеров крайне неудачных историй, поэтому рекомендую пользоваться списком признаков плохого описания Job Story:
- Ситуация (Когда <…>) без видимой проблемы или затруднения.
- Описание работы (я хочу <…>) подразумевает конкретное решение.
- Ожидаемый результат (для того, чтобы <…>) является всего лишь перевернутым описанием ситуации (Когда <…>).
- Job Story имени Капитана Очевидность.
Вот несколько плохих примеров:
- Когда я нашла слишком много информации по конкретному законодательству, я хочу воспользоваться фильтрами для того, чтобы сократить время, затрачиваемое на выбор релевантной для меня информации. Почему плохо: в формулировке содержится конкретное решение.
- Когда я трачу много времени на поиск разных ресурсов, я хочу иметь единый источник информации для того, чтобы экономить время. Почему плохо: результат — перевернутое описание ситуации.
- Когда мне нужно решить рабочую задачу, я хочу изучить изменения законодательства для того, чтобы избежать риска ошибки. Почему плохо: Капитан Очевидность.
Рекомендуем посмотреть видео никиты Ефимова с разбором типичных ошибок в работе с Job Map (29 минут).