О грейдах в IT

– Как у вас там называются эти, ну как их... крутые, в общем... Милорд или типа того, да?
– Бэклог пустеет, милорд!

Или почему у двоих программистов в одной и той же компании на одном и том же проекте зарплата может отличаться раза в полтора.
Айтишники, конечно, всё это лучше меня распишут, но я так, для человека, особо не шарящего в ступенях карьеры разработчика ПО (или, как говорят любители английского, грейдах), расскажу. Как сумею и насколько шарю. Пока обедаю, ага. В каждом пункте могу ошибаться, писать имею право.
Итак, самая низшая ступень в карьере разработчика – это... не, деца, сбъркахте... в ряде компаний даже не джун. Самая низшая ступень – это стажёр. В компаниях, где любят англоязычные грейды, это ещё называют трейни. Стажёр – ну, он и есть стажёр, что рассказывать. Это как интерны в одноимённом сериале. «То, что написано у вас в дипломах – это ложь. Вы ни черта не знаете. И да... добро пожаловать!» Стажёр фактически в основном занимается тем, что разбирается в текущем техпроцессе и выполняет самые подай-принесишные задачи, типа "надпись на кнопочке поменять". Руководитель проекта к нему приглядывается. Стажёр – это ступень проходная, на ней долго не задерживаются. От месяца до полугода можно рассчитывать на этот грейд, потом либо перешёл выше, либо вылетел с вихором. Уровень зарплат стажёра – чтоб с голоду не подох. Даже в Москве полно компаний, берущих стажёров на зарплатный уровень условного кассира в Пятёрочке. Однако, смущать это не должно – помните, что это ступень проходная, дальше или уволитесь и забудете, или успешно перейдёте на нормальную позицию.
Следующая ступень – или первая из более или менее постоянных – это джуниор, или, разговорно, джун (не путать с Джуной и со Ждуном). Это именно та ступень, на которой с кожаным могут успешно конкурировать всякие копилоты, гпт и прочие ИИ. Джуниор – это молодой специалист. Ему можно поручать несложные задачи, а результат его работы крайне желательно ревьюить. Польза джуна для самого джуна – набить стаж и приобрести навыки. Польза джуна для компании – дешёвые задачи делать за дешёвые человеко-часы. Зачем отвлекать человека, час работы которого стоит, условно говоря, два штукаря до вычета налогов, на то, чтобы выполнить простенькую задачу, если это за то же время и с тем же качеством (потому что ниже-то некуда) может сделать вдвое более дешёвый специалист? Долго сидеть в джунах можно, но ненормально (потому как это означает, что обучаемость плохая) и опасно (потому что рано или поздно нишу займёт какой-нибудь очередной кремниевый копилот). Но начинающему по любому год, а то и два-три, в джунах поторчать придётся. Зарплатный уровень – если по Москве, то это 100-120к, в зависимости от стека технологий, от крутизны компании и т.д. Есть, разумеется, статистические хвосты в обе стороны – видел вакансии и на 75к, и на 150к.
Следующая, уже более или менее постоянная ступень – это миддл, или, разговорно, мид (не тот, по которому раки ползают). Это человек, который знает свою работу, знает используемые технологии с практической точки зрения, легко может врюхнуться в новые, а главное, может уверенно и без подсказок выполнять свою работу, не отвлекая ресурсы более дорогих специалистов на своё дообучение. В принципе, на уровне мида можно оставаться и до пенсии, если нет желания расти выше – это уже крепкий ремесленник, тот, кто, пока айти в принципе существует, без куска хлеба не останется. Мид понимает цену каждого решения, мид не «изобретает велосипедов» и не «варит спагетти». Это, можно сказать, рабочее мясо. Вместе с тем, если на фирме есть хотя бы сеньоры, то за решениями, влияющими на жизнь проекта в целом, лучше обращаться к ним, а мидам оставить реализацию придуманного сеньорами. Мид не обязан уметь переводить с человеческого языка на технический, но мид обязан понимать задачу, поставленную на техническом языке. Зарплатный уровень по Москве – 180-220к, но статистические хвосты очень длинные, могут и джунские 120к предложить, а могут и фактически сеньорные 300к, особенно, если стек технологий дорогой (по рыночной цене конечного продукта) и редкий (по количеству хороших специалистов).
Милорды... простите, сеньоры – это... нет, не верхний уровень, но верхний из классической меметизированной триады джун-мид-сеньор. Сеньор обязательно (в отличие от мида) не только знает используемые технологии с практической точки зрения, но и отлично разбирается в том, как и почему они работают, и когда и почему они не работают. Сеньор может (и обязан) принимать решения, чувствительные для проекта в целом. Сеньор – это уже не просто крепкий ремесленник, как мид. Сеньор – это гуру. Сеньор, получив от бизнес-аналитика (или, за его отсутствием, непосредственно от заказчика) задачу из серии «короче сделайте нам зашибись» может её перевести на язык технических требований и, что важно, может её декомпозировать на отдельные задачи, каждой из которых может заняться мид (один или разные – это уж как повезёт). Зарплатный уровень по Москве – 250-350к, в зависимости от. Статистические хвосты – ну, я и за полулимоном видел предложения с частотой, отличной от выброса.
Вместе с тем, сеньор – это тоже рабочее мясо. Самое крутое, мраморное даже, но всё же рабочее мясо.
Однако именно от позиции сеньора, можно сказать, в карьеру прилетает путевой камень. А на нём написано... и накакано... и наблё... кгхм... простите. А на камне этом, значит, написано: налево пойдёшь – свою фирму создашь, направо пойдёшь – в менеджмент уйдёшь, прямо пойдёшь – в разработке останешься.
То есть, позиция сеньора – это точка, на которой можно ещё раз взглянуть на себя и решить, чего больше хочется – расти в административном плане и уходить в руководство, или расти в техническом плане и уходить в штучные специалисты. Ситуацию «ушёл налево» рассматривать не будем.
Рассмотрим сначала административную ветку карьеры. Тогда следующая ступень за сеньором – это тимлид. Фактически, это тот же сеньор, но на которого повесили бригадирство. Тимлид меньше занимается кодом (а когда занимается, больше занимается ревьюингом кода подчинённых), и больше занимается подбором команды, раздачей задач, выгоном эффективности и т.д. Это, грубо говоря, технический директор, но не по фирме в целом, а по конкретному проекту (или по нескольким проектам – бывает, что крупная компания ведёт больше проектов, чем имеется тимлидов).
Дальше по административной лесенке идёт менеджер проекта. Тут ещё меньше кода (фактически, в норме его на этом уровне вообще нет), и больше беготни и согласований. Если тимлид – это технический директор проекта, то менеджер проекта – это его генеральный директор. Тимлид больше про взаимодействие целей проекта с командой разработчиков, а проджект менеджер – про взаимодействие заказчиков (или покупателей, если продукт боксовый) с целями проекта.
Наконец, завершает (ну как завершает... дальше уже топ-менеджмент идёт) административную лесенку продакт оунер, буквально «владелец продукта». Это тот, кто персонифицирует собой проект вообще. То есть, если, например, команда сорвала сроки, и заказчик кому-то порвёт сраку, то этот кто-то – продакт оунер. Продакт оунер решает, что мы вообще делаем, зачем и почём.
Теперь техническая ветка карьеры. Там после сеньора идёт техлид. Техлид – это, условно говоря, ведущий инженер. Техлид принимает решение о стеке технологий, берёт на себя ответственность и задачи по выстраиванию рабочих процессов (разработка, контроль качества, передача в прод и т.д.). За ним последнее слово в принятии технически сложных решений, в разработке требований к навыкам команды и т.д. То есть, если мид запиливает фичу, а сеньор знает, как эту фичу запилить, то техлид знает, чем и как пилить фичу, чтобы это было максимально эффективно. Грубо говоря, чтобы система была в M раз надёжнее, в N раз быстрее и в K раз дешевле по себестоимости. Техлид должен не просто думать, а ещё и думать о том, как он думает. Техническое благополучие проекта – это к нему.
И вершина технической карьеры, истинно штучный специалист – это архитектор базовой архитектуры. Для простеньких (в смысле архитектуры) чисто десктопных однопользовательских приложений он, может быть, не столь важен, а для современных масштабных интернет-решений с сотнями и тысячами пользователей и огромным количеством запросов в секунду человек с такими навыками необходим. Это человек, который, вероятно, в сеньорах пробыл лет десять и более. Он досконально знает все используемые технологии, и множество технологий, которые могут быть использованы в будущем, знает их слабые места и бутылочные горлышки, возможности и ограничения каждого из используемых сторонних продуктов (никто не будет для каждого продукта писать с нуля операционку, апп-сервер или СУБД, так что сторонние продукты по любому будут). Это человек, который точно понимает, какой стек технологий подойдёт данному конкретному продукту, чтоб не пришлось потом переделывать фактически насквозь. Он примет, например, решение о том, делать в такой-то ситуации монолит или микросервисы, в случае юридически значимого документооборота какие механизмы обеспечения юридической значимости использовать, СУБД какой архитектуры использовать, и т.д., и т.п.