Долина героев и пустошь для остальных: Почему без фундамента масштабирование невозможно
Когда я слышу фразу «У нас классно, потому что мы как стартап — никакой бюрократии, полная свобода», я обычно жду продолжения. Чаще всего через год-два этот же человек говорит: «У нас выгорела половина команды, а новые не приживаются».
В IT-сообществе принято романтизировать «режим управляемого хаоса». Кажется, что если убрать все регламенты, правила и handbook’и, то останется самое главное — творчество, гибкость и скорость. Но реальность такова, что хаос — это среда, в которой выживают только Герои. А компании, состоящие только из героев, не масштабируются. Они выгорают.
Давайте разберемся, почему крепкий фундамент — это не скучная бюрократия, а единственный способ построить устойчивую систему, в которой могут расти обычные разработчики.
Кто такие Герои?
Прежде чем говорить о системе, нужно понять, о людях какого типа идет речь. Герои — это не просто хорошие разработчики. Это особый психотип, особый набор качеств, который позволяет человеку не просто выживать в хаосе, а чувствовать себя в нем как рыба в воде.
Вот портрет Героя.
Герой — это человек, способный в одиночку выстроить всю вертикаль продукта. Он может сам придумать идею, спроектировать архитектуру, написать фронтенд и бэкенд, спроектировать базу данных, продумать безопасность, нарисовать дизайн и упаковать это все в готовое решение. Ему не нужна команда, не нужны согласования, не нужны регламенты — он сам себе и заказчик, и исполнитель, и архитектор, и тестировщик. Там, где другие видят сложность координации, он видит просто задачу, которую нужно решить.
Герой — это человек с внутренним двигателем, который не требует внешнего топлива. Он способен самостоятельно обучаться чему угодно, разбираться в сложных вещах без чьей-либо помощи. Ему не нужны руководители, которые будут его вдохновлять, мотивировать или «пинать». Он сам себя организует, сам ставит себе цели и сам их достигает. В его внутренней системе уже прописаны все правила — ему не нужны внешние инструкции, потому что у него есть внутренний компас.
Герой — это человек, который не ждет задач. Если задач нет, он их найдет сам. Он увидит слабое место в любой системе и улучшит его без чьих-либо указаний. Для него состояние покоя — это сигнал к действию. Он не может просто «сидеть и делать что сказали», потому что его природа — непрерывное улучшение реальности вокруг. Там, где другие останавливаются, он начинает искать, что еще можно сделать лучше.
Герой — это человек, который способен не только выживать в хаосе, но и создавать среду для других. Проходя через сложные проекты, решая нестандартные задачи, выстраивая процессы с нуля, он приобретает уникальную способность: там, где другие видят проблемы, он видит возможности. Для него отсутствие четких правил — это не проблема, а плодородная почва, где можно проверить свои навыки в боевых условиях и вырасти еще сильнее.
Узнаете себя? Возможно. Но важный нюанс: если вы Герой, эта статья не про то, что вы «плохой». Эта статья про то, что ваша суперсила имеет обратную сторону. И про то, как превратить свою исключительность из способа выживания в инструмент для строительства системы, в которой смогут жить и расти другие.
Герои и управляемый хаос: красивая легенда
Представьте джунгли. Здесь нет дорог, нет карт, нет правил выживания. Но здесь живут люди. Они невероятно сильны, выносливы и обладают феноменальной интуицией. Они знают, какие плоды можно есть, а какие убьют, где прячутся хищники и как перейти бурную реку.
Это — Герои, которых мы описали выше. В мире разработки это те самые «ребята-легенды», которые помнят, как чинить сервер в 3 часа ночи по логам пятилетней давности, знают все зависимости проекта наизусть и могут заменить целый отдел.
Какое-то время джунгли (управляемый хаос) существуют. Герои справляются. Но проблема джунглей в том, что они не масштабируются.
- Новые люди не выживают. Обычный человек, попадая в джунгли без карты и инструкций, скорее всего, погибнет. Он просто не обладает набором «встроенных правил» Героя.
- Герои не вечны. Герой может устать, уйти в другую «экспедицию» или просто выгореть. И тогда джунгли поглощают всех.
- Нет преемственности. Знания умирают вместе с Героем. Каждое новое поколение вынуждено набивать те же шишки заново.
Так работает компания, где нет фундамента. В ней могут жить и приносить пользу 2-3 супермена. Но построить бизнес, который будет устойчив к изменениям и способен нанимать десятки специалистов, опираясь только на героизм, — нельзя.
Четыре слоя устойчивой системы
Чтобы система стала жилой для всех, а не только для избранных, она должна состоять из четырех обязательных уровней.
1. Фундамент: Handbook, регламенты, процессы, чек-листы, архитектура
Это базис. Звучит скучно, но именно он удерживает конструкцию от обрушения при первом же землетрясении (уходе ключевого сотрудника или смене технологий).
Handbook — это не «сборник запретов». Это карта местности. Это ответы на вопросы:— «А как у нас принято называть переменные?»— «Что делать, если сломался билд?»— «К кому идти за ревью архитектуры?»
Чек-листы и регламенты — это не попытка задушить свободу творчества, а страховка от глупых ошибок. Пилот всегда проходит чек-лист перед взлетом не потому, что он дурак, а потому что цена ошибки слишком высока.
Архитектура — это не красивые диаграммы в Confluence. Это границы, в которых разработчик чувствует себя уверенно. Когда архитектура прозрачна, ты понимаешь, куда положить новый код, а куда не надо совать руки без веских причин.
Когда у вас есть фундамент, разработчик тратит силы не на угадывание правил игры, а на решение реальных задач. Фундамент превращает хаос в систему.
2. Инструменты: Библиотеки и утилиты
Инструменты в разработке — это результат труда предыдущих поколений инженеров, упакованный в удобную форму.
— Если вы каждый раз пишете один и тот же компонент авторизации с нуля — у вас плохие инструменты.— Если ваши разработчики тратят 80% времени на рутину вместо уникальной бизнес-логики — у вас нет инструментов.
Хорошие библиотеки и внутренние утилиты позволяют разработчику заниматься творчеством, а не решать одни и те же задачи по кругу.
Но здесь есть важный нюанс: инструменты должны быть отчуждаемыми.
Когда инструменты тесно срастаются с конкретным проектом, конкретным стеком или конкретными «героями», которые их поддерживают, возникает скрытая монолитность. Внешне система может быть разбита на микросервисы или микрофронты, но если каждый инструмент существует в единственном экземпляре и не может быть использован за пределами своей «песочницы», вы получаете монолит на уровне культуры.
Признаки слабой отчуждаемости:— Библиотека живет только в коде одного проекта, потому что «там своя логика»;— Чтобы подключить утилиту в другой проект, нужно переписывать ее с нуля;— Документация хранится в головах, а не в readme;— Инструмент умирает, когда уходит его автор.
Настоящие инструменты — это те, которые можно передать. Они не требуют присутствия создателя для установки и настройки. У них есть четкие интерфейсы, версионирование и понятная документация. Они живут своей жизнью, отдельной от проекта, в котором родились.
Отчуждаемость — это тест на зрелость инструмента. Если библиотеку нельзя просто взять и использовать в соседней команде без группы сопровождения и недели танцев с бубном — это еще не инструмент. Это просто кусок кода, привязанный к контексту.
Хорошие инструменты снижают связанность системы. Плохие — создают иллюзию порядка, за которой скрывается та же самая монолитность, просто замаскированная под модульность.
3. Умение: Скиллы разработчика
Это то, с чем человек приходит и что развивает. Но важно понимать: умение бесполезно без фундамента и инструментов.
В здоровой системе скиллы прокачиваются быстрее, потому что:— Есть готовая база знаний (не нужно изобретать велосипед);— Есть лучшие практики, зафиксированные в коде (инструменты);— Есть менторы, которые не тушат пожары 24/7, а могут спокойно учить.
Более того, в системе с фундаментом становится понятной траектория роста: от выполнения задач по чек-листам до участия в проектировании архитектуры и создании инструментов для других.
4. Ответственность: Вовлеченность и вклад в общее дело
Когда у человека есть понятные правила (фундамент), удобная среда (инструменты) и возможность расти (умение), у него появляется ресурс на ответственность.
Он перестает думать: «Как бы выжить сегодня?». Он начинает думать: «Как сделать наш продукт лучше?». Появляется чувство хозяина. Разработчик понимает, что у системы есть будущее, что его вклад увидят и сохранят. Он готов вкладываться не только в свой участок, но и в улучшение общего фундамента и инструментов.
Ответственность — это не про «наказать за косяк». Это про взрослую позицию: «Я здесь не просто так, я влияю на то, что будет завтра».
Что будет, если убрать один элемент?
Система устойчива, когда есть все четыре слоя. Но если хотя бы одного элемента нет — конструкция начинает хромать или держится исключительно на героизме. Вот как это выглядит в жизни.
1) Если есть фундамент и инструменты, но нет умений
Вы получаете склад мертвых заготовок. Handbook написан, библиотеки разложены по полочкам, процессы утверждены, но люди не понимают, как всем этим пользоваться. Они читают документацию и не видят, как применить ее к реальной задаче. Инструменты простаивают, регламенты пылятся, а разработка идет по старинке — через силу и костыли. Фундамент есть, но строить некому.
2) Если есть умения и ответственность, но нет фундамента
Это классический клуб героев-одиночек. Здесь работают сильные ребята, которые могут всё. Они гордятся тем, что справляются без правил. Но система живет, только пока они в форме. Новые люди приходят и уходят, потому что не могут вписаться — нет карты местности, нет берегов, нет ответов на базовые вопросы. Знания хранятся в головах, а не в документации. И когда герой уходит в отпуск или меняет работу, его участок превращается в черный ящик. Никто не знает, как там что устроено и почему оно работает (или не работает).
3) Если есть фундамент и умения, но нет инструментов
Это эпоха ручного труда. Регламенты есть, люди грамотные, но каждый раз они пишут один и тот же код с нуля. Авторизация, работа с формами, типовые компоненты — всё делается заново, под каждый проект. Рутина съедает 80% времени, на уникальную бизнес-логику не остается ни сил, ни ресурсов. Скорость низкая, усталость высокая. Формально система есть, но эффективности в ней нет.
4) Если есть инструменты и умения, но нет ответственности
Вы получаете формальных исполнителей. Люди умеют работать, инструменты у них под рукой, задачи они делают. Но ровно те, которые записаны в задаче. Никакой инициативы, никакого желания улучшить общее. Код написан — молодец, дальше не его дело. Баги в чужом модуле? Не его. Устаревшая документация? Не его. Инструмент, который можно доработать для всей команды? А зачем? Система не развивается, потому что никто не вкладывается в нее сверх обязательного минимума. Она стоит на месте, пока конкуренты уходят вперед.
Только когда есть все четыре слоя — фундамент, инструменты, умения и ответственность — система начинает жить своей жизнью. В ней могут расти обычные люди, в ней остаются знания, в ней появляется энергия для движения вперед.
Модель Адизиса: Кто создает условия?
Здесь мы подходим к самому важному — роли лидеров и архитекторов. Модель Адизиса (PAEI) отлично объясняет, почему без определенных людей устойчивый рост невозможен.
Для создания фундамента (системы, порядка, регламентов) нужен Администратор (А). Это человек, которому не нравится хаос, который любит раскладывать все по полочкам и писать инструкции. Именно он строит тот самый «фундамент».
Если в компании нет Администратора, а есть только Предприниматели (Е) (генераторы идей) и Производители (Р) (герои-кодеры), система всегда будет в огне. Идеи есть, код пишется, но процессы не фиксируются. Новые люди не задерживаются, потому что нет «перил», за которые можно держаться.
Герои создают результат. Администраторы создают условия, при которых результат могут создавать все остальные.
Только когда Администратор строит фундамент, у обычных разработчиков появляется шанс вырасти до уровня Героев, но уже не ценой постоянного выживания, а благодаря качественному скачку в мастерстве.
И здесь важный момент для самих Героев. Ваша сверхспособность — создавать новое из хаоса. Но если вы хотите построить нечто большее, чем просто очередной проект, вам придется научиться фиксировать этот хаос в правила, понятные другим. Стать не только Героем-производителем, но и Администратором, который строит фундамент. Иначе ваша империя рухнет, как только вы решите отдохнуть.
Вывод
Мы все хотим работать в интересных проектах и решать сложные задачи.
Разработка строится на четырех слоях:
— Фундамент — handbook, регламенты, процессы, чек-листы, архитектура;
— Инструменты — библиотеки и утилиты, которые можно передать;
— Умения — компетенции и способности команды;
— Ответственность — вовлеченность и желание улучшать общее.
Пока мы стоим на зыбкой почве, мы вынуждены быть героями — только так можно удержаться и не провалиться. Как только мы обретаем твердую основу, у нас появляется возможность стать созидателями.
Хватит выживать. Пора строить :)