Привет, Хабр! Я — Иван Потапенко, на момент подготовки этого материала был независимым экспертом, а сейчас работаю в Yandex Infrastructure. В IT — 20 c копейками лет. Потрудился в восьми компаниях, в пяти из них управлял отделами. Эта статья основана на докладе для конференции Saint TeamLead, и в ней я расскажу о том, что делать, если некоторые процессы в команде сильно завязаны на отдельно взятых людях.
Зачастую есть план «Б». Я большой фанат планов B, C, D — не в том смысле, что мне нравится, когда всё идёт по плану Е, Ё и другим буквам. Мне так спокойнее, я могу делать более резкие движения, более рискованные шаги, что даёт свой положительный результат. Поэтому мне хочется рассказать, почему следует избавиться от всех незаменимых сотрудников в ваших отделах, как это сделать легко, а порой даже с удовольствием.
Кто такие незаменимые сотрудники: на реальных примерах
Недавно мне посчастливилось участвовать в стабилизации одного релиза. До него оставалось дней пять, и в проекте было порядка 60 багов. Продукт для меня новый, команда тоже, логичен диалог: «Ребята, а мы точно справимся?» — «Фигня вопрос», — отвечает команда, и мы стартуем.
В первый день команда закрывает 15 задач — классно, даёт надежду на успех. Но вечером приходит QA, переоткрывает 4 и находит 10 новых. Ладно, в принципе, по закону больших чисел мы все знаем, что одно измерение — не показатель. Однако ситуация повторяется.
Мы в коллективе приняли логичное решение: «А давайте наконец сдвинем дату релиза!». Судя по графику, примерно через три месяца мы могли стартовать без проблем, но тут меня остановила команда: «Стоять, завтра к нам подключится Федя».
Фёдор — эксперт компании, написал много кода в различных продуктах, и с его участием ситуация стала немного лучше.
Мы вовремя всё стабилизировали и выпустили релиз. Казалось бы, успех! Но в течение месяца я становлюсь свидетелем похожей ситуации с другой командой.
Проблема заключалась в одном из проектов, который закрыли три года назад. Команда уже распалась, большая часть сотрудников уволилась. Но появился заказчик, который говорит, что на каком-то устройстве при определённых условиях возникает баг.
Начали проводить сборку, а она не запускается. Что делать? Стали искать людей, которые занимались этим проектом и нашли того, кто знает именно это устройство и его специфику. Диалог выглядел приблизительно так.
Попробовали — работает. Сделали сборку, запустили, баг починили, заказчик счастлив, команда счастлива. Несчастлив менеджер.
В этих ситуациях меня стриггерил даже не факт наличия сотрудников, которые могут точечно решить проблему. Мне не понравилось отношение команд ко всему этому. Вкратце его можно описать так: «Классно, что у нас есть такие люди, иначе бы всё накрылось медным тазом!». В целом, они правы, и именно таких людей я называю незаменимыми сотрудниками.
По сути, это люди, которые обладают чем-то уникальным — знанием, навыками, либо ресурсами, которые позволяют им решать задачи, неразрешимые для других. Иногда это лучшие сотрудники отдела, как в первой ситуации. А иногда случайные люди, которые обладают знаниями или специфичными ресурсами.
Перед тем как рассказать, зачем всё-таки надо избавляться от людей, на которых держится всё, мне хочется подсветить, откуда же появляются у нас такие сотрудники.
Причины, по которым в команде появляется незаменимый сотрудник
Я выделяю три решающих фактора:
High-performance-сотрудники — те, которые изначально обладают незаурядными навыками и знаниями. Продуктивность этих специалистов кратно превышает продуктивность любого другого сотрудника, а порой даже отдела целиком.
Оно само. Например, если после краха отдела остался единственный сотрудник и так получилось, что все знания о продукте, навыки работы с ним или другой ресурс остались только у него. Проблема в том, что, в отличие от перформеров, этот сотрудник не обязательно сверхпродуктивный и незаурядный, зачастую это просто типичный миддл.
Процессы и традиции — такой человек появился в команде специально. Лично я считаю этот фактор едва ли не основным. Например, если компания перестанет требовать от сотрудника «тратить время» на составление инструкции к новым фичам, полагаясь на то, что он создаёт рабочий продукт и наверняка продолжит это делать, то со временем каждый такой сотрудник станет обладателем уникальных знаний и будет незаменимым. Именно поэтому я считаю, что процессы — это самый простой способ создать себе проблемы на пустом месте.
Риски, связанные с незаменимыми сотрудниками
Казалось бы, зачем избавляться от незаменимых сотрудников, если они хорошо решают сложные задачи. Но я считаю, что у этого есть негативные последствия:
В ближайшее время вы провалите один из своих проектов.
Постепенно начнётся деградация процессов.
Развитие других ваших сотрудников остановится.
Риски для производительности
Почему вы провалите проект?
Bus-Factor
Потеря сотрудника из-за болезни или увольнения вычёркивает большую часть экспертизы из вашего отдела, что ставит любой проект под риск.Bottleneck
Обращаясь к теории ограничений Голдратта, это бутылочное горлышко: вы просто не можете производить продукт быстрее, чем работает ваш самый продуктивный сотрудник, он задаёт верхнюю планку.Саботаж
Риск потери контроля над незаменимым сотрудником и командой. Например, если такой сотрудник будет действовать по своему усмотрению, а не плану, согласованному с продакт-менеджером.
У всех этих рисков есть одна положительная сторона — они произойдут не сразу и не обязательно в ближайший месяц. Однако негативное влияние незаменимых сотрудников будет всегда давить на ваши команды.
Негативное влияние незаменимых сотрудников на команду
Централизация профессионального роста
Персональный рост остальных сотрудников ограничен, потому что им не поручают сложные задачи. Наверняка в условиях ограниченного времени вы отдадите критически важную или самую интересную фичу самому производительному сотруднику. Все остальные участники команды так и остаются на заурядных задачках и постепенно деградируют.Слепота к точкам роста и деградация процессов
Люди просто не замечают, что процессы в команде работают не всегда правильно, ведь у вас есть рыцарь на белом коне, который приходит и всё спасает. Решение первой истории с Федей было до ужаса тривиальным: «А давайте мы перестанем оставлять баги на этап стабилизации и начнём их чинить по мере возникновения». И это сработало, но изначально команда просто не видела это — все последние релизы она закрывала без проблем, и никто не страдал. Только нервные клетки руководителя.Вопросы к качеству работ
Как это ни смешно, но вопросы о качестве работ возникают именно к незаменимым сотрудникам. Осознание того, что вы являетесь единственным владельцем какой-то зоны ответственности, не стимулирует вас писать документацию, делать «защиту от дурака». Если вы хоть раз заглядывали в код уволившегося сотрудника с фразой: «Да боже мой, как эта фигня работает?», знайте, скорее всего, он считал себя незаменимым. По крайней мере, в этой части.
Быть незаменимым — это палка о двух концах
Незаменимые тоже платят свою цену:
Перегруженность
Сотрудник вынужден раз за разом уделять внимание той области, в которой он незаменим, отрываясь от текущей работы, и тратит всё больше времени на саппорт вместо создания новых фич.Проблемы с промоушеном
Для промоушена такого сотрудника потребуется найти замену на его обязанности, а он незаменим.Затруднено саморазвитие
При высокой перегруженности сотрудник ограничивается деятельностью в той области, в которой он является незаменимым, и постепеноо начинает деградировать. Просто потому, что некогда изучать новый материал либо негде его применить.
Так зачем избавляться от таких сотрудников?
Для CTO я обычно продаю первые три проблемы с производительностью — и этого достаточно. В случае с командой идеально работают последние три проблемы. А для себя я решил: если я хочу работать в команде, которая развивается органично и постоянно добивается новых результатов, то просто должен избавиться от незаменимых сотрудников и растить всех равномерно.
Не только увольнение: способы избавиться от незаменимых сотрудников
Увольнение не всегда является решением — более того, скорее всего, вам не одобрят предложение избавиться от самого лучшего сотрудника в отделе.
Ранее я сказал про три уникальных фактора, которые делают людей незаменимыми: знания, навыки и ресурсы. По сути, если мы сделаем их неуникальными, этого должно хватить.
Пойдём от простого к сложному.
Оцифровка знаний
Достаточно просто оцифровать знания.
Есть куча методик, которые рассказывают, что такое знания, как они формируются, что такое неявные и явные знания, как они переходят друг в друга.
Здесь хочу подсветить два метода, которые пригодятся в работе с незаменимыми сотрудниками. Часто это идёт по такому сценарию: «Роман, ты сделал такую классную тестовую систему! А напиши всё-таки документацию, как ей пользоваться, чтобы другие могли её запускать и не отвлекать тебя». А через неделю человек говорит: «Я был так занят! Ко мне прилетели более важные новые задачи, поэтому документации нет». В принципе да, незаменимые сотрудники более загружены, в это можно поверить, если бы не одно НО. Как правило, за эту неделю Роман делает 4–5 созвонов с другими командами, рассказывая, как пользоваться этой системой, либо помогая запустить тесты, а это похоже на саботаж.
Но есть выход:
Дублирование знаний
«Маша, тебе Роман объяснял, как пользоваться системой? Отлично, напиши, пожалуйста, на Wiki статью и дай Роману проревьюить». Оцифровка знаний через дубляж с помощью других коллег, наверное, самый идеальный способ работы при незаменимых сотрудниках.
Работа вслух
Этот метод направлен не столько на явные знания, сколько на «подводные». Например, как мы применили это в ситуации с Федей и стабилизацией релиза: «Федя, ты классно решаешь баги! Давай через полчаса соберём всю команду, и ты покажешь, как решишь новый». Главное, чтобы это не было заранее спланированное демо, в котором специально подобрали баг с минимумом проблем. При работе вслух можно вытащить много нового и интересного. Один раз мы получили скрипт, который позволял собирать и запускать сборку на устройстве за 30 секунд вместо 5 минут.
В базовом варианте этих двух способов мне хватает вытаскивать знания. Можно переходить к навыкам.
Навыки
Формула достаточно упрощённая, но для себя я её трактую именно в таком виде: навыки есть знания, умноженные на количество попыток применения этих знаний. Со знаниями мы разобрались — остаётся только увеличить количество попыток. Для этого идеально подходит стандартный метод — ротация по обязанностям.
Распределение навыков
1. Получение экспертизы на доработках
Самый простой способ обеспечить ротацию — разбить проект на этапы, и на каждом назначить новых людей на зону ответственности, которой занимались незаменимые сотрудники. Либо можно вообще передать доработку или сопровождение проекта другим сотрудникам, которые дополнят вам документацию и проработают архитектуру. Кстати, проработку техдолга проще всего отдать другим сотрудникам — они найдут новые баги и сделают всё по-другому.
2. Прототипирование
Если из команды приходят и говорят: «А почему вы начинаете просто так ротировать людей, которые делали что-то и, наверное, знают лучше», я практикую прототипирование. Незаменимый сотрудник делает что-то на коленке, что детально прорабатывается другой частью команды. Здесь есть одна проблема — вовремя остановить незаменимого сотрудника, чтобы прототип не стал MVP. Поможет немного микроменеджмента.
3. Ротация общих работ
Эта часть касается, как правило, тимлидов. Существует огромный пласт работ на плечах тимлида, к которому команда не имеет отношения. Что произойдёт в данном случае? Вы как руководитель станете незаменимым, а мы уже знаем, почему это не самый лучший вариант для вас. Подготовку демо, планирование, защиты и другую работу можно изредка поручать вашим сотрудникам. Это сработает не сразу и будет много проблем, придётся набраться терпения и раз за разом учить свою команду. Но поверьте, результат будет того стоить.
Культура расширенных обязанностей
Распределяйте задачи и ответственность практично. Например, вот как это может работать:
Упавшие автотесты
Если после упавших автотестов нужен разбор, а у вас вся команда говорит, что ждёт QA, то, вероятно, QA и станет потихонечку незаменимым. Но этим может заняться сотрудник, сделавший последнюю доброску или который сломал эти автотесты.
Проблемы с окружением
Кто занимается упавшей ночной сборкой? Почему бы это не сделать сотруднику, который первым пришёл на работу?
Уточнение требований продакта
Необязательно ждать аналитика, если это может сделать текущий сотрудник.
Задавая правильные вопросы на стендапах, прямыми указаниями и поощрениями инициативы можно создать культуру, когда каждый начинает отвечать за чуть большую область своих обязанностей. Так незаменимых сотрудников становится чуть меньше, можно отдохнуть.
Но есть нюанс, который касается перформеров. Например, моя жена читает раз в пять быстрее, чем я. Знаете ощущение, когда ты дочитываешь второй абзац, а она уже переворачивает страницу? Если мы хотим дочитать книжку и обсудить её, ей придётся ждать неделю. Но есть выход: «Дорогая, ты так прекрасно готовишь чай! Приготовь, пожалуйста, кружечку!». И у меня есть целых 5 минут для того, чтобы успеть дочитать страницу. Если этого недостаточно, тогда прошу борщ. В принципе, шансы уже совместимы. Этот способ я переношу на команды.
Вывод незаменимых сотрудников из операционной работы
Lite version
Работа вне операционной деятельности
Задача — немножечко отстранить перформеров от операционной деятельности. Дайте другой части команды догнать по знаниям, по навыкам самых лучших коллег. Нагрузите перформеров планированием, декомпозицией задач. Пусть, в конце концов, шляются по конференциям. Если вы придумаете красивое название для этой роли, например чемпион по конференциям или чемпион по планированию, они будут только счастливы.
Исследования
Если компания спрашивает, зачем, можете сказать, что у нас есть исследования. В современном C++ новый стандарт выходит каждые три года. Нужно понять, какие там на текущий момент баги и доказать, что нам на него действительно нужно переходить. Всё это может сделать ваш незаменимый перформер.
А если и этого мало, наймите стажёра.
Менторство
Знаете, сколько вопросов может задать один любопытный стажёр? Вы можете получить сильного миддла и немножко уставшего перформера.
Hardcore
Переходя к тяжёлой артиллерии:
Промоушен
Если у перформера есть потенциал для роста, вы можете собрать под него мини-команду. Если нет, необязательно промоутить в вертикаль. Например, недавно узнал, что одна из моих очень способных QA перешла в продакты. При таком решении вы оставляете экспертизу сотрудника внутри отдела, не увольняя его.
Перевод на другой проект / в другую команду
Человека не обязательно увольнять. Вы можете перевести его в другой отдел, оставив экспертизу хотя бы в рамках компании. Но это даёт шанс раскрыться всей остальной команде, поднять новые таланты. Возможно, ваш перформер является ограничивающим фактором для роста какого-то нового гения.
С чего начать изменения
Поговорить
Все новые методики учат тому, что нужно начать с разговоров с сотрудниками и объяснения наших целей.
Поставить цель
Вы не обязаны решать проблему сами. Вы можете её делегировать непосредственно вашему незаменимому сотруднику. Поставьте цель на следующие полгода, чтобы он передал свои знания, навыки и т. д.
План эвакуации
По-хорошему, каждый сотрудник должен иметь план B того, что будет происходить в отделе в случае его отсутствия. Единственная проблема с этим планом — надо периодически проводить пожарные учения, или он может устареть.
Итого, чек-лист:
оцифровываем знания;
настраиваем ротацию;
выводим перформеров из оперативки;
делегируем.
Что в итоге
В сложный период компании у меня из отдела ушло 40% сотрудников, но мы не сорвали ни одного релиза. Все проблемы решились внутренней ротацией. Любые задачи от руководства типа 100% покрытия автотестами или полного pipeline CI/CD решались мгновенно за счёт внутренней переброски ресурсов, потому что нанимать людей долго.
А ещё если вы решите сломать себе руку и полежать месяцок в больнице, производительность вашей команды не упадёт, качество останется прежним, и всё будет хорошо.
Скрытый текст
Ещё больше полезного для командных процессов можно будет узнать от моих коллег на следующей конференции Saint TeamLead — она пройдёт в Санкт-Петербурге в июне 2026 года. Присоединяйтесь, чтобы пообщаться не только в комментариях, но и на живом нетворкинге и мастер-классах.
Комментарии (70)
AriaQA
30.03.2026 09:28Иван, спасибо за статью. Но вы описали идеальную команду в идеальном мире, где все хотят знаний, читают инструкции и горят развитием. На практике же 80% людей приходят на работу потому что кушать надо. Им фиолетово на ваши ротации и дубляж знаний. Они хотят получить задачу, сделать, получить деньги, пойти домой. И да, они не читают инструкции. Никогда. Потому что проще спросить у того, кто знает. А те 20%, кому интересно, развиваются сами, копают глубже, становятся незаменимыми и потом читают статьи про то, как от них избавляться. Методы из статьи хороши ровно до первого контакта с реальностью, где у человека есть жизнь кроме работы. Проблема не в том, как передать знания. Проблема в том, как заставить их забрать.
MrZorg
30.03.2026 09:28В точку. И потом приходит оптимизация в лице эффективного менеджера и уравнивает 1 и 2 категорию. Команда же должна работать как единый организм одинаково на благо проекта. По другому же быть не может в этом идеальном мире. А те самые 20% постепенно становятся несогласными с политикой и смотрят на открытие вакансий на HH на их позиции.
GBR-613
30.03.2026 09:28А надо в качестве оценки деятельности сотрудника учитывать не только то, как он работает, но и то, как он не мешает работать другим.
А когда начальник видит, что ценному сотруднику мешают работать, для начала он должен это выкатить в качестве предьявы тому, кому мешают: "Федя, это они идиоты, или ты все плохо задокументировал?"
iwram
30.03.2026 09:28Конечно, все правильно. Все процессы должны быть структурированы и прозрачны и не должно быть уникальностей.
Вы ведь починили отсутствие квот при выходе целого дата центра? Та самая проблема когда ресурсы должны переехать (ну хотя бы в кубер узлы запустить) - это вопрос про документацию. Каким образом ваш клиент может удалить ресурсы из зоны, которая ему недоступна т.к. у вас авария?
К чему это я? К тому что в сложной системе хочется знать про все и понимать как это работает, но иногда определенная голова про это помнит лучше чем другие. Спасибо, что написали не обтекаемо, а точно. Теперь лично у меня не будет возникать вопросов к вашему облаку. Спасибо.
trublast
30.03.2026 09:28Ситуация, описанная вами, для клиента конечно выглядит неприятно.
Но если погрузиться чуть глубже, то можно найти объяснение. Например, если при аварии датацентр недоступен, то это не значит, что ресурсы там не запущены. Ваши вм-ки наверняка продолжают там работать, только управление ими не работает. Вам, как пользователю, это конечно не интересно (ну кроме случаев, когда у вас кластерные решения и вы вынуждены думать о потенциальном сплитбрейне). Но это вполне себе реальная причина, почему ресурсы в недоступном датацентре считаются в квотах. Пока не доказано, что они были выключены - они считаются включенными.
Представьте ситуацию, что произошел разрыв связи, и вы запустили +100 узлов в другом датацентре. А когда связь восстановилась, то оказалось, что у вас запущено 200 узлов. При квоте в 100. Вы выключили 50, но все равно не можете запустить 1 узел.
Так что в описанной вами ситуации хорошего решения возможно нет. Оба со своими нюансами.
iwram
30.03.2026 09:28И таких ньюансов будет еще больше. Я веду к тому, что прогноз подобных потенциальных проблем обычно ложится на плечи руководства и "незаменимых сотрудников", которые знают огрехи и проблемы архитектуры системы. В данном конкретном случае описываю большого клиента - это важно, а для более мелкого - это не так важно. Не настаиваю на правильности предложенного, но вы можете дать кнопку для буста квот в случае выхода из строя целого дата центра, но её никто не планировал и не будет давать. А ведь впереди будет еще не одно падение датацентра или целой зоны, необходимо готовиться к подобным сценариям в таком изменчивом мире.
Druzd
30.03.2026 09:28"«Роман, ты сделал такую классную тестовую систему! А напиши всё-таки документацию, как ей пользоваться, чтобы другие могли её запускать и не отвлекать тебя» " - тут автор оговорочку забыл приписать, зачастую такие просьбы не входят в рабочее время, как бы просят в не рабочее время написать мануал. В чем собственно проблема сделать СТО задачу с наивысшим приоритетом и мануал будет готов! Лукавишь автор!
В целом "рыба гниет с головы!". Какой СТО был в команде, такой и результат на выходе. Не надо, как говорится, перекладывать на незаменимых сотрудников.
PereslavlFoto
30.03.2026 09:28. В чем собственно проблема сделать СТО задачу с наивысшим приоритетом
Для этого надо отменить какие-то другие задачи, которые следует немедленно сделать уже второй месяц как.
mckeenly15
30.03.2026 09:28И поэтому автор просто попросил написать документацию. Видимо надеясь, что разработчик отодвинет в сторону текущие задачи и сядет писать документацию, или будет делать это в нерабочее время (о чем коммент выше). Или автор просто не знает, что любое действие разработчика на работе должно иметь основание в виде задачи.
Evgueni_Gavrilov
30.03.2026 09:28Можно ли написать документацию, прочитав которую джуниор начнёт локализовывать баги в незнакомом коде так же быстро, как Фёдор?
NatalyOld
30.03.2026 09:28Для этого надо создать agi :-) и назначить джунира ответственным сразу за всю систему... не, ну а вдруг :-) вон вайб кодинг как продвигается, скоро еще что нибудь будут рекламировать :-)
sharptop
30.03.2026 09:28Отчасти согласен с автором, что наличие незаменимого специалиста в команде несет риски для команды. Но хотелось бы описать ситуацию и с другой стороны, со стороны такого незаменимого специалиста.
Я на одном из этапов своей карьеры был тем самым незаменимым специалистом и вот какие отрицательные моменты для меня это несло:
1) В рабочее время ты в основном решаешь чьи-то проблемы, объясняешь, почему это не работает, или работает не так, поскольку кроме тебя это никто не знает - и почти совсем не решаешь свои рабочие вопросы или же решаешь их в послерабочее время
2) Почти нет свободного времени - в выходные и вечером тебе могут позвонить потому что что-то где-то упало и надо либо срочно выезжать либо чинить по удаленке. Я почти 3 года не мог сходить в отпуск нормально по этой причине - максимум на неделю и чтобы был всегда на связи.
3) Я был бы рад поделиться знаниями, но на тот момент либо никого не было, кому эти знания передать, либо не было времени, чтобы это все хорошо задокументировать - хорошо, что на память я в то время не жаловался.
В определенный момент меня это все достало и я пошел к руководству и сказал, что я не вывожу это в одного и мне нужен помощник. Помощник появился через какое-то время и я, введя его в общий курс дел и поделившись с ним теми самыми недоступными никому знаниями, отправил его в свободное плавание, делегировав ему часть своих задач. Первое время он обращался ко мне несколько раз в день, но со временем кол-во обращений снизилось до 1-2 в неделю. Ситуация через какое-то время повторилась со вторым сотрудником, у нас наконец-то появилась возможность это все задокументировать хоть как-то и еще через год после всего этого я смог наконец-то уехать в отпуск на 2 недели и никто не звонил мне во время отпуска. И когда я через несколько лет уволился, то я четко знал, что все что я знал - оно не осталось только у меня, есть люди, которые смогут справиться с теми задачами, которые решал я, когда был незаменимым.
wmlab
30.03.2026 09:28-- У нас проблема. У нас талантливый сотрудник (я ему, конечно, об этом на 1:1 не говорю, чтобы нос не задирал), который имеет больше effort points в спринте, чем все остальные, вместе взятые. Он всегда вызывается помочь и все самые сложные задачи, которые я ему поручал, он решал.
-- А в чем проблема-то?
-- Он демотивирует остальных. Я хочу от него избавиться.
-- Логично.
mahmud90
30.03.2026 09:28Да, потрясающая логика. Причём вопросов к членам команды, у которой "60 багов" за несколько дней до релиза (60, Карл), никаких не возникает. Видимо, команда привыкла выезжать на "незаменимых" и работает непонятно как. Или вопрос в данном случае к качеству найма.
Но избавиться хотят от того, кто тащит работу и решает проблемы.
PeeWeee
30.03.2026 09:28Не только увольнение: способы избавиться от незаменимых сотрудников
Увольнение не всегда является решением — более того, скорее всего, вам не одобрят предложение избавиться от самого лучшего сотрудника в отделе.
Прозвучало как сожаление о том, что такой метед “решения” редко прокатывает и не является единственным возможным. Без шуток осталось слегка гаденькое чувство после прочтения. Проблема рассматривается как игра с нулевой суммой между худшим случаем незаменимого специалиста (коллекционер тайных знаний - саботажник) и его калькой из мира управленцев (могу управлять чем угодно, ничего не понимая в прцессах - просто построю систему из одинаковых взимозаменяемых винтиков, выкинув или подрихтовав кувалдой все “выдающееся”). Оптимистично предположу что это вышло, пардон, по глупости (думаю на хабре технарей больше чем управленцев), а не
со злав силу склада мышления автора или ожидаемой ЦА в виде вышеназванного подвида управленцев.“Кабы я была царица” то, помимо разделения незаменимых сотрудников по категориям, прошелся бы по мотивации этих сотрудников и попытался спроектировать взаимовыгодное решение проблемы незаменимости. В том числе с осознанием того факта, что в большинстве случаев для незаменимого сотрудника это не является, или не осознается, проблемой. Типа такого (чуть упростив Вашу классификацию) .
Хайперформер. С большой вероятностью или не осознает свою незаменимость, или не считает это своей, а не управленца, проблемой. Грубо говоря, он искренне готов всегда поделиться опытом, но либо не может “залезть в шкуру” лоуперформера, чтобы обьянить так чтобы тот понял, либо ему это неинтересно. Предложить (в крайнем случае придумать) другую, не менее интересную, задачу “здесь никто кроме тебя не справится” с выделением в помощь при решении его текущей задачи “перенимателей опыта”. Вот тогда он будет заинтересован в выстраивании процесса передачи опыта по “старой” задаче. И да, “просто отправьте его на конференцию” врядли сработает - такие люди не так глупы, и не всегде настолько тшеславны или аутисты, как о них думает средний управлец на основании того, что в бюрократические игры они играют хуже него (они им просто неинтересны).
Добросовестный тащун - лучше сделаю сам, чем играть в бюрократический пинг-понг по делигированию и выстраиванию процессов. Тут еще проще - он и сам бы рад поделится знаниями, но не за счет “классно ты работаешь за себя и за раздолбая Петю, давай ты еще и будешь Пете квалификацию повышать == взвалишь на себя задачу раздолбая менеджера Феди”. И все это при сохренении прежней нагрузки и зп. Т.е. тут не сотрудник проблема, а хреновый менеджмент.
Саботажник. Ну вот тут примерно по мотивам Вашей менеджерской методички, только начав заход по лекалам добросовестного тащуна - “ты такой классный, давай мы тебя чуть разгрузим/повысим”, отслеживая насколько получается выстроить передачу опыта, т.к. может оказаться что это не саботаж, а неумение в общение или околоменеджерские задачи. Ну или чтобы не спугнуть, если таки худший случай.
MEGA_Nexus
30.03.2026 09:28Странно, что у статьи так много плюсов, хотя очевидно, что вся статья - это отрыжка ИИ.
Мы в коллективе приняли логичное решение «А давайте наконец сдвинем дату релиза!». Но тут меня остановила команда: «Стоять, завтра к нам подключится Федя».
Подскажи, как такое может быть, что "Мы в коллективе приняли решение, но при этом коллектив с тобой не согласен и всячески тебя останавливает"?
Этот "коллектив" он сейчас с нами? В этой комнате? Или он существует только в твоей фантазии?
Проблема заключалась в одном из проектов, который закрыли три года назад. Команда уже распалась, большая часть сотрудников уволилась. Но появился заказчик, который говорит, что на каком-то устройстве при определённых условиях возникает баг.
Каким образом у закрытого проекта имеются какие-либо заказчики? Проект ведь закрыт, а значит, он никому не нужен. Почему проект закрыли, можешь уточнить у руководителей отдела или департамента. Они владеют нужной информацией.
Если проект закрыт, а не находится на стадии технической поддержки, то никакие услуги по этому проекту оказываться не могут, т.к. нет бюджета и исполнителей.
Сделали сборку, запустили, баг починили, заказчик счастлив, команда счастлива. Несчастлив менеджер.
Какая команда? Это ведь закрытый проект, где "команда уже распалась, большая часть сотрудников уволилась".
Какой менеджер несчастлив? Менеджер, который уволился 3 года назад из закрытого проекта? Или менеджер - это ты? Если ты, то какое отношение ты имеешь к этому мёртвому проекту, где нет ни команды, ни менеджера? Если этот мёртвый проект отдали тебе, то именно ты должен возродить команду, правильно настроить процессы в нём и стать счастливым. Или ты ждёшь, что кто-то сделает тебя счастливым?
По-хорошему, каждый сотрудник должен иметь план B того, что будет происходить в отделе в случае его отсутствия.
bus factor - это проблема руководителя, а не сотрудника.
kirichenec
30.03.2026 09:28Шутка прям так и напрашивается, но это не пикабу)
(предлагаю на этом и остановиться)
JabbaHutt2
30.03.2026 09:28Блин, прям разобрало..
Это случайно не про девайс, который нужен бабушке, чтобы она была дедушкой?
kirichenec
30.03.2026 09:28Про бабушку с девайсом, да. Но данная статья никак не поможет)
Есть сотрудник, которому на пенсию пора, но не знаем, что с ним делать. Кроме того, части коллег он почему-то просто так нравится, а другой части он просто позволяет конфеты грести из вазочки сколько вздумается. Так и
живемработаем
Matshishkapeu
30.03.2026 09:28Попытка сделать всех одинаково некомпетентными в максимально широком спектре технологий - очень частый менеджерский паттерн, рационализируемый идеей, что можно будет таки сделать тот самый мифический человеко-час реальным. И тогда занимаясь любимой менеджерской штурмовщиной перед очередным рандомно запланированным дедлайном тестер Ирина при авральном релизе будет править CSS вместе с бэкэндером Сергеем. Интересно, кто-то пробовал донести до менагерков выгоды разделения труда и специализации. Понимают?
AcronyMoM
30.03.2026 09:28У нас нынче в тренде расчеловечивание?
За всеми правильными словами про bus factor и ротацию ни разу не мелькнула мысль о том, каково это быть Федей. Человек блин годами тащил на себе критические куски системы, спасал релизы, а в итоге оказывается не коллегой, а организационным риском, который надо «нейтрализовать». Финиш: аналогия с женой, которую отправляют варить борщ, чтобы не мешала. Ну и «в сложный период ушло 40% сотрудников, но мы не сорвали ни одного релиза» это успех? У вас блин 40% текучки, если только для красного словца вы не говорите, что это 2 из 5. Если 4 из 10, это нифига не норма, от вас тупо сбежали. Люди ушли, похрен, зато дедлайны соблюли.
andreygn
30.03.2026 09:28Например это информация повод задуматься "Феде". Можно даже прочитать если не читал ранее Законы Паркинсона (или перечитать).
В больших компаниях часто процессы важнее результата. Поэтому одинаковость важнее индивидуальности. Шестерни процессов должны вращаться согласовано. Если какае-то начнет вращаться сама- это нарушит весь процесс/либо нарушит при замене такой шестерни если все же выстроить.
Повод "Феде" подумать. Либо стать как все, по сути потеряв свою индивидуальность (по сути выкинуть часть своей личности). Либо найти место где индивидуальность ценится.
belav
30.03.2026 09:28Должен остаться один ("Горец")
Вечная борьба менеджеров с незаменимыми...
В любом проекте будет как минимум один незаменимый человек: автор идеи, продвинутый разработчик или менеджер. Из статьи понятно, что должен остаться последний.
ibmself
30.03.2026 09:28Всегда уходя оставлял доки и в файлах и в распечатках. По мере возможности дополнял железом и инструментом, хотя-бы на первое время.
Всегда (блин) железо приватизировалось, а по докам чаще или выбрасывалось или просто файлы стирались. Им оказывалось проще позвонить и спросить что, где и как, а то вообще "может по старой памяти всё сделаете сами".
Когда цель только деньги и личный интерес никакой ротацией проблем не решить. А попытка плодить одинаково некомпетентных специалистов, даст результат без результата, и спасать его сможет только тот с кем собираетесь бороться.
nmouse
30.03.2026 09:28Планов должно быть столько сколько нужно, и если вы перешагнули через буквы Ж, ну значит вы в Ж - нужно пересматривать процессы, иначе вся команда будет в Ж.
Добавлю в закладки из-за комментов, ну неплохой the worst practice
Покрутил в голове с точки зрения стратегии и опыта: крупных корпорациям не сильно нужны перформеры и рыцари на белом коне, условный мидл и синьер , которые приходит и с 10 до 19, с перерывами часовыми на обед и кикер, - вполне себе нормально делают свою работу, для буйных перформеров обычно в таких компаниях есть r&d или внутренний инкубатор, где среди таких же можно отрываться. Но про процессы всё равно не нужно забывать и про их эффективность, а так же работоспособность в реальной цейтнот ситуации.
JabbaHutt2
30.03.2026 09:28Indeed... Только R&D, развиваться можно только среди себе подобных.
Автор видимо с высшей школой знаком понаслышке а уж postgraduate и рядом не лежал (пардон за высокомерие) и фундаментальные различия между профессионализмом и педагогикой он просто не знает. Учат специальные люди а не Федя Клаву, это не секс...
nmouse
30.03.2026 09:28ndeed... Только R&D, развиваться можно только среди себе подобных.
Поделюсь собственными наблюдениями, если честно, то могу наврать, ниже собственные мысли, возможно, всё было значительно сложнее:
МТС, есть подразделение НБиТ (Новые Бизнесы и Технологии), самые известные продукты, которые выросли там: МТС-Деньги, МТС-Инвестиции, SmartMed. Знаю ещё несколько, но они под вайтлеблеми продаются, не знаю насколько корректно, с точки зрения NDA, о них говорить.
Альфа-Банк, было подразделение AlfaLab: AlfaSence - мобильный банк, который почему-то не пошел и вдруг превратился в Anna-Money, Поток - краудинговая инвестиционная компания, Alfa-Tips - чаевые по QR (которую Альфа изначально задвинула, а потом через несколько лет выкупала у владельцев)
Тинькофф Банк, по сути, все годы был таким стартапом, пока, не переименовался в Т-Банк.
У Вымпелкома (Билайн) было подразделение, например, eCommers, которое потом почти полностью выделилось в RURU. Но там всё сложно было, так как Вымпелком надорвался скупая местных телеком провадейрдеров, типа Корбины, пришел кризис 2008-2010 годов и нужно что-то не с профильными активностями делать.
UserNoUser
30.03.2026 09:28В статье показан пример, как дефективный манагер разваливает фирму/проект и наивно полагает,что виноваты незаменимые. При этом с самого начала на примере сроков задачи конкретно этот дефективный НЕ провел анализ рисков, реальных (!) сроков, анализ компетенций и загруженности сотрудников.
Далее, на примере Руси незаменимый документирует для Джуна: миддл или сеньор работает со своим уровнем знаний и опыта. При этом дефективный манагер Обязан организовать обучение для тех, кто по его мнению отстаёт в компетенцию и развитии. И это требует денег, времени и как ни странно работы с персоналом.
Но,к сожалению полно дефективных , которые видят только показатели, не отражающие весь производственный цикл со всеми трудоемкости и проблемами. Как итог малоэффективной производство , постоянная ротация персонала. А с учётом требований нового поколения - отсутствие нужных кадров.
Адиос
mmMike
30.03.2026 09:28В IT — 20 c копейками лет. Потрудился в восьми компаниях, в пяти из них управлял отделами.
Не обязательно относится к автору статьи, но почему то навеяло.
Типаж - кочующий менеджер. Знаю. сталкивался. Зачастую даже дают очень хорошую характеристику лишь бы ушел поскорее (увольнение по своему желанию) куда ни будь в другое место. Сем видел несколько таких примеров (впрочем и с программерами то же).
При этом частое смена работы по причине (по словам) “стало не интересно там. не те масштабы”. Но по факту, обычно пол года дают на вхождение в тему, год на “ну может быть получше будет. отчеты же хорошие”. А потом просто сваливает в другое место.
Основное чем оперирует - трудоднями и красивыми отчетами для начальства.
До сих пор помню как “преподаватель” на курсах PME рассказывал, что настоящему менеджеру проектов все равно чем управлять “хоть созданием космического кОробля, хоть стройкой дома” (сейчас не можно, но как то занесло и получил сертификат)
goBrat
30.03.2026 09:28Чушь какая. Очередно особо эффективный управленец. Недоволен что в команде есть амбициозные и умные люди способные решать проблему на изи, а не слоняться в слезах по коридорам. И вопрос бы не плохо самому себе было задать, почему я не подтягиваю и не развиваю других коллег, а вместе с ними закидываем всё вокруг болтами.
FullstackHamster
30.03.2026 09:28А по факту 5 раз избавлялись от автора. Оно и понятно - фраза "давайте сольём ценный актив" - это уже повод проверить вышестоящему руководству, а "я вам потом расскажу зачем" - ну, в принципе, можно и не проверять.
В принципе статья без панчей про избавиться, уволить, отрицательный отбор при повышении, неплохая. Проблема есть, автор подробно её рассмотрел. Но с формулировками нужно работать. Не "избавиться от сотрудника", а "как грамотно и безопасно устранить бас-фактор и боттлнэк" и т.д.
Спасибо
Xanderith
30.03.2026 09:28>к теории ограничений Голдратта
Творчество Голдратта - это шарлатанство типа ТРИЗ или саентологии. Даже странно, что в 2026 году его продолжают упоминать.
Akon32
30.03.2026 09:28Творчество Голдратта - это шарлатанство
Не сказал бы. Его идеи об оптимизации процессов весьма очевидны, по крайней мере в настоящее время, и даже при оптимизации компьютерных программ применяются схожие идеи, но под другими именами (например, закон Амдала).
d3d12
30.03.2026 09:28С каких пор ТРИЗ стало шарлатанством? )
konst90
30.03.2026 09:28С тех пор, как появился.
ТРИЗ позволяет "решить" и описать методами ТРИЗа только ту задачу, ответ которой известен заранее. А вот если решения у вас нет, то ТРИЗ может только предложить вам штук двадцать направлений, в которых это решение можно искать, причем направления сформулированы максимально абстрактно и противоречат друг другу.
Bobar35
30.03.2026 09:28Статья из разряда. Много букв в свое оправдание. На самом деле автора статьи до управления командами вообще допускать нельзя. Вот того незаменимого для примера , обучения и вдохновения команды нужно поставить. А автора в гаражи на сборку мебели механическим путем определить. Такие статьи к развалу отраслей и команд приведут.
Gradiens
30.03.2026 09:28Погодите-погодите! А решение точно бьется с проблемой?
Возьмем ваш пример с Федей. Вот видно, что до дедлайна не успеть.
Как было: подключали Федю и успевали.
Как стало: Не подключаем Федю а.... что? Ротируем Федю? Заставляем Федю писать вики? Заставляем Федю передать знания Маши?
Что заставляет думать, что при таком подходе мы не сорвем этот (и последующие) дедлайны?
Tim_86
30.03.2026 09:28Похоже, в том случае это не имело особого значения. Автор пишет, что они могли перенести релиз на 3 (!) месяца. То есть им вообще было все равно - сорвут дедлайн, не сорвут. Команде, у которой 60 багов в проекте за несколько дней до релиза, и которая починив 15 багов создает 10 новых, а 4 переоткрывают. Руководству, которое набрало и держит такую команду.
Главная задача, видимо, была просто создавать видимость какой-то деятельности. Федя этому немного мешал - он был нацелен на результат.
Akon32
30.03.2026 09:28Что заставляет думать, что при таком подходе мы не сорвем этот (и последующие) дедлайны?
Смысл не в несрыве дедлайнов, а в хорошей отчётности руководству. В отчёте может быть что-то вроде "построили стабильные процессы, уволили токсичного сотрудника, сделали шаги в сторону масштабирования разработки, работаем над эффективностью, нанятая команда джунов быстро разберётся в предметной области не хуже этих старых, которые работать не умели". А после хороших отчётов можно и деньги просить.
Gradiens
30.03.2026 09:28Смысл не в несрыве дедлайнов, а в хорошей отчётности руководству.
Соглашусь, во время роста пузыря так было во многих местах
Сейчас, кажется, тренд сменился. Собственники приходят к топам со словами "Где деньги, Зин?" Топы дальше каскадируют вопрос. Их не устраивают отчеты. Отчет на хлеб не намажешь. И они отрезвляют средний менеджмент: "Процессы? Стратегии? Эффективность? Хватит! Покажите эффект в деньгах!"
И вот тут, когда денег не заработали (ну потому что дедлайны профуканы) - начинается самое интересное. Средний менеджмент начинает бегать как ужаленный. Ибо выживут не только лишь все. Кто-то перестраивается, перестает маяться фигней и показывает быстрые результаты. Кто-то заигрывается и ... ищет потом новую работу.
Что делать в этом случае Феде? Наверное удостовериться, что его менеджер не потянет его на дно.
Делать только важное, мгновенно дающее результат. Обучение кого-то, документирование - извини, нет. Да, это противоречит идее статьи. Но сейчас не время для ротаций, вылизывания документации, настройки процессов.
Если менеджер Феди имеет чувство самосохранения, он сократит не особо эффективных, сократит скоуп работ (делаем только важное), удержит Федю (желательно дать медалек и других штучек-неберучек). Отрапортует о сокращениях затрат и почти той же производительности наверх. Не то чтобы я поддерживал тако подход. К счастью я - не менеджер. Просто так устроена жизнь.
Arhammon
Прям с ходу могу сказать - это 95% будет статья написанная левой пяткой, а Маша через 2 недели без практики забудет, что она писала... Управленческий ритуал выполнен, а ничего не поменялось...
Видимо должно работать только со штрафом в пол зарплаты за минутное опоздание...
И еще вероятно попадете на карандаш... а уж что из этого выйдет будет зависеть от адекватности вышестоящего руководства, может на повышение, а может на мороз...
sirmax123
Писать по-настоящему хорошую документацию, а не "на отвали" очень сложно (как минимум очень сложно для меня)
Когда ты "в теме" то для тебя многие вещи очевидны, и ты об этом самым естественным образом в документации не упоминаешь
Когда потом это читают - хватаются за голову, WTF, почему тут --foo=3 а --bar=4 ???
Для того что бы получить хорошую инструкцию - требуется что бы ее прочитал человек который совершенно не в теме, задал все вопросы (ответы на которые добавить в документацию). В идеале повторить итерацию несколько раз, чем ниже квалификация "читателя" и чем дальше он от темы документа, тем лучше
Только кто ж на это время даст? И кому интересно это делать? Так что как обычно )
NightKiro
Не согласен, в работе практикую подобную штуку, всегда когда что-то надо объяснить коллеге из раздела специальных знаний, прошу по итогу записать инструкцию для будущего
Так как инструкция пишется по какому-то кейсу(например настройка окружения для очень специфичного режима работы отдельной точки), человеком который ничего не знал, то текст содержит как минимум информацию достаточную по запуску
Если пару раз попередавать друг другу эту инструкцию, с каждой итерацией просить задать вопросы по ней, если есть, и тут же дополнять, то получается рабочий документ для решения рабочих задач
Очень ценю эту практику, ибо именно благодаря ей когда мне по прошлой работе спустя 3 года что-то спросили, я смог просто открыть документ, ответить на вопрос и все довольны, я оплатой консультацией, они решенной задачей которую не смогли решить новой командой(эта документация была у команды в корпоративной вики, но почему-то никто туда не посмотрел)
Ну и в работе она опять же помогает, потому что онбординги провожу по такому же принципу, есть человек, есть вопросы, записываем и вопросы и ответы, в какую-то итерацию все стартовые вопросы будут закрыты докой
Arhammon
Так никтож не против документации. Просто это требует развитой культуры "производства" иначе в бардачной системе, раз подойдут спросят-напишут, два подойдут и всё. Я так же примерно пытался поступать с документацией и меня самого это так же выручало, но на практике это точечные инструкции, про которые моментально все кроме тебя забудут как только ты ослабишь хватку в жалких попытках борьбы с бардаком.