Двигаюсь дальше в проращивание нового метода на смену User Story Mapping (USM). В прошлый раз я выстраивал критику метода USM и в минусах коротко затронул почему я хочу двинуться дальше в его развитие. Сейчас пришло время поговорить о полезных практиках, что проросли в моей авторской интерпретации USM.
Материал о моём авторском прочтении метода USM представлен в серии статей «Полное руководство по сбору требований в формате User Story Mapping»:
Как оказалось и этот метод подвергся незаметной для меня приработке в личной практике. Подход, который я описываю и которому учу коллег, отличается от того, что закладывали авторы. Так же было и с моей гибридной версией CJM и Service Blueprint дошедшей в итоге до практики Карты процесса-опыта. Потребовался рефлексивный взгляд со стороны, чтобы увидеть произошедшее развитие и оформить это в новый метод.
В этой заметке я хочу ещё раз оглядеться и сформулировать важные аспекты USM, что хочу сохранить в будущем методе.
Корни могущества USM
Вот коротко то, что делает всю работу в методе, на мой взгляд.
- Слитная запись важнейших разнородных элементов деятельности, а именно: целей деятельности, способа деятельности и аспектов ситуации. См. картинку ниже, где показаны основные элементы структуры истории, соотнесённые со схемой акта действия.
- Разделение замысла и реализации: замысел-потребность, лишённая любых упоминаний о форме реализации, находится на уровне хребта историй, а реализация — под ним. Если вы дисциплинированно разделяет содержание замысла и форму воплощения, то метод играет всеми своими красками, помогая перебирать варианты реализаций на любом этапе проектирования и разработки.
- Текстовая фиксация как таковая. Любая записанная формулировка содержания истории, создаёт причину для дальнейшей коммуникации об этом содержании и его утончении. Правда, нужно внутренне иметь ещё и устремление, намерение снижать неопределённость и разночтения.
- Выкладывание в последовательность. Когда истории записаны друг за другом, это создаёт ещё и контекст разговора о процессе как последовательности или алгоритме. Да, не слишком подробно, без ветвлений, не всегда порядок имеет значение, но это уже нюансы. Важнее то, что после введения логики следования, её уже нельзя игнорировать в размышлениях. Это углубляет понимание отдельных ситуаций и процесса в целом.
Если хочется наглядно разобраться с выделенными аспектами, привожу схему. На картинке приведено сопоставление структур пользовательской истории и карты со структурой акта действия из теории мыследеятельности, разработанной Московским методологическом кружком.
Отличие моего авторского диалекта USM
Обобщая весь опыт работы с методом, я бы выделил такие фокусы, дающие преимущество в проектировании. Будьте внимательны, здесь я отхожу от догматов тех, кто разрабатывал подходы пользовательских историй и карты пользовательских историй.
Строгость структуры историй
Удивительно, что создатели формата пользовательских историй Майкл Кон и автор метод USM Джефф Паттон утверждают, что неважно насколько хорошо вы запишете истории. Они, говорят так: история это плейсхолдер, то есть начальный заполнитель. Паттон рекомендует не спорить долго о формулировках, а записать-зарисовать первое, что приходит в голову.
Да, подобная рекомендация является прекрасным растопщиком «льда» на совместных сессиях картирования. Однако это решает только психологические трудности коммуникации, но никак не решает задачу точного выявления сложного объекта. С точки зрения третьего корня силы метода — фиксация как таковая, конечно, это лучше чем ничего, тут не поспоришь. Но выделенные мной первые два пункта (строгая запись согласно структуре и разделение замысла и реализации) при такой упрощённой форме записи историй уничтожаются.
В записи историй часто путают способ того как разработчикам или потребителям/пользователям хочется решать какую-то из деятельностных задач с тем, из чего эта задача содержательно состоит. История это всегда гипотеза, и в ней легко бесплодно фантазировать о конкретных решениях, тогда как важнее всего разобраться с предопределяющими эти решения ситуациями и реальными способами организации деятельности. Только строгое заполнение структуры формата может гарантировать сохранение логики выделения важных компонент.
Ещё чаще опускают в записи ценность или записывают вместо неё липу. Ниже я иллюстрирую это на набившем оскомину примере с авторизацией. Обычно я слышу такое: а что там описывать в ценности, очевидно, что нужна авторизация. Я считаю, что это прямое нарушение догмы метода. Если вам очевидна ценность, хорошо, тем лучше, значит вы быстро запишете её. Но обычно вас ждёт фиаско. Даже в такой очевидной на первый взгляд ситуации как авторизация можно найти и записать смысл и ценность требуемой операции. Ниже на рисунке я привожу три варианта истории, одну с липовой ценностью, как пишут многие, и две другие с ценностью, берущей смысл операции.
Здесь «горизонтальные» ценности — это отсылка на продукт, яляющийся исходным материалом в следующей истории. Лучше избегать горизонтальных ценностей и указывать «вертикальные» — такие, что выявляют смысл действия, вместо результата в контексте ближайшей следующей операции
И, кстати, когда мы записали полную историю про авторизацию можно наконец понять, что никакой особенной ценности в предотвращении доступа к чужим данным в нашем конкретном случае нет. Например, можно обойтись либо временным хранилищем сделанного в локальном хранилище браузера, либо дать человеку ссылку, в которой будут запакованы все необходимые данные, если мы делаем что-то небольшое. Всё сильно зависит от ситуации и в эти варианты мысленно «не сходить», если раздельно не держать записи в строгой структуре истории.
Строгость предметного языка технологического слоя
Важно понимать, что USM — это метод, фиксирующий требования к решению в области инструментализации деятельности. Мы применяем его перед самым стартом детального проектирования и разработки какого-то инструмента для деятельности. Ими могут быть наглядные материалы, поддерживающие проведение лекции педагогом, информационные таблички навигации в общественных местах, калькуляторы, автоматические обработчики, веб-сервисы, приложение и много другое. Всё перечисленное всегда встроено в какую-то деятельность и обеспечивает её. И каждый раз любое инструментальное решение будет строиться на базе каких-то технологий. Технологии всегда накладывают свои ограничения на допустимый круг решений, и эту структуру важно учитывать на последнем этапе описания требований к инструменту.
Так как я и мои коллеги чаще всего использовали истории для создания инструментов в форме цифровых сервисов, то в формулировки проникали структурные особенности этой предметной области. Тут важно отметить, что речь идёт не о названиях конкретных решений на мелком детальном уровне типа элемента пользовательского интерфейса, например, «кнопка», или каких-то подходах решения типовой задачи в компьютерных системах, например, «обнаружение данных путём поиска по тексту». Речь идёт о том, что если человек взаимодействует с технической системой через интерфейс, то всегда потребуется закрыть потребности, связанные с этой технологией. При работе через интерфейс всегда важно обеспечить как минимум:
- понимание человеком концепций и принципов работы,
- понимание местоположения в диалоге с машиной и ситуации в целом,
- иллюминацию (показ) данных,
- манипуляцию данными: уточнение единичных значений и выборок, подача команд.
Схема с моделью человеко-машинного интерфейса. Из работы Консорциума исследования пользовательского интерфейса
Это в нашей практике привело к кристаллизации в лексиконе историй строго выверенных глаголов действия: понимает, видит и так далее. Такое заужение естественного языка улучшает взаимопонимание в команде и быстрее выводит на наиболее подходящий класс решений, но, конечно, требует знакомства с языком.
Новый метод по-видимому будет иметь рекомендации по выработке языка предметной области, в которых ищутся решения. Это язык не станет прикован к методу, а должен будет быть выработанным в каждой из технологических предметных областей. Заметьте, речь идёт не о предметной области деятельности, для которого ищутся инструментальные решения, а о предметной области технологий.
Вспомогательные инструменты
Кроме того, что мы использовали свой диалект USM, в ходе практики были порождены инструменты в помощь методу, без которых я не представляю его успешное использование в практике дизайнера.
Самая трудная и одновременно часто встречаемая проблема в работе с любыми картами процесса, и в том числе с USM, в ощущении практикующими разрыва между действием по созданию карты и переходом к проектированию макетов будущего интерфейса. Начинающие говорят, вот мы составили карты пользовательских историй, что нам делать дальше, как именно перейти к дизайну? Другими словами, отражается объективная трудность перехода от плоскости деятельностных ситуаций в плоскость решений.
Процесс перехода к решениям часто упрощается, когда люди пишут истории в терминах решений. Но тогда метод не работает — вместо систематического пути вы просто фантазируете о будущем цифровом инструменте в терминах знакомых вам решений. Тогда, конечно, вы записываете, что кто-то нажимает такую-то кнопку и случается магия. Но мы говорим о верном пути, с выявлением способов действия людей, и тогда в истории почти не просвечиваются до форм решений.
Ранее дизайнер сам каким-то образом переходил из слоя проблем в слой решений. Если дизайнер мог вырастить у себя соответствующую мышцу, вырабатывал способность к такому переходу, решение удавалось. Мы не могли мириться с таким неконтролируемом положением вещей, случайный успех не совместим с профессионализмом. Чем выше была сложность проекта, тем реже была надежда на то, что человек «вывезет» эту сложность перехода к решению. Такой переход всегда делается опосредованно, не напрямую. Для облегчения такого перехода я пришёл к тому, что полезны по-крайней мере три инструмента: инвентаризация историй, схемы страниц-блоков и схемы объектов оперирования.
1. Инвентаризация историй
Под инвентаризацией мы понимаем процесс составления описи артефактов, затрагиваемых в историях. Результат этого процесса перечень интерфейсных агрегатов, отдельных экранов, приёмов, которыми мы хотим закрывать истории в плоскости решений.
На иллюстрации выше это текст синим под каждой из колонок историй. Как вы видите, чаще всего такая процедура даже помогает предварительно оценить время на проектирование. С наличием структурированного справочника решений это помогало бы и оценить время разработки, но это пока дело будущего.
Чаще всего у нас детали историй под хребтом USM записываются именно в терминах создаваемого инструментального инвентаря в будущей системе. На картинке ниже светло-жёлтыми карточками приведены детали к историям в форме инвентаризации. То есть записано как конкретно мы это будем решать: что-то станет экраном в интерфейса, что-то будет загрузчиком данных. Если в команде есть наработанная библиотека решений, то название агрегатов ссылается на неё.
2. Схема страниц-блоков
Другое наше внутреннее название этой схемы — page-block diagram. На первый взгляд схема похожа на структуру страниц веб-сайта или диаграмму User Flow. Однако, если присмотреться, то каждая из страниц состоит из набора блоков двух типов. Первые с иконкой «глазика» отвечают за иллюминацию данных, вторые, с иконкой «мыши» — за манипуляцию данными. Такой заход на слой глубже даёт более детальную структуру и представление о предстоящем содержании проектирования и разработки.
Вёрстка решения на уровне таких схем проводится после инвентаризации.
3. Визуализация объектов оперирования
Разобраться с деятельностью невозможно без удержания объектов оперирования, используемых в ней. Это обычно какие-то вещи, сопровождающие деятельность. Например, в складской деятельности вы будете говорить о типах тары, которые могут быть то палетами, то рулонами. На этой таре будут укладываться товары, то в россыпь, то в гибких упаковках, то в коробах. У вас будут адресные ячейки и структура их устройства на конкретных складах. Будут разные системы выгрузки и погрузки грузов. Будут штрих-коды для обращения к цифровым двойникам всех физических предметов. Способы действия в историях обращаются именно с этими предметами, так что предметы нужно познавать в отдельности. Чтобы не путаться между вещами, людьми и прочими формами, я называю этот класс сущностей объектами оперирования. Чаще всего в начале проекта мы имеем дело с глубокой неопределенностью в этой области. Предметная область состоит для нас из белых пятен непознанного, а когда мы пробуем её познать, то натыкаемся на ошибки в терминологии, мешающие пониманию, к которым все привыкли на стороне бизнеса.
В сожалению, метод USM ничем не в состоянии помочь с этой частью познания. В нём нечем фиксировать полученные знания об объектах оперирования. Для этого мы используем схемы объектов или онтологические схемы. Обычно они выглядят как схемы, схватывающие структурное устройство предметной области, для которой готовится решение.
Приведу несколько примеров схем объектов оперирования. На первой довольно простой изучается иерархические отношения между логистическими сущностями в одном из маркетплейсов.
На следующей схеме-примере рассматривается то как предлагается формировать логистические цепочки. Подобную схему уже можно считать частью решения, потому что до создания системы не существовало и деятельности, и приходилось не познавать её, а констрировать заново вместе с бизнесом. Можно отнести подобные схемы к концептуальным.
Схемы потоков тоже можно отнести к объектно-онтологическим. С этой схемой, например, я пробовал осознать тракт внешне-экономическую деятельности с длинным циклом заказа.
И, наконец, синкретичные, то есть слитные, схемы соединяющие объекты оперирования с действиями — самые полезные на мой взгляд для формирования понимания. Приведу пару схем-примеров. Первая из сферы складской деятельности.
Вторая — из сферы продажи автозапчастей.
Трудности записи историй
Вернёмся к историям — центральной части USM. Вот уже 11 лет как я сам пишу истории и учу людей писать хорошие истории и строить USM. По какой-то причине людям сложно ёмко и точно уложить всю суть сюжетно-деятельностной ситуации в историю. Я постоянно встречаю одну из следующих проблем у коллег.
- Отсутствие содержания истории.Практикующие соблюдают форму шаблона, наполняя историю ерундой. Что-то мешает увидеть о чём должна идти речь в историях. Чаще всего не могут верно зацепить ценность и способ деятельности. Или же фиксируют их в общей форме, не дающей достаточных сведений. В итоге записанное не является историей, хотя таковой считается. В простых проектах это не мешает, в сложных проектах такие «истории» вносят сильные искажения.
- Запись историй в конкретных вариантах реализации вместо работы со способами деятельности. Мы все привыкли мыслить в конечных формах, и это на автомате проникает в запись историй. Мы пишем: «Покупатель получает СМС, чтобы узнать о поступлении заказа» вместо «Когда заказ прибыл, оповещается об этом без существенных промедлений». Здесь важно, что при второй записи освобождается пространство поиска вариантов как именно оповещать.
Выходит, что истории, являясь невероятно полезной находкой, плохо работают для подавляющего большинства случаев. Запись историй сродни искусству, что не может удовлетворить потребности практики — учиться этому требуется десятилетия, а работу нужно делать сейчас. Кроме того, метод требует дополнительных построений для перехода к области решений, что в принципе не обязательно плохо, но оставляет возможность для улучшения.
Собрав вместе описанное выше, я тем самым фиксирую отправную точку для следующего шага развития методов проектирования цифровых инструментов.