Комментарии 13
"Во многих компаниях до сих пор восхищаются теми, кто тушит пожары. Премии получает герой, который за ночь починил упавший сервер, вместо того чтобы заранее предотвратить падение"
У меня такое на первой работе было. Вместо того, чтобы «герою» вырастить помощников, передать знания и проч, начальник специально возводил его в ранк небожителя и запрещал подходить близко. В итоге мужик умер в 50 от инфаркта (вот реально бас фактор сработал), а на работе все искренне плакали, ведь никто не знал, как жить дальше
Заметил что средним-мелким компании выгодно держать только одного ведущего специалиста, который держит все у себя в голове, даже при любом пожаре и соответствующих последствиях.
Регулярно задавал вопрос, а может вы второго человека наймете или обучите имеющихся под такой же уровень? А если с ведущим что то случится, что если он уволится одним днём, что делать то будете? Внятного ответа никогда не получал. И смешно и грустно
Интересно, много ли реально проектов, которые реально не используют вот эту штуку со стратегией пожаров? Потому что постоянно с этим раньше сталкивалась — все надо тащить на себе одном, никакого тебе распределения задач, бессонные ночи ради не всегда понятной цели, а потом обычно выгорание и никто тебе за восстановление, кстати, не платит. Ну и вот тебе и бас фактор, и иже с ними.
О, в одной госкомпании, где мне довелось побывать, как раз была монополия на знания. Там только один человек, как Вася из известного мема, работал, а остальные менеджерили его непонятно зачем. Вася ушел — стройка встала. Никто не знал, что он вообще такого делал, чтобы работа работалась, только советы все давали. Молчу о финансовом ущербе.
Есть редкие случаи, когда старое решение действительно стоит оставить в покое — там, где стабильность важнее изменений
Вот тут имхо и сидит проблема. Где эта грань? Некоторые уж шибко много всего записывают в эту категорию. В любом проекте обязательно найдется "дед", которому будет приятнее сердцу смотреть на тихую, но работающую работу нежели на любые попытки внедрить что-то новое
За что такие наезды на мейнфрейм? Можно купить новый или обновить существующий. COBOL можно выучить так же, как и любой другой язык. Можно не менять всё, а выпилить только то, на что прыгает нагрузка, в отдельный microservice.
"В США до сих пор работают федеральные IT-системы возрастом 8–51 год, их поддержка обходится в $337 млн ежегодно." А во сколько обойдётся поддержка новых систем (и их покупки)?
"компании закладывают бюджет на модернизацию — в среднем это $2,7 млн в год, но 60–80% денег всё равно уходит на штопанье старого кода" - а они должны писать всё с начала?
А так к остальному у меня претензий нет.
С одной стороны много полезных мыслей организационного характера - про тот же фактор автобуса, необходимость написания документации, наличия ответственных за сервисы, своевременного обновления стека и закрытия технического долга - с другой стороны совершенно неуместный фанатизм в отношении микросервисов, которые ультимативно считаются серебряной пулей и единственным современным решением. Сразу вспоминается статья Смерть от тысячи микросервисов. А серебряной пули нет.
новичкам в команде не дают учиться, потому что во всех критических ситуациях зовут одного и того же супермена
На самом деле, в этом заинтересован в первую очередь сам супермен. Он формирует перед начальством образ своей незаменимости. Особенно если супермену перевалило за много лет и он изрядно отстал от жизни. Вот появится условный "новичок" и поменяет систему двадцатилетней давности на что-то новое. И куда податься тому супермену? А до пенсии "всего" лет десять...
Кстати, про Кобол. Пару лет назад как-то обратил внимание на этот вопрос и я посмотрел вакансии по нему. Было довольно много. Половина из них подразумевала "перевод" Кобола на другой язык, в основном Джаву. Фишка вся в том, что среди требований было программирование на Коболе в реальном корпоративном проекте не менее 5 - 10 лет. "Джуниорских" позиций не было совсем. То есть, чтобы стать программистом Кобола, даже имея знания, надо быть программистом Кобола с опытом.
Кто реально пробовал Strangler Fig approach? Сработало ли в условиях ограниченного бюджета или это история только для больших корпораций
ADR и матрицы RACI — это хорошо, но требует дисциплины. В маленьких командах часто нет ресурсов вести артефакты, всё решается устно. Как заставить людей это реально делать?
Проекты разваливаются не из-за старого ПО — виновата монополия на знания. Объясняем, сколько на этом теряют и как лечить