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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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