USM - злобный и странный зверь, который дается не всем😉

В феврале с одним из клиентов мы разбирали инструмент USM (User Story Map) или Карта Пользовательских Историй.

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

Для этой цели мы решили использовать USM.
Почему?

- Потому что USM поможет отразить полный состав US для продукта, о которых мы знаем на данный момент;

- Потому что USM поможет нам систематизировать потребности пользователей;

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

- Потому что, глядя на USM мы сможем предположить приоритетность US, а как следствие собрать состав MVP и нескольких первых релизов.

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

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

Например, когда команда создает USM до встречи со Стейкхолдером/Пользователем для того, чтобы составить представление о продукте и его функциях - это неверное использование инструмента. Ведь на этом этапе у вас еще нет подтвержденных US, а значит мозг просто начнет их придумывать. Т.е. вы создадите версию продукта, которую хочется получить вам, а не Стейкхолдеру, что гарантирует большое кол-во переделок.

Или еще пример, вроде цель использования USM правильная, но формулировки самих историй нет.
К чему это приводит?
Кривые критерии приемки = неконсистентность функциональности = нестабильная структура продукта = теряется ценность продукта = недоволен пользователь.
Нецелевое описание ценности = сложная функциональность = бесполезный продукт.

Писать еще выловленные инсайты по ИТ-инструментам?