На проекте вам регулярно приносят «проблему» — часто это уже готовое решение или жалоба на симптом. Техники анализа проблем помогают отделить наблюдаемое от сути, найти причинные связи и зафиксировать формулировку, пригодную для scope и требований. Здесь — нежелательное состояние и его диагностика; разведка возможностей (opportunity), business case и оформление артефактов — в 02.01.01 Определение бизнес-проблем и возможностей. Статья отвечает на вопрос: какие структурированные методы использовать на разных этапах анализа и как не подменить исследование преждевременным проектированием.

1. Суть темы

Анализ проблемы (problem analysis) — структурированное описание, разложение и объяснение нежелательного состояния до причин, границ и критериев проверки. Результат — не список фич, а формулировка проблемы (problem statement), допущения и гипотезы, на которых можно строить elicitation и моделирование.

В сводах знаний BA эта работа пересекается с Analyze Current State, Define Future State и root cause analysis — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148); здесь — практические техники, а не обзор стандарта.

Ключевое различение для системного аналитика:

СимптомПроблема
Что этоНаблюдаемое проявлениеРазрыв между текущим и желаемым состоянием относительно целей
Пример«Пользователи звонят в support 200 раз в день»«Операторы не могут закрыть типовой кейс за один контакт из‑за отсутствия истории взаимодействий в едином представлении»
РискЛечить метрику, не понимая механизмЗадаёт границы исследования и критерии успеха

Техники анализа проблем — процедурный слой поверх 01.01 Понятие системы и системного подхода и 01.02 Ментальные модели аналитика. Ментальная модель определяет, что вы ищете; техника — как структурируете поиск. Без модели fishbone даст политический список причин; без техники системное мышление останется абстракцией.

flowchart LR
    S[Симптомы и жалобы] --> P[Формулировка проблемы]
    P --> D[Декомпозиция и gap analysis]
    D --> C[Причины и гипотезы]
    C --> H[Handoff: scope, требования, критерии]
    H -.->|обратная связь| S

Анализ проблемы задаёт границы исследования, критерии успеха и допущения до детализации требований — мост к 02.01.04 Определение границ решения (Scope Modelling), но с фокусом на диагностике, а не на управлении scope. На выходе 01.03 фиксируете: согласованный problem statement, разрыв (для кого, с какими последствиями), гипотезы причин и out of scope; оформление в Vision, BRD или ticket — см. 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

Когда в жизненном цикле. Набор техник зависит от фазы 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC): discovery и change — gap analysis и KJ; инцидент или post-release — RCA с хронологией; дефект спецификации или контракта — fishbone на уровне системы с проверкой через 08.03 Тестирование требований (статическое тестирование); повторяющийся сбой в эксплуатации — RCA и, при необходимости, CLD.

Отличие от соседних тем раздела:

2. Ключевые понятия

ПонятиеСуть для системного аналитика
Корневая причина (root cause)Условие, устранение которого предотвращает повторение нежелательного эффекта. В социотехнических системах обычно несколько contributing factors, а не одна «главная» причина.
Формулировка проблемы (problem statement)Краткое проверяемое описание: кто затронут, что не так, где/когда, масштаб — без преждевременного решения.
Декомпозиция проблемыРазбиение на подпроблемы, сценарии, компоненты процесса или системы для анализа границ и зависимостей.
Gap analysisСопоставление as-is, to-be и разрыва между ними — диагностика, не замена Vision/Scope (оформление — 02.01.01 Определение бизнес-проблем и возможностей).
RCA (Root Cause Analysis)Рамка, а не отдельный «официальный отчёт»: факты → хронология → гипотезы причин → проверка. 5 Why, fishbone, problem tree — инструменты внутри RCA.
Cause tree / problem treeИерархия «симптом → промежуточные причины → корень»; только причинно-следственная цепь вниз от эффекта.
Issue tree / solution treeДекомпозиция задачи или гипотезы решения («как достичь X»), не причин. Смешение с cause tree — типичная ошибка solutioning.
5 Why (пять «почему»)Итеративное углубление от симптома к цепочке причин; популяризовано в контексте Toyota Production System.
Диаграмма Исикавы (Ishikawa, fishbone)Классификация возможных причин по категориям; типична для инцидента, дефекта спецификации или артефакта.
Принцип Парето (80/20)Приоритизация факторов: фокус на меньшинстве причин, дающих большинство эффекта.
Affinity diagram / KJГруппировка факторов и идей в кластеры для выявления скрытых тем.
Системные петли (causal loops)Дополнение к fishbone/RCA при обратных связях и задержках; построение CLD — 01.01 Понятие системы и системного подхода.

