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

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

❦

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

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

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

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

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

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

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

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

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

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

Готовясь к первой лекции в вузе, вспоминал экстраординарные примеры интерфейсов, чтобы зажечь интерес студентов. В число примеров вошел чат головастиков, где каждый участник может подплыть к другим и что-то прокричать в надежде быть услышанным. А также два фрагмента из презентации «Изобретая на основе принципа» гениального Брета Виктора.

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

«Увидеть немедленно». Фрагмент из речи Брета Виктора «Изобретая на основе принципа»

«Сыграть анимацию собой», оттуда же

Ситуации проектирования на примерах дизайна в цифровой среде

Материал этой статьи был написан три года назад в ходе работы над книгой «Как проектировать цифровые сервисы». В нём я разбирался с уровнями сложности в проектировании. В качестве примеров я использовал задачи в области дизайна информационных систем, которыми занимаюсь вот уже 20 лет. Без этих иллюстраций написанное осталось бы сухими теоретическими выкладками.

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

https://ashapiro.ru/articles/design-situations

14 октября был ровно год как я начал писать книгу о Карте реализации историй. Завершил черновик за 11,5 месяцев — почти вдвое дольше, чем работал над текстом первой книги. В этот раз мне помогала небольшая группа поддержки, читавшая книгу по мере её написания и разговаривовашая со мной о её содержании. Спасибо всем, кто был рядом это время, задавал вопросы и пробовал метод.

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

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

Владислав Головач, дизайнер, автор книг «Культура дизайна» и «Искусство мыть слона»

Если вам интересна Карта реализации историй и проектирование на основе историй, то у метода есть отдельный канал — https://news.1rj.ru/str/simapping О крупных новостях я буду рассказывать и здесь, но нюансы КРИ будут рассматриваться в отдельном канале.

Друзья, оказывается сегодня всемирный день бизнес-анализа, с чем я многих из вас и поздравляю 🤗

Узнал я об этом по случаю приятного поздравления от коллег из Казахстана.

Андрей, в честь праздника всемирного дня бизнес-анализа разреши от имени казахстанского чаптера IIBA выразить тебе большую благодарность за твою методологическую деятельность и за участие в наших мероприятиях. Спасибо! Надеемся, что и в дальнейшем ты будешь нас учить и развивать нашу профессию!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Книг «Карта процесса-опыта. Проектирование услуги через её визуализацию» осталось 114 штук, 12% тиража. До Нового года их раскупят. Будет ли допечатка или переиздание пока неизвестно, мне нужно заниматься другими частями системы проектирования.

Посмотреть о книге в канале · у дизайнера книги | Купить

Прототипирование становится доступнее

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

Сегодня прототипирование на основе кода стало ближе, благодаря помощи таких языковых моделей, как, например Anthropic Cloude Sonnet 3.7. Диву даюсь, как ему удаётся программирование и исследование проблем в нём.

Вчера понадобилось накидать по-быстрому прототип. Проверять собирались поведение с прокруткой холста во вьюпорте от наведений на края. Был риск, что наведение на панели, находящиеся в краевых зонах, будет конфликтовать. Это и проверяли.

Я сначала по-старинке решил, что буду сам писать код на Processing, потому что люблю это дело, но спохватился и попробовал дать задачу Клоду. В итоге, я получил рабочий прототип за 9 уточнений подробностей и несколько минут. Правки по неработоспособности кода у Клода минимальные — я пару раз ему скормил сообщение об ошибке, и он выправил код.

Так что, прототипировать теперь можно быстрее. В комментариях привожу запросы к Клоду.

❦

Если вам нравится и не чужда разработка, то предлагаю ознакомиться с материалами Егора Гилёва о прототипировании с AI. Smashing Magazine недавно выпустил его статью о том как создавать прототипы сразу в коде: первая и вторая части

Андрей Шапиро написал о вопросах, направляющих проектирование.

— Вопрос — коммуникационный инструмент направленного размышления;
— В проектировании чаще всего имеют дело с вопросами исследовательскими (определение области, которую надо изучить подробнее) и проблематизирующими (постановка задачи);
— В начале проекта, когда идёт снятие задачи, проектировщики иногда не понимают, куда двигаться дальше;
— Чтобы задать качественные вопросы, надо начать исследование и минимально погрузиться в предметную область;
— Основа мышления — создание в голове схем, отражающих модели реальности. Обнаружив отсутствие важных деталей или нарушение логики в построении схем, мы можем это исправить;
— Вопросы позволяют подсветить себе или проектной группе эти проблемные места. Белое пятно — полное отсутствие понимания (по аналогии с картами до великих географических открытий). Серая зона — место, где понимание туманно, и мы это знаем;
— Есть практики ненаправленного интуитивного творческого поиска (вроде поиска образа в каракулях), но в проектировании нужны более надёжные направляющие;
— Ими могут быть следующие артефакты, уточняющие устройство человеческой деятельности: структура потоков, процессы как цепочки последовательных действий и событий, типичные ситуации и способы принятия решений в них, структура внутреннего устройства объекта, структура взаимодействий объектов и так далее;
— Получив новую порцию знаний в диалоге с экспертами и представителями заказчика, проектировщик обновляет картину и подсвечивает вопросами новые моменты для уточнения;
— Беглость приходит с опытом. Не страшно, если новая пачка вопросов появляется между встречами;
— Шаблонные вопросы позволяют снизить неопределённость на старте. Всегда есть фаза предварительного анализа замысла, выяснения сути задачи, её границ и целей заказчика;
— Всегда важно, как будут построены отношения, каковы у сторон ожидания друг к другу, из чего будет строиться процесс, как будет достигаться результат;
— Примеры вопросов о бизнесе клиента: Как вы работаете? На чём зарабатываете? Где вы берёте клиентов? Какой канал продаж самый эффективный?
— Есть ещё вопросы, демонстрирующие проблемы, когда вы уже увидели проблему, а собеседник — нет;
— Большую часть времени проектировщик задаёт вопросы сам себе. Это проблематизирующие вопросы, в которых сформулирована задача. Например: «Как проверяющий узнает, что по портфелю заново запущена проверка?»;
— Шаблоны таких вопросов: Как сделать так, чтобы появился <отсутствующий пока желаемый эффект> или исчез <наблюдаемый нежелательный эффект>? Как или за счёт чего будет работать <отсутствующий пока механизм> с <таким-то результатом на выходе>? Что, где и как поменять в системе, чтобы удовлетворить <новому требованию>?

#analysis

Пока идёт редактура книги про рабочие истории и Карту реализации историй (КРИ), добавляю в неё иллюстрации и поясняющие схемы.

Хочу поделиться одной такой схемой с процессом картирования историй в нотации Карты процесса-опыта. Надеюсь, эта схема войдёт в издание книги в виде развёртки. В треде прикрепляю в формате ПДФ

Сегодня немного о проектировании собственной жизни. Делюсь признаками выявления одержимости в работе и способом выхода из неё — практика «кормления коней».

Ранее рассказывал об этой практике в подкасте у Саши Ефремова. В заметке более полно удалось раскрыть тему.

Выдержка из упомянутого подкаста на тему выгорания и практики «кормления коней»