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

Но при этом он всегда рядом.
И постоянно мешает жить.

Почему логика размазана по трём слоям?
Не надо пихать флажочек в модель — давай подумаем
На прод сразу пушить не стоит — сначала проверим
А как эта штука будет работать через 6 месяцев?

Раздражает? Ещё как. Но, возможно, это именно тот человек, который держит проект от краха.

Кто он?

Это — невидимый архитектор.

Он может даже не быть архитектором по должности. Это может быть «обычный» разработчик, без регалий и таблички на двери.
Но у него есть две вещи: техническое чутье и инстинкт выживания проекта

Он не про «сейчас закоммитим, потом разберёмся».
Он про: «Если сейчас не остановить, то потом будет поздно».

Почему его не любят?

Потому что он ломает комфорт.

Всё уже “почти готово”, а он:

• предлагает вынести бизнес-логику из контроллера,

• замечает, что «с этой схемой база ляжет через месяц»,

• мешает “быстренько закоммитить” в прод.

Он мешает команде двигаться по привычному сценарию:
сначала сделать кое-как → потом дотюним → потом всё забудем.

Он мешает «пихать, что есть».
Мешает «двигаться быстрее».
Мешает «отложить это на потом».

Что будет, если его убрать?

Сначала — ничего. Все вздохнут с облегчением:
«Наконец-то не нужно объяснять, зачем мы добавили эту кнопку в пять разных мест».

Но потом могут начаться разные побочки:

• база начнёт тормозить,

• к фиче невозможно прикрутить новую фичу,

• появляется фрагментированный код,

• баги начинают вылезать в самых непредсказуемых местах,

• система становится всё более хрупкой.

Проект продолжает работать — но каждый шаг вперёд похож на операцию на теле без наркоза.

В чём его реальная ценность?

Он не ускоряет проект напрямую. Он защищает от замедления.

Он:

• видит на 5 шагов вперёд,

• строит каркас, к которому потом можно прицепить десятки фич,

• закладывает архитектурные решения, которые сэкономят месяцы,

• вводит стандарты, чтобы другие не повторяли хаос.

И самое важное — он не работает “на сейчас”. Он работает “на потом”.

Не пытайтесь измерить его метриками

У невидимого архитектора всегда будет «мало закрытых задач».
Он может не участвовать в ежедневных микрореволюциях и не собирать лайки за выкат фичи.

Но если смотреть на темп всей команды, становится ясно — именно он создаёт среду, в которой остальные могут работать быстрее, чище и безопаснее.

Невидимый архитектор — как иммунитет.
Его не видно, пока всё хорошо.
Но стоит его убрать — начинается болезнь.
Потому что кто-то должен держать в голове не только то, как работает код сегодня, но и что с ним будет завтра.

Если в вашей команде есть такой человек — берегите его.
Даже если иногда кажется, что он просто мешает.

Небольшой оффтоп

В Telegram-канале Техдир на пальцах я также разбираю подобные проблемы/кейсы/советы. Там все про разработку и управление, но простым языком, понятным бизнесу.