Апология USM, авторский диалект и вспомогательные практики

Двигаюсь дальше в#nbsp;проращивание нового метода на#nbsp;смену User Story Mapping (USM). В#nbsp;прошлый раз я выстраивал критику метода USM и#nbsp;в#nbsp;минусах коротко затронул почему я#nbsp;хочу двинуться дальше в#nbsp;его развитие. Сейчас пришло время поговорить о#nbsp;полезных практиках, что проросли в#nbsp;моей авторской интерпретации USM.

Материал о#nbsp;моём авторском прочтении метода USM представлен в#nbsp;серии статей «Полное руководство по#nbsp;сбору требований в#nbsp;формате User Story Mapping»:

Как оказалось и#nbsp;этот метод подвергся незаметной для меня приработке в#nbsp;личной практике. Подход, который я#nbsp;описываю и#nbsp;которому учу коллег, отличается от#nbsp;того, что закладывали авторы. Так#nbsp;же было и#nbsp;с#nbsp;моей гибридной версией CJM и#nbsp;Service Blueprint дошедшей в#nbsp;итоге до#nbsp;практики Карты процесса-опыта. Потребовался рефлексивный взгляд со#nbsp;стороны, чтобы увидеть произошедшее развитие и#nbsp;оформить это в#nbsp;новый метод.

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

Вот коротко то, что делает всю работу в#nbsp;методе, на#nbsp;мой взгляд.

Если хочется наглядно разобраться с#nbsp;выделенными аспектами, привожу схему. На#nbsp;картинке приведено сопоставление структур пользовательской истории и#nbsp;карты со#nbsp;структурой акта действия из#nbsp;теории мыследеятельности, разработанной Московским методологическом кружком.

Обобщая весь опыт работы с#nbsp;методом, я#nbsp;бы#nbsp;выделил такие фокусы, дающие преимущество в#nbsp;проектировании. Будьте внимательны, здесь я#nbsp;отхожу от#nbsp;догматов тех, кто разрабатывал подходы пользовательских историй и#nbsp;карты пользовательских историй.

Удивительно, что создатели формата пользовательских историй Майкл Кон и#nbsp;автор метод USM Джефф Паттон утверждают, что неважно насколько хорошо вы#nbsp;запишете истории. Они, говорят так: история это плейсхолдер, то#nbsp;есть начальный заполнитель. Паттон рекомендует не#nbsp;спорить долго о#nbsp;формулировках, а#nbsp;записать-зарисовать первое, что приходит в#nbsp;голову.

Да, подобная рекомендация является прекрасным растопщиком «льда» на#nbsp;совместных сессиях картирования. Однако это решает только психологические трудности коммуникации, но#nbsp;никак не#nbsp;решает задачу точного выявления сложного объекта. С#nbsp;точки зрения третьего корня силы метода#nbsp;— фиксация как таковая, конечно, это лучше чем ничего, тут не#nbsp;поспоришь. Но#nbsp;выделенные мной первые два пункта (строгая запись согласно структуре и#nbsp;разделение замысла и#nbsp;реализации) при такой упрощённой форме записи историй уничтожаются.

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

Ещё чаще опускают в#nbsp;записи ценность или записывают вместо неё липу. Ниже я#nbsp;иллюстрирую это на#nbsp;набившем оскомину примере с#nbsp;авторизацией. Обычно я#nbsp;слышу такое: а#nbsp;что там описывать в#nbsp;ценности, очевидно, что нужна авторизация. Я#nbsp;считаю, что это прямое нарушение догмы метода. Если вам очевидна ценность, хорошо, тем лучше, значит вы#nbsp;быстро запишете#nbsp;её. Но#nbsp;обычно вас ждёт фиаско. Даже в#nbsp;такой очевидной на#nbsp;первый взгляд ситуации как авторизация можно найти и#nbsp;записать смысл и#nbsp;ценность требуемой операции. Ниже на#nbsp;рисунке я#nbsp;привожу три варианта истории, одну с#nbsp;липовой ценностью, как пишут многие, и#nbsp;две другие с#nbsp;ценностью, берущей смысл операции.

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

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

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

