Структура книги
Если вы хотите лишь издалека взглянуть на метод и получить первое представление о нём, достаточно будет прочесть первые две главы. В первой главе метод даётся кратко и с высоты птичьего полёта. Вторая глава описывает процесс создания карты на примере. Если вы торопитесь и желаете быстрее начать строить карты, рекомендую также заглянуть в приложение, чтобы ознакомиться с типичными конфигурациями элементов в картах.
Третья глава вводит важные понятия и концепции и представляет некоторый вызов для читателя. Разбирать её сложнее, чем остальные, но это стоит того. Разобравшись с предлагаемыми понятиями, вы перейдёте от интуитивного проектирования к осмысленным практикам. Всё дальнейшее повествование использует понятия, введённые в третьей главе. Поэтому я рекомендую не пропускать её, если вы читаете последовательно.
Четвёртая глава в подробностях рассматривает основные элементы карты, исключая события.
В пятой главе рассматривается процесс создания карты во всех подробностях; в заключении даётся контрольный список, с которым можно проверять себя поначалу. Дочитав до конца пятой главы, вы должны, по моей задумке, составить достаточно полное представление о методе.
Шестая глава содержит в себе набор тонкостей – её можно пропустить, читая книгу в первый раз, и вернуться, только когда появятся вопросы, на которые нет ответов в других главах. В ней разбирается, о чём важно думать строго, а что можно пустить на самотёк. Даны рекомендации по фасилитации встреч с построением карт процесса-опыта. Впервые рассмотрен такой тип элементов, как событие; даны примеры ситуаций, которые решаются лучше событиями.
Чтобы не листать книгу каждый раз в поисках забытого термина, обращайтесь к глоссарию в приложении – в нём я постарался собрать все важные опорные понятия, появляющиеся в тексте книги.
Предуведомление
Для понимания назначения метода «Карта процесса-опыта» важно уделить пару слов тому, в какой деятельности он возник. Большую часть профессионального опыта я приобрёл в сфере информационных технологий в роли проектировщика информационных систем и дизайнера интерфейса пользователя. Примерами систем, для которых применялся метод, были потребительские и корпоративные веб-сервисы и приложения. Это были веб-сервисы площадок электронной коммерции, приложения для инвентаризации магазинов розничных сетей и настройки особенностей транспортной и складской логистики; мобильные приложения для курьеров, кладовщиков и многие другие.
Во всех этих проектах важно было не только появление вспомогательного инструмента, такого как веб-сайт, приложение для мобильных устройств или терминалов сбора данных, но и достижение высокого качества взаимодействия людей с этими инструментами. Гладкость процесса работы сервиса и качество взаимодействия с ним – важнейшие параметры, на которые влияет работа дизайнеров сервиса и 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).
