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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Канал Андрея - https://t.me/how2scheme