Как по-настоящему решать проблемы
Есть четыре пути решения проблемы: absolve, resolve, solve, dissolve. Давайте представим себе голодного человека и постараемся решить его проблему с помощью всех четырех инструментов:
- Absolve — сделать вид, что проблемы нет. Самое простое решение: мы взаимодействуем с проблемой путем бездействия! Красиво?
- Resolve — частичное решение: вернуть систему назад к рабочему состоянию. Мы даем человеку рыбу и возвращаем систему к "рабочему" состоянию, человек сыт. Но это не решает проблему целиком!
- Solve — оптимальное решение: не просто вернуть систему в рабочее состояние, но обеспечить стабильность решения: мы выдаем человеку рыбу каждый день. Проблема решена навсегда, ведь человек будет сыт каждый день, верно? Не совсем: это не системное решение, это костыль. Ключевое здесь вот что: мы не поменяли систему, мы просто решили проблему.
- Dissolve — ликвидация проблемы и перестройка системы таким образом, что в будущем она не сможет возникнуть ни при каких условиях: мы даем человеку удочку и учим рыбачить. Проблема решена навсегда.

Абстрактно и непонятно, понимаю. Позвольте мне развернуть идею.

Перенесем пример на ИТ. Представьте: в результате инцидента сервис деградировал на час и компания понесла убыток в десяток миллионов рублей. Инцидент устранили и теперь все работает нормально. Поехали!

I — Absolve
Инцидент устранен, бизнес работает, деньги капают. Ну упали и упали, надо дальше двигаться.

Итог: никаких действий не предприняли. Вопрос времени, когда инцидент повторится.

II — Resolve
Фиксим баг в коде, который привел к падению.

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

III — Solve
Фиксим баг и пишем тесты. Кажется, что решение системное. Но нет: вы не застрахованы, что ваш код сломается в другом месте, где тестов нет. Покрыть весь код тестами? Даже если у вас получится, вы потратите тонну времени.

Итог: мы вернули систему в стабильное состояние плюс обеспечили продолжительность нашего решения, больше в этом месте ничего не сломается. А в других — может сломаться.

IV — Dissolve
Проводим post mortem, на котором разбираем причину возникновения бага. Допустим, разработчик не успел дописать тесты, потому что у него слишком много горящих задач.

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

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

Что дальше
Это хорошая система для измерения себя как руководителя. Я думаю, хороший менеджер стремится решать проблемы с помощью dissolve: таким образом, проблем будет возникать все меньше и меньше.

Еще раз подчеркну разницу: solve решает проблему самым оптимальным образом, а dissolve перестраивает систему и устраняет возможность появления проблемы в будущем.

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

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