Шаблон формулировки проблемы

[Роль/группа] не может [цель/результат] из‑за [барьер/разрыв], что проявляется как [симптомы/метрики].

Отдельно фиксируйте out of scope — что сознательно не входит в текущий анализ (полная модель scope — 02.01.04 Определение границ решения (Scope Modelling)). Минимальный блок артефакта: ID/версия, problem statement, симптомы/метрики, гипотезы, out of scope, владелец, дата согласования — размещение в Vision, ADR или Confluence по 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

Сквозной пример

Жалоба «200 звонков в support в день» → KJ по транскриптам выделяет кластер «нет единой истории клиента» → Pareto показывает, что 70% повторных обращений — по трём типам кейсов → fishbone по топ-кластеру: Process (handoff между CRM и телефонией), Data (расхождение идентификаторов), Application (интеграция as-is vs фактическое поведение API) → 5 Why по ветке Data → problem statement без «купить новый CRM». На уровне системы проверка: контекстная диаграмма 03.01.02 Моделирование контекста системы (Context Diagram) и статическая ревизия контракта 08.03 Тестирование требований (статическое тестирование).

Одна проблема или портфель

Если KJ выявил несколько независимых кластеров, не сливайте их в один problem statement: у каждого — своя формулировка, гипотезы и приоритет. Смешение разных разрывов в одну фразу ломает scope и приоритизацию.

Definition of Done для problem statement

Считайте анализ проблемы на текущую итерацию завершённым, когда:

  • формулировка согласована с владельцем проблемы и ключевыми стейкхолдерами (версия и дата зафиксированы);
  • перечислены гипотезы причин и способ их проверки или явный риск «анализ без данных»;
  • out of scope и допущения видны в документе;
  • при изменении фактов — новая версия, а не правка «в голове».

Критерий зрелости формулировки (один на весь цикл анализа): sponsor и команда отличают problem statement от предложенного решения и могут назвать, что опровергнет текущую гипотезу причины.

Уровни анализа: не смешивайте слои

УровеньВопросТипичная ошибкаSA-сценарий
БизнесКакой результат под угрозой?Сразу «нужен новый CRM»Запрос фичи без разрыва as-is
ПроцессГде в потоке разрыв?Путать процесс с IT без проверкиHandoff между ролями в BPMN
Система / интеграцияКакие компоненты и интерфейсы участвуют?Лечить интеграцию при корне в регламентеКонтракт OpenAPI ≠ фактическое поведение; инцидент как симптом NFR
ДанныеКакие данные отсутствуют, устарели, противоречат?Отчётность поверх «грязного» источникаРасхождение master data между сервисами

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

3. Как применяется в работе аналитика

Старт: контекст до техники

Проблема относительна цели. До выбора метода уточните стейкхолдеров и критерии успеха — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map). Полный RCA не нужен, если вход — запрос возможности без разрыва as-is, регуляторный must-have с известным целевым состоянием или согласованная фича с явным владельцем: достаточно лёгкой gap- или stakeholder-проверки и перехода к 02.01.01 Определение бизнес-проблем и возможностей.

Выбор техники под задачу

