# Ошибки содержания точек ## Выделение ключевых точек Эти ошибки происходят чаще всего. Поначалу легко с непривычки спутать разные понятия категории ключевой точки. В имена точек кладут то события, то отдельные операции, то каналы и названия систем. Рекомендуется разбирать ситуацию и растаскивать её по разных категориям, чтобы моделировать точнее. Вот примеры типичных ошибок здесь. #### **Форма решения в названии ключевой точки.** Преждевременная конкретизация Например, в «Встреча по обсуждению оценки и возможному формированию плана развития». Встреча — это формат мероприятия, то есть конкретный вариант решения задачи. В целях гибкости проектирования лучше всегда отделять смысл от форм решения. В данном случае лучше назвать точку «Формирование плана развития», а вариант исполнения записать в Средства: Встреча с обсуждением оценки. \ \ Или другой пример. «Окно подачи заявки». Если так назвать точку, то невозможно будет перестать думать про окно. Так уж устроено наше сознание, если нам показать конкретный вариант, мы уже не сыщем альтернативы. Вы ничего больше не придумаете, потому что всё уже решено и зафиксировано — вот же оно, «окно». Подходящим названием было бы, например, «Подача заявки». Вариантами решений при этом могли бы быть хоть заполнение бумажной форма, хоть электронной, хоть устное сообщение между людьми. #### **Глагол в названии ключевых точек** Например, «Авторизуется в Личном кабинете». Глагол отправляет нас к действиям и операциям, а они ненадёжное средство выявления [ключевых точек](/xpm/praktiku/vazhnye-ponyatiya/klyuchevye-tochki.md). Лучше назвать, например, «Аутентификация». Называя точки глаголами мы будем скорее всего излишне «мельчить». Это приведёт к множеству точек на карте, что затруднит её чтение. #### **Канал или название подсистемы в названии ключевой точки** «Авторизуется в Личном кабинете». Ключевая точка смешана с конкретным каналом взаимодействия — личный кабинет. Если цепочка ключевых точек создана под этот канал, то так действовать допустимо. Если же у вас несколько каналов, например личный кабинет, офис компании, контактный центр, чат-бот, и везде происходит проверка идентичности, то лучше обобщить точку до «Аутентификация» и записать каналы под ней. #### **Артефакт в названии ключевой точки** Например, «Уведомление об активации аккаунта». Лучше назвать точку «Активация аккаунта», а факт отправки уведомления убрать в артефакты выхода или отметить отдельным событием. ## Целевые установки #### **Потребитель в качестве мыслительной позиции** Например, мы делаем карту процесса онбоардинга сотрудника в компанию и выбираем в качестве мыслительной позиции «сотрудника». Даже если мы сами сотрудники той же компании, чтобы осмыслить процесс, мы должны выйти в рефлексивную позицию. То есть перестать действовать и начать наблюдать себя со стороны как действовавших определённым образом. В цели картирования мы фиксируем то для чего мы рассматриваем процесс. Например, «Поиск белых пятен в онбоардинге». В мыслительной позиции мы фиксируем то, как кто мы смотрим на процесс. Например, как «HR-директор». --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ashapiro.gitbook.io/xpm/kratko/tipovye-oshibki/oshibki-soderzhaniya-tochek.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.