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

❦

— Формально соблюдён формат рабочей истории — заполнены все её пять элементов

— Каждый из пяти элементов по содержанию соответствует своей категории. Например, в Ситуации описан контекст возникновения истории, а не что-то иное, и так со всеми другими элементами

— Содержание элементов истории согласованы между собой

— Смысловая ценность истории ясна и понятна всем участникам рабочей группы. Внутреннее ощущение: понимаю задачу, ощущаю боль, вижу потребность пользователя или бизнеса

— Поставка изменений к выявленной потребности находится в сфере влияния рабочей группы

— В воображении появляются образы решения на основе формулировок истории

— Ощущается внутренняя готовность действовать: хочу приступить к проектированию или разработке по истории

Ребята, книга на подходе. Как у вас с практикой записи рабочих историй и составления Карты реализации историй?

Сегодня поделюсь секцией из книги «Рабочие истории. Проектирование через текстовые модели поведения с Картой реализации историй». Надеюсь закончить её черновик к концу сентября. В этом отрывке разобран щепетильный момент замены в историях пользователя на систему.

❦

Инверсия Носителя действия
В главе 7 мы встретили приём, когда рабочая история была переписана так, что в Носителе действия вместо пользователя появилась система. Этот приём как мощный, так и чрезвычайно опасный. Многие так и записывают требования к системе, вот небольшой отрывок из подобных описаний.

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

Проблема здесь в том, что написавший это, ещё мог как-то думать о сути происходящего. Он представлял себе части своей деятельности, конечный результат и то, как в результате изменений поменяется процесс. Однако по получившимся описаниям невозможно восстановить эти мысли. Главная проблема всех технических заданий (ТЗ), в шутку называемых «не ТЗ, а ХЗ», в том, что они скрывают ход мысли тех, кто их составлял. Даже писавший их через некоторое время не вспомнит почему он сделал то или иное допущение в качестве конкретного решения. Концентрация на функциях системы всегда приводит к такому зауженному видению и амнезии.

Рабочая история — это в первую очередь текстовая модель поведенческой потребности человека, и рассматривать в ней нужно действующее лицо. В период активного развития пользовательских историй в практике User Story Mapping допускалось записывать истории для разрабатываемой информационной системы, чтобы описать некоторые технические действия в ответ на предыдущую историю пользователя. Однако, на мой взгляд, все необходимые действия системы можно и лучше описать в Формах реализации под историей, так что отдельная история для системы не нужна. Когда же тогда допустимо записавать рабочии истории для системы?

Во всех ситуациях, когда нам важно что-то разработать, но у потребителя нет его собственной явной потребности, мы всё равно должны отыскать к чему прикрепить этот запрос. Чаще всего это ситуации, когда мы встречаемся с потребностью бизнеса как-то влиять на потребителя или пользователя. В этом случае мы могли бы записать рабочую историю для бизнеса, с Целью действия в его картине мира. Например, там будет «Побудить потребителя покупать залежавшийся на складе товар». Бизнес хочет побудить потребителя, однако делать он это будет скорее всего некоторым поведением системы. Например, будет рассказывать об акционных скидках и распродажах. Вот когда в Носителе действия закономерно появляется часть системы, которая будет воплощать эту потребность бизнеса.

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

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

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

- Оператор видит какие параметры далеки от нормы, чтобы исправить ошибки настройки
- Колцентр понимает какие способы доставки в городе не на ходу и какими их допустимо заменить для оперативного восстановления логистического тракта
- Оператор видит суммарные статистические данные для использования их в пресс-релизах
- Оператор выгружает отчёт о текущих тарифах в формате Excel для субъекта доставки, чтобы получить данные для отчёта перед руководством.

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

Потихоньку пополняется копилка типовых ошибок при работе с Картой реализации историй. Недавно в это внесли свою лепту мои студенты.

Какую ошибку видите в экранно-блочной схеме?

«Я, как пользователь…» и что с этим не так. «Рабочие истории» Андрея Шапиро как апгрейд User Story

Многие аналитики писали User Stories. Каковы их слабые места? Часто «Я, как пользователь…» на самом деле прикрывает «Я, как бизнес, хочу, чтобы пользователь…», а ценность в «чтобы…» притягивается за уши просто для соблюдения формата .