Это в#nbsp;нашей практике привело к#nbsp;кристаллизации в#nbsp;лексиконе историй строго выверенных глаголов действия: понимает, видит и#nbsp;так далее. Такое заужение естественного языка улучшает взаимопонимание в#nbsp;команде и#nbsp;быстрее выводит на#nbsp;наиболее подходящий класс решений, но, конечно, требует знакомства с#nbsp;языком.

Новый метод по-видимому будет иметь рекомендации по#nbsp;выработке языка предметной области, в#nbsp;которых ищутся решения. Это язык не#nbsp;станет прикован к#nbsp;методу, а#nbsp;должен будет быть выработанным в#nbsp;каждой из#nbsp;технологических предметных областей. Заметьте, речь идёт не#nbsp;о#nbsp;предметной области деятельности, для которого ищутся инструментальные решения, а#nbsp;о#nbsp;предметной области технологий.

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

Самая трудная и#nbsp;одновременно часто встречаемая проблема в#nbsp;работе с#nbsp;любыми картами процесса, и#nbsp;в#nbsp;том числе с#nbsp;USM, в#nbsp;ощущении практикующими разрыва между действием по#nbsp;созданию карты и#nbsp;переходом к#nbsp;проектированию макетов будущего интерфейса. Начинающие говорят, вот мы#nbsp;составили карты пользовательских историй, что нам делать дальше, как именно перейти к#nbsp;дизайну? Другими словами, отражается объективная трудность перехода от#nbsp;плоскости деятельностных ситуаций в#nbsp;плоскость решений.

Процесс перехода к#nbsp;решениям часто упрощается, когда люди пишут истории в#nbsp;терминах решений. Но#nbsp;тогда метод не#nbsp;работает#nbsp;— вместо систематического пути вы#nbsp;просто фантазируете о#nbsp;будущем цифровом инструменте в#nbsp;терминах знакомых вам решений. Тогда, конечно, вы#nbsp;записываете, что кто-то нажимает такую-то кнопку и#nbsp;случается магия. Но#nbsp;мы#nbsp;говорим о#nbsp;верном пути, с#nbsp;выявлением способов действия людей, и#nbsp;тогда в#nbsp;истории почти не#nbsp;просвечиваются до#nbsp;форм решений.

Ранее дизайнер сам каким-то образом переходил из#nbsp;слоя проблем в#nbsp;слой решений. Если дизайнер мог вырастить у#nbsp;себя соответствующую мышцу, вырабатывал способность к#nbsp;такому переходу, решение удавалось. Мы#nbsp;не#nbsp;могли мириться с#nbsp;таким неконтролируемом положением вещей, случайный успех не#nbsp;совместим с#nbsp;профессионализмом. Чем выше была сложность проекта, тем реже была надежда на#nbsp;то, что человек «вывезет» эту сложность перехода к#nbsp;решению. Такой переход всегда делается опосредованно, не#nbsp;напрямую. Для облегчения такого перехода я#nbsp;пришёл к#nbsp;тому, что полезны по-крайней мере три инструмента: инвентаризация историй, схемы страниц-блоков и#nbsp;схемы объектов оперирования.

Под инвентаризацией мы#nbsp;понимаем процесс составления описи артефактов, затрагиваемых в#nbsp;историях. Результат этого процесса перечень интерфейсных агрегатов, отдельных экранов, приёмов, которыми мы#nbsp;хотим закрывать истории в#nbsp;плоскости решений.

На#nbsp;иллюстрации выше это текст синим под каждой из#nbsp;колонок историй. Как вы#nbsp;видите, чаще всего такая процедура даже помогает предварительно оценить время на#nbsp;проектирование. С#nbsp;наличием структурированного справочника решений это помогало#nbsp;бы и#nbsp;оценить время разработки, но#nbsp;это пока дело будущего.

Чаще всего у#nbsp;нас детали историй под хребтом USM записываются именно в#nbsp;терминах создаваемого инструментального инвентаря в#nbsp;будущей системе. На#nbsp;картинке ниже светло-жёлтыми карточками приведены детали к#nbsp;историям в#nbsp;форме инвентаризации. То#nbsp;есть записано как конкретно мы#nbsp;это будем решать: что-то станет экраном в#nbsp;интерфейса, что-то будет загрузчиком данных. Если в#nbsp;команде есть наработанная библиотека решений, то#nbsp;название агрегатов ссылается на#nbsp;неё.

