Диаграмма Исикавы: как построить на примере

Диаграмма Исикавы помогает разложить проблему на возможные причины, проверить их и выбрать действия, которые изменят результат. Для задержки релиза команда сначала записывает наблюдаемый эффект, затем собирает гипотезы по нескольким категориям, подтверждает их данными и только после этого заводит корректирующие задачи. Схема показывает, где искать причину; сама по себе она не доказывает, что причина найдена.

Учебный пример основан на двух релизах, которые вышли на шесть и восемь календарных дней позже согласованных дат. Числа показывают ход анализа и не описывают результаты реальной команды.

Рисунок 1. Состав схемы: проблема справа, категории и возможные причины на ветвях.

Состав причинной схемы

Причинная схема состоит из «головы» с формулировкой проблемы, центральной линии и ветвей категорий. На крупных ветвях размещают возможные причины, на мелких — их уточнения. Форма напоминает рыбью кость; английское название fishbone diagram означает «диаграмма рыбьей кости». Ветви помогают рассмотреть несколько объяснений до выбора действия.

Различие между причиной и симптомом

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

Предполагаемую причинную связь проверяют вопросом: если устранить фактор, уменьшится ли наблюдаемая задержка? Утвердительный ответ команды ещё не доказательство. Нужны следы в задачах, переписке, журналах или измерениях, а иногда небольшой эксперимент.

Рисунок 2. Шаблон помогает разделить причину, её статус и способ проверки.

Подготовка разбора причин

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

Условия применения метода

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

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

Формулировка проблемы для схемы

Проблему для схемы формулируют как наблюдаемый факт с периодом и величиной отклонения: «два последних релиза вышли на 6 и 8 календарных дней позже согласованной даты». Укажите, от какой даты считаете задержку и что означает «релиз вышел». Точная запись задаёт границы поиска причин.

Фраза «релизы постоянно срываются» не указывает период и величину отклонения. Если утверждённый срок или дата публикации не сохранены, установите их по плану и журналу выпуска до обсуждения. Предполагаемое решение «нужно нанять ещё одного разработчика» также не описывает наблюдаемую проблему.

Рисунок 3. Измеримая формулировка задаёт период и величину отклонения.

Участники и материалы разбора

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

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

Построение причинно-следственной схемы

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

Рисунок 4. Четыре шага построения причинной схемы.

Выбор категорий причин

Категории причин выбирают по устройству конкретного процесса. Для учебного релиза используются шесть ветвей: «люди», «процесс», «требования», «инструменты», «зависимости» и «измерение». Шесть ветвей составляют рабочую схему примера, а не обязательный стандарт. Фактор, затрагивающий две ветви, запишите там, где легче проверить механизм.

В ветви «зависимости» команда рассматривает внешние интерфейсы программирования приложений (API) и решения других команд. Ветвь «измерение» показывает, фиксируется ли время ожидания между этапами. Для производственного процесса понадобятся другие категории.

Сбор причин по ветвям

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

Не выбирайте победившее объяснение на этом этапе. Если ветвей много, сгруппируйте повторяющиеся записи, а затем упорядочите найденные причины по возможному влиянию и стоимости проверки.

Углубление ветви методом «5 почему»

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

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

Рисунок 5. Цепочка «почему» углубляет одну ветвь, но требует проверки фактов.

Статус предполагаемой причины

Для причин на схеме используйте три рабочие пометки: «гипотеза», «подтверждена» и «не подтвердилась». Рядом укажите источник и способ проверки. Например: «ожидание ревью у одного специалиста — гипотеза; сверить длительность ожидания с историей задач». После проверки запись меняет пометку; неподтверждённый вариант сохраняет ход анализа. Пометки на схеме не являются статусами задач Strive.

Рисунок 6. Наблюдение, гипотеза и проверка — разные записи.

Проверка предполагаемых первопричин

Предполагаемую первопричину проверяют по связи между событием и конкретным отклонением. Для задержки релиза сравните план и факт по этапам: когда работа была готова, сколько ждала проверки, когда пришло подтверждение внешнего API и какие задачи влияли на дату выпуска. Частота упоминаний на встрече не подтверждает причину.

Приоритет проверки причин

Первыми проверяют причины с возможным влиянием на дату выпуска и доступными следами. Ожидание единственного ревьюера и позднее согласование API можно сопоставить с датами задач; утверждение о «низкой мотивации» не содержит наблюдаемого события. Приоритет проверки отличается от приоритета исправления: усилия и риски действия оценивают после подтверждения причины.

