👨‍🚀 Start Where You Are - первое впечатление может быть обманчивым

Продолжаем разговор о принципах ITIL. Ранее я уже писал о нескольких из них, и все они, по сути, про одно - как принимать решения не в теоретически идеальных условиях, а в суровой реальности с ограничениями, долгами и компромиссами. Сегодня обсуждаем принцип Start Where You Are.
Звучит банально, но именно этот принцип на практике часто нарушается.

⚡ Первое впечатление

Приходя в новый проект, легко поймать себя на знакомом импульсе: “проще все переписать”. Тот же мотив нередко звучит и при обсуждении проблем с подрядчиком, только в более аккуратных формулировках - “нужно перевнедрять”, “архитектура устарела”.
У этого есть простое объяснение: в первый момент мы видим не систему, а симптомы. Мы замечаем сбои, задержки, раздраженные комментарии пользователей, но почти не видим того, что остается за кадром и продолжает работать каждый день.

🫣 Что обычно остается невидимым

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

🧱 Что бы ни случилось - пилим монолит

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

🎯 Выводы

Часто оказывается, что достаточно выделить несколько ключевых направлений изменений, чтобы снизить градус обсуждения с “все переписать” до “исправить конкретные проблемы”. А уже потом, в более спокойной обстановке, принимать решения о новых внедрениях и замене продуктов.
Почти всегда решения, принятые с холодной головой, приводят к более устойчивым результатам, чем жесты отчаяния в точке безысходности. И это касается не только разработки.