Почти 7 млн из 11,8 млн open source-репозиториев поддерживаются одним человеком. Для индустрии это не просто любопытная цифра, а прямое напоминание о том, что фактор автобуса в разработке часто упирается не в качество кода, а в качество общения. Для русскоязычных IT-команд вывод неприятный, но полезный: если знания живут в голове одного сеньора и плохо передаются дальше, проект начинает зависеть от его календаря, настроения и трудовой книжки.
Эту тему подняли в Beeline Cloud, сообщает Habr / Карьера. Поводом стала старая, но явно не потерявшая актуальности проблема: даже сильные разработчики далеко не всегда умеют объяснять решения менеджерам, передавать контекст коллегам и оформлять знания так, чтобы ими можно было пользоваться без личного созвона с автором системы. В результате команда получает не просто коммуникационный дискомфорт, а вполне осязаемый организационный риск.
Сам термин bus factor давно известен в инженерной среде. Это довольно мрачный, зато честный тест на устойчивость команды: сколько ключевых людей должны выбыть из проекта, чтобы он начал разваливаться. Если критическая экспертиза сосредоточена у одного человека, фактор равен единице. Если знания распределены между несколькими независимыми специалистами, команда переживает кадровые встряски заметно спокойнее. Проблема в том, что узкое горлышко здесь часто образуют не архитектура и не легаси сами по себе, а неспособность превращать личную экспертизу в коллективную.
На это же указывает и Джордан Катлер, инженер Pinterest и автор рассылки High Growth Engineer. Он предложил термин communication smells по аналогии с code smells. Идея простая: запутанный код сигнализирует о будущих проблемах, но расплывчатые формулировки в пулл-реквестах, слабая аргументация решений и неумение обсуждать изменения не менее опасны. Только последствия видны не сразу. Сначала команда просто тратит больше времени на уточнения, потом начинает зависеть от пары «незаменимых» людей, а дальше любая их недоступность превращается в мини-аварию.
Когда проблема уже измеряется цифрами
В open source это особенно заметно, потому что статистика там лежит почти на поверхности. ИБ-специалист Anchore Джош Брессерс в прошлом году проанализировал архив ecosyste.ms, который собирает данные о миллионах открытых проектов. Вывод получился тревожный: почти 7 млн репозиториев из 11,8 млн в базе поддерживает всего один человек. И это не новый перекос. Еще в 2014 году аналитики Bocoup писали, что 93% пакетов в экосистеме npm имеют одного мейнтейнера. Исследование 2015 года по популярным проектам на GitHub показывало похожую картину: почти две трети таких репозиториев поддерживаются одним или максимум двумя людьми.
Сами мейнтейнеры проблему тоже не скрывают. В 2019 году автор системной библиотеки libinput прямо признавал, что фактический фактор автобуса у проекта равен единице: формально участники были, но из примерно 1200 коммитов около тысячи принадлежали одному человеку. Ситуацию он называл неидеальной и даже публиковал отдельный призыв к сообществу подключиться к развитию библиотеки. Это важный штрих: низкий фактор автобуса возникает не только там, где нет процессов. Иногда процессы есть, репозиторий живой, продукт полезный, но знания все равно не успевают распределяться по команде.
Для бизнеса история еще менее академическая. По оценкам, которые приводит источник, компании из списка Fortune 500 ежегодно теряют 31,5 млрд долларов из-за неэффективного обмена знаниями внутри команд. Особенно болезненно это проявляется там, где накопилось много легаси-кода, а его авторы давно ушли в другие компании. В такой конфигурации каждая неописанная интеграция, каждый молча принятый архитектурный компромисс и каждый «я потом расскажу на созвоне» становятся скрытым обязательством, которое рано или поздно нужно будет оплачивать.
Важно, что Beeline Cloud не сводит проблему только к отсутствию базы знаний или плохо настроенным процессам. Эти причины понятны и привычны. Менее приятная мысль в том, что препятствием нередко становятся сами разработчики: человек действительно хорошо понимает систему, но объяснить ее так, чтобы другой инженер смог безопасно продолжить работу, не может. В разговоре про seniority это особенно неудобная тема, потому что индустрия долго измеряла зрелость почти исключительно по хардам, а навык передавать контекст считала чем-то второстепенным.
Почему рынок все еще недооценивает этот риск
С софт-скиллами у IT в целом давняя сложная история. Само понятие расплывчатое: в систематическом обзоре статей за 1993-2019 годы, который в сентябре 2024-го подготовили исследователи Университета Акдениз, в список «мягких навыков» попадали и умение строить отношения, и самоконтроль, и вычислительное мышление, и креативность, и даже способность сохранять хорошее настроение. То есть термин широкий, а потому многие компании до сих пор трактуют его как приятное, но необязательное дополнение к инженерной ценности. На практике это ошибка: для разработчика ключевой soft skill обычно не абстрактная «командность», а очень приземленное умение ясно формулировать мысли, обсуждать идеи и передавать знания.
Это подтверждали еще в 2013 году исследователи из Университета Томпсон-Риверс, Университета Западного Онтарио и Университета ОАЭ. Они изучили научную литературу, требования в вакансиях, опросили около 170 разработчиков и сопоставили рабочие задачи с нужными навыками. Абсолютным лидером оказались именно коммуникативные способности. С тех пор картина не особенно изменилась: сообщество Developer Nation по-прежнему относит коммуникацию и передачу опыта к числу важнейших компетенций современного инженера. Но на уровне повседневного найма рынок упорно делает вид, что это опция, а не часть профессии.
Отсюда и системный перекос. В университетах будущих программистов в основном учат языкам, архитектуре и другим хардам. Исследователи из бразильской школы CESAR, которые проанализировали 31 научную работу 2020-2022 годов о дефиците кадров в software development, пришли к неприятному выводу: многие молодые специалисты выходят на рынок без софт-скиллов, необходимых для нормальной командной работы. Рекрутеры ситуацию лишь закрепляют: технические харды считаются входным билетом в профессию, а главным фильтром на найме часто остаются тестовые задания. Человек может написать приличное решение в одиночку, но это почти ничего не говорит о том, способен ли он документировать решения, менторить коллег и не превращать проект в персональный квест.
Для российских команд, особенно в компаниях с высокой текучестью, распределенными разработчиками и тяжелым наследием, это звучит как практический чек-лист. Если в проекте есть сервисы, которые «лучше не трогать без Пети», если ревью регулярно превращаются в угадайку, если новые люди месяцами распутывают контекст в чатах, значит, низкий фактор автобуса уже не гипотеза, а рабочая реальность. И исправляется она не корпоративным плакатом про командную работу, а скучными, но эффективными вещами: понятными PR, живой документацией, обязательной передачей контекста и ожиданием, что senior умеет не только чинить сложное, но и объяснять сложное.
Главный вывод здесь, пожалуй, самый неприятный для индустрии: зрелость разработчика уже трудно измерять только качеством кода. Чем сложнее продукты и чем дороже простои, тем выше ценность специалистов, которые умеют превращать личную экспертизу в общую. И если рынок продолжит считать коммуникацию второстепенной надстройкой над хардами, фактор автобуса останется не теоретическим термином из инженерных дискуссий, а обычным состоянием слишком многих команд.