Андрей Анатольевич Шапиро "Карта процесса-опыта. Проектирование услуги через её визуализацию"

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

Под аббревиатурой UX (User Experience) скрывается проектирование пользовательского опыта. Эта междисциплинарная область знаний, увы, имеет высокую планку входа для новичков и до сих пор недостаточно стандартизирована и превращена в учебники и справочники. Принято считать, что область проектирования взаимодействия является уделом узких специалистов – UX-проектировщиков. Специалист в этой области достигает зрелости по прошествии десятилетий, что представляет собой непозволительную роскошь в современном мире. Я считаю, что знаниями по проектированию опыта либо должны обладать все в команде, либо специалистами в этой области важно становиться гораздо быстрее.

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

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

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

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

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

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

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

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

– осознание потребности потребителем,

– поиск исполнителей потребности,

– коммуникация о понимании содержания потребности,

– исполнение её,

– коммуникация о качестве исполнения,

– распространение сведений об исполнителе.

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

Карта процесса-опыта абстрактной услуги

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

Историческая справка и назначение метода

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

Генезис

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

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

Хронология основных ветвей развития методов моделирования процессов и схематизации опыта

Ветка схематизации процессов в сфере информационных технологий

– 1970, ANSI Flowchart – широко известная нотация блок-схем. Появление стандарта по обозначению ветвления в программах.

– 1997, UML 1.1 – многоцелевая нотация с диаграммами структуры объектов и их поведения, выросшая из объектно-ориентированной парадигмы проектирования и разработки. Схематизация сильна учётом инженерных механик, принятых в разработке программного обеспечения. Наиболее важные в контексте процесса средства: диаграмма деятельности (англ. Activity Diagram), развивающие средства Flowchart и диаграмма последовательности (англ. Sequence Diagram) – прародитель дорожек в BPMN.

– 2008, UML 2.2 – максимальная точка развития UML на текущий момент. После разработчики стандарта перешли к нотации BPMN.

– 2004, BPMN 1.0 – нотация, созданная в кооперации с бизнес-аналитиками и нацеленная на управляемость и автоматизацию бизнес-процессов.

– 2013, BPMN 2.0 – максимальная на 2024 год точка развития стандарта. Объединение потокового и событийного подходов. Поддержка нескольких соглашений о моделировании: процесс, коллаборации, хореографии.

Событийно-ориентированное (англ. event-based) направление

– 1990, Event-Driven Process Chain, Август-Вильгельм Шеер – первый из известных мне методов схематизации процесса, делающий акцент на событиях.

– 2013, Event Storming, Альберто Брандолини – метод коммуникации о процессе, призванный штурмовать проблемное пространство и изучать процесс, состоящий из рекордно малого количества элементов в нотации – шести.

– 2018, Event Modeling, Адам Димитрюк – шаг вперёд от Event Storming с акцентом на моделирование в форме раскадровки с экранами интерфейса.

Потоко-ориентированная ветка

– 1910, диаграммы Ганта – средство визуализации зависимостей, создание сетевого графика как направленного математического графа.

– 1984–1997, деревья текущей и будущей реальности в Теории ограничений (Theory of Constraints, TOC). Подход оптимизации главных потоков в деятельности, направленный на последовательное исключение наибольшего ограничения в тракте поставки ценности.

– 1995, Value Stream Mapping (VSM) – диаграммы схематизации потока ценности, выросшие из Производственной системы «Тойоты» (англ. Toyota Production System) и Шести сигм (англ. Six Sigma).

Ветка схематизации опыта

– 1989, Customer Journey Mapping (CJM), идея схемы предложена в статье Беллом и Земке (Chip Bell, Rom Zemke, 1989).

– 1999, появление CJM в версии компании IDEO, внёсшей большой вклад в её распространение.

– 2010, моё знакомство с CJM в версии Usability Lab, начало практикования с этой версией и поиск своих адаптаций.

– 2015–2023, годы практики гибридного подхода CJM с Service Blueprint в версии компании Byndyusoft.

– 2023, Карта процесса-опыта. Осознание того, что метод получил развитие и свои особенности, заслуживающие отдельной публикации. Метод собирает практики CJM, Service Blueprint, уточняет понятие ключевой точки и вводит методические указания по тому, как составлять карты.

Симбиоз схематизаций процесса и опыта

– 1984, Service Blueprint – диаграмма чертежа сервиса. Первый метод, в котором процессы деятельности внутри предприятия совмещаются с опытом потребителя услуги. Появляется понятие линии сервиса (Shostack, 1984).

– 2023, Карта процесса-опыта.

Почему это следующий шаг в развитии

Авторская практика гибридной нотации в схематизации пользовательского опыта развивалась в течение восьми лет в компании Byndyusoft на проектах её заказчиков и обросла собственными особенностями. Когда мы говорили, что используем свою версию CJM, то слышали вновь и вновь: «Нам нравится ваш метод», – а следом: «Это что-то другое». Из разговоров с коллегами по компании и отрасли стало понятно, что получилось развитие метода и сто?ит это отметить и закрепить отдельно. Метод получил имя и описан в этой книге в формате методических инструкций.

Метод назван «Карта процесса-опыта», или на английском Experience—Process Mapping (коротко: XP Mapping, XPM), потому что он соорганизует внутренние процессы и пользовательский опыт.

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

– Как снизить разрывы в логике процесса и всячески улучшать опыт и впечатления человека в работе с сервисом – ориентация на человека, позиция UX.

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

– Как обеспечить максимум потребительской ценности при минимуме затрат – предпринимательская позиция.

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

Что не устраивало в CJM, Service Blueprint и BPMN

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

Заказ и доставка пиццы. Схема классического CJM

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

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

Заказ и доставка пиццы. Схема Service Blueprint

Схема Service Blueprint была ближе к тому, чтобы строить чертёж сервиса, однако в нём не доставало важных элементов, которые были сильной стороной CJM. Сила схем типа CJM и User Story Mapping (Паттон, 2014; Шапиро, 2019) в том, что к каждому элементу карты пристыковывалась масса информационных слоёв. Как раз эту особенность нам захотелось сохранить и совместить её с дорожками и взаимодействиями между разными исполнительскими слоями сервиса из схем типа Service Blueprint.

Заказ и доставка пиццы. Схема взаимодействий в нотации BPMN из спецификации BPMN By Example