Но главная боль, как по мне, в другом. В классической User Story нет предметной области. Нет данных, нет сущностей, нет «объектов». Из-за этого получается огромный разрыв между историей и тем, что потом увидят дизайнеры и разработчики.

Андрей Шапиро дал почитать рукопись книги о своем методе «Рабочие истории». ИМХО, это очень удачная попытка всю эту кухню систематизировать и вылечить. Это не просто «еще один шаблон», а целая технология.

Структура и содержание

Книга разделена на две части. Первая часть анализирует эволюцию пользовательских историй как инструмента сбора требований. Андрей делится практическими примерами из реальных проектов, обсуждая шаблоны, преимущества и недостатки user stories. Он подчеркивает их роль в преодолении "вавилонской башни" — языковых барьеров между стейкхолдерами, — но отмечает ограничения: краткость часто приводит к потере контекста, а отсутствие строгой структуры затрудняет работу в сложных доменах.

Новый шаблон «Рабочей истории» (НСДОЦ)

Вторая часть вводит ключевую инновацию — рабочие истории и Карту реализации историй (КРИ). Рабочие истории расширяют шаблон user stories, фиксируя не только роль, функциональность и ценность, но и ситуацию, объекты оперирования, а также каскад реализации (от замысла к форме).

Автор предлагает 5-компонентную структуру:
• Н (Носитель действия)
• С (Ситуация)
• Д (Способ действия)
• О (Объекты оперирования)
• Ц (Цель действия)

И ключевое здесь — «О (Объекты оперирования)». Нас наконец-то заставляют на уровне требования описать, с какими вещами, данными и сущностями работает носитель действия. Это сразу снимает кучу вопросов и заземляет историю.

«Карта реализации историй» (КРИ)

Это тот самый мост от «что» к «как». КРИ — это матрица , где по горизонтали идет процесс (логика следования) , а по вертикали — «каскад реализации». Каждая история раскладывается на:

• Саму Рабочую историю (описание необходимой деятельности) .
• Форму реализации (как именно это будет воплощено, какие технологии, допущения, решения).
• Структуру блоков интерфейса (что конкретно будет на экране, какие инфо-блоки и элементы управления).

В итоге получается мощное развитие техники. Такой подход лечит «проблему молотка» (когда в User Story сразу «пихают» готовое решение, а не потребность). И он помогает четко отделить потребности пользователя от требований бизнеса (для этого есть специальный прием с инверсией Носителя, когда им становится «Система»).

Для аналитиков книга предлагает практический фреймворк для сбора требований в запутанных проектах. Метод помогает структурировать беседы со стейкхолдерами, выявлять пробелы в знаниях и проверять адекватность моделей. Вспомогательные практики — приёмочные тесты, чистка от ложных требований, оценка в сторипоинтах — интегрируются с agile-подходами. Примеры ошибок и рекомендаций по сессиям картирования делают книгу ценным руководством для командной работы. Автор подчеркивает: без практики инструмент не освоить, рекомендуя применять техники на реальных проектах.

В общем, для системных и бизнес-аналитиков — очень советую прочесть книгу, когда она будет опубликована. (А также для продактов, дизайнеров, разработчиков). Это достаточно просто, но куда более строгий и инженерный подход к требованиям, чем то, к чему многие привыкли.

Канал Андрея - https://news.1rj.ru/str/how2scheme

Случайно был найден хороший подход — разделение этапов большой КРИ на фреймы. Чем это хорошо. На уменьшении масштаба ярлычки тематической группировки остаются читаемыми

Но вскоре КРИ появится в сервисе Социотех, где метод будет максимально поддержен автоматизацией. В видео-анонсе под неё появились иконки в навигации по холсту с картами

Мини-навигация для быстрого перемещения между картами

1. В любой момент можно быстро переключаться между картами.
2. Оставлены заготовки для карт, которые появятся в скором времени: ИИ-ассистент, Карта процесса-опыта и Карта реализации историй.

---
Создавайте свои решения в Социотехе https://sociotech.center

В новой книге о Карте гипотез в главе 6.4 уделено внимание тому как организовать дальнейшее проектирование. И упоминается метод Карты реализации историй с примером