Исследуя опыт преподавания и применения метода карты пользовательских историй User Story Mapping (USM), я заметил у практикующих две трудности. Первая затрагивает содержание историй, остающихся излишне предписывающими и наводящими на одно конкретное решение. И, как правило, это решение оказывается неверным из-за того, что не согласуется с слабо изученными особенностями реального запроса жизнью.

Эта проблема известна под названием «Проблема XY». Она существенна для ситуации разработки программного обеспечения. Её суть в том, что незаметно для себя легко начать строить решение для проблемы Y, тогда как требовалось решение молчаливо подразумеваемой проблемы X, о которой никто вначале не узнал. Y было незаметно выбрано кем-то как решение-кандидат умалчиваемой проблемы X. Решение проблемы Y настолько конкретно, понятно и желанно, что затмевает собой существование X, а следовательно путь к любым альтернативам. При этом оперировать альтернативами в разработке крайне важно, потому что время и деньги всегда ограничены, и часто становится понятно, что какой-то из вариантов не укладывается в срок и бюджет.

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

С этими двумя упущениями метода USM и разбирается метод Карты реализации историй.

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

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

1. Цель действия — ценность действия на уровне бизнеса, чистая функция без примесей форм реализации. Ответ на вопрос «ЗАЧЕМ что-то делается?»
2. Носитель действия — субъект (человек) или машина, кому вменено действие или операция. Ответ на вопрос «КЕМ или ЧЕМ делается действие?»
3. Рабочая ситуация — описание контекста рабочей ситуации, условия входа в неё. Ответ на вопрос «КОГДА происходит действие, описанное в истории?»
4. Способ действия — вариант формы процесса, Варианты исполнения рабочих ситуаций. Ответ на вопрос «КАКИМ ОБРАЗОМ что-то делается?»
5. Объекты оперирования — перечисление и взаимосвязи вещей, задействованных в действии до его начала и как результат. Ответ на вопрос «С ЧЕМ взаимодействует носитель действия?»
6. Форма решения — конкретные варианты технических решений и технологий, которыми мы оснащаем действие и поддерживаем записанную историю. Ответ на вопрос «С ПОМОЩЬЮ ЧЕГО или ИЗ ЧЕГО мы построим инструментальное решение?»
7. Структура экранных блоков — перечисление блоков визуализации и манипуляции данными в интерфейсе пользователя. Ответ на вопрос «КАК ОРГАНИЗОВАНО решение с точки зрения предмета UX/UI?»

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

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

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

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

Для нас здесь важнее всего, что при правильном планировании замысел всегда должен «давить» на реализацию и главенствовать над ней. Как железная формочка своей жёсткой структурой создаёт форму песочной пироженки, так и замысел отпечатывается на реализации. Замысел находится в пространстве идей и смыслов. Реализация — на земле, конкретная и со всеми подробностями. И реализация, будучи сопряжённой с множеством обусловленностей реального мира, всегда будет вносить свои коррективы в замысел. Именно поэтому от неё идёт обратная корректирующая стрелочка к замыслу на схеме.

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

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

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

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

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

Наиболее неизменной частью остаётся чистая функция. «Чистая» она в смысле отсутствия в ней примесей реализации. Такая функция формулируется в языке бизнеса или предметной области развиваемой нами деятельности и должна быть максимально лишена терминов конкретных инструментальных технологий.

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

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

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

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

ВАРИАНТ 1

• Цель действия: Cинхронизировать данные о товарах в физическом и цифровом мирах
• Носитель действия: Сотрудник склада
• Рабочая ситуация: Когда товара немного и он крупный
• Способ действия: Организует счёт по одному
• Вариант реализации: Ручной счётчик с кнопками +/−, влияющими на итоговое значение и редактируемое поле итогового значения

ВАРИАНТ 2

• Цель действия: Cинхронизировать данные о товарах в физическом и цифровом мирах
• Носитель действия: Сотрудник склада
• Рабочая ситуация: Когда подсчёт ведётся порциями и несколькими людьми
• Способ действия: Скорректировать итоговое количество на размер порции, вместо того чтобы считать в уме
• Вариант реализации: Ручной счётчик с изменяемым размером порции. Редактируемые поля итога и размера порции с операциями прибавить — вычесть порцию.

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

Так как это истории, то каждую из ситуаций выше можно, свернув каскад, записать одним предложением.

