Follow us on Twitter
    slavb18

    Самая дорогая ошибка в IT - это не архитектура. Почему найм - это судьба вашей системы

    IT managementhiringrecruitmentsoftware architectureConway's Lawteam buildingengineering cultureproductivityHRtech leadership

    Самая дорогая ошибка в IT - это не архитектура. Почему найм - это судьба вашей системы

    Самая дорогая ошибка в IT - это не архитектура. Почему найм - это судьба вашей системы

    В индустрии принято считать, что архитектурные ошибки - самые фатальные. Мы тратим недели на споры о микросервисах, выборе БД и паттернах проектирования. Но реальность жестче: код можно переписать, систему - рефакторить, облака - сменить.

    Единственное, что вы не можете «откатить к предыдущему коммиту» без колоссальных потерь - это человека. 😱 И в этом кроется глубокая философская ловушка, о которой часто забывают лиды и фаундеры.

    Философия Конвея: Ваша команда и есть ваша архитектура

    В 1967 году Мелвин Конвей сформулировал закон, который сегодня звучит как приговор: «Организации проектируют системы, которые являются копией их структуры коммуникаций».

    Если перевести это с «менеджерского» на «инженерный», получится фундаментальный вывод: вы не можете построить стройную архитектуру, если у вас хаотичный найм.

    Ваша система - это лишь тень вашей команды. 👥 Если вы нанимаете людей, склонных к сложности ради сложности, вы получите «овер-инжиниринг» в продакшене, сколько бы гайдлайнов вы ни писали. Если вы нанимаете тех, кто не умеет договариваться, ваша микросервисная архитектура превратится в распределенный ад.

    Ошибка найма - это не просто лишние траты. Это фундаментальный дефект в фундаменте здания, который вы еще даже не начали строить. 🏗️

    Энтропия и «Разбитые окна» в коде

    С точки зрения термодинамики, любая система стремится к хаосу (энтропии). Хороший инженер - это источник анти-энтропии, человек, который вносит порядок. ✨

    Ошибка найма вносит в систему интеллектуальную энтропию. Один посредственный разработчик не просто пишет плохой код - он легитимизирует его существование.

    1. 🗑️ Сначала появляется один «грязный» коммит.
    2. 🤷‍♀️ Затем команда привыкает, что «и так сойдет».
    3. 📉 В итоге планка качества падает у всех.

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

    Иллюзия контроля и «Театр безопасности»

    В разработке у нас есть контроль: Code Review, мониторинг, CI/CD. Это дает нам ложное чувство безопасности. 🛡️ Мы думаем, что если мы окружим слабого разработчика жесткими процессами, мы нивелируем его слабость.

    Но это «театр безопасности». 🎭 Процессы могут ограничить вред, но они не могут заставить человека генерировать ценность. Вы тратите ресурсы сильных инженеров на то, чтобы они «подтирали» за слабыми. В этот момент вы платите дважды: за низкую производительность одного и за деградацию производительности другого. 💸

    Почему резюме - это Платоновская пещера

    Вспомним аллегорию Платона о пещере: узники видят лишь тени на стене и принимают их за реальность. Резюме и стандартное собеседование по списку вопросов - это те самые тени. 🌑

    Мы обсуждаем:

    • ⏳ «5 лет React» (тень опыта).

    • 🏢 «Работал в BigTech» (тень репутации).

    • ✍️ «Знает синтаксис» (тень знаний).

    Но мы упускаем сущность:

    • 🚀 Скорость мышления: как быстро он проходит путь от идеи до реализации?

    • 💪 Ownership: готов ли он нести ответственность за результат, а не за тикет?

    • 🤖 AI-интеграция: использует ли он современные рычаги (LLM), чтобы быть в 5 раз эффективнее, или работает по старинке?

    В 2026 году разница между «просто инженером» и «эффективным инженером» - это не проценты, это порядки (10х). 🤯

    Найм как мета-архитектура

    Пора признать: найм - это не HR-задача. 💼❌ Это мета-архитектура. 🏗️ Это проектирование системы, которая будет проектировать ваш продукт.

    Если упростить, система оценки должна стать инженерной:

    1. 🔍 Деконструкция опыта: не «где работал», а «что конкретно изменил».
    2. 🚦 Анализ сигналов: оценка поведения в условиях неопределенности.
    3. 📈 Прогноз результативности: измерение скорости выдачи первого результата (Time to Result).

    Эпилог

    Вы можете идеально спроектировать схему базы данных. 💾 Но если за клавиатурой сидит человек, который не понимает «зачем», система не полетит. 🚀❌ И наоборот: по-настоящему сильные инженеры способны вытащить даже самую кривую архитектуру, потому что они - живой, самообучающийся код вашей компании. 🧠

    Главный вопрос не в том, как ускорить разработку. Вопрос в том: «Кого вы впускаете в систему?». 🤔 Потому что каждый новый наем - это либо вклад в порядок, либо налог на энтропию, который вы будете платить годами. 💰

    💬 Как вы считаете, можно ли процессами компенсировать слабого игрока, или «закон Конвея» неумолим? Делитесь в комментариях, обсудим.

    📚 Читайте также