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

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

Метод прекрасно дополняет и может применяться совместно с такими процессными нотациями как карта процесса-опыта, карта пользовательских историй и метод ключевых действий.

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

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

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

Чему соответствуют преобразователи в реальных информационных системах? Ими могут быть:

• вызовы внутренних или внешних сервисов, в этом случае преобразователями являются вызываемые сервисы;
• отдельные процедуры функции, методы в потоке вычислений внутри одной программы;
• работа человека с интерфейсом системы.

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

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

Задача предохранителя не допустить запуска преобразователя с «грязными данными». В автоматизированных сервисах этому служат коды результатов работы и сообщения об ошибках. В интерфейсах пользователя — искусственные ограничители и обратная связь (Норман, 2006; Купер, 2009).

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

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

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

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

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

Рассмотрим более пристально один преобразователь. Чтобы его описать полезно ответить на следующие вопросы.

• Какова функция преобразования, в чем её смысл? Какой способ преобразования используется?
• Какова чувствительность преобразователя и предохранителя: сколько вариантов ввода по разным формам обрабатывается, а сколько лишь распознаётся и возвращаются назад для коррекции?
• Каковы функции вход и выход по задумке, что в них ожидается принимать и получать?
• Каковы формы значений вход и выход: что реально вводят и что попадает на выход, учитывая все вариации?

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

Вот что я обычно фиксирую в шапку таблицы преобразователя на сквозном примере.

Преобразователь в общем случае является решателем, исполняющим некоторую бизнес-логику. Другими словами, он перебирает варианты условий и выдаёт решения на каждую из комбинаций. Такие решатели элегантнее всего записывать в форме таблиц решений. Такие таблицы примеряются, например в нотации в Decision Model and Notation (DMN), тесно дружащей с BPMN-нотацией.


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

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

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

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

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

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

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

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

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

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