Software Engeneering 2.0 в терминологии Тбанк (этот термин пытались использовать еще до AI с другими посылами), открывает вопросы про кадры. Кто должны быть этими универсальными инженерами и как их растить?

Понятно что сеньеры с 10-15+ летним опытом которые в т.ч. могли поработать в компаниях где аналитиков и QA еще/уже не было - справятся, это ок.

В этом плане хочется считать что я как раз в этой парадигме хорошо захожу т.к. всегда качал ширину:
- Поработал и на фронте и на беке (в т.ч. без аналитиков и QA)
- Строил с нуля отделы QA, Аналитики, Devops
- Нанимал и управлял специалистами этого профиля, погружался в специфику их работы при развитии отделов
- Регулярно посещаю и выступаю на конференциях вроде Heisenbug, AnalystDays, Devopsconf и пр. в т.ч. чтобы быть в тренде их развития.

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

Плюсом, Александр в своем докладе еще подчеркивает что часть сложности в т.ч. должна снимать развитая платформа. Это к слову что инвестировать в платформенную инженерию нужно продолжать, AI ее не замещает.

Но блин, как вырастить широких инженеров С НУЛЯ?

Если пофантазировать, то в целом если бы ВУЗ учил условно год фронту, год беку, и год на QA/Аналитику. Причем все на реальных рыночных задачах... то можно было бы получить такого широкого инженера мидл уровня.
Но звучит не очень реально.