Недавно в кругу старых друзей мы обсуждали, что вообще значит быть senior-разработчиком. И в какой-то момент один из них задал резонный встречный вопрос:
«А как назвать разработчика, который технически силён, кодит быстро, но при этом не делится знаниями и работает строго в одиночку?»
После короткой паузы ответ прозвучал просто и жёстко — накопитель риска (Risk Accumulator).
В этой короткой статье разберём, откуда берутся такие одиночки, почему это опасно и как с этим бороться.
Кто такие «накопители риска» и в чём суть проблемы
Кажется, что если человек быстро пишет код, отлично разбирается в системе и «не мешает другим» — то это плюс. На деле же это может быть миной замедленного действия.
Когда один человек становится единственным носителем знаний о критичной системе, алгоритме или бизнес-логике, он превращается в точку отказа. Он может уйти, заболеть или просто перегореть — и тогда команда окажется в заложниках.
Это прямо противоречит базовым принципам надёжности, которые мы, как инженеры, исповедуем. Ведь никто не станет хостить крупный сайт на одном сервере в одной стойке, верно? Почему тогда мы строим команды так, что всё держится на одном человеке?
Почему так происходит
Причин на самом деле много:
Карьерные стереотипы. Часто «сеньора» воспринимают как мастера кода, а не как командного игрока.
Лень менеджмента. Проще не вмешиваться в работу продуктивного одиночки, чем инвестировать в культуру обмена знаниями.
Неумение делиться. Некоторые разработчики искренне считают, что обучать других — это пустая трата времени.
Боязнь потерять значимость. Быть единственным экспертом даёт чувство контроля и важности.
Экономика одиночки. Бывает, что один сильный инженер делает за месяц то, что команда пилила бы полгода.
Чем это опасно
Вот несколько эффектов, которые может вызвать подобная ситуация:
Замедление команды. Новички не могут разобраться без помощи, а «сеньор» на контакт не идёт.
Блокировка развития продукта. Изменения в «зоне эксперта» становятся невозможными без его участия.
Выгорание. Когда всё завязано на одном человеке — он же и будет гасить все пожары.
Технический долг. Без рецензий и обмена опытом кодовая база деградирует.
Себестоимость Одиночки ниже, а отдача выше — особенно на старте. Это соблазнительный путь, особенно для стартапов или небольших команд. Но он работает до тех пор, пока не нужно масштабироваться. Тогда резко растёт стоимость передачи знаний, адаптации процессов и интеграции других разработчиков — что часто становится неожиданным (и болезненным) для бизнеса.
Что с этим делать
Культурный сдвиг
Переопределить понятие senior. Это не только про код, но и про поддержку команды, менторство, документацию.
Награждать за помощь другим. Включить в performance review метрики наставничества и командной вовлечённости.
Практики
Ротации. Никто не работает постоянно с одной системой.
Парное программирование. Не факультатив, а часть процесса.
Документация как часть Definition of Done.
Качественные code review. Инструмент передачи знаний, а не бюрократия.
Вывод
«Одиночные волки» в разработке могут быть очень талантливыми. Но если они не помогают команде расти и всё держится только на них — это не senior, это уязвимость.
А вы как решаете проблему «одиночек» в команде?
Поделитесь в комментариях — кейсы, грабли, удачные практики. Будет интересно сравнить.
Комментарии (64)
EvilMan
11.05.2025 11:30Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
SolidSnack
11.05.2025 11:30Что значит "не делится знаниями"?
Смотрю в код, а там одна магия.
EvilMan
11.05.2025 11:30Тут уже другая проблема - человек пишет неподдерживаемый код (магия без комментариев и документации).
Rive
11.05.2025 11:30Это может быть просто малопонятный низкоуровневый язык. Разработчик может напичкать проект документацией и комментариями, но вносить изменения на их основе остальная команда не сможет.
EvilMan
11.05.2025 11:30Это может быть просто малопонятный низкоуровневый язык.
Ошибка при выборе инструмента.
Разработчик может напичкать проект документацией и комментариями, но вносить изменения на их основе остальная команда не сможет.
Skill issues.
brmn Автор
11.05.2025 11:30Документация не заменяет живое общение. Когда знания живут только в коде и в вики, но не в головах команды, то скорость адаптации, дебага и развития падает. А "объяснять" — это не про семинар, это про часть командной ответственности senior-уровня. Не каждый день, не на каждую строчку, но регулярно и по делу.
xata6
11.05.2025 11:30регулярно и по делу, это в сторону L3? То есть отдельная вакансия, которую надо бы доверить отельному человеку? И платить ему как полагается? А если кто то в обязательной манере, что-то кому то объяснять, то и не плохо было бы соответсвенно платить, если это небыло в контракте прописано.
А то по итогу проект сделай(это одни деньги), проект поддерживай(это другие деньги), а потом еще объяни как все работает "Не каждый день, не на каждую строчку, но регулярно и по делу."(это третьи деньги).brmn Автор
11.05.2025 11:30В идеале — да, если компания требует постоянного менторства, обучения и поддержки коллег, это должно быть отдельно зафиксировано и оплачено. Но тут есть нюанс: если разработчик претендует на senior-уровень, то способность объяснять решения и помогать команде — это не отдельная "услуга", а часть роли. Это не значит «читать лекции», но да — быть доступным, объяснять ключевые решения, помогать ориентироваться. Это про устойчивость команды, а не бесплатную нагрузку сверху.
Во многих европейских компаниях это вообще норма: сеньор без менторства там долго бы не продержался. Просто потому, что от него ждут не только кода, но и влияния на культуру, процессы и рост других. Это не бесплатно — это вшито в компенсацию и ожидания.
EvilMan
11.05.2025 11:30Вполне себе заменяет.
brmn Автор
11.05.2025 11:30Согласен, если документация написана живым языком, покрывает реальные кейсы и кто-то её действительно читает, тогда да, может заменить. Но на практике чаще видим вики две тыщи лохматого года с "TODO: дописать", а потом всё равно идём спрашивать того самого человека. Так что документирование — однозначно нужный инструмент, но не волшебная панацея.
olartamonov
11.05.2025 11:30А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа
Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В то же время, ещё материалистическая диалектика учила нас закону о переходе количественных изменений в качественные.
Если бы его не было (а он выведен эмпирически, то есть, на основании реальных наблюдений и следующих из них логических умозаключений), то да, синьор бы отличался от миддла и джуна исключительно тем, что пишет в единицу времени больше кода, имеющего меньшее число ошибок на тысячу строк, и больше ничем.
Но так как он всё же есть, то каждая ступенька роста подразумевает изменение не только количественные, но и качественные. Джун действует по инструкции, описывающей метод решения поставленной перед джуном проблемы. Миддл умеет самостоятельно идентифицировать известные проблемы и находить инструкции по их решению. Синьор умеет определять наличие неизвестных проблем и не только решать их, но и переводить эти проблемы в категорию известных.
Собственно, последнее и есть «передача опыта». Технически она может осуществляться разными способами (и документацией, и семинарами, и личным общением).
(и если что, синьорам и платят больше, чем миддлам, в том числе и за это, а не за тысячи символов кода в час)
Да, есть ошибка во многих компаниях, когда до синьора повышают за
просиживание задницывыслугу лет, а не за умение решать задачу передачи опыта. Точно так же — и об этом много сказано, и свежее например сказано тут, и добавить мне к этому нечего — потом повышают до тимлида, у которого качественная разница с синьором совсем радикальная.Это проблема компании: в ней не собрана корректно работающая система построения иерархической лестницы.
Но. Если такая система в компании выстроена, вышеуказанное качественное различие между ролями руководство понимает, а вот конкретный сотрудник считает, что это не его дело, его дело исключительно кнопки давить — то именно как описано автором статьи, такой сотрудник является угрозой для проекта (и компании в целом) на роли синьора, если он почему-то на неё попал, или, в более корректном варианте, очень-очень хорошим миддлом, которого никогда не повысят (а он не поймёт почему, обиженный уйдёт туда, где его возьмут в синьоры — и в силу вышесказанного для компании, из которой он уволился, это будет не провалом «не смогли удержать!», а неизбежной потерей).
EvilMan
11.05.2025 11:30Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
brmn Автор
11.05.2025 11:30Ваш подход близок к инженерному идеалу. Но на практике он работает только в очень зрелых и дисциплинированных командах. В реальности люди не всегда читают, не всегда понимают сразу, и живое общение сильно ускоряет передачу контекста. Особенно если речь про принятие архитектурных решений, а не просто «как это работает».
stay_protected
11.05.2025 11:30инженерный идеал это когда выпусники не могут и не хотят читать старые доки да предприятие держит пенсионеров сидеть на стульях в ожидании что ктото из молодых обратиться с вопросом по ими когда наделаной документации - видел такие научно-производственные предприятия с несколькими этажами динозавров
olartamonov
11.05.2025 11:30Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит
Как я уже сказал выше — жаль, что вы до этого тезиса не дочитали, а поторопились писать ответ — если в компании не выстроена система построения иерархической лестницы, в результате чего синьор отличается от миддла только частотой давления на кнопки и процентом совершаемых при этом ошибок, то это, несомненно, проблема компании. У такой компании будут серьёзные трудности в развитии.
Впрочем, в некоторых областях это вполне прокатывает — например, в типовой контрактной разработке, где действительно вполне эффективно иметь штат программистов, в обязанности которых входить только давить кнопки с разной скоростью. Трудности у таких компаний возникают только при смене ориентации деятельности — например, изнутри однажды наблюдал героические попытки перейти с рельс контрактов на выпуск своего продукта, закончившиеся полным ничем.
Gar02b
11.05.2025 11:30Вполне возможно, что этот "аккумулятор риска" был отравлен отношением на предыдущем месте работы. Я видел однажды, как людей попросили подробно задокументировать все знания по проекту, а потом выставили их вон и наняли дешёвую замену.
Как думаете, стремились ли они делиться знаниями с коллегами на новой работе?
stay_protected
11.05.2025 11:30возможно из взяли на новую за то-что они сделали на предыдущей
StarWings
11.05.2025 11:30Разве что в комедийном фильме. В реальности никто и не узнает, что они там реально сделали, да и не интересует это никого особо. Потому что никому не хочется судиться из-за разглашения закрытой информации.
stay_protected
11.05.2025 11:30пишут же людив резюме что от kpi'или столькото отделов да тп результатов достигли - вот и они напишут что продукоментировали всё возможное
brmn Автор
11.05.2025 11:30Кстати, про риски замены опытных специалистов на дешёвых я писал отдельно. Можете почитать, если интересно: https://medium.com/@dobeerman/the-hidden-costs-of-hiring-low-cost-developers-ac7f79027961
stas_dubich
11.05.2025 11:30Это достаточно частая история, одиночка делает хороший продукт, расписывает и рассказывает мельчайшие детали, потом его просят на выход, заменяя джунами. Или мне так везло с работодателями)
Tantacula
11.05.2025 11:30Если не распишите, вас все равно уволят и на ваше место возьмут других разработчиков, которым на старте поставят задачу: разобраться и задокументировать, что и как работает.
StarWings
11.05.2025 11:30Плюсы на сегодня закончились. Но именно написанное вами и приходит в голову первым, при чтение статьи, которая основана на популизме и "эффективном менеджменте".
gazkom
11.05.2025 11:30А люди бы хотели написать программу один раз, а потом ничего не делать и получить за нее зарплату десять лет. К большому моему сожалению, так не работает. Почему-то так работает только с музыкой.
f-tech
11.05.2025 11:30Как минимум, люди хотели бы остаться на прежнем месте работы. Наверное хотели бы развивать продукт, в который вложили столько сил. А людей натурально кинули.
Я не Ванга, но прям вижу, что этим же людям рассказывали про "мы одна семья", и что "сейчас надо потерпеть, зато потом заживем по-королевски" когда оправдывали бесплатные овертаймы и отстающую от инфляции ЗП.
Informatik
11.05.2025 11:30Люди хотели бы один раз на старте пожертвовать время чтобы разобраться с проектом, а потом каждый день небольшими усилиями вносить улучшения, потому что у людей может быть ещё и личная жизнь, которая требует внимания. А что делает с людьми предлагаемый в статье подход? Каждый день как в самом начале трать много времени чтобы разбираться с тем что наделали другие до тебя и ещё объясняй другим, что ты сам наделал, потому что менеджер боится потери бойца, а продуктивность у тебя должна быть такая как если бы ты не тратил на все это время, короче будь ноулайфером, живи и дыши работой пока тебя не выдоят досуха и не выбросят как отработанный материал.
gazkom
11.05.2025 11:30Один раз сделать и годами вносить мелкие улучшения? Лично я убился б лучше на старте программистской карьеры (это было 30 лет назад). Скука то какая.
Informatik
11.05.2025 11:30Ну это нормально, что хочется порезвиться. Каждый программист сам по себе источник хаоса и задача менеджера как раз таки контролировать этот хаос, а не потворствовать ему, ограничить его рамками модуля чтобы этот хаос не распространился на весь проект. Да вот в рамках своего участка делай что хочешь лишь бы работало, но на другие не лезь. Например, один программист пилит бэкенд и что-то ему как-то скучно стало и он начинает доставать менеджера чтобы тот дал ему другую задачу развеяться, а тот и возьми и дай ему фронтенд задачу. Кросс-скиллинг и все такое. Бэкендщик приходит в модуль фроненда и начинает там резвиться, а потом наломав там дров возвращается обратно к себе в бэкенд. В итоге код проекта уродуется нашествием таких гастролеров. Ревью кода от этого не защищает потому что, когда время уже потрачено на задачу и она уже хоть как-то реализована, то никто ничего переделывать не будет.
Tantacula
11.05.2025 11:30Заставьте разраба выкладывать коммиты по задаче в отдельной ветке не реже раза в день, даже если сама задача не завершена и ревью делайте тоже раз в день, пока качество его кода не начнет вас удовлетворять и ревью вполне начнет защищать.
Gar02b
11.05.2025 11:30Это ПО для POS-терминалов. У его разработки, как у революции, "есть начало, но нет конца". Оно постоянно развивается, но среди управленцев это могут понять не все.
Кстати, в том проекте это быстро поняли. :-) Я часто злорадствую, когда менеджеры получают ума через задние ворота.
andmerk93
11.05.2025 11:30Документация как часть Definition of Done
This. Документация на систему - часть системы.
Но, как и бэкапы и автотесты, техническая документация не приносит прямой прибыли, только затраты. Поэтому, бизнес этим заниматься не хочет. Вопрос не технический, вопрос - организационный.
Ну, и хрен с ним, с этим бизнесом, пусть горит. А руковод - сам виноват.
brmn Автор
11.05.2025 11:30Согласен — документация, как и бэкапы, юнит-тесты, CI и мониторинг, не приносят прибыли напрямую. Зато очень хорошо показывают свою ценность в момент, когда всё начинает "идти по ...", вобщем, падать.
Это не про «лишние расходы», а про управление рисками. Как и страховка: дорого, скучно, но без неё больно.
Так что да — вопрос действительно организационный. Но игнорировать его техническим командам тоже себе дороже.
andmerk93
11.05.2025 11:30Я, как технарь, всегда и везде топлю за документацию.
Ибо, бывал в как ситуациях, когда приходится разбираться с "черным ящиком". Так и в ситуациях, когда уходишь, и оставляешь коллегам "черный ящик", и как-то неловко, совестливо, и вообще, цеховая солидарность свербит.
Но проблема документации в том, что она сама себя не напишет. Надо отдельно время выделять и отложить часть оперативных задач, которые никогда не заканчиваются. Руководители на это обычно не идут.
Так что, я б не сказал, что это технические команды игнорируют. Ну, во всяком случае, у нас на заводах-пароходах - так.
i360u
11.05.2025 11:30Еще бывает так, что знания передавать просто некому. Каждый сфокусирован на своем узком круге задач и любые "знания" извне своего непосредственного процесса воспринимает как досадный и ненужный шум. Команда, тупо, может не иметь достаточных компетенций / мотивации для того, чтобы принимать ваши знания и документацию вашу никто особо не читает. Всем некогда. Работает - и хорошо.
Я сам часто был в такой ситуации, когда очень хочешь делится знаниями, но всем просто пофигу. Это очень демотивирует. Именно по этой причине, однажды, я ушел со своей прошлой работы и собрал собственную R&D команду.
ЗЫ. Статья, по сути, выставляет самого компетентного игрока в команде - как слабое звено. Вам не кажется, что с этим мнением, мягко говоря, что-то не так?
brmn Автор
11.05.2025 11:30Не компетентность делает кого-то слабым звеном, а изоляция. Один эксперт, замыкающий знания на себе — это как сервер без бэкапа: пока работает, все довольны, но риск растёт каждый день. Статья не про «наказать лучших», а про то, как сделать команду устойчивее.
i360u
11.05.2025 11:30Поймите, разработчики - это люди. Они очень разные. Часто выдающиеся технические скилы соседствуют с трудностями в социализации. Грамотный руководитель отличит "молоток" от "микроскопа" и каждого использует на своем месте. А вот передать свойства "микроскопа" "молоткам" - это очень сомнительная идея. Я бы сказал, заведомо провальная. Таким образом, основным фактором риска, в этой ситуации, является РУКОВОДИТЕЛЬ и именно его компетенции.
svistkovr
11.05.2025 11:30«А как назвать разработчика, который технически силён, кодит быстро, но при этом не делится знаниями и работает строго в одиночку?»
У вас есть человек который глубоко разбирается в части ваших бизнес-процессов. На него не надо тратить ресурсы для обучения и введения в работу. Ему нравится его деятельность. Учитывая современную обстановку с кадрами - этого спеца надо не просто удержать, а сделать совладельцем бизнеса. Выделить небольшой бюджет и сделать его руководителем нового отдела. Пусть сам уже внутри своего отдела нанимает помощников и делегирует свои задачи. А так же в качестве стимула добавить к его зарплате небольшой процент от дохода. У спеца будет интерес вкладываться в работу бизнеса.
Но советы из поста в стиле больше недоверия к человеку и больше гнобления чтоб знал холоп свое место. После такого любой спец убежит, а нового выращивать долго и с кучей расходов и простоев бизнеса.brmn Автор
11.05.2025 11:30Ваша позиция вполне понятна, но, боюсь, вы немного не о том. В статье не предлагается «гнобить спеца» или отбирать у него автономию. Речь о системном риске, когда знания замыкаются на одном человеке.
Если специалист крут, то это не повод строить вокруг него культ. Это повод создать условия, при которых его знания масштабируются, а не становятся узким горлышком. Делегирование, развитие отдела, участие в прибыли — отличные идеи, если он сам к этому готов. А вот игнорировать риск — это управленческая халатность, а не уважение к профессионалу.
stay_protected
11.05.2025 11:30есди бы организация оплачивала ему образование то имела бы право его выжимать в организацию
brmn Автор
11.05.2025 11:30В нормальных компаниях как раз и есть learning budget, потому что развитие сотрудника = развитие бизнеса. Но даже без этого знаниевый монополизм остаётся риском. Здесь не про «выжимать», а про устойчивость процессов и здравое управление.
На этот счет у меня есть любимая фраза:
– А что, если мы обучим наших сотрудников, а они уйдут от нас?
– А что будет, если мы их не обучим, а они останутся?
Lewigh
11.05.2025 11:30Почему так происходит
Причин на самом деле много:
Причина в большинстве своем одна - эффективный менеджмент. Задайтесь для начала вопросом - как так вообще случилось что у вас один человек только во всем разбирается?
Вопрос то не сложный. Вы много пишете про сеньоров а на деле часто такие люди средней руки мидлы и даже бывает вообще джуны. Да, даже такое видел.
Возвращаясь к вопросу как так вообще выходит. Вот есть команда разработки, в ней есть пару опытных разработчиков и несколько среднячком и даже слабых. Найдется такой инициативный человек который начнем компенсировать свои технические скилы тем что будет усердно разбирается в бизнесе и проекте и как пирожки шлепать гавнокодом задачи, чем приводить в неистовый восторг всех менеджеров. Часто у менеджеров кроме сиюминутных проблем голова ничем не забита и такой человек будет все больше и больше нравится чем скучные опытный разрабы которые будет предлагать очевидно бесполезные с точки зрения менеджера вещи как рефакторинг, проектирование и что что самое страшное будут предлагать думать головой. Угадаем на чью сторону встанет менеджмент и кого будет поддерживать. Через какое то время может этого инициативного вообще тимлидом сделают (и такое я видел) а опытные разработчики уйдут с проекта так как надоест работать с дурдоме. Как итог произойдет замещение с опытной команды на лояльную.
Как итог сидит такой незаменимый специалист которого все любят и делает все чтобы он продолжал оставаться незаменимым. А кто его вырастил?
Переопределить понятие senior. Это не только про код, но и про поддержку команды, менторство, документацию.
Нечего там переопределять. Это просто красивое слово которое в лучшем случае обозначает привязку к зарплатной сетке конкретной компании.
ooko
11.05.2025 11:30Наверно вся успешная музыка написана в командной работе. Нет универсального подхода. В свете развития ИИ думаю соло разработчиков будет становиться больше. И в какой-то момент выйдет статья где будет написано что командная разработка это накопитель рисков.
adrozhzhov
11.05.2025 11:30Фактор грузовика/автобуса. Bus factor - Wikipedia
С начала века реально видел как он срабатывал 3 раза у коллег в 3х разных странах.
При этом в первом случае израильская команда должна была начать передавать знания через 2 недели, а начала потихоньку через полгода, после выздоровления.
И это ещё самый оптимистичный итог из 3 случаев.
Поэтому держать его хотя бы 2-кой и делать документацию и обучение чему-то сразу - это удобно на самом деле.
nvantropov
11.05.2025 11:30Сейчас это модно называть словом bus-фактор, вроде. Его многие недооценивают, потому что это выглядит дешево сначала – один человек работает за целую команду. Но со временем даже небольшое изменение нагрузки/требований начинает стоить очень дорого:
Переработку может сделать в адекватные сроки только один человек;
Этот один человек может быть уже занят другими изменениями, которые тоже может быстро сделать он один;
Этот один человек может заболеть или уволиться.
По моему опыту эффективно показать человеку, что он может перейти к более интересным задачам, если передаст коллегам свои старые наработки.
brmn Автор
11.05.2025 11:30Да, это и есть классический bus-фактор — и в вашем списке чётко видны все симптомы. «мотивация через освобождение» — это действительно работает: передал знания → освободил себе путь к новым задачам. Выгода для всех.
Hivemaster
11.05.2025 11:30Ох, сколько раз я видел, как менеджмент целенаправленно создаёт такую ситуацию! Это же так удобно, завести швеца, жнеца и на дуде игреца, который будет всё тащить за одну зарплату. А ещё менеджмент не понимает или просто не хочет понимать, что на передачу знаний нужно время, причём тем большее, чем больше разрыв в квалификации между носителем этих знаний и обучающимися. Если остальная часть команды - это джуны после курсиков, то они уйдут к другому работодателю раньше, чем успеют перенять хотя бы десятую часть знаний "накопителя риска". Плюс нагрузку-то с сеньора тоже никто не снимает, 40 часов в неделю надо пилить фичи, а раз зарплата у сеньора большая, то пусть напилит за эти 40 часов 60-часовую норму, желательно пока на созвонах сидит.
danilovmy
11.05.2025 11:30В опроснике "А у вас в команде были или есть «накопители риска»?" пропущен важный вариант ответа: "да, это я". Количество ответивших покажет сколько ещё единорогов осталось.
P. S. И да, это я. :(
SemiHDD
11.05.2025 11:30С ростом проекта и его ответственность, большинство руководителей задумываются про бекапов, масштабирование и отказоустойчивости инфраструктуры продукта, но не о тех кто строит продукт, т.е. об увеличение количество сеньоров мало кто задумывается (да это дорогое удовольствие, как и 3 мастер ноды k8s, зато отказоустойчивее)
Informatik
11.05.2025 11:30Да, про людей не думают. Вся статья по сути про то, что бы такое придумать чтобы защититься от потери разработчика и все предлагаемые решения лишают разработчика возможности комфортно работать. Если менеджмент выстраивает систему с защитой от ухода людей, то в такой системе люди будут уходить потому что это заложено в работу системы. А надо наоборот выстраивать систему в которой людям захочется остаться. Что сделать чтобы разработчику было комфортно? Может все таки стоит ему дать возможность работать над чем-то одним, а не гонять по системе как вшивого по бане. В IT много управленцев, которые ими стали за то, что хорошо делали техническую работу, но они не понимают базовых принципов организации труда: разделение труда, рабочая нагрузка и пр.
frostsumonner
11.05.2025 11:30Но это все-таки не входит в обязанности разработчика... Делать качественное review - да, подсказывать что-то - да, а вот нацеленно кого-то обучать - нет. Команда должно приходить сверху ~используй 20% времени на обучение нового сотрудника.
brmn Автор
11.05.2025 11:30Вы правы – это должно быть закреплено сверху. Но в международной практике менторство и обмен знаниями давно входят в обязанности senior-инженера. Это не «допнагрузка», а часть роли. Без этого – это просто быстрый middle, а не senior.
nathatfree
11.05.2025 11:30Вот мой глупый вопрос.
Что мешает бизнесу, создать единый подход к решению задачи?
Тот кто лучше разбирается в этом подходе, тот и топ-разработчик.
Тогда даже этот фактор риска будет учтен в зачаточном состоянии задачи.
brmn Автор
11.05.2025 11:30Идея здравая, но на практике "единый подход" часто размывается: задачи разноплановые, требования меняются, люди уходят. Даже лучший подход не спасёт, если знания о нём знает один человек. Важно не только что делать, но и как делиться знаниями по ходу.
HEXFFFFFFFF
Есть еще одна причина о которой вы забыли упомянуть. Себестоимость конечного продукта сделанного таким одиночкой в разы меньше чем при коммандной работе. При этом доход такого одиночки в несколько раз выше среднего по рынку.
Я сам такой одиночка. Я могу сделать за месяц продукт который в компании будет делать группа из нескольких человек полгода.
Часто работодатель не понимает что сделав разработку коммандной он увеличит рассходы в разы ( по моей оценке в среднем раз в десять) и для него это становится неприятной неожиданностью, что приводит к конфликтам с работодателем.
stay_protected
ещё забыл(и) что одиночка претендует на интелектуальную собственность
Rive
Насколько я могу судить, статья не про расходы при оптимальном раскладе - статья про риски.
stay_protected
директор компании тоже может не проснутся
Informatik
Вот да, но если я предложу, что давайте применим практику ротации к управленцам, например, CEO, Team Lead, директор по маркетингу, product manager будут меняться между собой, то они мне скажут, что это бред, но почему-то учинять такое издевательство над разработчиками считается в порядке вещей.
brmn Автор
Спасибо за комментарий — вы абсолютно правы, это хорошее дополнение.
Да, одиночка в хорошей форме действительно может сделать MVP или даже полноценный продукт на порядок быстрее и дешевле команды. И именно поэтому такие люди ценны, особенно в старте, R&D, на сложных участках. Но тут как с костылями в проде: помогает быстро в моменте, а потом может аукнуться.
Вы правильно подметили — работодатели не всегда осознают, что командная разработка не масштабирует результат линейно, а расходы — да, масштабирует. И если в голове был план «сейчас разовьём успех и передадим в команду» — начинаются проблемы: коммуникации, бриджинг знаний, падение скорости, рост расходов, нестыковки по качеству и ожиданиям.
Получается дилемма: или быстро и дёшево, но нестабильно; или стабильно и масштабируемо, но дороже и дольше.
Так что, согласен — эта часть стоит более явно обозначить в статье. Я подумаю, как аккуратно дописать про «причины» и «ожидания бизнеса».
arutune
Если все правильно организованно, группа всегда будет эффективнее любого одиночки
lastrix
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут.
Организация решает не везде, но то что она дает мультипликативный эффект - да.