Школа скрам-мастеров

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

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

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

🥹🤪😳 А во время составления Карты, я слышу от команд восклицание: «А мы думали, что…, а оказалось вон оно как можно было!»

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

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

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

🕵‍♀Несколько вопросов по поводу того, кто будет пользоваться результатом вашей деятельности приводит нас к следам 👣 пользователя, не всегда сразу 😅

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

Сейчас вы можете воскликнуть «Так это мы увидели некорректную нарезку команд! Надо срочно всё менять!»

Пожалуйста, будьте аккуратны в подобных заключениях, они свойственны начинающим агентам изменений, а также тем, кто влюблён в какой-то конкретный фреймворк и начинает его «натягивать» везде… 🦉🌏

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

На просторах Интернета вы можете найти множество примеров Карт пользовательских историй и … не все они на самом деле являются ими 😔 Давайте разбираться.

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

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

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

Это мой самый любимый миф 😁 Вот есть у некоторых консультантов перекосы в одну или другую сторону. Одни «топят» за пользовательские истории, другие — за джоб стори … Однако, мир не чёрно-белый, а пользовательские истории уже потеряли свой первоначальный вид, когда составлялась некая усреднённая персона. Давайте обо всём по порядку.

Бывает такое, что команда только отстраивает процесс, тот путь, по которому будет ходить клиент, и есть ряд шагов, которые клиент ну никак не хочет, чтобы были и, если их формулировать через: «Я, как кто-то <роль>, хочу что-то <функциональность>, для того чтобы <потребность>», звучит она абсурдно и слышно от команды: «Да не хочет этого пользователь!»

Например, «Я как клиент банка, хочу иметь возможность сканировать QR-код, для того чтобы осуществить платёж без банковской карты, так как постоянно её забываю»… Ауч…🙈

Тут мы видим уже и реализацию…

но порой конкретика по реализации нам очень даже нужна и как же быть?!

Такие истории мы перефразируем в джобы, т. е. Job Story, через «Когда» и слегка её адаптируем под наш контекст, с учётом той реализации, которую хотим дать клиенту сейчас.

И пот итогу у вас может получится что-то такое:

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

Помимо того, что у вас в Карте пользовательских историй могут быть как пользовательские истории (User Stories), так и джобы (Job Story), у вас также могут быть технические истории. Например, при разборе оплаты по счёту контрагенту, может появиться «Встроить проверку Комплаенс, чтобы не попасть под нарушение 115-ФЗ».

Также про QR-код у команды может быть как целая отдельная техническая история, так и подзадача, которой не будет на карте, она будет внутри Job Story (в нашем примере).

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

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

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

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

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