Если вы в Челябинске или Казани, приходите на мой доклад о мышлении историями. В Челябинске он пройдёт 24 мая на UWDC, в Казани — 30-31 мая на Дизайн-выходных

Презентация сегодняшнего выступления на UWDC и другие материалы по Карте реализации историй

Преимущества Карты реализации истории, которые я вижу на текущий момент.

Полезное действие
📍Шаблон рабочей истории организует беседу заказчика, потребителя и рабочей группы. Это помогает коммуницировать более направленно и точно, что сокращает время.

📍Карта и её метод даёт технологию завёрстывания истории, где поиск смысла содержания истории идёт параллельно с поиском решений.

📍Выход на решения стал более быстрым с новыми слоями-«линзами» объектов оперирования и структуры элементов UI. Они проясняют то, с чем идёт работа, а также снижают число выходов на перепроектирование.

📍Расслоение модели потребителя на три слоя упростил процесс сбора знаний в этой части контекста. Сейчас за это отвечают три слоя: носитель действия, ситуация и способ действия.


Преимущества формата
📍Пустые элементы важных слоёв требуют своего заполнения.

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

С методологической точки зрения
📍Каскад реализации организует работу системно, вовлекая в это второе понятие системы. Учитываются функциональный и процессуальные слои, а также слой организованности материала.

📍Шаблон рабочей истории охватывает элементы схемы акта деятельности из системомыследеятельностной методологии.

Свежак. Слайды и видео сегодняшнего выступления о мышлении историями на Дизайн-выходных.

https://ashapiro.ru/talks/tpost/zy9c2lp5d1-d-v-mishlenie-istoriyami-kak-tekstovie-m

Павел Шерер сделал обзор на КРИ, отметил плюсы и минусы со своего ракурса. Я ответил на его тезисы в этом эссе. Получилось довольно объёмно, но возможно именно в ответах на высказывания эксперта, пробующего разбираться по прочитанному, метод раскроется для вас глубже.

Появляются первопроходцы, кто использует вместе с Картой процесса-опыта, Карту реализации историй и Карту гипотез. Сегодня был интересный вопрос по связи КПО и КРИ. Похожий вопрос мне задали на последнем докладе о КРИ, поэтому спешу поделиться ответом.

Сейчас завершаю КПО и перехожу к КРИ, в КПО уже получилось много ключевых точек и если буду идти чисто интуитивно, то что-нибудь забуду. Появилась мысль, что каждую ключевую точку (закрашенную, подконтрольную нам) КПО можно "приземлить" в инструментальную форму КРИ, что условно равно 100% покрытию системы. Вопрос: корректно ли организовывать переход из КПО в КРИ путем преобразования каждой закрашенной ключевой точки в одну или несколько деятельностных историй? — спрашивает Дмитрий Прокопьев

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

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

То есть созданный инструмент многократно использовался в разных точках процесса.

Маша Даровская, деврил Скиллбокс и редактор в Онтико, написала статью по видео моего доклада. Маша позвала меня выступить в клубе экспертов Скиллбокс уже во второй раз. До этого я рассказывал о КПО, теперь — про Карту реализации историй. Ну, а Маша всё это перенесла в доступный текст и разместила на Хабре, за что ей отдельное спасибо 🤗

https://habr.com/ru/articles/917176/

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

https://ashapiro.ru/talks/tpost/jssaoink11-karta-realizatsii-istorii-ubiitsausm

Пример рабочей истории

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

Впервые увидел его в Camunda Modeler, на её примере и показываю. Он висит на горячей клавише S.

Вот рабочая история, описывающая этот инструмент. Мне его очень не хватает в современных электронных досках.

Н: Пользователь инструмента рисования диаграмм,
С: Когда работает с объёмной схемой, в середину которой нужно сделать вставку,
Д: Сдвигает пропорционально вправо/влево или вниз/вверх все элементы холста, находящиеся правее или ниже линии, проходящей через курсор,
О: Оперируя вертикальным или горизонтальным курсором-«скребком/тягачом»
Ц: Чтобы экономить время на расчистку места, уходящее на отлёт, выделение, перенос и возврат на нужный зум

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

❦

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

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

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

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

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

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

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

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

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

❦

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

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

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

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

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

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

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

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

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

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