Недавно на Хабре вышла статья Ивана Потапенко «Зачем и как избавляться от незаменимых сотрудников». Там про bus factor, про бутылочное горлышко, про ротацию, про дубляж знаний и работу вслух. Выглядит убедительно. Автор с 20 летним опытом, управлял отделами, доклад на конференции. Но есть одна проблема.
Иван описал идеальную команду в идеальном мире. Мир, где все хотят читать документацию. Где сотрудники сами пишут статьи в Wiki. Где ротация воспринимается с энтузиазмом, а не как «опять этот менеджер придумал». В реальности живут другие люди.
80% приходят на работу потому что кушать надо. Им не нужны ваши планы эвакуации. Им не нужны ваши знания. Они хотят получить задачу, сделать её, получить зарплату и уйти домой. К хобби, к семье, к сериалу. К чему угодно, только не к вашему коду и не к вашей документации. Они не будут читать инструкции. Никогда. Потому что спросить у того, кто знает, это 15 секунд. А читать и вникать это 15 минут скучной работы, которую никто не оплачивает отдельно.
Оставшиеся 20% это те, кому реально интересно. Они сами копают, сами читают, сами становятся экспертами. Их не надо заставлять. Они становятся незаменимыми не потому что процессы плохие, а потому что они так устроены. И они тащат на себе проекты. Пока 80% обсуждают в чатиках, что заказывать на обед, эти 20% правят критические баги в три часа ночи.
И тут приходит Иван и предлагает от них избавляться.
Я не буду просто критиковать. Критика без предложений это нытье. Давайте разберем, почему методы Ивана не работают, а потом я расскажу, что работает на самом деле. Спойлер: деньги, культура и организационные методы, а не ротация ради ротации.
О чем на самом деле статья Ивана
Иван приводит три примера незаменимых. Первый — Федя, который пришел и починил релиз с 60 багами. Второй — сотрудник, который один знал, как собрать проект под старое устройство. Третий — гипотетический перформер, который делает всё быстрее других.
Дальше Иван перечисляет риски. Bus factor (сотрудник заболел или уволился — всё встало). Bottleneck (команда не может делать быстрее, чем самый быстрый сотрудник). Саботаж (незаменимый действует по своему усмотрению). А еще деградация команды, потому что сложные задачи отдают перформеру, а остальные чахнут на простых.
Решение по Ивану: оцифровать знания (через дубляж и работу вслух), распределить навыки через ротацию, вывести перформеров из операционки (исследования, конференции, менторство), а в тяжелых случаях — промоутить или перевести в другую команду.
Почему это не работает?
Почему методы Ивана не работают с реальными людьми
Про инструкции и дубляж знаний
Иван пишет: «Маша, тебе Роман объяснял, как пользоваться системой? Отлично, напиши, пожалуйста, на Wiki статью и дай Роману проревьюить». И дальше: «Федя, давай через полчаса соберем всю команду, и ты покажешь, как решишь новый баг».
Предполагается, что команда будет это читать и смотреть. А если не будет? Иван не отвечает на этот вопрос. Потому что в его модели все хотят развиваться. В реальности 80% откроют Wiki, увидят простыню текста и закроют. Или придут на демо, полчаса послушают Федю, ничего не запомнят и пойдут дальше. Потому что им это не нужно. У них свои KPI, свои задачи, свой начальник, который спрашивает не «прочитал ли ты инструкцию?», а «закрыл ли ты свой спринт?».
Документация работает только тогда, когда ее чтение встроено в процесс. Когда без нее нельзя сдать задачу. Когда код не примут на ревью, если не приложен скриншот из Wiki с подтверждением, что разработчик прочитал раздел про эту фичу. Иван об этом молчит. Потому что это жестко, это конфликтно, это не про красивую ротацию, а про дисциплину. А дисциплину в современных IT статьях упоминать не модно.
Про ротацию и распределение навыков
Иван предлагает разбить проект на этапы и на каждом назначать новых людей на зону ответственности незаменимого. Или отдать доработку другим сотрудникам.
Вопрос: а если другие сотрудники не хотят? Или не могут? Или могут, но в три раза медленнее, и дедлайн горит? Вы как руководитель будете смотреть, как миддл третий день разбирается с легаси, которое перформер починил бы за час? Или вы всё таки отдадите задачу перформеру, потому что бизнесу нужен результат, а не эксперименты с ротацией?
Ротация работает только в командах, где уровень выравнен. Где нет разрыва между перформером и остальными. Но если разрыв есть, ротация превращается в издевательство над проектом. Иван не предлагает, как выравнивать уровень. Он предлагает ротировать и молиться.
Про вывод перформеров из операционки
Иван пишет: нагрузите перформера планированием, декомпозицией, конференциями, менторством стажера.
Это называется «нагрузить эксперта еще больше». Он и так решал сложные задачи. Теперь он еще и планирование тянет, и стажера учит, и конференции готовит. А его операционная работа никуда не делась. В итоге перформер выгорает и уходит. И тогда bus factor наступает не из-за болезни, а из-за того, что вы превратили жизнь эксперта в ад.
Иван пишет про найм стажера как про способ разгрузить перформера. Стажер задает вопросы. Перформер отвечает. Это не разгрузка. Это дополнительная работа. Разгрузка это когда стажер делает часть задач перформера. Но для этого стажер должен быть не стажером, а хотя бы миддлом. А миддлов нет, потому что вы их не вырастили.
Что работает вместо этого
Вы не превратите 80% в 20% никакими ротациями и дубляжами. У людей разная мотивация. И это нормально. Не все хотят быть архитекторами. Некоторые хотят быть добросовестными исполнителями. Им нужна понятная работа и предсказуемый доход. И это ок.
Проблема не в том, что 80% не читают инструкции. Проблема в том, что выстроена система, где можно не читать. И в том, что незаменимые не получают компенсацию за то, что тащат проекты.
Вот что реально работает. Без розовых пони, без bus factor истерики, без советов «поговорить по душам».
1. Заплатите незаменимым. Серьезно
Самый простой способ. Если сотрудник решает задачи, которые не может решить больше никто, он должен получать за это деньги. Не моральное удовлетворение. Не возможность сходить на конференцию. Не «спасибо, ты наш герой». А прямые, ощутимые деньги.
Сделайте надбавку за экспертизу. Дайте долю от проекта. Премию за каждый успешный релиз. Бонус за то, что к нему ходят с вопросами. Оформите это официально, чтобы человек видел, что его вклад ценят в рублях, а не в грамотах.
Почему это работает. Потому что когда незаменимый получает в полтора два раза больше коллег, он перестает беситься от того, что его дёргают. Он говорит: «Ок, это часть моей работы, мне за это платят». Исчезает раздражение. Исчезает желание уйти в другую компанию, где тоже нужны эксперты, но там хотя бы платят. А ещё у остальных появляется стимул. Они видят: если стану незаменимым, буду получать как он. И некоторые начинают читать инструкции.
Но нет. Вместо этого Иван предлагает ротацию. Потому что платить дорого. А ротация бесплатная.
2. Сделайте обращение к эксперту дорогим в усилиях
Не в деньгах. В усилиях. Введите правило. Прежде чем написать Роме, открой Wiki. Найди инструкцию. Прочитай её. Если не понял, перечитай. Если всё равно не понял, напиши Роме, но приложи скриншот того места, где завис, и опиши, что именно ты уже попробовал.
Это правило должен контролировать руководитель. Когда приходит вопрос без попытки самостоятельного решения, руководитель отвечает: «А что ты уже прочитал? Покажи, где застрял. Нет такого? Иди читай, потом приходи».
Сначала будет нытьё. «Раньше Рома отвечал за 15 секунд, а теперь меня отправляют в Wiki». Потом привыкнут. Потому что люди быстро адаптируются к правилам. Если вы как руководитель будете их соблюдать и требовать от команды, через месяц 80% начнут открывать Wiki прежде чем писать.
Иван пишет про культуру «расширенных обязанностей», где каждый отвечает за чуть большую область. Но он не пишет про то, как это внедрить. А внедряется это только через системное требование, через отказ быть быстрым ответчиком, через боль первых недель. Это не про «прямые указания и поощрения». Это про «я не отвечу, пока не увижу, что ты попытался сам».
3. Нанимайте тех, кто умеет читать и искать
При собеседовании дайте кандидату задание. Вот ссылка на документацию вашего проекта. Вот вопрос, ответ на который там есть. Найди ответ за 10 минут. Не ищет, не находит, сдается и просит подсказку? Не подходит. Потому что этот человек будет дёргать экспертов. Он привык, что ответ приносят на блюдечке.
Наймите того, кто скажет: «Я нашел раздел про это, там написано так то, но у меня уточнение вот по какому пункту». Это стоит потраченного времени на собеседовании. Потому что такой сотрудник не станет частью 80%, которые не читают. Он будет как минимум пытаться.
Иван пишет про ротацию и дубляж, но не пишет про найм. А найм это самое важное. Если вы берете в команду людей, которые не умеют и не хотят искать ответы сами, никакие инструкции не спасут. Вы будете бесконечно писать документы, которые никто не читает.
4. Введите дежурства и часы тишины
Организационный метод. В команде есть один эксперт. Вместо того чтобы избавляться от него, организуйте его время так, чтобы его не дёргали 24/7.
Введите дежурного по вопросам. Каждую неделю другой сотрудник (не эксперт) отвечает за то, чтобы собирать вопросы, искать ответы в документации, а если не нашел — формулировать для эксперта четко и письменно. Эксперт отвечает раз в день, в выделенный час. Всё.Введите часы тишины. С 10 до 12 и с 14 до 16 эксперта нельзя дёргать вообще. Он пишет код. Всё остальное время можно, но только через дежурного или после прочтения Wiki.
Эти методы работают. Они не требуют увольнять незаменимого. Они просто меняют правила игры. Иван про это не пишет. Потому что это скучная органика, а не красивая история про bus factor и работу вслух.
5. Признайте, что 20% всегда будут тащить. И перестаньте их за это наказывать
Самое важное. В любой команде есть распределение. Кто то тащит, кто то просто работает. Это не баг, это фича человеческой природы. Вы не сделаете всех одинаковыми ротациями. Вы только потеряете лучших.
Что значит «наказывать»? Это когда эксперт получает столько же, сколько миддл, который каждые 15 минут дёргает его с вопросом. Когда эксперта грузят написанием инструкций и обучением стажеров в дополнение к его основной работе. Когда эксперт читает статьи про то, как от него избавиться. Это наказание.
Что значит «не наказывать»? Это когда эксперт получает больше. Когда у него есть время на свою работу, потому что вопросы отфильтрованы. Когда его не заставляют быть учителем, если он не хочет. Когда ему говорят «спасибо, что ты с нами», а не «ты проблема, потому что без тебя всё встанет».
Как понять, что Иван не прав, на своем опыте
Я работала в компаниях, где пробовали подход Ивана. Руководитель прочитал умную статью и решил, что пора избавляться от незаменимости. Начали ротацию. Экспертов пересадили на другие проекты. Их старые задачи отдали миддлам. Результат? Дедлайны сдвинулись на месяцы. Качество упало. Эксперты на новых проектах тоже не горели, потому что их оторвали от того, что они любят и умеют. Через полгода два эксперта уволились. А миддлы так и не выросли до их уровня, потому что уровень разрыва был слишком большим.
Я работала в компаниях, где делали по другому. Экспертам подняли зарплату на 40%. Ввели правило «прежде чем спросить, открой Wiki». Нанимали только тех, кто умеет искать. И оставили экспертов на своих местах, где они эффективны. Результат? Проекты сдавались вовремя. Эксперты не бесились. Миддлы постепенно подтягивались, потому что у них был стимул (деньги эксперта) и была культура самостоятельного поиска. Через год двое миддлов сами стали экспертами. Кажется, что второй путь сложнее? Он сложнее ровно в одном месте. В первом месяце, когда команда привыкает, что на вопросы не отвечают мгновенно. Потом всё становится нормально.
Что в итоге
Иван, ваша статья хороша для MBA курсов и выступлений на конференциях. Там любят схемы про bus factor и ротацию. Но в реальности ваши методы либо не работают, либо работают только в командах, которые уже состоят из 20% горящих глаз. Такие команды есть, но их мало.
Для остальных 95% команд работают другие методы:
Заплатить незаменимым столько, чтобы они не хотели уходить и не бесились от вопросов.
Сделать обращение к эксперту дорогим через правила и контроль руководителя.
Нанимать тех, кто умеет читать и искать.
Ввести дежурства и часы тишины, чтобы у эксперта было время на работу.
Принять как факт, что 20% тащат, и перестать их за это наказывать.
Ни один из этих методов не требует избавляться от незаменимых. Они требуют денег, дисциплины и честности. А это сложнее, чем написать статью.
И последнее. Если ваш проект рушится от того, что один сотрудник ушел в отпуск или заболел, проблема не в этом сотруднике. Проблема в том, что вы построили систему на хрупком фундаменте. И вместо того чтобы укрепить фундамент (найм, документирование встроенное в процесс, распределение знаний не через «напиши инструкцию», а через «ты не сдашь задачу, пока не докажешь, что инструкция прочитана»), вы хотите избавиться от единственного, кто этот фундамент держит.
Не надо избавляться. Надо строить нормальную систему. Дорого? Да. Долго? Да. Но это единственный способ, который работает с живыми людьми, а не с идеальными сотрудниками из статей.
Иван, если вы читаете это — спасибо за статью. Она заставила меня сесть и написать свой взгляд. Дискуссия полезна. Но пожалуйста, в следующий раз добавьте в статью хотя бы пару абзацев про деньги и про то, как заставить людей читать документацию. Это поможет больше, чем очередная схема про bus factor.
