Как найти настоящую причину проблемы, а не её симптом

На еженедельном синке всплывает та же проблема: конверсия в активацию падает. Прошлый раз переписали онбординг — не помогло. До этого упростили регистрацию — тоже. Теперь предлагают поменять триггерные письма.

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

Именно для этого существует диаграмма Исикавы. Не чтобы добавить ещё один слайд в разбор, а чтобы остановить цикл «заметили → пофиксили → снова заметили» и добраться до того, что реально сломано.

Диаграмма Исикавы — графический метод структурного анализа причин, при котором команда последовательно раскладывает проблему на категории и подкатегории до тех пор, пока не доходит до конкретных, операционально устранимых источников.

Что такое диаграмма Исикавы

Метод создал японский инженер Каору Исикава в 1960-х для Toyota Production System. Он заметил: когда дефект возникает на производственной линии, команды фиксируют его и устраняют следствие — вместо того чтобы систематически искать источник. Диаграмма решала это структурно: она не позволяла остановиться на первом ответе.

Внешне диаграмма напоминает рыбий скелет — отсюда второе название, fishbone diagram. Голова рыбы — проблема. «Кости» — категории причин. Мелкие «косточки» — конкретные факторы внутри каждой категории. Визуальная форма не случайна: она показывает, что у одной проблемы всегда несколько системных источников, и ни один из них не является «главным» сам по себе.

Главная сила инструмента — в том, что он убирает иллюзию быстрого ответа. Когда все причины на одном листе, очевидно: «пользователи не понимают ценность» — это не причина, это ещё один симптом. И команда вынуждена двигаться глубже.

Когда нужна диаграмма Исикавы

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

Как построить диаграмму: 5 шагов

01 Сформулируйте проблему как точное утверждение

Запишите проблему в одно конкретное предложение с измеримым следствием. Не «плохая конверсия», а «конверсия из регистрации в первое действие составляет 12% при целевом показателе 30% — последние две недели». Размытая формулировка даёт размытый анализ.

Критерий успеха: любой новый участник сессии, прочитав формулировку, понимает, что именно анализируется.

02 Определите категории причин

Классическая схема для производства — 6М: Man (люди), Machine (оборудование), Method (процессы), Material (материалы), Measurement (измерение), Mother Nature (среда). Для продуктовых команд адаптируйте: люди, процессы, технология, данные, рынок, продукт. Начните с 4–6 категорий — больше создаёт путаницу.

Критерий успеха: каждая категория достаточно широкая, чтобы в неё попало хотя бы три фактора.

03 Проведите сессию генерации причин

Соберите команду на 60–90 минут. По каждой категории задайте один вопрос: «Что внутри этой категории могло привести к проблеме?» Записывайте всё без фильтрации. Используйте метод «5 почему» — задавайте вопрос «почему?» к каждому ответу до тех пор, пока не доберётесь до конкретного, изменяемого фактора.

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

04 Определите приоритетные причины

После генерации оцените каждую причину по двум осям: вероятность влияния (насколько это реально объясняет проблему) и управляемость (насколько команда способна это изменить). Начинайте с высокой вероятности и высокой управляемости — это ваш первый RAT (Riskiest Assumption Test, проверка самого рискованного предположения).

Критерий успеха: из диаграммы выходит список из 3–5 приоритетных гипотез о причинах с конкретным экспериментом для каждой.

05 Проверяйте данными, не обсуждением

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

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

Типы диаграмм Исикавы

Инструмент адаптируется под задачу — важно не перепутать форму с целью.

Классическая fishbone (6М)Подходит для производственных или операционных проблем. В продуктовых командах — для анализа качества поставки, процессных сбоев, задержек.
Процессная диаграмма Категории — шаги процесса, а не абстрактные области. Используется когда проблема возникает на конкретном этапе воронки или пайплайна.
Диаграмма 4P (Product, Price, Place, Promotion) Для анализа провалов в выручке или росте. Структурирует причины вокруг маркетинговых переменных.
Вариант с голосом клиента Категории — роли участников пути клиента: пользователь, покупатель, команда поддержки, партнёр. Применяется при анализе оттока или низкой удовлетворённости.
Impact Mapping Для распаковки истинной потребности пользователя, можно также по Исикавы распаковать.

Общий принцип

6M принцип

Что меняется после диаграммы Исикавы

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

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

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

В продуктовой работе большинство проблем системные, а не точечные. Диаграмма Исикавы — это способ увидеть систему до того, как в неё вложено ещё два спринта работы.

Попробуйте прямо сейчас

Возьмите одну метрику, которая не двигается последние 4–6 недель, несмотря на действия команды. Запишите её как проблему. Выделите 60 минут с командой и пройдите по четырём категориям: люди, процессы, продукт, данные. На каком уровне «почему» вы обычно останавливаетесь — и что находится на уровень глубже?

Литература и источники

Kaoru Ishikawa — «Introduction to Quality Control» (1990)Первоисточник. Автор метода объясняет не только технику, но и философию: почему поиск причин важнее устранения следствий. Читать для понимания логики, а не только инструмента.
Ash Maurya — «Running Lean» (2012)Связывает анализ причин с lean-экспериментированием. Объясняет, как сделать из гипотез о причинах проверяемые RAT. Брать оттуда: структуру Lean Canvas и логику приоритизации рисков.
Taiichi Ohno — «Toyota Production System» (1988)Контекст, в котором вырос инструмент. «5 почему» как системная практика. Читать, чтобы понять, почему метод работает — не только как его применять.
Teresa Torres — «Continuous Discovery Habits» (2021)Современная адаптация структурного анализа в продуктовую практику. Глава об opportunity trees перекликается с логикой диаграммы Исикавы. Брать оттуда: как встроить анализ причин в регулярный ритм продуктовой команды.
Marty Cagan — «Inspired» (2018)Раздел о product discovery и корневом анализе проблем. Брать оттуда: почему «решение» без понимания причины — самая дорогая ошибка в продуктовой работе.