«У нас всё делает Вася»: как выйти из зависимости от одного человека

MAATRIX

В любой команде из десяти-пятнадцати человек рано или поздно появляется свой Вася — тот, кому пишут в личку в девять вечера, когда что-то упало, и кто один знает, почему прошлогодний скрипт назван final_v2_really и зачем он до сих пор запускается по крону. Формально у Васи такие же права, как у остальных айтишников в команде, но фактически вся техническая реальность компании держится на одной голове. Это не история про плохого сотрудника или ленивое руководство — это устойчивая групповая динамика, которая формируется по вполне понятным причинам и которую нельзя сломать директивой «отныне документируем всё». Ломать её нужно медленнее и внимательнее — меняя не процессы, а роль конкретного человека в команде.

Откуда берётся «свой Вася»: удобство, которое затягивает

Динамика «спроси у Васи» почти никогда не возникает по чьему-то злому умыслу — она вырастает из десятков маленьких решений в моменте, каждое из которых было рациональным. Когда что-то ломается в пятницу вечером, проще написать человеку, который чинил это в прошлый раз, чем читать документацию, которой чаще всего просто нет. Когда нужно быстро выкатить фичу, проще попросить того, кто уже знает, где лежит нужный конфиг, чем тратить полдня на объяснение контекста новому человеку. Каждое такое решение экономит час здесь и сейчас — и одновременно откладывает на потом создание процесса, который сэкономил бы гораздо больше времени в масштабе года.

Руководство в этой динамике тоже участвует, часто не замечая этого. Такой человек прекрасно закрывает вопросы — быстро, без совещаний, без бюрократии — и до тех пор, пока ничего не сломалось, у руководства просто нет повода спрашивать «а что если завтра его не будет». Формализация процессов требует времени и выглядит как расход ресурса на то, что и так работает. Это классическая ловушка: система, которая явно уязвима, продолжает казаться надёжной ровно до момента отказа. Похожий разбор того, что происходит в компании в первые часы и дни после исчезновения такого человека, есть в статье про bus factor и первые сутки без единственного админа — там показано, насколько быстро удобство оборачивается кризисом.

Со временем «спроси у Васи» превращается в дефолтный маршрут для любого технического вопроса, даже тривиального. Люди перестают пытаться разобраться сами — не потому что не способны, а потому что путь наименьшего сопротивления уже проложен, и идти по нему быстрее и безопаснее для собственной репутации: если сделаешь сам и ошибёшься — виноват ты, если спросишь Васю и он ошибётся — это его ответственность. Так динамика подкрепляет сама себя с обеих сторон.

Что Вася получает от этой роли — и почему не спешит её терять

Здесь важно быть честными: у самого Васи почти всегда есть неявный стимул не торопиться размывать эту зависимость, и дело не в злом умысле, а в том, что роль незаменимого специалиста даёт вещи, которые сложно получить иначе. Это статус в команде — к его мнению прислушиваются не по должности, а потому что без него ничего не работает. Это ощущение нужности и контроля — в компании, где формальная иерархия может быть плоской или вообще не выстроенной, экспертное превосходство становится единственной понятной формой веса. Иногда это и вполне материальный аргумент на переговорах о зарплате: пока никто, кроме тебя, не может починить прод, твоя позиция объективно сильнее.

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

Отдельная причина инерции — то, что сама передача знаний требует времени и усилий именно от Васи, причём в моменте, когда он и так самый загруженный человек в команде. Написать документацию, провести человека за руку через систему, ответить на десять уточняющих вопросов — это дополнительная работа поверх текущей, а стимулов делать её меньше, чем стимулов просто закрыть тикет самому за пять минут.

Почему прямая атака не работает: «задокументируй всё» звучит как недоверие

Самая частая ошибка руководства, осознавшего проблему, — резкий разворот в духе «с понедельника всё документируем, ты больше не единственный, кто трогает прод». Формально это правильное требование. Психологически — это удар по статусу человека, который годами закрывал компанию собой, часто в ущерб личному времени, и вдруг слышит, что теперь это подаётся как проблема, которую нужно срочно устранить.

Реакция на такое требование предсказуема и редко бывает открытым сопротивлением — гораздо чаще это пассивное торможение: документация пишется формально и неполно, передача знаний новому человеку идёт медленно и с недомолвками, а критичные нюансы («вот тут нужно руками поправить, иначе всё упадёт») почему-то не попадают ни в один документ. Не потому что Вася вредничает специально, а потому что мозг сопротивляется тому, что воспринимается как угроза собственной значимости.

Здесь стоит честно признать психологическую сложность задачи: смена устоявшейся годами динамики требует времени и деликатности, и быстрого решения тут нет. Компания, которая пытается продавить формализацию за две недели директивой сверху, чаще получает не распределённые знания, а демотивированного ключевого специалиста и документацию для галочки. Правильный путь медленнее, но он действительно меняет структуру, а не создаёт видимость изменений.

Шаг первый — признать знания активом компании, а не личной зависимостью

Первый и самый важный сдвиг происходит в языке, которым руководство описывает ситуацию. Есть разница между «мы слишком зависим от одного человека, это риск» и «у нас в одной голове накоплен огромный объём ценных знаний о системе, и наша задача — защитить этот актив, чтобы он не терялся вместе с уходом человека в отпуск, на больничный или в другую компанию». Первая формулировка звучит как претензия к Васе. Вторая — как признание его вклада с параллельной постановкой задачи, в которой он выступает не источником проблемы, а держателем ценности, которую нужно сохранить.

