Навигация по серии статей

• От Job Story к User Story. Часть 1. Введение в связь артефактов и циклов (Вы здесь :-) )

• От Job Story к User Story. Часть 2. Цикл исследования и разработки. Маппинг CustDev -> JTBD -> UserFlow -> CJM -> UC -> US -> USM (В разработке, здесь будет ссылка)

• От Job Story к User Story. Часть 2.1. Абстрактная и Конкретная Job Story: связь с ABCDX и др (В разработке, здесь будет ссылка)

• От Job Story к User Story. Часть 2.2. Шаблон User Scenario, User Story и Use case в Confluence (В разработке, здесь будет ссылка)

• От Job Story к User Story. Часть 3. Цикл поставки (В разработке, здесь будет ссылка)

• От Job Story к User Story. Часть 4. Цикл экономики и гипотез. Маппинг Job Story -> Юнит-экономика. (В разработке, здесь будет ссылка)

• От Job Story к User Story. Часть 5. Цикл экономики и гипотез. Связь с другими циклами (В разработке, здесь будет ссылка)

Мы любим говорить: «Нужно делать CustDev». Или: «Нужно считать Юнит-экономику». Или: «Нарисуем CJM — и станет ясно».

Проблема в том, что эти артефакты часто делаются изолированно: JTBD не связывается с User Story, Юнит-экономика существует в вакууме, Use Cases живут отдельно от гипотез, а гипотезы накапливаются и становится непонятно, почему они появились именно в таком порядке.
В результате — знания есть, но целостной картины видения продукта нет.

Всем привет! Меня зовут Рычихин Павел, я являюсь Менеджером продукта и Бизнес-системным аналитиком.

Данная публикация открывает серию статей, в которой я покажу путь от пользовательской потребности через Job Story к пользовательской истории и связи с Юнит-экономикой, используя понятные артефакты и взаимосвязи между ними. Скажу прямо: тем, кто сидит на ЗП и пилит фичи ради фичей, эта статья вряд ли покажется значимой.

Кому подойдёт статья: аналитики, менеджеры продукта или проекта.

К концу этой статьи вы:

• Узнаете структуру серии статей

• Познакомитесь с такими «странными» артефактами, как Абстрактная Job Story и Конкретная Job Story

• Получите 2D-представление схемы связи артефактов развития любого Продукта или Проекта

• Сможете открыть новые возможности для решения своих задач.

Что я сознательно исключаю из этой и следующих статей:

• Технические артефакты: архитектурные документы, БД, методы/контракты и др.

• Бизнес-артефакты: Product Visio и др.

• Версионирование артефактов

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

Схема

Итак. Для начала проиллюстрирую связь артефактов и циклов схематично.

Циклы

Под циклами я понимаю довольно известные понятия и комбинацию входящих в них артефактов:

1. Цикл исследования и разработки (или Discovery)

   В него входят следующие артефакты

   1. CustDev

   2. Abstraction JobS (Абстрактная Job Story в рамках JTBD) + связь с приоритезацией

   3. Specific JobS (Конкретная Job Story в рамках JTBD) + связь с приоритезацией

   4. User Flow (Карта пользовательских сценариев)

   5. CJM/UJM (Клиентский/Пользовательский путь)

   6. User Scenario (Пользовательский сценарий)

   7. Use Case (Сценарий использования)

   8. User Story (Пользовательская история)

   9. USM (Карта пользовательских историй)

   10. БП или UI/UX (бэк или фронт-процессная форма Бизнесс-процесса или UI/UX)

2. Цикл поставки (или Delivery)

3. Цикл экономики и гипотез
   В него входят следующие артефакты:

   1. Гипотезы, метрики и Job Story + связь с Конкретными Job Story (Specific JobS) в контексте бизнеса и Юнит-экономики.

   2. Гипотезы, А/Б-тесты

   3. Маркетинг

   4. Юнит-экономика

   5. Когортный анализ

Необходимо сообщить о свойствах циклов:

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

• Цикличность означает, что внесение достаточного изменения в один из артефактов затрагивает весь цикл артефактов. В связи с этим необходимо проверить весь цикл взаимосвязи артефактов, чтобы убедиться в сохранении целостности.

Каждый артефакт каждого цикла описывается по одной и той же схеме.

Заключение

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

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

В своей работе я ставил задачу иметь гибкий, и в тоже время стойкий фреймворк, который позволяет относиться к процессу жизнедеятельности ИТ-Продукта или ИТ-Проекта с позиции Цели как процесса непрерывного совершенствования (привет Голдратт). И этот фреймворк нашёл успешное применение в моей работе, особенно когда у тебя десятки абстрактных и сотни конкретных job story, и это всё необходимо увязать с User Story. При этом все гипотезы должны легко определяться и прослеживаться в каждый отрезок времени, весь трафик должен быть собран в когорты, а метрики должны лежать на своих местах без использования специальных фреймворков.

Глобальный плюс подхода: по данной связке циклов и артефактов можно организовать работу любого ИТ-продукта или ИТ-Проекта. Все иные артефакты будут служить работе данной связке артефактов. 

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

В следующих статьях я разберу обозначенные циклы и артефакты.

Поехали!