ИСТОРИЯ 1
Сотрудник склада, когда товара немного и он крупный, организует счёт по одному, чтобы зафиксировать количество товаров на палете физического мира в цифровом двойнике.

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

В истории мы не фиксируем вариант реализации, он остаётся за её пределами. Ниже мы увидим, где именно место вариантов реализации в карте.

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

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

• Рамка смысла — ради чего что-то делается, это вершина в каскаде реализации. Ей соответствует карточка цели действия или чистой функции. Например, цель — синхронизировать данные о товарах в физическом и цифровом мирах.
• Рамка ситуации — кто или, в случае машины, что делает и когда делает, по какому случаю. Ей соответствуют карточки носителя действия и контекста ситуации. Например: сотрудник склада + во всех ситуациях с крупным товаром в небольшом количестве. Или пример с машиной в качестве носителя действия: сервис лицензий + в случаях установки на серверах, когда истёк срок или вышли за границы лицензий.
• Рамка варианта действия — как именно делается, каким способом. Ей соответствует карточка способа действия. Например: подсчитывает по одному в уме и вводит итоговое количество. Или: подсчитывает размер новой порции и складывает с подсчитанным ранее, чтобы получить итоговое количество.

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

• Цель действия — пунцовый
• Носитель действия — бледно-жёлтый
• Ситуация — сиреневый
• Способ действия — голубой

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

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

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

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

То же самое относится к слою ситуации. Заполнение карточки ситуации для каждой колонки необязательно. Если вы обозначили контекст ситуации в большой составной истории, разбитой на разные действия, то карточка ситуации появится у вас только в колонке с новым контекстом.

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

Носитель действия — на самом деле функциональное место, куда можно положить практически любое содержание. Мой опыт проектирования человеко-машинных систем показывает, что чаще всего люди не совершают действия, в смысле поступков, с проявлением их воли. Чаще всего люди вынуждены как-то вести себя, находясь в сложном поле обусловленности. Поэтому чаще всего они выполняют некое «чужое» действие, то, что им приходится делать с той или иной степенью удовольствия. Всё чаще это «чужое» действие забирают машинные части системы. Значение портрета человека в месте носителя действия сильно возрастёт в системах-инструментах для отдельных небольших групп людей, когда ищется прорывной способ экономии времени и сил в решении типовых задач. Но и в этих случаях чаще всего задачу удаётся взять целью и ситуацией. Обратите внимание, что это полностью сочетается с методикой Jobs To Be Done. Никаких персон. Роль карточки носителя действия в шаблоне деятельностной истории самая ничтожная.

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

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

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

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

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

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

Может показаться, что в выделении объектов нет ничего сложного, однако это не так. Лишь на простейшие вещи мы можем с лёгкостью указать пальцем. Лишь с обыденными вещами получится чётко отделить, где они начинаются и где заканчиваются. Со сложными и невидимыми организованностями, такими, например, как «распределительный логистический центр», «контрольное событие в системе учёта», «рекламное место на сайте», приходится разбираться, чтобы очертить их границу, заглянуть к ним внутрь, понять смысл их существования и найти связи с другими объектами. Проектировщик сложных систем подолгу думает, что же мешает соединить всё в единое понимание, картинка как будто бы рассыпается.

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

А вот пара примеров схем объектов для более сложных предметных областей.

Может показаться, что приведённые примеры — предмет глубокого проектирования. И да, и нет. Да, детальные схемы, безусловно, появятся позже, после погружения в действительность проекта. Однако не сделать прикидку объектов оперирования при записи историй, значит, с 80% вероятности обречь себя на возвращение на перепроектирование, а стало быть, потратить больше времени в итоге. По моему опыту, без прорисовки подобных схем достигнуть достаточной глубины понимания задачи невозможно. Так что к перечням объектов оперирования чаще всего крепятся схемы с ними.

Вы спросите: как научиться выделять объекты? Прекрасный вопрос. С этим есть трудности. Частично с выделением ключевых сущностей разбирается предметно-ориентированный подход (DDD) [Вернон, Эванс]. Однако эта дисциплина находится в чересчур тесной склейке с вопросами разработки программ. Неразработчику практически невозможно прочитать и понять ценность подходов, описанных в литературе по DDD. Другая попытка приблизиться к выделению сущностей в сфере ИТ была предпринята в объектно-ориентированном подходе [Буч, Эккель]. И снова эти книги я не могу порекомендовать, например, дизайнерам, потому что эта литература пропитана предметной областью, чуждой дизайнерам, и нужен недюжий труд, чтобы вытащить оттуда способы мышления по выделению сущностей. Но как бы трудно ни было научиться этому, выделять объекты оперирования крайне важно.

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

