В IT периодически появляются люди, которые выучили несколько красивых слов и решили, что теперь готовы менять архитектуру, процессы, продукт и судьбу компании.
Микросервисы. AI. Event-driven. Kubernetes. Serverless. DDD. CQRS. NoSQL. Можно ещё пару английских слов добавить, чтобы звучало дороже.
Сами по себе эти вещи не плохие. Проблема начинается, когда красивый термин тащат в проект без связи с реальной задачей.
Не потому что бизнесу это нужно. Не потому что пользователю станет лучше. А потому что звучит умно.
И вот тут начинается веселье, за которое потом платят временем, бюджетом, нервами и иногда целым проектом.
1. Проблема не в технологиях, а в людях с блеском в глазах и без критического мышления
Давайте сразу оговорим: микросервисы, AI, Kubernetes, event-driven-подходы, DDD и прочие умные штуки — это не зло. Зло начинается, когда технология становится не инструментом, а игрушкой, которую срочно хочется куда-нибудь применить.
Разработчик начитался про микросервисы — и теперь монолит на небольшом проекте кажется ему личным оскорблением. Руководитель послушал про "data-driven-подход" — и уже хочет продавать клиентам сложную аналитику, хотя клиенту сначала нужен нормальный учет заявок.
Проект спокойно жил на React без Redux? Сейчас придет человек и объяснит, что без глобального хранилища дальше жить нельзя. Даже если в приложении три страницы и состояние уровня "открыта ли модалка".
Нужно просто отправить письмо после заявки? Давайте срочно поставим брокер очередей. Нагрузки нет, фоновых задач почти нет, зато будем поддерживать RabbitMQ ради трех писем в день. Архитектурно же.
На бумаге это выглядит как развитие. На практике получается карго-культ: внешние признаки серьезной инженерии есть, понимания зачем — нет.
2. Если это разработчик — начинается война за "правильную" технологию
Вчера проект спокойно жил на понятном стеке. Сегодня человек приходит и говорит: "Нам срочно нужен CQRS, отдельная шина событий и нормальная доменная модель". Почему? Потому что так правильно. Где именно проблема? Ну... в будущем точно будет.
Любой аргумент против воспринимается как техническая отсталость. Бизнес-цели — скучно. Сроки мешают настоящей инженерии. Главное — внедрить правильный подход, потому что так делают большие ребята.
Хотя иногда проекту не нужны микросервисы, Kubernetes, сложная событийная архитектура и три слоя абстракций поверх формы заявки. Иногда нужен нормальный CRUD, понятная админка, стабильная оплата, быстрый деплой и код, который сможет поддерживать команда из двух с половиной человек.
Иногда не нужен Redux, потому что локального состояния хватает. Не нужен Elasticsearch, потому что каталог из 200 товаров фильтруется обычной базой. Не нужен GraphQL, потому что две REST-ручки закрывают задачу без отдельного слоя магии.
Но это звучит не так эффектно, как "мы заложили масштабируемую архитектуру с несколькими слоями отказоустойчивости. Да. Теперь ваша визитка будет работать как часики. Комазик с валютой загоняйте к парадной офиса".
3. Если это руководитель — достанется и клиенту, и команде
С разработчиком хотя бы можно спорить внутри команды. А когда умные слова подхватывает руководитель или человек, который принимает решения сверху, это легко превращается в "делайте так и никак иначе".
Команда может понимать, что брокер очередей сейчас не нужен. Что Redux ничего не улучшит. Что Kubernetes для одного сервиса — это дорогой способ усложнить себе жизнь. Но если сверху уже решили, начинается классическая IT-гимнастика: аргументируй, объясняй, доказывай, а потом всё равно делай.
Команду это выматывает: люди начинают обслуживать не задачу, а чью-то красивую идею. Появляются лишние слои, согласования, сущности и ощущение, что проектом управляет презентация на 12 слайдов.
Клиенту тоже прилетает. Он хочет быстрее обрабатывать заявки, убрать ручной Excel или связать сайт с CRM. А ему продают "умную платформу", "предиктивную аналитику", "масштабируемую архитектуру" и прочее счастье.
Ему не нужен Kubernetes, если у него один небольшой сервис. Не нужна "платформа", если он просто хочет перестать терять заявки из формы. Ему важно, чтобы работало.
В итоге команда страдает, потому что тащит лишнюю сложность. Клиент страдает, потому что платит за неё. А руководитель может искренне считать, что двигает всех в светлое технологическое будущее.
4. Самые узнаваемые симптомы
Обычно такие истории можно распознать довольно быстро.
"Нам нужна интеллектуальная система". На вопрос "какую операцию она должна улучшить?" начинается туман.
"Давайте сразу распределенную архитектуру". Хотя у проекта один backend, одна база, три разработчика и основная боль — отсутствие нормальных требований.
"Без Redux проект не масштабируется". Хотя весь проект — это несколько экранов, где состояние можно спокойно держать локально.
"Нужен брокер очередей". Хотя вся "очередь" — это отправка уведомления после формы обратной связи.
"Надо как у больших компаний". Без учета того, что у больших компаний другой масштаб, другая команда, другой бюджет и вообще другие проблемы.
"Монолит — это плохо". Не потому что конкретно этот монолит мешает бизнесу, а потому что слово "монолит" стало звучать недостаточно современно.
Во всех этих случаях проблема не в технологии. Проблема в том, что решение выбирается не от задачи, а от красивого слова.
5. К чему это приводит на практике
Когда решение принимается на основе красивой презентации, а не задачи, проект начинает платить по полной.
Появляется лишняя сложность, сгорает бюджет, растет технический долг, команда спорит не о пользе для бизнеса, а о том, насколько солидно выглядит стек.
Самое неприятное — проблема всплывает поздно. Пока идут созвоны и красивые формулировки, всё выглядит как движение вперед. А потом проект стоит, сроки поплыли, бюджет ушел, а понимания так и не появилось.
6. Как отличить понимание от декорации
Пустую уверенность часто можно проверить простыми вопросами. Без токсичности и желания кого-то "поймать".
Спросите не "вы знаете X?", а:
- какую бизнес-задачу это решает;
- какой самый простой рабочий вариант;
- почему обычное решение не подходит;
- какие риски у предложенного подхода;
- что клиент или пользователь реально получит на выходе.
Человек, который реально понимает тему, обычно может ответить: "тут trade-off", "это не нужно на текущем этапе", "можно проще", "вернемся к этому, когда появится реальная нагрузка".
Человек, который просто знает слова, чаще уходит в новую порцию абстракций. Еще больше терминов. Еще меньше конкретики.
Еще один тест — попросить объяснить решение простыми словами, без жаргона. Если после этого объяснение рассыпается — возможно, его и не было.
7. Что делать, если "гений" уже несет технологию в проект
Если вы разработчик, не обязательно устраивать публичную дуэль на созвоне. Но молча кивать тоже плохая идея. Переводите разговор из слов в задачи, называйте риски заранее, предлагайте более простой вариант и не бойтесь говорить: "это звучит умно, но нам это пока не нужно".
Если вы заказчик или менеджер, не ведитесь только на термины. Вопрос не в том, умеет ли подрядчик произносить "архитектура" и "масштабирование". Вопрос в том, зачем это нужно именно вашему проекту.
Если вы руководитель или тимлид, ваша задача — не дать красивой речи заменить инженерную дисциплину. Команда потом будет разгребать не презентацию, а последствия.
И да, нейронки тут только ускорили старую проблему. Теперь можно за пять минут собрать красивое обоснование, схему и уверенный текст, почему вашему маленькому сервису жизненно необходима космическая архитектура.
Подписывайтесь на SkylinnTime — https://dzen.ru/skylinntime. Здесь будем говорить про IT, разработку и игровую индустрию без сказок про лёгкие деньги, но и без лишнего нытья. Пишет практикующий Senior Fullstack web developer и teamlead, который всё это видит не только со стороны красивых вакансий.