Наткнулся тут недавно на
статью Андрея Шапиро про развитие USM. Прочитал, понравилось (ну почти). А потом мне ещё несколько человек её скинули: кто-то с просьбой прокомментировать, кто-то с предложением внедрять. Каждому отдельно отвечать влом, так что вот вам небольшой и исключительно субъективный разбор SIM/КРИ-подхода.
Пересказывать статью не стану, почитаете при желании. Если коротко, это визуальная «семиэтажная» карта, которая связывает бизнес-цель, контекст, предметные объекты и первый каркас интерфейса в одном столбце. Она помогает команде увидеть сквозную логику «зачем - как - на каких данных - через какой UI», лечит типичную XY-проблему и вытягивает доменную модель.
В целом, мне нравится подход. И местами он даже вполне себе решает свои задачи. Но, будучи убеждённым скептиком и противником любых «голых» методологий, возведённых в ранг аксиомы, давайте-ка я накидаю на вентилятор. А Андрей (которому я скину ссылку на этот пост), быть может, захочет меня переубедить.
Итак, плюсы и сильные стороны метода:1. Чётко лечит XY-проблему. Первый слой «Цель» заставляет сначала сформулировать зачем, а слой «Объекты» выводит доменные сущности «на поверхность», так что ни задача-X, ни данные не потеряются. Здесь, конечно, имеет смысл уточнить, что user story вообще не решает проблему
потребности, только
задачи. С потребностями лучше справляется job story.
2. Сквозная трассировка «цель - процесс - данные - UI». Семь вертикальных слоёв собирают всю логику реализации в одном столбце карты, поэтому дизайнер, аналитик и разработчик опираются на единый контекст. Вот это круто.
3. Читаемый, легко приоритизируемый бэклог. Карта даёт «структурную матрицу» (горизонталь — логика процесса, вертикаль — глубина детализации), а компактный текст историй сокращает время изучения документации. Правда, формат представления тут может перекрыть суть, но это решается применением банального здравого смысла.
4. Самый сок: SIM/КРИ отлично мапятся с Domain Driven Development и Event Storming. Цветовое кодирование слоёв и фокус на домене позволяют встроить метод в воркшопы по моделированию процессов и предметной области. Ну во всякие PI-планирования SAFe.
Есть ещё плюсы, но эти мне показались главными. Метод хорош, но я убеждён, что такая карта не может быть опорным артефактом комплексного проектирования продукта. И вот почему.
Минусы и слабые стороны подхода:1. Тема хорошо работает на уже сформированной бизнес-модели. Если вы — динамичный стартап и ваши метрики определяются в процессе анализа и проектирования, то «чистая» цель вам попросту недоступна. А если корректируются цели, метод по каскаду распадается и карта устаревает уже через спринт.
2. Метод держит в фокусе деятельность, а не истинные потребности людей. Всё равно придётся пилить CJM и другие карты опыта. Это значит, что вы устанете синхронизировать эти документы при малейшем изменении любого фактора.
3. Каркас экранов создаётся слишком рано. Да, это не UI в финальном его виде, но все мы знаем, что дизайнеры мыслят картинками. После того, как конкретный лайаут зафиксировался в их нейронных цепочках, он останется там навеки. И никакие исследования потом этого риска не снимут.
4. При большом бэклоге доска становится нефункциональной. Нет прямой связи историй с KPI, нет явного инструмента синхронизаций (а синхронизация Holst/Miro с таск-трекерами — ебля ещё та, поверьте). Так что на реально большом проекте вы будете тратить целого проджекта или двух на синхронизацию доски и трекеров. Классический USM проще, поэтому и синковать его не так сложно.
5. Фасилитация, кривая обучения и избыточность на маленьких фичах. Объединил это в один пункт, потому что метод реально сложный. На мелкой хрени типа «добавить оплату через Х» он избыточен. Для полного его понимания и эффективного применения не достаточно просто скинуть статью. Ну и без грамотной фасилитации карта, как я уже сказал, устареет буквально через спринт.
Есть ещё недостатки, типа сложностей с инкрементальной поставкой и перебором upfront-аналитики, но и так получился лонгрид, телега мне тут пишет минусы в количестве символов
ПА 