СитуацияФаза SDLC*ТехникаЧто получаете
Инцидент, дефект релиза, post-mortemЭксплуатация / post-releaseRCA → 5 Why + fishboneХронология, цепочку «почему», карту категорий
Нужна иерархия «симптом → корень»Discovery, changeCause tree (problem tree)Дерево гипотез; углубление 5 Why по ветке
Много разрозненных жалобDiscoveryAffinity / KJТемы проблем; кандидаты в backlog — 05.02 Scrum и Kanban (аналитик в Agile)
Сотни дефектов или обращенийПриоритизация backlogParetoАргумент для MVP — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)
Change, миграцияDiscovery / designGap analysisРазрыв as-is / to-be для elicitation
Дефект спецификации или контрактаDesign / buildFishbone + статическая проверкаГипотезы по артефактам — 08.03 Тестирование требований (статическое тестирование)
Расхождение as-is интеграции и фактаBuild / эксплуатацияContext diagram + RCAГраница системы — 03.01.02 Моделирование контекста системы (Context Diagram)
Повторяющиеся сбоиЭксплуатацияRCA с хронологиейГипотезы вместо «человеческой ошибки»; blameless post-mortem
Обратные связи, смещение симптомаЛюбаяCLDКогда fishbone/5 Why не объясняют динамику — 01.01 Понятие системы и системного подхода
Границы процесса неясныDiscoverySIPOC (5 полей)Краткая рамка «поставщики — вход — процесс — выход — потребители» перед fishbone; детали процесса — 03.04.01 BPMN 2.0 - введение и основы

*Связь фаз с ролью аналитика — 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC).

Последовательность для одной проблемы: KJ → Pareto → fishbone по топ-кластеру → 5 Why по ключевой ветке. При ветвлении 5 Why — отдельная гипотеза на каждую существенную ветку.

RCA как рамка

  1. Сбор фактов — логи, метрики, интервью, документы.
  2. Хронология (timeline) — что произошло и в каком порядке.
  3. Гипотезы причин — fishbone, cause tree, 5 Why.
  4. Проверка — данные, эксперимент, воспроизведение; для критичных отказов — крайний случай 04.04 Техника HAZOP и FMEA для анализа рисков.
  5. Фиксация — problem statement, contributing factors, рекомендации как область изменений и гипотезы для elicitation, а не форма решения или перечень фич. Handoff в scope и 01.06 Принципы и паттерны проектирования решений — после согласования PS.

Формальные фреймворки (Kepner-Tregoe, Apollo RCA, ITIL Problem Management) существуют; для проектной практики достаточно этой рамки — обзор стандартов в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148), риски — 08.05 Управление рисками на этапе анализа.

Cause tree и issue tree

Cause tree (problem tree) — только «почему случилось»: от симптома вниз к изменяемым условиям. Issue tree в консалтинге часто означает декомпозицию вопроса «как достичь цели» — это уже solution tree; смешивать с cause tree нельзя.

Процедура cause tree:

  1. Вершина — измеримый симптом, не решение.
  2. Уровень 1 — прямые гипотезы «почему»; ветвите, не выбирайте одну линию.
  3. Углубляйтесь, пока не дойдёте до изменяемого условия (процесс, политика, контракт, архитектура).
  4. Пометьте гипотезы статусом: подтверждена / опровергнута / не проверена.
  5. Согласованные корни → элементы problem statement; не превращайте ветки в backlog фич без отдельного solutioning.

5 Why на воркшопе

Фасилитация — 02.02.02 Воркшопы, фасилитация и совместные сессии; на воркшопе активны когнитивные ловушки — 01.07 Когнитивные искажения и критическое мышление:

  1. Зафиксируйте симптом в измеримой форме.
  2. «Почему?» 3–5 раз; ветвите расходящиеся ответы.
  3. Привлеките разные роли — разработка, ops, бизнес.
  4. Остановитесь на изменяемом условии, не на персоналии.
  5. Зафиксируйте гипотезы и способ проверки.

При сложных инцидентах сначала timeline в RCA, затем 5 Why.

Fishbone (диаграмма Исикавы)

Категории адаптируйте под домен: People, Process, Application/Technology, Data, Environment. Диаграмма — карта гипотез для проверки; динамику и петли — через CLD в 01.01 Понятие системы и системного подхода.

Pareto для приоритизации

Классифицированная выборка (инциденты, жалобы support, дефекты по модулю) → распределение 80/20 как аргумент в переговорах о backlog, не замена бизнес-ценности.

Affinity / KJ после сбора фактов

После 02.02.01 Интервьюирование и анкетирование или 02.02.03 Наблюдение и анализ документов: карточки → группировка → именование кластеров → связь с метриками. KJ без данных — голосование мнений; см. 01.07 Когнитивные искажения и критическое мышление.

