Зачем вообще фиксировать решения?

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

Я не буду начинать с мягких заходов, “best practices” и историй успеха. Будем честны сразу.

Факт №1. Код - не является решением

Это нужно проговорить вслух, потому что до сих пор многие этого не понимают.

Код - это следствие. Решение - это причина.

Когда ты смотришь на код и пытаешься понять:

почему здесь именно так?
почему не иначе?
почему этот вариант вообще был выбран?

и не находишь ответа, значит решение никогда не было оформлено. Оно существовало максимум в чьей-то голове. Иногда - даже не до конца.

Если решение нельзя восстановить без автора - его не существует.

Факт №2. Память команды - миф

Любимая иллюзия:

“Мы помним, почему так сделали”

Нет. Не помните.

Через:

3 месяца,
смену контекста,
одного уволившегося разработчика,
одну аварийную задачу,

память испаряется.

Остаётся только код, который:

нельзя менять,
страшно трогать,
никто не хочет брать на себя ответственность за пересмотр.

Так рождаются:

legacy,
“не трогай, оно работает”,
архитектурные кладбища.

Факт №3. Обсуждение ≠ решение

Slack, Teams, митинги, созвоны - всё это не фиксация.

Даже если:

все согласились,
покивали,
“да, вроде норм”,
“поехали так”.

Если после этого не появился артефакт, значит:

решения нет,
ответственности нет,
обратного пути нет.

Обсуждение без фиксации - это утечка энергии. Вы поговорили. И всё.

Факт №4. Нефиксированное решение невозможно оспорить

А теперь ключевой момент.

Если решение не зафиксировано:

его нельзя проверить,
нельзя оспорить,
нельзя улучшить,
нельзя отменить.

Любая попытка выглядит как:

“Ну мы тогда так решили”

Кто - мы? Когда - тогда? На основании чего?

Ответов нет. Есть только апелляция к прошлому, которое нельзя воспроизвести.

Факт №5. Решения - это граф, а не список

Проекты ломаются не потому, что приняли “неправильное” решение. Они ломаются потому, что:

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

Без фиксации связей между решениями ты никогда не увидишь:

где именно возник конфликт,
какое решение стало источником проблемы,
что именно нужно пересмотреть, а не переписать всё.

Вывод

Если ты не фиксируешь решения:

ты не управляешь системой,
ты не управляешь эволюцией,
ты не управляешь ответственностью.

Ты просто реагируешь.

Фиксация решений - это не бюрократия. Это минимальное условие мышления в сложных системах.

Почему этот блог вообще существует

Этот блог - не про разработку. Он про мышление, зафиксированное в форме решений.

Про:

что считается решением,
когда возникает конфликт,
как фиксировать изменение контекста,
и почему отмена решения - это тоже решение.

Если решение нельзя зафиксировать - значит, его нельзя принимать.