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

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

Меня зовут Борис Вольфсон, я вице-президент по продукту в СберМаркете. Хочу рассказать про подходы к системному решению проблем, которые использую в своей практике. Я говорю больше про 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.