Коллеги! У нас новые вакансии в Техдирском Найме: https://t.me/ctorecordshr/

Напоминаю, что

1. Теперь все приходящие вакансии будут публиковаться бесплатно в Техдирском Найме: https://t.me/ctorecordshr

2. За отдельную плату вакансии будут публиковаться в открытом чатике. Чтобы было понятно, - никаких более-менее вменяемых денег заказчики публикаций вакансий платить не в состоянии, так что это скорее админу на хороший односолодовый виски :)

3. Строго техдирские вакансии теперь отныне и навсегда уходят только в закрытый клуб за хорошие деньги, чтобы распространяться по виралке через техдиров. Правила публикации в закрытом клубе будут самыми жёсткими, чтобы уважаемые члены закрытого клуба были довольны! Строго вилка, строго все условия и вот это вот всё. Техдир из закрытого клуба, приведший на вакансию кандидата, будет получать с компании бонус.

4. За отдельную плату админ готов провести кастдев техдирской вакансии, как это было сделано с вакансией КРОКа, чтобы лучше понять потребности заказчика.

Сделал про это пост на фб: https://www.facebook.com/ctorecords/posts/10157016785447504

Приглашаю всех рекрутёров, тусящихся поблизости, стучаться ко мне в личку, - поставим дело на поток!

Лайк, шер, алишер....

Интервью со мной про легаси

Рассказал, откуда берётся легаси, каким бременем это ложится на техдиров, как они пытаются бороться с ним и командой, а также изложил один из оптимальных способов лечения.

https://habr.com/ru/company/southbridge/blog/512672/
Поплюсуйте, plz!

@ctodsimonov спасибо за статью! Плюсанул на виси и на хабре. Очень приятно было почитать. Подписался на канал, буду ждать еще материалов! :)

Да, интересно, спасибо!
Но вот вопрос...
Подход 1, 2 или 3 ведь зависит и от возможности его применения. Скажем, есть монолит на, скажем, дельфи под ms sql, а вы хотите докеры/куберы и postgresql. Тут ведь проще сразу новое делать, чем ковырять монолит и к каждой новой фиче какие-то интеграции прикручивать, боясь, что у колоса глиняные ноги расползутся...

Или второй вопрос.
А вам ведь для нового подхода ещё и новая ИТ-инфраструктура нужна. Вы же не будете на том же дохленьком сервачке с фокс про всякие котлины  запускать. Всё равно надо эти затраты на технику как-то обосновать?

Или третий вопрос.
Вот вы пришли, а команда-то старая... Причём по возрасту от 50+, а техлид уже "продукт" пилит 25 лет на паскале, да и продуктов этих 40+ штук, а документации нет. Чего делать? Как их убедить, что тут Питон нужен или, упаси, С#?

Это очень хорошие вопросы, - прямо реально жизненные ситуации. Респект!

Скажем, есть монолит на, скажем, дельфи под ms sql, а вы хотите докеры/куберы и postgresql. Тут ведь проще сразу новое делать, чем ковырять монолит и к каждой новой фиче какие-то интеграции прикручивать, боясь, что у колоса глиняные ноги расползутся...

Новое-то проще делать, но старый колос - в продакшне. И если писать новое с нуля, то Ты гарантированно не перенесёшь всю логику, заложенную в колоссе. Кроме того, пока Ты пишешь новое решение с нуля, старое вообще ни как не развивается, - бизнес будет категорически против: у него же бизнес-план, обязательства перед инвесторами, за падение продаж ему вымя не только оторвут, но ещё и заставят приготовить на сковородке собственными руками.

А если бизнес пострадает, пострадаешь и Ты.

А вам ведь для нового подхода ещё и новая ИТ-инфраструктура нужна. Вы же не будете на том же дохленьком сервачке с фокс про всякие котлины  запускать. Всё равно надо эти затраты на технику как-то обосновать?

Да, это тоже надо продавать бизнесу. А модернизация всегда оооочень тяжело продаётся. Во-первых, Тебе самому надо её продать бизнесу. А во-вторых, бизнесу её надо продать инвесторам.

Вот вы пришли, а команда-то старая... Причём по возрасту от 50+, а техлид уже "продукт" пилит 25 лет на паскале, да и продуктов этих 40+ штук, а документации нет. Чего делать? Как их убедить, что тут Питон нужен или, упаси, С#?

С этого места ни как Ты ничего не продашь. Кроме того, что убеждать надо бизнес, надо ещё саму старую команду убедить.

Надо подниматься на уровень выше, - до стратегического планирования на 1-2 года и вписывать смену стека в стратегические хотелки бизнеса: для увеличения продаж на 200%, как вы хотите, требуются такие-то и такие-то ресурсы. И подробно обосновываешь каждый момент.

Так будет легче потому, что в рамках краткосрочного планирования, Ты ни как не сможешь с бюджетом на канцелярию построить лос-анжелес.

А в рамках долгосрочного планирования, будет видна картина в целом и насколько кто в чём заинтересован. Фундаментально легче управлять командой, имея рычаги в многолетнем планировании: и команда пластичнее и с бизнесом разговариваешь на равных.

Благодарю за ответы. Полезно :)

Хи ведь просто всё. Задайте вопрос "зачем" и "кому это надо" и того кому это надо и убеждайте

А перевод продукта на новые рельсы должен подразумевать собой качественный прорыв ибо "переписать" на уровне архитектуры это эквивалентно "создать новый продукт, при наличии на рынке старого"

Норм идея. А уже пробовал?

Какая занимательная статья ;) с одной стороны спорить можно (но не буду) с любым тезисом: я вот прям представил техдира компании в которой 2000 специально отобранных специалистов различных профилей пилят билинг для оператора с сотнями миллионов абонентов, который за недельку на коленке набросал прототипчик концепции... (What?); с другой стороны у каждой методики (наблюдения/совета) есть границы применимости.
Из наблюдений: все успешные случаи рефакторинга это следствие ситуации когда у бизнеса уже настолько болит, что резать поздно, пора закапывать. И тут появляются парни в белых плащах и начинают священную борьбу с легаси по секретным методикам. Потому что могут. И в этот раз у них получилось.

Если бизнес в лице конкретных представителей уже попадал в такие ситуации - то возможно быстрее пойдет на контакт в вопросе "скоро жахнет, надо что то делать, что будем делать?"

P.S. за стиль и слог отдельное спасибо. Читать приятно ;)

У меня получилось продать замену одного из компонентов написанным с нуля под соусом снижения издержек, мол функционально будет тоже самое, но эксплуатация - дешевле

так обычно на бэке php на golang заменяют.
бизнес смотрит, что на новом продакшне серверов не 30, а всего 5, а скорость работы увеличилась в 10 раз и очень радуется

Да. Несколько раз. В одном кейсе это была разработка новой платформы, что в итоге привело к организации отдельной дочки и выделению целого нового продуктового направления.

Ну 2к человек прототип сделанный 1м техлидом ни как не заменит. Здесь "без б".

В другом случае это было улучшение ТТХ на 3 порядка, преодоление технологического барьера и способствовало занятию новой ниши сразу для нескольких компаний холдинга

Если только этот прототип не докажет преодоление какого то препятствия принципиального