Это не просто смена риторики ради того, чтобы человеку было приятнее. Разговор в терминах актива компании честно отражает реальность: то, что знает Вася, — это результат его многолетней работы, часто не задокументированной именно потому, что он один справлялся быстрее, чем успевал бы писать инструкции. Обесценивать этот опыт формулировкой «ты — риск, которого надо избежать» контрпродуктивно вдвойне: и потому что это неприятно услышать, и потому что это неточно описывает ситуацию. Риск — это отсутствие резервной копии знаний, а не сам факт того, что знания у кого-то есть.

Практически это означает разговор один на один, не на общем собрании, где формулировка звучит примерно так: то, что ты держишь в голове, — это то, что позволяет компании вообще работать, и именно поэтому нам страшно, что это держится в одной голове. Мы хотим не забрать у тебя эту роль, а сделать так, чтобы твоя экспертиза не исчезала вместе с твоим отсутствием — будь то отпуск, болезнь или что угодно ещё. Дальше стоит прямо спросить, что мешало документировать раньше — почти всегда ответ будет «не было времени», и это уже конкретная, решаемая проблема, а не абстрактное сопротивление.

Шаг второй — сделать Васю соавтором процесса, а не объектом контроля

Разница между «мы внедряем регламент документирования, и ты обязан ему следовать» и «помоги нам придумать, как задокументировать то, что ты знаешь, так, чтобы это было реально полезно, а не для галочки» — не косметическая. Во втором случае Вася становится автором решения, а не его целью. Он лучше кого угодно в компании знает, какие куски системы критичны, а какие тривиальны, какие грабли неочевидны, а какие можно найти за пять минут в официальной документации. Спросить его мнение о том, как организовать передачу знаний — не формальность, а способ получить рабочий процесс вместо мёртвого документа.

На практике это можно оформить как отдельную небольшую задачу с понятным результатом и, что важно, с выделенным на неё временем — не «в свободную минуту», а именно выделенные часы в рабочем графике, потому что иначе документирование неизбежно проигрывает более срочным вещам. Хорошо работает формат, в котором Вася сам выбирает, что фиксировать в первую очередь — обычно он интуитивно понимает, где риск потери знаний выше всего, даже если раньше не формулировал это явно. О том, какой минимум стоит вести и в каком формате, чтобы документ не превратился в мёртвый груз, подробно разобрано в статье про то, что нужно фиксировать в документации сервера — но важно, что содержание в этой статье вторично по отношению к тому, кто и как это содержание собирает.

Отдельно стоит подчеркнуть публично — на общей встрече, в переписке, где это увидит команда — что новая документация существует благодаря конкретному человеку, а не появилась откуда-то сама. Это закрывает главный страх: что формализация знаний равна их обесцениванию. Наоборот, письменная фиксация экспертизы Васи делает эту экспертизу более видимой и более защищённой, а не менее.

Шаг третий — вводить других через совместную работу, а не резкую замену

Резкая замена «теперь этим занимается не Вася, а Петя» почти гарантированно воспринимается как понижение в статусе, даже если формально никто ничего не понижал. Гораздо мягче и результативнее работает постепенное подключение — через совместную работу, а не через передачу полномочий одним решением сверху.

Первый шаг — не «Петя теперь делает это сам», а «Петя садится рядом с Васей и смотрит, как тот решает задачу, потом пробует повторить под присмотром». Роль Васи на этом этапе — не отдать задачу, а стать наставником, что снова работает на статус, а не против него. Дальше — «Петя делает сам, Вася на подхвате». И только на третьем этапе — «Петя делает сам, Вася в курсе постфактум». Каждый переход занимает недели, иногда месяцы: цель не в скорости, а в том, чтобы знания реально закрепились у второго человека, а не были формально переданы и тут же забыты.

Важный нюанс: не стоит выбирать для дублирования компетенций только самого слабого или самого свободного человека в команде — это читается как «дайте это тому, кого не жалко» и не выглядит как настоящая инвестиция в устойчивость. Лучше работает выбор человека, который сам проявляет интерес к этой части системы, даже если формально он занят другими задачами — мотивация участника сильно влияет на то, приживутся знания или нет. Похожая логика постепенного подключения разобрана в статье про разграничение доступов в команде из трёх человек — там показано, как маленькая команда может распределить ответственность без резкой ролевой ломки.

Параллельно стоит закрыть техническую часть риска — отдельный вопрос от психологии роли, но игнорировать его тоже нельзя: пока знания передаются постепенно, у компании всё равно должен быть резервный доступ на случай, если Вася окажется недоступен раньше, чем передача завершится. Это не альтернатива описанному выше процессу, а параллельная страховка на время переходного периода.

Что делать руководству: язык, темп и признание

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

Не сравнивайте Васю с другими сотрудниками в контексте этой темы — фразы вроде «а вот в других компаниях так не бывает, там всё задокументировано» работают против вас, потому что звучат как упрёк, а не как приглашение к изменению. Хвалите конкретные шаги, а не абстрактную идею — если Вася провёл час с новым человеком, объясняя часть системы, это стоит отметить явно и сразу, а не ждать финального результата через полгода.

Закладывайте время на передачу знаний в планирование так же, как закладываете время на фичи и баги — если документирование и наставничество существуют только в промежутках между «настоящей» работой, они и будут восприниматься как менее важные, и в первую очередь самим Васей. Отслеживайте прогресс не через контроль («ты уже написал документацию?»), а через регулярный разговор о том, что получается, а что буксует — это тот же принцип соавторства, применённый к самому процессу изменений.

И, пожалуй, главное — будьте готовы к тому, что процесс займёт месяцы, а не недели, и это нормальная цена за то, что изменение окажется устойчивым, а не косметическим. Компания, которая торопит этот процесс, рискует получить обратный эффект: обиженного ключевого специалиста, который либо уходит, либо возвращается к старой роли единственного держателя знаний просто потому, что так было спокойнее для всех, включая его самого.

Частые вопросы