Вчера стукнуло шесть лет со дня выхода самой читаемой моей статьи на Медиуме. Руководство по карте пользовательских историй прочли 5500 раз и 500 раз апплодировали. Сейчас, когда Медиум заблокирован, статья доступна на сайте.

Хотя я пишу давно, но именно с этой работой я впервые понял, что такое писательство и какого труда это сто́ит. Но мне понравилось 😊

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

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

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

О потоке по-человечески

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

1. Принцип визуализации: всё, что невидимо, неуправляемо. Как только ты выклыдываешь что-то на доску, ты обретаешь силу управлять этим в мышлении. Также, Rumpelstiltskin principle: When you name something then you have a power to talk about it.

2. Многослойность знания. Приходится работать в разных пространствах, чтобы смотреть на один и тот же объект с разных сторон. Речь о проектно-инженерном знании и о предметном или онтологическом, что возвращает картину мира деятельности.

3. Строгость категориального мышления. Отказ от мыслительной «склейки» и работы с ассоциациями. Упор на различение тонкостей.

3.1. Отделение формы воплощения от смысла (как следствие). Все три метода фреймворка построены так, что они отделяют принципиальное от деталей реализации. КГ разделяет цели и задачи, соединяя их через принципы-стратегемы. КПО выделяет значимые функциональные места в процессе, отделяя их от способ воплощения. КРИ расщепляет модель поведения или действия человека на рабочем месте или в жизни на слои от смысла шага до форм реализации иснструмент. Журнал проектирования различает фрагменты знания по их смыслу в проектной деятельности.

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

5. Программный подход. Учёт, а не отказ от сложности. Вовлечение всех заинтересованных лиц в формирование знаний. Знаковые конструкции из фрагментов знаний направляют и «выдавливают» итоговое решение

6. Принцип пережигания неопределенности в работоспособность. В нашей работе всегда есть две направляющие силы: движение в сторону сжигания неопределенности (белых и серых пятен) и движение в сторону достройки работоспособной конструкции деятельности в мыслительной имитации с опорой на схемы.

★

К методам социотехнического подхода на данный момент относятся:
— Карта гипотез
— Карта процесса-опыта
— Карта реализации историй
— Связанный свот-анализ

Программирующее дерево

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

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

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

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

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

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

Мне понравилось. Техника помогла подготовиться к грядущей сессии по Карте гипотез с заказчиком. До этого в беседе, он уже перечислил опорные точки. Из текста речи заказчика я зафиксировал их в тело SWOT, а после вытащил первые 2 гипотезы для проверки.

К технологии Карты гипотез добавился предваряющий шаг со своей логикой. Рекомендую

6 мая в 19:00 мск расскажу о технологии работы с детальными требованиями с Картой реализации историй.

Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе с тем, их инструментарий настолько давно не развивался, что пришло время это исправить.

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

Метод Карты реализации истории входит во фреймворк проектирования социотехнических систем.

6 мая, во вторник вечером, Андрей Шапиро, проектировщик цифровых сервисов и методолог проектирования, расскажет о переосмыслении личного и отраслевого опыта работы с пользовательскими историями.

Ссылка на регистрацию

📍 22 мая в Москве проведу долгожданный дневной тренинг по Карте процесса-опыта. Занимаемся с 10 до 18 с перерывом на обед. В группе будет до 10 человек, чтобы успеть проработать карты. Приходите учиться.

Записаться на тренинг

В 19:00 по Москве начинаем про Карту реализации историй. В этот раз начнём с подробного разбора недостатков классических пользовательских историй. Затем выйдем на рабочие истории КРИ

https://youtube.com/live/16syPUiuNT4

🎞️ Запись эфира о Карте реализации историй

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

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

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

ВКонтакте
Рутуб
Ютуб

Меня много раз спрашивали когда будет обучение по Карте процесса-опыта. Ещё есть шанс попасть на очный тренинг 22 мая в Москве. Когда будет следующий и будет ли — пока неизвестно

Возможно вы пропустили, но у нас тут организовался тренинг по инструменту Карта Процесса-Опыта. 22 мая в Москве, офлайн.
Тренинг будет вести автор подхода - Андрей Шапиро. Считайте уникальный шанс поучиться у автора.

Кому интересно - велком сюда: https://neogenda.com/karta-processa-opyta

Хочу поделиться введением для моей новой книги «Рабочие истории. Практика проектирования с текстовыми моделями Карты реализации историй». За счёт примера из него должна стать понятна суть работы с рабочими историями.

❞

Введение

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

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

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

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

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

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

❦

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

— Хорошо, что происходит дальше? — спросил дизайнер.
— Дальше уведомление у продавца — отвечает заказчик.
— Здесь важно написать кто и как действует. Действует у нас вроде бы продавец.
— Продавец получит мгновенное уведомление.

Дизайнер записывает что-то в странный формуляр:

Н: Продавец
С:
Д: Получает мгновенное сообщение
О:
Ц:

