Comments 7
По моим наблюдениям, процентов 80 разработчиков на рынке не видели оформленного карьерного фреймворка (системы грейдов) ни разу в жизни.
Я в своей карьере два раза в живую видел эти самые "карьерные фрэймворки". У Siemens и Datev.
В обоих случаях любой разговор о повышении должности и/или зарплаты сводился к разговорам о каких KPI, которые надо было надрочить чтобы получить следующий грейд. Или о выслуге лет.
И как раз таки там человек, который имел опыт за пределами компании и тащил проекты спокойно мог зарабатывать меньше чем середнячок-миддл с опытом внутри компании.
Так что грейды, тарифы и карьерные фрэймворки это не панацея. И конкретно для айтишников и по моему опыту они создают больше проблем чем решают.
Хотя конечно для людей, которые не умеют торговаться и выбивать себе хорошие условия это вполне себе вариант.
Полностью понимаю, о чём идет речь) Обидно за скромных ребят, кто лишний раз бояться с этим к руководству идти, а среди них есть реальные таланты, которым надо давать больше влияния в проектах.
Да, когда карьерный фреймворк превращается в бюрократию или тупо завязан на «выслугу лет» — это скорее вред, чем польза. И уж точно не про мотивацию или реальный вклад. Особенно больно, когда «середнячки» внутри получают больше, чем реально сильные ребята, пришедшие с опытом.
Я именно поэтому в статье и написал, что фреймворки — не панацея. Всё зависит от того, как и кем они внедряются. Если делают «для галочки» или чтобы прикрыть хаос — получится ещё больше хаоса. Но если подходить с умом и опираться на реальный вклад, навыки и бизнес-импакт — может получиться инструмент, который помогает расти и команде, и самому разработчику.
И вы прям в точку сказали: для тех, кто не умеет торговаться, это может быть хоть каким-то способом получить понятный путь развития. Но для этого система должна быть живой, а не формальной.
Грейды это та самая вещь, которую сложно привести к общему виду. Есть целая масса компаний, в которой сотрудники не развиваются, хотя в рамках её становятся сеньорами из-за выслуги лет, и ничего толком не умеют. Идут в другую команду устраиваться как сеньор-помидор, а там что бы не обижать нанимают его как сеньора, но за меньшие деньги, чем платят мидлу. А кого-то нанимают как мидла, хотя понимают, что для них он вообще сеньор, и предлагают ему оклад выше, чем у их сеньоров.
Сложная штука эти грейды. Имею ввиде не именно в рамках одной компании, а в целом. В одной компании требуются знания и умения одни, в другой компании это будет совсем другое.
На своем примере, что у нас использовался очень специфичный стек, что найти вакансию с этим фреймворком будет очень проблемно. Вроде как был мидл в компании (просто когда-то спросил, могу ли я с младшего-разработчика перейти на простого разработчика, и мне сказали, что переведут xD), но читая требования других, то я больше похож на джуна, т.к. тупо не знаю многих технологий, которые используются у многих.
А в целом удобная штука, когда видим в компании эту градацию, что мы должны знать и уметь, значит и вилку по ЗП тоже будем видеть и расчитывать на свои силы. Меньше вопросов возникает после этого. В т.ч. должностные обязанности знаешь свои, что можешь делать в проекте, а что должен по должностной инструкции. А не просто на каких-то созвонах спрашивать про подъем ЗП или слушать, что начальство просит еще начать заниматься другими вещами, которыми ты раньше не занимался...
я, конечно, не разработчик, но оценка грейда та еще история) как системный аналитик пришел в компанию, где в принципе системных аналитиков не было, теперь нанимаю аналитиков и по факту руковожу направлением, задаю стандарты. Но работаю 3 года в целом в этом направлении. Полномочия и влияние на проекты как у лида, но как оценить себя и свои навыки без понимания, что реально делают профессионалы в системном анализе и каким критериям соответствуют..)
Dropboх тоже лукавит.
У них senior - это в первую очередь менеджер и тим-лид, во вторую экспертные знания самого продукта, и только в третью чувак, который способен эффективно решить неоднозначную проблему
I own and deliver semi-annual/annual goals for my team
I define technical solutions or efficient operational processes that level up my team
I am a strong leader for my team with my impact beginning to extend outside my team
Technical Strategy | Project Leadership | Product Expertise | Mentorship
А чтобы управлять командой - нужны рычаги влияния. Но там нигде не написано, что senior может увольнять.
И еще не понятно - когда все это успевать. Пока ты бухаешь с начальством за понимание стратегических целей компании, составляешь и контролируешь планы для команды, собеседуешь людей, оптимизируешь процессы - теряешь техническую экспертизу для соответствия разделу Craft.
Пожалуй есть один выход - это когда работаешь лет 10 в компании, успел много чего поделать и на полугодовом ассасменте говоришь такой "ну я вон 5 лет назад делал вот эту хрень из уровня IC4-5-6, так что я достоин". Не уверен правда - сработает это или нет. Ведь один раз за 5 лет - это далеко от экспертизы.
Миддл получает больше сеньора: к чему приводит хаос с грейдами в IT