У объектов оперирования в Карте реализации историй могут быть три стадии «зрелости». На первой минимально необходимо перечислить все объекты, которыми оперирует носитель действия в этой истории. Наличие даже этой стадии гарантирует прозрения.

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

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

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

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

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

На Карте реализации историй слой форм решений обозначается жёлто-оранжевыми карточками.

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

Как вы помните, правый из кругов на схеме продуктивного действия отвечает за «меню» решений. Это метафорический или реальный «театр машин» — амбар, копилка, музей решений, который накопила ваша проектная группа, отрасль и человечество в целом. Именно отсюда берутся готовые варианты решений или составные части для решений комбинированных.

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

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

Последний из слоёв отвечает за интерфейс пользователя в цифровых системах. Для перехода от историй к формам реализации я долгое время использовал подход с инвентаризацией историй [подробнее: один, два]. Подход с инвентаризацией вылился со временем в структурные схемы интерфейса: схемы страниц-блоков (page-block diagrams). Эти схемы и разместились теперь в Карту реализации историй сразу под слоем форм решений, на уровне реализации.

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

В процессе разметки данных мы обращаем внимание на три аспекта:

1. Какие данные будут визуализированы — аспект иллюминации данных, обозначается на схемах пиктограммой глаза. В тексте за неимением иконок я использую эмоджи с глазами 👀
2. Какими данными допустимо будет управлять — аспекты манипуляции данных, обозначается в схемах пиктограммой руки или компьютерной мыши. В тексте я обозначаю их эмоджи с джойстиком 🕹
3. Как данные будут сгруппированы и где локализированы — аспект общего места и местоположения.

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

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

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

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

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

1. Взять готовый шаблон Карты реализации историй: Miro, Excel, Numbers
2. Решить, для какого инструмента составляется карта, записать его имя в карту. Удостовериться, что цели и процессы уже изучены, например, с Картой гипотез и Картой процесса-опыта
3. Начать цикл заполнения по колонкам. Одна колонка — одна история
4. Попробовать записать цель действия, если возможно
5. Записать в носителя действия исполнителя, если точно известна функциональная роль и история пишется для неё. Если мы собираем действие, для которого исполнитель ещё не определён, оставляем пока пустым
6. Записать способ действия, лишённый подробностей реализации
7. Если способ действия не один, записать над ним ситуацию и контекст, определяющие выбор способа действия. Если способ один, но хочется указать ситуацию, можно записать, но, строго говоря, это не требуется.
8. Описать объекты оперирования, задеваемые историей. В формах: перечня, двух перечней на входе и выходе или схемы
9. Перейти к определению реализации, заполнив карточки реализации и структуры экранных блоков
10. Проверить историю и её реализацию на связанность, целостность и непротиворечивость
11. Перейти к записи следующих историй, начиная с пункта 4
12. Убедиться, что описаны все истории, охватывающие будущий инструмент
13. Ввести обозначение этапов заголовками над колонками историй для удобства навигации по карте

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

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

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

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

Все эти преобразования уже стали частью нашей повседневности, и эта ситуация нам полезна лишь в качестве иллюстрации. Подобный переход между прошлым и будущим никогда не произошёл бы сам по себе, его ещё нужно было организовать. Для планирования этого перехода мы составляем стратегию ближайшего шага развития. Мы в компании Бындюсофт делаем это с помощью метода Карты гипотез, я часто пользуюсь для тех же целей Деревом гипотез развития. Затем, чтобы понять, из чего состоит деятельность в прошлом и будущем с точки зрения логики последовательностей, мы применяем методы схематизации процессов. Мы применяем для этого Карту процесса-опыта. Ну и наконец, чтобы перейти к проектированию недостающих решений-инструментов, мы используем методы, детализирующие отдельные сценарии использования и форму их технической реализации. Здесь место предлагаемого метода Карты реализации историй (сокращённо КРИ), в английском варианте — Story Implementation Mapping (SIM).

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

• Карта реализации историй
• Карта системы-инструмента
• Карта исполнения системы
• Карта деятельностных историй
• Карта инструментальных историй
• Каскад проектирования деятельности
• Карта инструментального оснащения деятельности
• Карта проектирования деятельности
• Каскад требований

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