Системное решение проблем: как находить их источники и не допускать пожаров в будущем

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

Системное решение проблем: как находить их источники и не допускать пожаров в будущем

Меня зовут Борис Вольфсон, я вице-президент по продукту в СберМаркете. Хочу рассказать про подходы к системному решению проблем, которые использую в своей практике. Я говорю больше про IT, но все это легко транслируется на любую сферу: HR, аналитику, маркетинг, менеджмент проектов и управление бизнесом в целом.

Откуда проблемы берутся и что с ними делать

У проблем много причин: человеческий фактор, низкая квалификация специалистов, ошибки планирования.

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

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

«Пять почему»: простой способ найти источник проблемы

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

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

Разберем цепочку «почему» на примере все той же проблемы с БД:

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

  2. Почему в конфиге ошибка? Потому что разработчик забыл поменять конфиг при релизе.
  3. Почему разработчик забыл поменять данные? Потому что в конфиге необходим ручной релиз, хотя это можно автоматизировать.
  4. Почему у нас ручной релиз вместо автоматического? Потому что мы не можем автоматизировать релиз из-за того, что в компании отсутствуют DevOps-практики.

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

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

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

Предыдущий способ хорош для разбора одной проблемы. А что делать, если их много и они явно взаимосвязаны, но непонятно, как именно? Построить интеллект-карту причинно-следственных связей. По-английски она называется Cause-effect diagram.

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

Такую карту причинно-следственных связей строили в СберМаркете
Такую карту причинно-следственных связей строили в СберМаркете

В итоге возникнет несколько ситуаций на графе:

  • есть проблемы, из которых стрелки только выходят. Это те самые пожары;

  • есть проблемы, из которых стрелки не выходят вообще. Это как раз те самые первоисточники, так как у них уже нет причин. Чем больше стрелок входит в такую проблему, тем больше других проблем она генерирует, и решать ее нужно в первую очередь;
  • в отдельных местах возникают циклы. Что-то вроде «У нас нет data-driven-культуры → мы не можем проверять data-driven-скиллы при найме сотрудников → в итоге у нас так и нет data-driven-культуры». Циклы нужно обязательно разрывать.

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

Алгоритм системного решения всех проблем в мире

Алгоритм максимально простой и состоит из пяти шагов.

  1. Потушите возникший пожар.

  2. Вникните в суть проблемы и выявите первопричины с помощью «пяти почему» или интеллект-карты.
  3. Выработайте меры по устранению источников проблем и профилактике «пожара».
  4. Реализуйте эти меры. Очень важный шаг, часто его пропускают, довольствуясь только знанием проблемы. Решение требует вложений, но они окупятся в будущем, когда тушить пожары вам больше не придется.
  5. Проверьте, что принятые решения работают.

Последних трех шагов мы в статье не касались, когда-нибудь расскажу о них подробнее — это тема для отдельной статьи.

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

Системное решение проблем: как находить их источники и не допускать пожаров в будущем

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

Что почитать про решение проблем

На эту тему есть несколько полезных книг:

  • Нассим Талеб «Черный лебедь. Под знаком непредсказуемости». Рассказывает о «черных лебедях» — глобальных и серьезных проблемах, которые возникают внезапно. Интересная книга для понимания причин проблем и того, что «случайности не случайны».

  • Лайкер Джеффри «Дао „Тойота“». Книга про принципы менеджмента компаний «Тойота», в которой тоже много говорится о предотвращении проблем.
  • Дональд Уилер «Статистическое управление процессами». Тут говорится о непрерывном мониторинге и диагностике бизнес-процессов.
  • Эстер Дерби «Agile-ретроспектива». Более айтишная книга, в которой говорится о решении проблем, связанных именно с разработкой, аналитикой и прочим IT.

Если у вас остались вопросы по системному решению проблем или есть дополнения и свой опыт, приходите поделиться в комментариях.

Еще мы завели соцсети с новостями и анонсами Tech-команды. Если хотите узнать, что под капотом высоконагруженного e-commerce, следите за нами там, где вам удобнее: Telegram, VK, FB, Twitter.

1010
7 комментариев

Так Маркет и МегаМаркет - это разные маркеты :D

2
Ответить

Я бы добавил в "Что почитать" один из первоисточников по теме - Теорию ограничений Голдратта

1
Ответить

Почему у нас ручной релиз вместо автоматического? Потому что мы не можем автоматизировать релиз из-за того, что в компании отсутствуют DevOps-практики.
НЕТ!
Потому что разраб у вас один и он бедный въебывает в мыле за прогера, тестера и сисадмина!

1
Ответить

Продам аналогичную карту по созданию проблем😅

Ответить

В статье, КМК, одна рекомендация — обязательно найдите и устраните корневую причину проблемы. Для определения причины предлагается задавать ПОЧЕМУ, и рисовать глобальную схему причинно-следственных связей.

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

Также, метод Голдратта не требует создавать всеобщую схему связей, и менее трудоемкий.

Надеюсь, что в следующих статьях авторы напишут, как именно проблемы решать.

Спасибо за статью.

Ответить