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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– 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). Подход оптимизации главных потоков в деятельности, направленный на последовательное исключение наибольшего ограничения в тракте поставки ценности.