Gap analysis

Фиксируйте разрыв: что не совпадает, для кого, с какими последствиями — вход в elicitation и as-is моделирование (03.04.01 BPMN 2.0 - введение и основы, 03.04.02 Диаграмма потоков данных (DFD)). Трассировка «проблема → требование» — 02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки.

Когда нужны системные петли

Если локальный fix смещает симптом: нарисуйте границу системы (03.01.02 Моделирование контекста системы (Context Diagram)), переменные и связи, отметьте обратные связи (B) и задержки. Полноценное CLD — тема 01.01 Понятие системы и системного подхода; инструменты TOC — 01.05 Теория ограничений и бережливое мышление.

Wicked problems и проверка гипотез

Для bounded проблем: три альтернативные гипотезы причины и эксперимент, который их различит. Для wicked problems (конфликтующие цели, «чья проблема») — trade-offs, dissenting views, 01.04 Теория игр для аналитика; один RCA-отчёт не закрывает политический конфликт.

Способы проверки: метрики эксплуатации; 02.02.04 Прототипирование и UI-UX-исследования; shadowing — 02.02.03 Наблюдение и анализ документов. Недостаток понимания — риск в 08.05 Управление рисками на этапе анализа или 02.04.01 Верификация и валидация (V&V).

Эскалация vs локальный fix

Когда корень — организационная или policy-причина, фиксируйте для 09.07 Управление ожиданиями заказчика и 09.03 Управление конфликтами и переговоры, а не маскируйте «ещё одной фичей».

Связь с elicitation и моделированием

ЭтапРоль анализа проблем
До интервьюГипотезы и вопросы, не «сбор пожеланий»
На воркшопеСтруктура обсуждения — 02.02.05 Мозговой штурм и креативные техники
После as-is моделированияПроверка gap на BPMN/DFD
Перед спецификациейОснование для 02.03.03 Спецификация требований (SRS, Use Case, User Story)

4. Типовые ошибки и ограничения

ОшибкаКак проявляетсяЧто делать
Solutioning под видом анализа«Нужен новый CRM» вместо разрываПереформулировать через цель и барьер — 10.03 Разбор кейса "Старт проекта без требований"
Cause tree vs solution treeВетки «купить X / внедрить Y» в дереве причинОтделить «почему» от «как»; solutioning — 01.06 Принципы и паттерны проектирования решений
Одна корневая причинаЛинейный 5 Why без ветвленияНесколько веток; contributing factors
Смешение проблем в одном PSОдин PS на три KJ-кластераПортфель problem statements с трассировкой
Остановка на человеческой ошибке«Аналитик ошибся» без процесса и инструментов«Почему система допустила ошибку»; blameless post-mortem
Игнор системных эффектовЛокальная оптимизация ухудшает смежный потокГраницы и CLD — 01.01 Понятие системы и системного подхода, 01.05 Теория ограничений и бережливое мышление
Смещение симптомовМетрика ↑, опыт клиента — нетLeading/lagging indicators — 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)
Анализ без фактовFishbone/KJ на мненияхДанные, логи, выборка; 01.07 Когнитивные искажения и критическое мышление
Wicked как boundedОдин RCA на политический конфликтTrade-offs — 01.04 Теория игр для аналитика
Over-analysisБесконечное уточнениеTimebox + DoD; 10.04 Чеклист аналитика перед стартом разработки
RCA на каждый входПолный RCA на запрос возможностиЛёгкая проверка и handoff в 02.01.01 Определение бизнес-проблем и возможностей

Ограничения самих техник

  • 5 Why — слаб без хронологии; склонен к упрощению.
  • Fishbone — не показывает динамику и обратные связи.
  • Cause tree — не заменяет проверку данными; не путать с issue/solution tree.
  • Pareto — чувствителен к классификации и выборке.
  • KJ — структура собранных данных, не полнота картины.
  • RCA — «устранение причины» часто означает управление, не разовый fix.
  • CLD — псевдо-петля на воркшопе хуже честного fishbone.

Связи с другими разделами базы

Якорные связи, не раскрытые выше:

Источники и дополнительные материалы

Книги и стандарты

Статьи и справочные материалы