Другое наше внутреннее название этой схемы#nbsp;— page-block diagram. На#nbsp;первый взгляд схема похожа на#nbsp;структуру страниц веб-сайта или диаграмму User Flow. Однако, если присмотреться, то#nbsp;каждая из#nbsp;страниц состоит из#nbsp;набора блоков двух типов. Первые с#nbsp;иконкой «глазика» отвечают за#nbsp;иллюминацию данных, вторые, с#nbsp;иконкой «мыши»#nbsp;— за#nbsp;манипуляцию данными. Такой заход на#nbsp;слой глубже даёт более детальную структуру и#nbsp;представление о#nbsp;предстоящем содержании проектирования и#nbsp;разработки.

Вёрстка решения на уровне таких схем проводится после инвентаризации.

Разобраться с#nbsp;деятельностью невозможно без удержания объектов оперирования, используемых в#nbsp;ней. Это обычно какие-то вещи, сопровождающие деятельность. Например, в#nbsp;складской деятельности вы#nbsp;будете говорить о#nbsp;типах тары, которые могут быть то#nbsp;палетами, то#nbsp;рулонами. На#nbsp;этой таре будут укладываться товары, то#nbsp;в#nbsp;россыпь, то#nbsp;в#nbsp;гибких упаковках, то#nbsp;в#nbsp;коробах. У#nbsp;вас будут адресные ячейки и#nbsp;структура их#nbsp;устройства на#nbsp;конкретных складах. Будут разные системы выгрузки и#nbsp;погрузки грузов. Будут штрих-коды для обращения к#nbsp;цифровым двойникам всех физических предметов. Способы действия в#nbsp;историях обращаются именно с#nbsp;этими предметами, так что предметы нужно познавать в#nbsp;отдельности. Чтобы не#nbsp;путаться между вещами, людьми и#nbsp;прочими формами, я#nbsp;называю этот класс сущностей объектами оперирования. Чаще всего в#nbsp;начале проекта мы#nbsp;имеем дело с#nbsp;глубокой неопределенностью в#nbsp;этой области. Предметная область состоит для нас из#nbsp;белых пятен непознанного, а#nbsp;когда мы#nbsp;пробуем её#nbsp;познать, то#nbsp;натыкаемся на#nbsp;ошибки в#nbsp;терминологии, мешающие пониманию, к#nbsp;которым все привыкли на#nbsp;стороне бизнеса.

В#nbsp;сожалению, метод USM ничем не#nbsp;в#nbsp;состоянии помочь с#nbsp;этой частью познания. В#nbsp;нём нечем фиксировать полученные знания об#nbsp;объектах оперирования. Для этого мы#nbsp;используем схемы объектов или онтологические схемы. Обычно они выглядят как схемы, схватывающие структурное устройство предметной области, для которой готовится решение.

Приведу несколько примеров схем объектов оперирования. На#nbsp;первой довольно простой изучается иерархические отношения между логистическими сущностями в#nbsp;одном из#nbsp;маркетплейсов.

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

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

И, наконец, синкретичные, то#nbsp;есть слитные, схемы соединяющие объекты оперирования с#nbsp;действиями#nbsp;— самые полезные на#nbsp;мой взгляд для формирования понимания. Приведу пару схем-примеров. Первая из#nbsp;сферы складской деятельности.

Вторая — из сферы продажи автозапчастей.

Вернёмся к#nbsp;историям#nbsp;— центральной части USM. Вот уже 11 лет как я#nbsp;сам пишу истории и#nbsp;учу людей писать хорошие истории и#nbsp;строить USM. По#nbsp;какой-то причине людям сложно ёмко и#nbsp;точно уложить всю суть сюжетно-деятельностной ситуации в#nbsp;историю. Я#nbsp;постоянно встречаю одну из#nbsp;следующих проблем у#nbsp;коллег.

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

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