Анти-паттерны

05.3 Anti-Patterns

Этот каталог — об ошибках аналитика, а не о паттернах в системе. Системные архетипы (05.1 Каталог системных архетипов) описывают повторяющиеся структуры в анализируемой системе. Анти-паттерны описывают повторяющиеся ошибки в том, как применяется сам STAF.

Различие принципиально: архетип — это то, что вы находите. Анти-паттерн — это то, как вы ошибаетесь, находя.

   Системный архетип            Анти-паттерн STAF
   ─────────────────            ─────────────────
   в АНАЛИЗИРУЕМОЙ системе       в РАБОТЕ аналитика
   "Fixes That Fail"            "диагноз по неверифицированной карте"
   находишь и устраняешь        замечаешь у себя и прекращаешь

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

AP-1: Диагноз по неверифицированной карте

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

Почему возникает. После погружения в материалы карта ощущается как факт. Верификация воспринимается как формальность, замедляющая "настоящую работу".

К чему ведёт. Каскад: разрывы найдены относительно неверной карты, рекомендации обоснованы относительно неверных разрывов. Диагноз технически корректен и при этом полностью ошибочен — самое опасное сочетание, потому что он звучит уверенно.

   неверная карта → "корректный" диагноз → уверенные рекомендации
        ▲                                          │
        └────── ошибка не видна на каждом шаге ─────┘
                (форма правильная, основание ложное)

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

Нарушает: Принцип 2 (валидация перед диагнозом), ворота 1.

AP-2: Картирование процесса вместо системы

Как выглядит. Построена аккуратная блок-схема: шаг 1 → шаг 2 → шаг 3. Выглядит как карта STAF, но не содержит ни одной петли обратной связи.

Почему возникает. Процессное мышление привычнее системного. "Что за чем следует" проще, чем "что на что влияет".

К чему ведёт. Анализ теряет главное — динамику. Без петель невозможно увидеть ни усиление проблемы, ни сопротивление системы, ни разомкнутые контуры обучения. Диагностика вырождается в поиск "узких мест" в линейной цепочке.

   ПРОЦЕСС (не STAF)        СИСТЕМА (STAF)
   ──────────────          ─────────────
   A → B → C → D           A → B → C
   все стрелки                 ▲       │
   в одну сторону              └───────┘
   нет петель                  есть петля

Как распознать у себя. Если на вашей карте все стрелки ведут в одну сторону и нет ни одного замкнутого пути — вы нарисовали процесс, а не систему.

Нарушает: этап S1 (картирование), раздел 02.2 Диаграммы CLD.

AP-3: Выдуманная причинность

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

Почему возникает. Корреляция и смежность во времени легко принимаются за причинность. Аналитик "видит связь", которой автор источника не утверждал.

К чему ведёт. Петли, построенные на выдуманных связях, производят несуществующую динамику. Диагноз описывает систему, которой нет.

Как распознать у себя. Для каждой причинной стрелки спросите: есть ли прямая цитата, утверждающая это влияние? Если нет — связь должна быть помечена как предположенная, и проверена при верификации. Непомеченная выдуманная связь — это анти-паттерн.

Нарушает: протокол провенанса (01.2 Элементы и связи, раздел о причинных связях).

AP-4: Решение, спрятанное в постановке проблемы

Как выглядит. Вопрос-катализатор сформулирован как недостающее решение: "нам не хватает автоматизации", "нужен новый процесс согласования".

Почему возникает. Заказчик часто приходит уже с готовым решением и формулирует проблему через него. Аналитик принимает эту формулировку как данность.

К чему ведёт. Весь анализ превращается в обоснование заранее выбранного решения. Это структурно эквивалентно архетипу "Fixes That Fail" на уровне самого анализа: решение выбрано до понимания причины.

   "нам нужна автоматизация"   ← решение как проблема
        │
        ▼
   анализ ищет, где автоматизировать
        │
        ▼
   находит — потому что искал именно это
        │
        ▼
   коренная причина не рассмотрена

Как распознать у себя. Если в формулировке проблемы уже содержится глагол действия ("внедрить", "нанять", "автоматизировать", "ввести") — это решение, а не проблема. Проблема описывает расхождение, а не лекарство.

Нарушает: этап S0 (постановка проблемы), 03.2 S0 · Постановка проблемы.

AP-5: Граница по симптому

Как выглядит. Граница системы проведена вокруг места, где проявляется симптом, а не где находится вероятная причина.

Почему возникает. Симптом виден, причина — нет. Естественно очертить границу вокруг видимого.

