Комментарии 76
Есть еще одна причина о которой вы забыли упомянуть. Себестоимость конечного продукта сделанного таким одиночкой в разы меньше чем при коммандной работе. При этом доход такого одиночки в несколько раз выше среднего по рынку.
Я сам такой одиночка. Я могу сделать за месяц продукт который в компании будет делать группа из нескольких человек полгода.
Часто работодатель не понимает что сделав разработку коммандной он увеличит рассходы в разы ( по моей оценке в среднем раз в десять) и для него это становится неприятной неожиданностью, что приводит к конфликтам с работодателем.
Насколько я могу судить, статья не про расходы при оптимальном раскладе - статья про риски.
Спасибо за комментарий — вы абсолютно правы, это хорошее дополнение.
Да, одиночка в хорошей форме действительно может сделать MVP или даже полноценный продукт на порядок быстрее и дешевле команды. И именно поэтому такие люди ценны, особенно в старте, R&D, на сложных участках. Но тут как с костылями в проде: помогает быстро в моменте, а потом может аукнуться.
Вы правильно подметили — работодатели не всегда осознают, что командная разработка не масштабирует результат линейно, а расходы — да, масштабирует. И если в голове был план «сейчас разовьём успех и передадим в команду» — начинаются проблемы: коммуникации, бриджинг знаний, падение скорости, рост расходов, нестыковки по качеству и ожиданиям.
Получается дилемма: или быстро и дёшево, но нестабильно; или стабильно и масштабируемо, но дороже и дольше.
Так что, согласен — эта часть стоит более явно обозначить в статье. Я подумаю, как аккуратно дописать про «причины» и «ожидания бизнеса».
Если все правильно организованно, группа всегда будет эффективнее любого одиночки
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут.
Организация решает не везде, но то что она дает мультипликативный эффект - да.
В 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 месяца после увольнения ключевого разработчика.
Вы абсолютно правы: допускать завязку на одного человека — управленческая ошибка. Именно об этом и статья: не про то, что «одиночки плохие», а про то, что их нельзя превращать в критическую точку отказа.
Когда стали работать в трекере задач и создали единое рабочее пространство, такой вопрос ушел. В Yougile стали вести не только текущие задачи, но и припасли материалы для адаптации каждого новичка. Удобно, что доски можно использовать как угодно. Да еще и эффективность отслеживать
А можно пример этих "сакральных знаний", которыми он не поделился? А то похоже на кучку ленивых протирателей штанов, с "ты че тут самый умный быстрей всех работать?!"
Проблема не в том, что кто-то «слишком умный», а в том, что критичные знания держатся в голове одного человека.
Пример из жизни (упрощенный, но реальный): у компании старая база на Informix, к которой за 15 лет никто толком не прикасался, кроме одного senior’а. Он знает, где что лежит, как запускается бэкап, какие индексы нельзя трогать и почему триггер в триггере — это «ок, но только тут». Он уехал в отпуск. Через два дня отвалилась отчётность, поднять бэкап не смогли, бизнес встал.
Это и есть «накопление риска». Не в том, что человек умный — а в том, что всё держится только на нём.
С поразительным постоянством появляются статьи о том, как плохи эксперты-одиночки. Может уже пора признать правду, что именно одиночки "тащат" всю компанию, а остальные "коллеги" им завидуют?
Вот человек стал экспертом. А почему он стал, а другие не стали? Болты пинали? Не хотели? А теперь внезапно эксперт стал риском? Т.е. другие не решились накапливать опыт, но что тогда они накапливали?
Легче обвинить одного человека
«Накопитель риска» в команде: как одиночные эксперты тормозят развитие