Dmitry_S365
New member
В начале карьеры я был убеждён, что идеальная архитектура решает все проблемы. Проектировал микросервисы, внедрял паттерны, которые видел в профильной литературе, и гордился тем, что код красивый и масштабируемый. Однако первый серьёзный проект, который я вёл как тимлид, показал мне, что бизнес думает совсем не так.
Нажать чтобы Перейти на сайт
У нас был заказ на платформу для ритейлера. Я предложил микросервисную архитектуру с событийной интеграцией и шардированием базы данных. На ревью главный архитектор компании сказал: «Это звучит впечатляюще, но у нас бюджет на два месяца, а не на год». Мне тогда было обидно, но постепенно я начал понимать, что он прав.
Бизнес не думает категориями «паттернов» и «сквозной согласованности». Он думает категориями сроков, рисков и денег. Однажды я попросил три недели на переработку архитектуры, чтобы учесть будущий рост нагрузки. В ответ услышал: «Насколько вырастёт выручка, если мы запустимся через две недели, а не через пять?». И тут же понял, что моя архитектура не отвечала на этот вопрос.
С тех пор я стараюсь начинать не с «как это устроить технически», а с «что бизнес получит через два месяца и что изменится через год». Это не значит жертвовать качеством — это значит осознанно выбирать, где строить фундамент на годы, а где допустим компромисс. Мой подход теперь: сначала определяю критические по пути к выручке компоненты, проектирую их основательно, а остальное строю так, чтобы его можно было переписать без боли.
Узнать подробнее →
Ещё один важный урок: архитектура — это не решение, а набор решений и компромиссов. Когда я перестал искать «идеальное» и начал искать «достаточно хорошее для текущих задач», конфликты с бизнесом резко уменьшились. Потому что я перестал защищать своё эго и начал защищать результат.
А как вы находите баланс между техническим совершенством и бизнес-требованиями? Бывает ли, что бизнес-требования заставляют жертвовать архитектурой так, что вы потом годами расплачиваетесь долговым долгом? Делитесь опытом — мне очень интересно услышать разные взгляды.
По теме советую почитать: Как AI-инструменты ускоряют разработку ПО: мой опыт
Нажать чтобы Перейти на сайтУ нас был заказ на платформу для ритейлера. Я предложил микросервисную архитектуру с событийной интеграцией и шардированием базы данных. На ревью главный архитектор компании сказал: «Это звучит впечатляюще, но у нас бюджет на два месяца, а не на год». Мне тогда было обидно, но постепенно я начал понимать, что он прав.
Бизнес не думает категориями «паттернов» и «сквозной согласованности». Он думает категориями сроков, рисков и денег. Однажды я попросил три недели на переработку архитектуры, чтобы учесть будущий рост нагрузки. В ответ услышал: «Насколько вырастёт выручка, если мы запустимся через две недели, а не через пять?». И тут же понял, что моя архитектура не отвечала на этот вопрос.
С тех пор я стараюсь начинать не с «как это устроить технически», а с «что бизнес получит через два месяца и что изменится через год». Это не значит жертвовать качеством — это значит осознанно выбирать, где строить фундамент на годы, а где допустим компромисс. Мой подход теперь: сначала определяю критические по пути к выручке компоненты, проектирую их основательно, а остальное строю так, чтобы его можно было переписать без боли.
Узнать подробнее →Ещё один важный урок: архитектура — это не решение, а набор решений и компромиссов. Когда я перестал искать «идеальное» и начал искать «достаточно хорошее для текущих задач», конфликты с бизнесом резко уменьшились. Потому что я перестал защищать своё эго и начал защищать результат.
А как вы находите баланс между техническим совершенством и бизнес-требованиями? Бывает ли, что бизнес-требования заставляют жертвовать архитектурой так, что вы потом годами расплачиваетесь долговым долгом? Делитесь опытом — мне очень интересно услышать разные взгляды.
По теме советую почитать: Как AI-инструменты ускоряют разработку ПО: мой опыт