Комментарии 79
Есть еще одна причина о которой вы забыли упомянуть. Себестоимость конечного продукта сделанного таким одиночкой в разы меньше чем при коммандной работе. При этом доход такого одиночки в несколько раз выше среднего по рынку.
Я сам такой одиночка. Я могу сделать за месяц продукт который в компании будет делать группа из нескольких человек полгода.
Часто работодатель не понимает что сделав разработку коммандной он увеличит рассходы в разы ( по моей оценке в среднем раз в десять) и для него это становится неприятной неожиданностью, что приводит к конфликтам с работодателем.
Насколько я могу судить, статья не про расходы при оптимальном раскладе - статья про риски.
Спасибо за комментарий — вы абсолютно правы, это хорошее дополнение.
Да, одиночка в хорошей форме действительно может сделать MVP или даже полноценный продукт на порядок быстрее и дешевле команды. И именно поэтому такие люди ценны, особенно в старте, R&D, на сложных участках. Но тут как с костылями в проде: помогает быстро в моменте, а потом может аукнуться.
Вы правильно подметили — работодатели не всегда осознают, что командная разработка не масштабирует результат линейно, а расходы — да, масштабирует. И если в голове был план «сейчас разовьём успех и передадим в команду» — начинаются проблемы: коммуникации, бриджинг знаний, падение скорости, рост расходов, нестыковки по качеству и ожиданиям.
Получается дилемма: или быстро и дёшево, но нестабильно; или стабильно и масштабируемо, но дороже и дольше.
Так что, согласен — эта часть стоит более явно обозначить в статье. Я подумаю, как аккуратно дописать про «причины» и «ожидания бизнеса».
т.е. у вас в компании армия неэкспертов?
Так было. Потому что, кто-то когда-то наверху решил сэкономить и обойтись минимумом сильных инженеров. Но когда мы показали сколько стоит выкатить фичу, сколько времени уходит на поддержку и как страдают сроки и качество, картина быстро поменялась.
Сейчас у нас вполне адекватный баланс по уровням – сеньоры, мидлы, джуны. Более того, мы выбили learning-бюджет с тремя нулями для всех разработчиков (курсы, митапы, конференции, ...) и немножко геймифицировали обучение – за активность выдаём фирменный мерч, билеты на матчи и прочую атрибутику. Работает удивительно хорошо. Если тема интересная и не все могут посетить мероприятие, то иногда организовываем что-то типа "Conf:recap", чтобы и остальные были в теме.
Бывает путь через грабли, но если есть цифры и аргументы, то наверху обычно слышат.
Если все правильно организованно, группа всегда будет эффективнее любого одиночки
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут.
Организация решает не везде, но то что она дает мультипликативный эффект - да.
В it это не так. Одиночка всегда эффективней группы. Другое дело что с правильной организацией только в двое, а с не правильной в сто раз.
Обычно что один программист пишет за месяц то десять программистов сделают за десять месяцев)))))
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Что значит "не делится знаниями"?
Смотрю в код, а там одна магия.
Тут уже другая проблема - человек пишет неподдерживаемый код (магия без комментариев и документации).
Документация не заменяет живое общение. Когда знания живут только в коде и в вики, но не в головах команды, то скорость адаптации, дебага и развития падает. А "объяснять" — это не про семинар, это про часть командной ответственности senior-уровня. Не каждый день, не на каждую строчку, но регулярно и по делу.
регулярно и по делу, это в сторону L3? То есть отдельная вакансия, которую надо бы доверить отельному человеку? И платить ему как полагается? А если кто то в обязательной манере, что-то кому то объяснять, то и не плохо было бы соответсвенно платить, если это небыло в контракте прописано.
А то по итогу проект сделай(это одни деньги), проект поддерживай(это другие деньги), а потом еще объяни как все работает "Не каждый день, не на каждую строчку, но регулярно и по делу."(это третьи деньги).
В идеале — да, если компания требует постоянного менторства, обучения и поддержки коллег, это должно быть отдельно зафиксировано и оплачено. Но тут есть нюанс: если разработчик претендует на senior-уровень, то способность объяснять решения и помогать команде — это не отдельная "услуга", а часть роли. Это не значит «читать лекции», но да — быть доступным, объяснять ключевые решения, помогать ориентироваться. Это про устойчивость команды, а не бесплатную нагрузку сверху.
Во многих европейских компаниях это вообще норма: сеньор без менторства там долго бы не продержался. Просто потому, что от него ждут не только кода, но и влияния на культуру, процессы и рост других. Это не бесплатно — это вшито в компенсацию и ожидания.
Вполне себе заменяет.
Согласен, если документация написана живым языком, покрывает реальные кейсы и кто-то её действительно читает, тогда да, может заменить. Но на практике чаще видим вики две тыщи лохматого года с "TODO: дописать", а потом всё равно идём спрашивать того самого человека. Так что документирование — однозначно нужный инструмент, но не волшебная панацея.
А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа
Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В то же время, ещё материалистическая диалектика учила нас закону о переходе количественных изменений в качественные.
Если бы его не было (а он выведен эмпирически, то есть, на основании реальных наблюдений и следующих из них логических умозаключений), то да, синьор бы отличался от миддла и джуна исключительно тем, что пишет в единицу времени больше кода, имеющего меньшее число ошибок на тысячу строк, и больше ничем.
Но так как он всё же есть, то каждая ступенька роста подразумевает изменение не только количественные, но и качественные. Джун действует по инструкции, описывающей метод решения поставленной перед джуном проблемы. Миддл умеет самостоятельно идентифицировать известные проблемы и находить инструкции по их решению. Синьор умеет определять наличие неизвестных проблем и не только решать их, но и переводить эти проблемы в категорию известных.
Собственно, последнее и есть «передача опыта». Технически она может осуществляться разными способами (и документацией, и семинарами, и личным общением).
(и если что, синьорам и платят больше, чем миддлам, в том числе и за это, а не за тысячи символов кода в час)
Да, есть ошибка во многих компаниях, когда до синьора повышают за просиживание задницы выслугу лет, а не за умение решать задачу передачи опыта. Точно так же — и об этом много сказано, и свежее например сказано тут, и добавить мне к этому нечего — потом повышают до тимлида, у которого качественная разница с синьором совсем радикальная.
Это проблема компании: в ней не собрана корректно работающая система построения иерархической лестницы.
Но. Если такая система в компании выстроена, вышеуказанное качественное различие между ролями руководство понимает, а вот конкретный сотрудник считает, что это не его дело, его дело исключительно кнопки давить — то именно как описано автором статьи, такой сотрудник является угрозой для проекта (и компании в целом) на роли синьора, если он почему-то на неё попал, или, в более корректном варианте, очень-очень хорошим миддлом, которого никогда не повысят (а он не поймёт почему, обиженный уйдёт туда, где его возьмут в синьоры — и в силу вышесказанного для компании, из которой он уволился, это будет не провалом «не смогли удержать!», а неизбежной потерей).
Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Ваш подход близок к инженерному идеалу. Но на практике он работает только в очень зрелых и дисциплинированных командах. В реальности люди не всегда читают, не всегда понимают сразу, и живое общение сильно ускоряет передачу контекста. Особенно если речь про принятие архитектурных решений, а не просто «как это работает».
Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит
Как я уже сказал выше — жаль, что вы до этого тезиса не дочитали, а поторопились писать ответ — если в компании не выстроена система построения иерархической лестницы, в результате чего синьор отличается от миддла только частотой давления на кнопки и процентом совершаемых при этом ошибок, то это, несомненно, проблема компании. У такой компании будут серьёзные трудности в развитии.
Впрочем, в некоторых областях это вполне прокатывает — например, в типовой контрактной разработке, где действительно вполне эффективно иметь штат программистов, в обязанности которых входить только давить кнопки с разной скоростью. Трудности у таких компаний возникают только при смене ориентации деятельности — например, изнутри однажды наблюдал героические попытки перейти с рельс контрактов на выпуск своего продукта, закончившиеся полным ничем.
Синьор умеет определять наличие неизвестных проблем и не только решать их, но и переводить эти проблемы в категорию известных.
Хм... А я думал это всë про мидлов, а сеньор это что-то ещë более высокоуровневое. Может я сеньор давно, просто не знаю об этом? Надо наверное перечитать про эти градации и на себя примерить.
Вполне возможно, что этот "аккумулятор риска" был отравлен отношением на предыдущем месте работы. Я видел однажды, как людей попросили подробно задокументировать все знания по проекту, а потом выставили их вон и наняли дешёвую замену.
Как думаете, стремились ли они делиться знаниями с коллегами на новой работе?
Кстати, про риски замены опытных специалистов на дешёвых я писал отдельно. Можете почитать, если интересно: https://medium.com/@dobeerman/the-hidden-costs-of-hiring-low-cost-developers-ac7f79027961
Это достаточно частая история, одиночка делает хороший продукт, расписывает и рассказывает мельчайшие детали, потом его просят на выход, заменяя джунами. Или мне так везло с работодателями)
Плюсы на сегодня закончились. Но именно написанное вами и приходит в голову первым, при чтение статьи, которая основана на популизме и "эффективном менеджменте".
А люди бы хотели написать программу один раз, а потом ничего не делать и получить за нее зарплату десять лет. К большому моему сожалению, так не работает. Почему-то так работает только с музыкой.
Как минимум, люди хотели бы остаться на прежнем месте работы. Наверное хотели бы развивать продукт, в который вложили столько сил. А людей натурально кинули.
Я не Ванга, но прям вижу, что этим же людям рассказывали про "мы одна семья", и что "сейчас надо потерпеть, зато потом заживем по-королевски" когда оправдывали бесплатные овертаймы и отстающую от инфляции ЗП.
Люди хотели бы один раз на старте пожертвовать время чтобы разобраться с проектом, а потом каждый день небольшими усилиями вносить улучшения, потому что у людей может быть ещё и личная жизнь, которая требует внимания. А что делает с людьми предлагаемый в статье подход? Каждый день как в самом начале трать много времени чтобы разбираться с тем что наделали другие до тебя и ещё объясняй другим, что ты сам наделал, потому что менеджер боится потери бойца, а продуктивность у тебя должна быть такая как если бы ты не тратил на все это время, короче будь ноулайфером, живи и дыши работой пока тебя не выдоят досуха и не выбросят как отработанный материал.
Один раз сделать и годами вносить мелкие улучшения? Лично я убился б лучше на старте программистской карьеры (это было 30 лет назад). Скука то какая.
Ну это нормально, что хочется порезвиться. Каждый программист сам по себе источник хаоса и задача менеджера как раз таки контролировать этот хаос, а не потворствовать ему, ограничить его рамками модуля чтобы этот хаос не распространился на весь проект. Да вот в рамках своего участка делай что хочешь лишь бы работало, но на другие не лезь. Например, один программист пилит бэкенд и что-то ему как-то скучно стало и он начинает доставать менеджера чтобы тот дал ему другую задачу развеяться, а тот и возьми и дай ему фронтенд задачу. Кросс-скиллинг и все такое. Бэкендщик приходит в модуль фроненда и начинает там резвиться, а потом наломав там дров возвращается обратно к себе в бэкенд. В итоге код проекта уродуется нашествием таких гастролеров. Ревью кода от этого не защищает потому что, когда время уже потрачено на задачу и она уже хоть как-то реализована, то никто ничего переделывать не будет.
Это ПО для POS-терминалов. У его разработки, как у революции, "есть начало, но нет конца". Оно постоянно развивается, но среди управленцев это могут понять не все.
Кстати, в том проекте это быстро поняли. :-) Я часто злорадствую, когда менеджеры получают ума через задние ворота.
Документация как часть Definition of Done
This. Документация на систему - часть системы.
Но, как и бэкапы и автотесты, техническая документация не приносит прямой прибыли, только затраты. Поэтому, бизнес этим заниматься не хочет. Вопрос не технический, вопрос - организационный.
Ну, и хрен с ним, с этим бизнесом, пусть горит. А руковод - сам виноват.
Согласен — документация, как и бэкапы, юнит-тесты, CI и мониторинг, не приносят прибыли напрямую. Зато очень хорошо показывают свою ценность в момент, когда всё начинает "идти по ...", вобщем, падать.
Это не про «лишние расходы», а про управление рисками. Как и страховка: дорого, скучно, но без неё больно.
Так что да — вопрос действительно организационный. Но игнорировать его техническим командам тоже себе дороже.
Я, как технарь, всегда и везде топлю за документацию.
Ибо, бывал в как ситуациях, когда приходится разбираться с "черным ящиком". Так и в ситуациях, когда уходишь, и оставляешь коллегам "черный ящик", и как-то неловко, совестливо, и вообще, цеховая солидарность свербит.
Но проблема документации в том, что она сама себя не напишет. Надо отдельно время выделять и отложить часть оперативных задач, которые никогда не заканчиваются. Руководители на это обычно не идут.
Так что, я б не сказал, что это технические команды игнорируют. Ну, во всяком случае, у нас на заводах-пароходах - так.
Еще бывает так, что знания передавать просто некому. Каждый сфокусирован на своем узком круге задач и любые "знания" извне своего непосредственного процесса воспринимает как досадный и ненужный шум. Команда, тупо, может не иметь достаточных компетенций / мотивации для того, чтобы принимать ваши знания и документацию вашу никто особо не читает. Всем некогда. Работает - и хорошо.
Я сам часто был в такой ситуации, когда очень хочешь делится знаниями, но всем просто пофигу. Это очень демотивирует. Именно по этой причине, однажды, я ушел со своей прошлой работы и собрал собственную R&D команду.
ЗЫ. Статья, по сути, выставляет самого компетентного игрока в команде - как слабое звено. Вам не кажется, что с этим мнением, мягко говоря, что-то не так?
Не компетентность делает кого-то слабым звеном, а изоляция. Один эксперт, замыкающий знания на себе — это как сервер без бэкапа: пока работает, все довольны, но риск растёт каждый день. Статья не про «наказать лучших», а про то, как сделать команду устойчивее.
Поймите, разработчики - это люди. Они очень разные. Часто выдающиеся технические скилы соседствуют с трудностями в социализации. Грамотный руководитель отличит "молоток" от "микроскопа" и каждого использует на своем месте. А вот передать свойства "микроскопа" "молоткам" - это очень сомнительная идея. Я бы сказал, заведомо провальная. Таким образом, основным фактором риска, в этой ситуации, является РУКОВОДИТЕЛЬ и именно его компетенции.
«А как назвать разработчика, который технически силён, кодит быстро, но при этом не делится знаниями и работает строго в одиночку?»
У вас есть человек который глубоко разбирается в части ваших бизнес-процессов. На него не надо тратить ресурсы для обучения и введения в работу. Ему нравится его деятельность. Учитывая современную обстановку с кадрами - этого спеца надо не просто удержать, а сделать совладельцем бизнеса. Выделить небольшой бюджет и сделать его руководителем нового отдела. Пусть сам уже внутри своего отдела нанимает помощников и делегирует свои задачи. А так же в качестве стимула добавить к его зарплате небольшой процент от дохода. У спеца будет интерес вкладываться в работу бизнеса.
Но советы из поста в стиле больше недоверия к человеку и больше гнобления чтоб знал холоп свое место. После такого любой спец убежит, а нового выращивать долго и с кучей расходов и простоев бизнеса.
Ваша позиция вполне понятна, но, боюсь, вы немного не о том. В статье не предлагается «гнобить спеца» или отбирать у него автономию. Речь о системном риске, когда знания замыкаются на одном человеке.
Если специалист крут, то это не повод строить вокруг него культ. Это повод создать условия, при которых его знания масштабируются, а не становятся узким горлышком. Делегирование, развитие отдела, участие в прибыли — отличные идеи, если он сам к этому готов. А вот игнорировать риск — это управленческая халатность, а не уважение к профессионалу.
В нормальных компаниях как раз и есть learning budget, потому что развитие сотрудника = развитие бизнеса. Но даже без этого знаниевый монополизм остаётся риском. Здесь не про «выжимать», а про устойчивость процессов и здравое управление.
На этот счет у меня есть любимая фраза:
– А что, если мы обучим наших сотрудников, а они уйдут от нас?
– А что будет, если мы их не обучим, а они останутся?
Почему так происходит
Причин на самом деле много:
Причина в большинстве своем одна - эффективный менеджмент. Задайтесь для начала вопросом - как так вообще случилось что у вас один человек только во всем разбирается?
Вопрос то не сложный. Вы много пишете про сеньоров а на деле часто такие люди средней руки мидлы и даже бывает вообще джуны. Да, даже такое видел.
Возвращаясь к вопросу как так вообще выходит. Вот есть команда разработки, в ней есть пару опытных разработчиков и несколько среднячком и даже слабых. Найдется такой инициативный человек который начнем компенсировать свои технические скилы тем что будет усердно разбирается в бизнесе и проекте и как пирожки шлепать гавнокодом задачи, чем приводить в неистовый восторг всех менеджеров. Часто у менеджеров кроме сиюминутных проблем голова ничем не забита и такой человек будет все больше и больше нравится чем скучные опытный разрабы которые будет предлагать очевидно бесполезные с точки зрения менеджера вещи как рефакторинг, проектирование и что что самое страшное будут предлагать думать головой. Угадаем на чью сторону встанет менеджмент и кого будет поддерживать. Через какое то время может этого инициативного вообще тимлидом сделают (и такое я видел) а опытные разработчики уйдут с проекта так как надоест работать с дурдоме. Как итог произойдет замещение с опытной команды на лояльную.
Как итог сидит такой незаменимый специалист которого все любят и делает все чтобы он продолжал оставаться незаменимым. А кто его вырастил?
Переопределить понятие senior. Это не только про код, но и про поддержку команды, менторство, документацию.
Нечего там переопределять. Это просто красивое слово которое в лучшем случае обозначает привязку к зарплатной сетке конкретной компании.
Наверно вся успешная музыка написана в командной работе. Нет универсального подхода. В свете развития ИИ думаю соло разработчиков будет становиться больше. И в какой-то момент выйдет статья где будет написано что командная разработка это накопитель рисков.
Фактор грузовика/автобуса. Bus factor - Wikipedia
С начала века реально видел как он срабатывал 3 раза у коллег в 3х разных странах.
При этом в первом случае израильская команда должна была начать передавать знания через 2 недели, а начала потихоньку через полгода, после выздоровления.
И это ещё самый оптимистичный итог из 3 случаев.
Поэтому держать его хотя бы 2-кой и делать документацию и обучение чему-то сразу - это удобно на самом деле.
Сейчас это модно называть словом bus-фактор, вроде. Его многие недооценивают, потому что это выглядит дешево сначала – один человек работает за целую команду. Но со временем даже небольшое изменение нагрузки/требований начинает стоить очень дорого:
Переработку может сделать в адекватные сроки только один человек;
Этот один человек может быть уже занят другими изменениями, которые тоже может быстро сделать он один;
Этот один человек может заболеть или уволиться.
По моему опыту эффективно показать человеку, что он может перейти к более интересным задачам, если передаст коллегам свои старые наработки.
Ох, сколько раз я видел, как менеджмент целенаправленно создаёт такую ситуацию! Это же так удобно, завести швеца, жнеца и на дуде игреца, который будет всё тащить за одну зарплату. А ещё менеджмент не понимает или просто не хочет понимать, что на передачу знаний нужно время, причём тем большее, чем больше разрыв в квалификации между носителем этих знаний и обучающимися. Если остальная часть команды - это джуны после курсиков, то они уйдут к другому работодателю раньше, чем успеют перенять хотя бы десятую часть знаний "накопителя риска". Плюс нагрузку-то с сеньора тоже никто не снимает, 40 часов в неделю надо пилить фичи, а раз зарплата у сеньора большая, то пусть напилит за эти 40 часов 60-часовую норму, желательно пока на созвонах сидит.
В опроснике "А у вас в команде были или есть «накопители риска»?" пропущен важный вариант ответа: "да, это я". Количество ответивших покажет сколько ещё единорогов осталось.
P. S. И да, это я. :(
С ростом проекта и его ответственность, большинство руководителей задумываются про бекапов, масштабирование и отказоустойчивости инфраструктуры продукта, но не о тех кто строит продукт, т.е. об увеличение количество сеньоров мало кто задумывается (да это дорогое удовольствие, как и 3 мастер ноды k8s, зато отказоустойчивее)
Да, про людей не думают. Вся статья по сути про то, что бы такое придумать чтобы защититься от потери разработчика и все предлагаемые решения лишают разработчика возможности комфортно работать. Если менеджмент выстраивает систему с защитой от ухода людей, то в такой системе люди будут уходить потому что это заложено в работу системы. А надо наоборот выстраивать систему в которой людям захочется остаться. Что сделать чтобы разработчику было комфортно? Может все таки стоит ему дать возможность работать над чем-то одним, а не гонять по системе как вшивого по бане. В IT много управленцев, которые ими стали за то, что хорошо делали техническую работу, но они не понимают базовых принципов организации труда: разделение труда, рабочая нагрузка и пр.
Но это все-таки не входит в обязанности разработчика... Делать качественное review - да, подсказывать что-то - да, а вот нацеленно кого-то обучать - нет. Команда должно приходить сверху ~используй 20% времени на обучение нового сотрудника.
Вот мой глупый вопрос.
Что мешает бизнесу, создать единый подход к решению задачи?
Тот кто лучше разбирается в этом подходе, тот и топ-разработчик.
Тогда даже этот фактор риска будет учтен в зачаточном состоянии задачи.
Ну так, а если он документацию и тесты обновляет своевременно, то разве будет это "точкой отказа"?
А где в этой схеме тимлид, архитектор, продакт и техпис? Ах дам там ещё срам-мастер, менеджер проекта и ещё кто-нибудь нынче присосался. Если ваш сеньор знает что делает, то пусть те кто не знают пишут документацию и параллельно изучают код. Есть простая калькуляция: берём себес сотрудника для компании, высчитываем стоимость его часа, затем считаем сколько в час он заработает для компании, потом тоже проделываем с командой. Увольняем всех причастных к не эффективным активам - Профит. На вырученные деньги берём необходимые навыки и людей.
Сначала на Хабре рассказывают как за 3 года стать сеньором не работая, потом вайб кодинг, потом называют профессионалов - риском. Что дальше? Тренды в ИТ, на каком языке модно будет писать в 2026 году? Подойдёт ли этот промт к моим розовым кедам?
Интересная арифметика, но есть нюанс :)
Если сеньор – единственный, кто знает, как всё работает, то остальная пирамида не «присосалась», а пытается как-то удержать знания внутри компании, чтобы бизнес не зависел от одного мозга.
Да, документацию может писать кто угодно. Но если код понимает только автор – это уже не код, а квест без подсказок. И увольнять всех, кто не "зарабатывает в час", – стратегия классная до первого отпуска или больничного этого самого сеньора.
А по поводу розовых кед – да, тренды бывают странные, но надёжность и командная передача знаний пока что вне моды не выходят.
Код это всего-навсего набор символов, разобраться в нем вопрос времени. Моим командам и мне довелось не однократно разбираться в чужом Легаси.
А вот убрать тех кто допустил зависимость бизнеса от одного наёмного человека - лучшее решение для владельцев. Знаю я несколько топовых компаний в разработке ПО, которые на стадии MVP закрывают продукты, потому что технология завязана на одном человеке. И этой практике не первый десяток лет
Да, разобраться можно — вопрос времени и бюджета. Вот только бизнесу обычно нужно «вчера», а не через 2 месяца после увольнения ключевого разработчика.
Вы абсолютно правы: допускать завязку на одного человека — управленческая ошибка. Именно об этом и статья: не про то, что «одиночки плохие», а про то, что их нельзя превращать в критическую точку отказа.
А можно пример этих "сакральных знаний", которыми он не поделился? А то похоже на кучку ленивых протирателей штанов, с "ты че тут самый умный быстрей всех работать?!"
Проблема не в том, что кто-то «слишком умный», а в том, что критичные знания держатся в голове одного человека.
Пример из жизни (упрощенный, но реальный): у компании старая база на Informix, к которой за 15 лет никто толком не прикасался, кроме одного senior’а. Он знает, где что лежит, как запускается бэкап, какие индексы нельзя трогать и почему триггер в триггере — это «ок, но только тут». Он уехал в отпуск. Через два дня отвалилась отчётность, поднять бэкап не смогли, бизнес встал.
Это и есть «накопление риска». Не в том, что человек умный — а в том, что всё держится только на нём.
С поразительным постоянством появляются статьи о том, как плохи эксперты-одиночки. Может уже пора признать правду, что именно одиночки "тащат" всю компанию, а остальные "коллеги" им завидуют?
Вот человек стал экспертом. А почему он стал, а другие не стали? Болты пинали? Не хотели? А теперь внезапно эксперт стал риском? Т.е. другие не решились накапливать опыт, но что тогда они накапливали?
Легче обвинить одного человека
Интересно, не пробовали платить двум подобным спецам на случай ухода одного? :)
«Накопитель риска» в команде: как одиночные эксперты тормозят развитие