К чему ведёт. Петли, ведущие к причине, оказываются за границей. Система выглядит так, будто причина проблемы — внутри симптомной зоны, и вмешательства направляются туда, где проблема только проявляется.

Как распознать у себя. Если граница совпадает с местом жалобы ("проблема в поддержке" → граница по поддержке) — проверьте, не находится ли вероятная причина за этой границей.

Нарушает: определение границы (01.1 Граница системы, ошибка 2), этап S0.

AP-6: Рекомендация без прогноза бездействия

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

Почему возникает. Бездействие интуитивно воспринимается как "сохранение текущего состояния" — кажется, что описывать нечего.

К чему ведёт. Бездействие получает статус бесплатного варианта по умолчанию. Решение принимается без понимания цены сохранения статус-кво, которая для большинства систем не равна нулю (петли продолжают работать).

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

Нарушает: Принцип 3 (симметрия сценариев), ворота 3, этап S3.

AP-7: Глубина рычага не по природе проблемы

Как выглядит. Два варианта одной ошибки:

• структурная хроническая проблема "решается" изменением параметра (слишком мелко);
• временный внешний шок вызывает масштабную реорганизацию (слишком глубоко).

Почему возникает. "Мелко" — потому что дёшево и быстро. "Глубоко" — потому что "раз уж взялись, сделаем фундаментально". Обе логики игнорируют природу проблемы.

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

   проблема          неверный рычаг        исход
   ────────          ─────────────        ─────
   хроническая   →   параметр (мелко)  →  возврат
   структурная

   преходящий    →   реорганизация     →  ущерб от
   шок               (глубоко)            лишних изменений

Как распознать у себя. Спросите: проблема воспроизводится структурно или это разовый шок? Глубина вмешательства должна соответствовать ответу.

Нарушает: Принцип 4 (глубина под природу проблемы), этап S2.

AP-8: Автоматизация без перепроектирования

Как выглядит. Рекомендация — автоматизировать процесс, который плохо спроектирован. Цель: ускорить то, что и так работает неправильно.

Почему возникает. Автоматизация выглядит как очевидное улучшение. Ручной труд → автоматический воспринимается как безусловный прогресс.

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

Как распознать у себя. Перед любой рекомендацией по автоматизации — явный вопрос: правильно ли спроектирован процесс, который мы собираемся автоматизировать? Если нет — сначала перепроектировать.

Нарушает: этап S3 (защита от Fixes That Fail при автоматизации).

AP-9: Иллюзия завершённости

Как выглядит. Отчёт сдан, рекомендации приняты, проект закрыт. Точка пересмотра не назначена. Никто не отвечает за вопрос "сработало ли?".

Почему возникает. Сдача отчёта ощущается как естественный конец работы. Назначение пересмотра выглядит как создание себе лишних обязательств.

К чему ведёт. Через цикл проблема возвращается, и невозможно сказать: была ли модель верна, сработали ли рекомендации, изменилась ли система. Знание потеряно, анализ начинается заново с нуля.

Как распознать у себя. Если в финале анализа нет ответа на вопрос "когда и по какому сигналу мы вернёмся к этой модели?" — цикл не замкнут.

Нарушает: Принцип 6 (итерация встроена), этап S5.

AP-10: Подтверждение у не того носителя

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

Почему возникает. К руководителю проще получить доступ, его подтверждение кажется более авторитетным.

К чему ведёт. Верификация формально пройдена, но подтверждена идеализированная картина, а не реальность. Разрывы между регламентом и практикой — именно то, что часто является причиной проблем — остаются невидимыми.

Как распознать у себя. Спросите: верифицирующий описывает то, что наблюдает ежедневно, или то, как заведено по регламенту? Для верификации нужно первое.

Нарушает: этап S1, ворота 1 (выбор носителя системы).

Сводная таблица

Как использовать этот каталог

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

   S0  →  AP-4 (решение в постановке), AP-5 (граница по симптому)
   S1  →  AP-2 (процесс), AP-3 (причинность), AP-1, AP-10 (верификация)
   S2  →  AP-7 (глубина рычага)
   S3  →  AP-6 (прогноз бездействия), AP-8 (автоматизация)
   S5  →  AP-9 (завершённость)

Анти-паттерн, замеченный у себя, — это не повод для самокритики, а сигнал вернуться на соответствующий этап. Методология предусматривает возвраты именно потому, что эти ошибки естественны и распознаются по ходу работы.

STAF 1.0 · SysMindLab · 2026