— Так, хорошо. А почему ему это важно?
— Что важно?
— Я услышал так: продавцу важна мгновенность сообщения
— Ну, как? Он же хочет продать, — улыбается заказчик
— Да, но почему важна скорость? Пусть, например, получит «медленное» сообщение. Скажем, через час или сутки. Что тогда?
— Тогда он вероятнее всего останется без заказа.

Дизайнер быстро черкнул в формуляр рабочей истории:

Н: Продавец
С:
Д: Получает мгновенное сообщение
О:
Ц: Чтобы не остаться без заказа

— А почему он останется без заказа?
— Ну, мы же на рынке. Всем нужно быстро. У нас B2B-маркетплейс, покупатели это станции технического обслуживания. Им нужно быстрее своих клиентов обслуживать. Когда продавец подолгу не отвечает сможет ли он поставить товар, поиск продолжается, — выпалил заказчик. Затем, усмехнувшись, добавил: — Вы же, небось, когда поступали в университет сразу документы в несколько подавали. Чтобы наверняка.

Дизайнер дописал на глазах у заказчика:

Н: Продавец
С:
Д: Получает мгновенное сообщение
О:
Ц: Чтобы выиграть в конкурентной борьбе

— Вот. Именно! Выиграть в конкурентной борьбе. Они и по цене конкурируют друг с другом.
— Хорошо, а как происходит эта борьба? Кто с кем соревнуется?
— Ну, смотри, если мы определили, что товар есть у нескольких поставщиков, то есть продавцов, мы при покупательском заказе смотрит какого выбрать. Там множество критериев: территориальная близость, рейтинг продавца: скорость его реакции, скорость поставки, качество продукции по оценкам потребителей, количество возвратов. Всё это мы смотрим, и, скажем, выиграл у нас продавец «Быстрые тяги». Мы ему отправили запрос, он должен его успеть взять.
— Ага, становится понятнее, — проговорил на автомате дизайнер, чтобы дать понять, что слушает, пока дописывал подробности в историю.

Н: Продавец
С: Когда поступает новый заказ
Д: Получает мгновенное сообщение
О:
Ц: Чтобы выиграть в конкурентной борьбе

— Но всё таки непонятно почему нужна мгновенность сообщения. Ведь продавец уже выиграл в конкуренции на площадке.
— Э, нее-ет. Мы у него отберём заказ и отдадим другому продавцу, если он будет медлить.
— Это через сколько?
— Ну, положим, через полчаса нужно отбирать и отдавать следующему в нашем списке победителей. Пусть конкурируют. Хотя я не уверен насчёт периода. Это нужно будет опытным путём определить.
— То есть, если я верно понял, важно вовремя увидеть, что заказ пришёл и успеть отреагировать на него?
— Точно!
— Тогда я бы это так записал, наверное:

Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О:
Ц: Чтобы не упустить его, когда система отдаст его конкурентам

— Да, всё так.
— По технологии мы ещё должны заполнить слой объектов оперирования. Это вещи и данные, с которыми продавец работает на этом шаге.
— Ммм...
— Я бы записал так. Раз продавцу необходимо успеть отреагировать, то ему важен сам сигнал о поступлении, а также, наверное, время, которое у него есть на его обработку.
— Да. И содержание заказа. Ему надо проверить наличие. Там у него обычно несколько сторонних учётных систем и разных маркетплейсов. Информация о реальных остатках всегда запаздывает. Мы можем продать то, чего уже нет.
— Ага, значит допишем, — печатает дизайнер.

Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О: Работая с сигналом о новом заказе, содержанием заказа и временем на его обработку,
Ц: Чтобы не упустить заполучить заказ до того как его отдадут конкурентам

— Отлично. История готова. Я бы подумал о вариантах её реализации.
— Ну, я же говорил уведомление.
— Да, теперь мы понимаем, что важно как-то оповестить продавца. С чем сейчас работают типичные продавцы? Что у них есть из оборудования?
— Все сидят в телефонах. Это самое простое. У большинства компьютеры у прилавков, но часто продавец болтается на складе, его надо оповещать и там. Мобила самый простой вариант.
— Сообщение в чат-боте?

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

— Как вариант. Не разоримся на разработке?
— Чат-бота придётся разрабатывать, да. Чуть дороже будет. Можем подавать громкий сигнал как в ЖизньМарт или МакДональдс, когда поступил заказ. У компьютеров на прилавках есть колонки?
— Поставят, если ещё не поставили. Им же важно успевать.
— Тогда основным вариантом будет звуковое оповещение в основном веб-приложении, чат-бот отложим как альтернативу.
— Положим.

Н: Продавец
С: Когда поступает новый заказ
Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени
О: Работая с сигналом о новом заказе, содержанием заказа и временем обработки,
Ц: Чтобы не упустить заполучить заказ до того как его отдадут конкурентам
Р: 1. Звуковой сигнал в веб-приложении + информация о содержании и времени на обработку заказа в перечне входящих заказов
Р: 2. Сообщение в чат-боте

❦

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

24 мая на конференции UWDC в Челябинске расскажу о том как структурировать беседу с заказчиком, чтобы гарантированно прийти к желанному результату.

С этим же докладом я выступлю на Дизайн-выходных в Казани, которые пройдут 30-31 мая