План проверки гипотезы

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

Проверьте альтернативные объяснения: задача могла ждать ревью, но не влиять на дату релиза; подтверждение API могло прийти поздно, пока команда выполняла независимую работу. При частичном подтверждении запишите «фактор внёс вклад в задержку», не объявляя его единственной первопричиной.

От выводов к плану задач

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

Содержание корректирующей задачи

Корректирующая задача должна содержать исходную проблему, подтверждённую причину, ссылку на схему и источник доказательства, действие, ответственного, срок и критерий проверки. Пример действия: «До следующего планирования спринта назначить резервного ревьюера для критических задач». Критерий эффекта команда определяет до изменения по истории ожидания ревью; без исходного замера нельзя обещать конкретное сокращение.

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

Проверка результата изменения

Результат изменения проверяют в следующем релизе по тем же определениям и источникам, что использовали при разборе. Сравните общую дату выхода и ожидание на изменённом этапе. Если ожидание ревью сократилось, а релиз опоздал из-за новой внешней зависимости, отделите результат задачи по ревью от результата всего релиза.

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

Пример диаграммы задержки релиза

Диаграмма учебной задержки релиза содержит шесть категорий возможных причин. Сначала команда записывает гипотезы, затем сверяет выбранные ветви с историей задач и согласований. В условном результате две причины получают подтверждение, четыре остаются гипотезами.

Рисунок 7. Шесть категорий возможных причин в учебном примере.

Гипотезы в шести категориях

В шести категориях учебной схемы записаны следующие гипотезы. Люди — ревью критических изменений сосредоточено у одного специалиста. Процесс — критерии готовности не проверяют до передачи в разработку. Требования — макеты меняются после старта работ. Инструменты — тестовая среда недоступна часть рабочего времени. Зависимости — изменения внешнего API подтверждают уже после начала спринта. Измерение — команда видит дату релиза, но не отслеживает время ожидания между этапами.

В условном разборе история задач показывает ожидание единственного ревьюера у задач, от которых зависел выпуск; переписка и даты работ показывают остановку интеграции до подтверждения API. Фразу «команда работает медленно» исключают до проверки: она не называет события и механизма. Четыре другие записи сохраняют пометку «гипотеза», пока команда не сверит даты и события по каждой ветви.

Задачи после проверки причин

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

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

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

Выбор метода анализа причин

Метод анализа выбирают по числу возможных причин: диаграмма Исикавы показывает несколько ветвей одновременно, а «5 почему» углубляет одну цепочку. Ни один метод не заменяет проверку фактов.

Диаграмма Исикавы и метод «5 почему»

Диаграмма одновременно показывает несколько направлений поиска и помогает собрать знания разных участников. «5 почему» последовательно углубляет один выбранный путь. При задержке релиза схема покажет ревью, требования, среду и внешние зависимости рядом; последовательные «почему» помогут выяснить, отчего именно ревью стало узким местом. Если взять только одну цепочку слишком рано, можно упустить независимую причину.

Ограничения диаграммы

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

Организация действий в Strive

В Strive проверки гипотез и корректирующие действия ведут как задачи на канбан-доске. Диаграмма остаётся отдельным материалом анализа; ссылку на неё и вывод помещают в описание задачи. У карточки указывают исполнителя и срок, а её положение на доске показывает рабочий этап.

Разделите задачи на проверки гипотез и изменения процесса. В описании задачи на проверку укажите источник данных и критерий подтверждения; в задаче на изменение — действие и способ оценки эффекта. Первичные данные о времени ожидания, согласовании API и выпуске сверяйте в системах, где они возникли. Канбан-доска Strive координирует действия, но не строит диаграмму Исикавы и не вычисляет первопричину.

Рисунок 8. Схематичный план задач после анализа.

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

Шаблон для собственного разбора

Шаблон разбора содержит поля: проблема и период; категория; возможная причина; статус («гипотеза», «подтверждена», «не подтвердилась»); источник данных; способ проверки; результат проверки; следующее действие; ответственный; срок; критерий результата. Заполняйте одну строку на одну предполагаемую причину. Если данных для проверки нет, сохраняйте статус «гипотеза» и заводите задачу на сбор данных. Разбор завершён, когда подтверждённые причины связаны с выполненными действиями, а их эффект проверен по исходным показателям.