“Почти в точку” считается только когда бросаешь ручную гранату.

Действительно, когда ты занимаешь созданием сложных технических проектов, то часто “почти получилось” приравнивается к неудаче. Состояние “почти” - не финальное, не результат. Только прислушайтесь:

👎 Почти корректный расчёт 🫠 Почти учтённый сценарий 😵 Почти до конца работающий кейс

Пока этим не пользуются в ПРОД, это ещё НЕ готово. А когда начинают пользоваться “почти” превращается в инцидент.

Цена ошибки в системах с финансовыми и регуляторными рисками кратно выше. Там нет режима “И так сойдёт”. Каждое изменение, которое планируется к выводу в ПРОД, проходит длинную цепочку фильтров:

🔹 бизнес-смысл 🔹 архитектурные ограничения 🔹 риски 🔹 нагрузка 🔹 негативные сценарии 🔹 end-to-end тестирование…

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

И всё же не стоит полностью обесценивать “метание гранат”.

Когда уровень неопределенности чрезвычайно высок - просто сделать и посмотреть на результата порой гораздо выгоднее, чем проводить миллионы исследований и тестов.

Но здесь ключевое — понимать:

🔹 Что именно ты собираешься “взорвать”? 🔹 Где радиус поражения? 🔹 Какие негативные последствия допустимы?

Зрелость не в том, чтобы всегда всё вылизывать до идеала. И не в том, чтобы постоянно клепать MVP. Зрелость - в умении различать режимы и оценивать риски.

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

Пытаться “гранатами” управлять критической инфраструктурой опасно и дорого. А пытаться строить инновации исключительно через многоступенчатые процессы проверок - медленно и неэффективно.

Баланс - в контексте.

Но если вы выводите что-то в ПРОД, и от этого зависят деньги, регуляторка, обязательства или доверие клиентов - “И так сойдёт” не работает.