Типовые ошибки
Last updated
Last updated
Форма решения в названии ключевой точки. Например, в «Встреча по обсуждению оценки и возможному формированию плана развития». Встреча — это формат мероприятия, то есть конкретный вариант решения задачи. В целях гибкости проектирования лучше всегда отделять смысл от форм решения. В данном случае лучше назвать точку «Формирование плана развития», а вариант исполнения записать в Средства: Встреча с обсуждением оценки. Или другой пример. «Окно подачи заявки». Если так назвать точку, то невозможно будет перестать думать про окно. Так уж устроено наше сознание, если нам показать конкретный вариант, мы уже не сыщем альтернативы. Вы ничего больше не придумаете, потому что всё уже решено и зафиксировано — вот же оно, «окно». Подходящим названием было бы, например, «Подача заявки». Вариантами решений при этом могли бы быть хоть заполнение бумажной форма, хоть электронной, хоть устное сообщение между людьми.
Потребитель в качестве мыслительной позиции. Например, мы делаем карту процесса онбоардинга сотрудника в компанию и выбираем в качестве мыслительной позиции «сотрудника». Даже если мы сами сотрудники той же компании, чтобы осмыслить процесс, мы должны выйти в рефлексивную позицию. То есть перестать действовать и начать наблюдать себя со стороны как действовавших определённым образом. В цели картирования мы фиксируем то для чего мы рассматриваем процесс. Например, «Поиск белых пятен в онбоардинге». В мыслительной позиции мы фиксируем то, как кто мы смотрим на процесс. Например, как «HR-директор».
Эти ошибки происходят чаще всего. Поначалу легко с непривычки спутать разные понятия категории ключевой точки. В имена точек кладут то события, то отдельные операции, то каналы и названия систем. Рекомендуется разбирать ситуацию и растаскивать её по разных категориям, чтобы моделировать точнее. Вот примеры типичных ошибок здесь.
Глагол в названии ключевых точек. Например, «Авторизуется в Личном кабинете». Глагол отправляет нас к действиям и операциям, а они ненадёжное средство выявления . Лучше назвать, например, «Аутентификация». Называя точки глаголами мы будем скорее всего излишне «мельчить». Это приведёт к множеству точек на карте, что затруднит её чтение.
Канал или название подсистемы в названии ключевой точки. «Авторизуется в Личном кабинете». Ключевая точка смешана с конкретным каналом взаимодействия — личный кабинет. Если цепочка ключевых точек создана под этот канал, то так действовать допустимо. Если же у вас несколько каналов, например личный кабинет, офис компании, контактный центр, чат-бот, и везде происходит проверка идентичности, то лучше обобщить точку до «Аутентификация» и записать каналы под ней.
Артефакт в названии ключевой точки. Например, «Уведомление об активации аккаунта». Лучше назвать точку «Активация аккаунта», а факт отправки уведомления убрать в артефакты выхода или отметить отдельным событием.
Одна из частых ошибок у начинающих использовать Карту процесса-опыта — размещение разрабатываемой ИТ-системы на отдельной дорожке, как будто это участник взаимодействия.
Делать так не нужно и даже вредно. Дело в том, что в этом случае фокус внимания смещается на вашу ИТ-систему или её часть как участника. Как будто вам нужно обслуживать её опыт и считаться с ней, а не выстраивать её как требуется. Так вы перестаёте видеть чистую структуру процесса-опыта с её живыми участниками без привнесения в нее конкретных инструментальных решений.
Разрабатываемая система появляется в аннотациях к ключевым точкам. Место для неё такие слои информации как каналы, средства, артефакты входа/выхода, действия. Приведу пример для вымышленной ключевой точки «Обработка нового заказа». Читатель узнают в нём паттерн ручной интеграции. В примере ИС-1, ИС-2 — информационные системы.
Вход
ИС-1: параметры новой заявки
Действия:
Участник считывает визуально параметры заявки в ИС-1 и переносит их в ИС-2
Выход:
ИС-2: новый заказ
Когда же допустимо размещать системы на дорожке? Только когда это внешние сервисы и API с которыми вам реально нужно взаимодействовать и поменять вы их не можете.