Недавно внимание ИТ-сообщества привлекла статья о том, что даже сеньоры не всегда способны эффективно передавать свою экспертизу — ни менеджерам, ни менее опытным коллегам-программистам. Мы в Beeline Cloud решили поговорить о том, как недостаток софт-скиллов разработчиков мешает обмену знаниями, какие опасности он таит для проектов и при чем тут «фактор автобуса».
Что еще за фактор автобуса
Проблемы коммуникации и передачи знаний внутри команд разработки — одна из тех тем, вокруг которых регулярно возникают дискуссии на профильных площадках. Джордан Катлер, инженер из Pinterest и автор популярной англоязычной рассылки для разработчиков на тему карьерного роста High Growth Engineer, даже предложил термин communication smells, по аналогии с известным выражением code smells. Подобно тому как запутанная логика сигнализирует о проблемах в коде, системные проблемы в общении внутри команд или, например, расплывчатые формулировки при составлении пулл-реквестов мешают коммуникации и обмену знаниями между коллегами.
Сложности с передачей экспертизы между разработчиками — от сеньоров к джунам — обсуждаемый в индустрии топик. Как правило, старшие разработчики — это костяк команды: они глубоко понимают архитектуру продукта, знают внутреннюю инфраструктуру, особенности процессов. Но если такие знания оказываются «заперты» в голове нескольких специалистов (или даже одного), компания сильно рискует. Прежде всего, снижается так называемый «фактор автобуса» (bus factor), отражающий степень зависимости команды от конкретных специалистов с уникальной экспертизой.
Название происходит от довольно мрачного мысленного эксперимента: сколько человек должен «сбить автобус» (выражаясь более мягко: сколько человек должны уйти из компании), прежде чем проект окажется неспособен нормально функционировать. Если вся экспертиза сосредоточена у одного человека, фактор автобуса равен единице; если знания распределены между пятью независимыми специалистами — пяти. Чем ниже значение, тем выше вероятность, что проект столкнется с серьезными проблемами, если ключевые люди будут вынуждены его покинуть.
Любопытно, что проблема низкого фактора автобуса особенно остро проявляется в мире открытого программного обеспечения. В прошлом году ИБ-специалист из компании Anchore Джош Брессерс проанализировал архив платформы ecosyste.ms, которая собирает данные о миллионах open source-проектов. Оказалось, что из 11,8 млн репозиториев в базе почти 7 млн поддерживаются всего одним человеком. Впрочем, такая ситуация сложилась не вчера. В 2014 году аналитики компании Bocoup выяснили, что 93% пакетов в экосистеме npm имеют всего одного мейнтейнера. Исследование 2015 года, посвященное популярным проектам на GitHub, показало, что почти две трети из них поддерживаются одним или, максимум, двумя людьми.
Даже сами open source-разработчики открыто говорят о проблеме. Так, в 2019 году автор системной библиотеки libinput признавался, что фактор автобуса у проекта фактически равен единице [формально у библиотеки были и другие контрибьюторы, однако из примерно 1200 коммитов около тысячи принадлежали ему одному]. Автор называл ситуацию «неидеальной» и, в попытке привлечь внимание сообщества, даже написал тематическую статью с призывом подключиться к развитию libinput.
Ситуация, когда все ключевые знания о проекте сосредоточены в руках одного-двух разработчиков, может показаться просто организационной проблемой. Но на практике она оборачивается вполне осязаемыми финансовыми потерями. По некоторым оценкам, компании из списка Fortune 500 ежегодно теряют 31,5 млрд долларов из-за неэффективного обмена знаниями внутри команд. Особенно болезненно это проявляется в компаниях, где много легаси-кода и компонентов, авторы которых уже давно сменили место работы.
Можно выделить множество причин, мешающих обмену знаниями. Иногда проблема кроется в неудачно выстроенных процессах, порой — в отсутствии корпоративной базы знаний. Но довольно часто препятствием становятся и сами разработчики: экспертиза есть, а вот умения понятно объяснять, делиться опытом и выстраивать коммуникацию оказывается недостаточно.
Софт-скиллы: базовый минимум программиста
Понятие «мягких навыков» довольно размыто: исследователи относят к этой категории самые разные качества, а универсального и исчерпывающего списка не существует. В сентябре 2024 года специалисты из Университета Акдениз в Турции провели систематический обзор статей про софт-скиллы с 1993 по 2019 годы и выделили навыки, которые разные исследователи относили к «мягким». В список попали: умение выстраивать отношения с другими людьми, самоконтроль, вычислительное мышление, креативность — некоторые считали софт-скиллом даже банальное умение сохранять хорошее настроение.
Более того, перечень самых популярных «мягких» навыков, которые соискатели указывают в своих резюме (а работодатели ожидают увидеть), со временем меняется. В LinkedIn ежегодно опрашивают тысячи специалистов по развитию персонала, и, согласно отчетам компании, в 2019-м на слуху были креативность, навыки убеждения и тайм-менеджмента, тогда как к 2021-му фокус сместился на эмоциональный интеллект и стрессоустойчивость. Последний отчет за 2025 год подсветил такие качества, как способность к обучению и готовность подстраиваться под меняющуюся обстановку.
Если говорить именно о разработчиках программного обеспечения, то среди наиболее востребованных софт-скиллов неизменно оказываются умение общаться и эффективно взаимодействовать с командой. К такому выводу пришли исследователи из Университета Томпсон-Риверс, Университета Западного Онтарио и Университета ОАЭ еще в 2013 году. Они провели масштабный обзор научной литературы, изучили требования к вакансиям на популярных сайтах по поиску работы, опросили около 170 разработчиков и сопоставили их рабочие задачи с необходимыми для их выполнения «мягкими» навыками. Абсолютным лидером среди софт-скиллов оказались коммуникативные способности: умение ясно формулировать мысли, обсуждать идеи и обмениваться знаниями. Важными оказались и межличностные навыки: способность выстраивать отношения и договариваться с коллегами.
С тех пор ситуация практически не изменилась: умение обмениваться знаниями по-прежнему остается одним из центральных навыков для разработчиков. Так, сообщество Developer Nation, объединяющее инженеров и аналитиков, относит навыки коммуникации и передачи опыта к числу наиболее важных компетенций современного ИТ-специалиста.
Что не так с «мягкими навыками» в ИТ
С университетской скамьи основной упор в образовании будущих программистов делается на «хардах»: изучении языков, построении ИТ-архитектуры и так далее. Это важные навыки, однако большинство молодых специалистов выпускаются из вузов без необходимых софт-скиллов для работы в команде — так говорят исследователи из бразильской школы CESAR, которые изучили тридцать одну научную статью, опубликованную в 2020-2022гг. и посвященную нехватке специалистов на рынке программного обеспечения. Даже рекрутеры в первую очередь смотрят на технические харды, которые называют «входным билетом» в профессию, и в качестве основного инструмента найма используют тестовые задания. Недостаток «мягких» навыков приводит к сложностям с передачей знаний внутри коллектива, что в долгосрочной перспективе снижает тот самый фактор автобуса со всеми вытекающими рисками.
Нехватка софт-скиллов (в том числе неумение посмотреть на ситуацию глазами собеседника) также может быть причиной расхождений в восприятии тональности при текстовом общении — например, в рабочем чате. Исследователи из Ганноверского университета имени Лейбница попытались понять, почему одно и то же сообщение один человек воспринимает как нейтральное, а другой — как негативное или агрессивное, и как это влияет на командную работу. Ученые использовали данные онлайн-опроса, в котором участвовали 94 разработчика с разным уровнем опыта. Им показывали реальные высказывания, которые взяли со Stack Overflow или GitHub (например, «У вас проблема с classpath» или «Обоснование разработчиков приведено в спецификации JDF») — и просили оценить тональность каждого: позитивная, негативная или нейтральная. Затем авторы использовали кластерный анализ, чтобы сгруппировать участников по схожести восприятия. В итоге они отметили, что существует как минимум две группы разработчиков, которые расходились во мнении о 65% высказываний — больше половины сообщений воспринимались ими по-разному, что в теории может приводить к конфликтным ситуациям.
Еще одна причина низкого фактора автобуса
Обмену знаниями могут препятствовать не столько «проседающие» софт-скиллы, но и плохо выстроенные корпоративные процессы в командах разработки. Зачастую инженеры готовы делиться опытом, но у них просто нет для этого ни времени, ни подходящих условий. Во многих компаниях «мерилом эффективности» сеньора до сих пор служит число написанных строк кода. Как отмечает один разработчик в тематическом треде, сеньоров фактически оставляют работать в изоляции: им ставят настолько плотные дедлайны, что времени хватает только на написание кода — и больше ни на что.
С другой стороны, проблема может быть и в отсутствии мотивации. Если внутри компании выстроена «токсичная» культура, сотрудники просто не видят смысла делиться опытом. Исследование, проведенное фирмой Slab, работающей с системами управления знаниями, выделяет три основные причины, по которым сотрудники «придерживают» экспертизу: стремление сохранить рычаги влияния, страх и внутренняя конкуренция. «Сотрудники должны обмениваться знаниями — это приносит пользу компании. Но если они не доверяют друг другу, всегда найдется причина не делиться опытом», — отмечает Кэтрин Коннелли, профессор Университета Макмастера в Онтарио. Исследователи замечают: если человек однажды пострадал от коллеги, который скрывал знания, он с высокой вероятностью может и сам начать вести себя так же, воспроизводя модель поведения «в джунглях каждый сам за себя».
Что с этим делать: пара банальных советов, которые работают
Исследователи и представители индустрии сходятся во мнении, что обмен знаниями не возникает сам по себе. Особенно в крупных или распределенных командах — для этого нужна осознанно выстроенная культура, на создание которой требуются время, ресурсы и усилия. При этом формируется она обычно сверху вниз: если руководство не демонстрирует готовность к сотрудничеству, не поощряет открытость, ожидать такого же поведения от сотрудников сложно. Например, в Atlassian рекомендуют регулярно проводить дни тимбилдинга, а также отказаться от собраний в стиле презентаций, на которых выступает только один человек, в пользу встреч, где каждый участник может высказать свое мнение, задать вопрос или поделиться опытом.
На первый взгляд, такие рекомендации кажутся очевидными. Однако на практике даже их реализуют далеко не всегда. Исследователи из Преторийского университета проанализировали научные работы по теме обмена знаниями в инженерных командах и выделили часто встречающиеся практики — например, все те же регулярные встречи для обсуждения рабочих проблем, совместные мозговые штурмы, программы наставничества. Однако сделали любопытный вывод на основе комментариев разработчиков: многие компании хорошо понимают, какие подходы работают, но редко занимаются их систематическим внедрением. Иными словами, возможно, даже банальная организация регулярного пятничного чаепития может сделать для увеличения фактора автобуса больше, чем сложные регламенты или обучение сотрудников искусству публичных выступлений.
Beeline Cloud — безопасный облачный провайдер. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
Еще больше интересных материалов в блоге на Хабре и на ИТ-площадке «вАЙТИ»:
