Принцип самоорганизации: Терпимость к отдельной оплошности и нетерпимость к серии ошибок

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

А важным здесь является не единичный случай, а структура формирующая серию неудач, если такая есть, конечно. Один раз опоздал на встрече — не беда. Хроническое опоздание обнажает неверные подход к планированию времени, неверной модели реальности. Именно серия случаев, а не единичный является наиболее важным сигналом к пересмотру стратегии.

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

Оплошность не проблема, и не причина для самобичевания и расстройства, важнее исключить систематическое проявление ошибки, становящееся проблемой.

Вадим Митякин и Андрей Шапиро обсудили CJM и Карту процесса-опыта.

— В CJM представляют линейный путь пользователя, который решает какую-то задачу, разложенный на ключевые точки, где с потребителем происходит что-то важное;
— Даже если в этих точках мы, как создатели продукта, во взаимодействии не участвуем;
— Цель — понять, как создать для пользователя ценность, помочь ему с решением задачи на том или ином шаге с помощью функций нашей системы;
— Функции CJM: фиксация, формирование единого понимания участниками процесса, включение новых участников, управление процессом изменения;
— Нет какой-то единой или классической нотации CJM;
— Нотация BPMN фиксирует процессы. Люди там тоже есть, но они на периферии;
— CJM нужен, чтобы попасть в шкуру пользователя, что-то понять и перейти к созданию какого-то конкретного решения для определённой ключевой точки. Поэтому CJM часто остаются пылиться после создания;
— Карта процесса-опыта — результат эволюции гибридной нотации CJM и Service blueprint;
— Она позволяет соединить опыт потребителя (или других участников взаимодействия) с обеспечивающими этот опыт процессами;
— В отличие от CJM у неё есть конкретная нотация. В отличие от BPMN, нотация простая, с минимумом элементов, не требующая специальных знаний, чтобы её читать;
— Также в отличие от BPMN она учитывает, что это не программы, а живые люди, которые не всегда обязаны двигаться по процессу. Потребитель может просто уйти;
— Но если вы пришли на проект, где все говорят на языке BPMN, возможно, не стоит этого менять и лучше подстроиться;
— Карта процесса-опыта соединяет машины и людей, показывает связь бизнес-модели и инструментов, задействованных в ней.

Копия видео в ВК. #cjm #sb

Истории-сюжеты

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


❦

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

Одна из историй могла бы звучать так:

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

А вот другая история.

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

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

1. Каждый отрывок написан так, что удерживает внимание читателя на одном герое
2. Каждый рассматривает свою уникальную ситуацию глазами героя
3. Каждый формирует складный сюжет, развивающийся строго последовательно
4. Каждый сюжет соответствует композиционному шаблону «завязка—кульминация—развязка», то есть рассматривает сначала причину всего последующего, затем главное препятствие и, наконец, путь его преодоления
5. Каждый отрывок максимально конкретен: не содержит обобщений и описывает в подробностях личные переживания и особенности отдельных людей

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

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

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

Бессюжетные тексты утверждают порядок и регулярность. Они «вскрывают структуру жизни на каком-либо уровне ее организации» [Лотман, 1998]. В этом смысле подобные тексты всегда обобщают и выводят закономерность, пусть даже временного характера. Так как проектирующему важно понимать как что-то устроено в мире, что повторяется и остаётся неизменным для некоторого круга лиц в определённых ситуациях, ему больше подходят бессюжетные тексты.

(Продолжение следует)

Дизайн современного сервиса с Картой процесса-опыта

Через девять дней в Ярославле пройдут очередные Дизайн-выходные — короткий слёт дизайнеров всей страны.

Я там расскажу о подходе к визуализации потребительского опыта совместно с описанием рабочих процессов в сервисе. Метод прошёл восьмилетнюю обкатку и создавался в первую очередь для CX- и UX-дизайнеров.

ГДЕ
Ярославль, Московский проспект 84 — ЯГТУ, корпус А, Зал 5

КОГДА
30 ноября, 17:00

Регистрируйтесь по ссылке

Вред историй-тем

User story — микропроект, который можно сдать заказчику

Очень, очень согласен с тезисом 👍 Увидел в цитировании доклада Дмитрия Блинова у Максима Цепкова.

Вот только истории в примере USM у Дмитрия содержат не истории, а темы: найти треню и записаться, инфо о тренере, инфо о клубе.

Вероятно команде показалось, что ценность этих тем самоочевидна, и они решили, что чекбокс V (value) в принципе записи хороших пользовательских историй INVEST закрыт. Но это не так. Здесь указаны то действия, то куски информации, но не ключевая суть ценности для потребителя.

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

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

Трудности принятия допущений. Пропущенный сценарий

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

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

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

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

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

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

https://rutube.ru/video/878dbb09c490756ea2efe789b6cdf526/?r=wd

Приятно получить такую высокую оценку от коллег по цеху

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

Настя Выдра, Дизайн-матрёшка

Это оч круто! И чертовски потенциально

Олег Питецкий, стратег Студии Артемия Лебедева

На Дизайн-выходных я стал случайным свидетелем доклада-откровения Артёма Кожевникова. И пусть предмет доклада в своих формах касается быта дизайнера, в нём мощный пример искренности, личной рефлексии и неравнодушия к собственному пути, а поднимаемый в названии вопрос касается каждого. Являемся ли мы лишь эхом или имеем собственный голос.

Доклад-вдохновение. Доклад-кувалда. Рад, что чуть причастен к выходу в свет этого кусочка живого и трепетного

https://rutube.ru/video/12a6699efaa1a03bec88cc82d4563575/

В середине этой статьи-интервью Александра Бындю сообществу экспертов Скиллбокс есть упоминание Карты процесса-опыта и Карты реализации историй. Наши методы применяются совместно в фреймворке возведения и развития антихрупкого продукта

Почему вообще возник такой формат как процесс-опыт. Давайте взглянем на картинку. На ней два человека сообщаются через информационную систему (ИС). Они делают одно дело. Желтыми полосками показаны потоки внимания этих людей. Время от времени они прерываются — люди переключаются на что-то другое, не связанное с рабочей задачей. Красным показаны барьеры из-за разрывов внимания. Потом, волей судеб или благодаря чему-то конкретному, внимание возвращается, и дело продолжается. Черными стрелками здесь отмечены посылы информации в систему. Хорошо, когда мы сразу проектируем то, что вернёт человека в систему или не выгонит его внимание из неё долгим ожиданием или отсутствием чего-то важного.

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

За этот год мы в Бындюсофт сделали многое для развития фреймворка проектирования социотехнических систем.

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

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

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

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

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

По ссылке материалы обо всех перечисленных методах:
https://yangx.top/byndyusoft/530