Собрали комментарии специалистов из разных компаний и агентств. Это выжимка из третьего выпуска НЕОЧПОП про грейды. Кому нравится смотреть слушать, просим на Ютуб.
Все опрошенные либо сами были разработчиками и дошли до позиций СТО и СЕО, либо управляют ими.
Разработчики подразделяются на уровни — джуны, миддлы, синьоры. Эта градация не является точной, у неё нет границ и она основана на субъективном суждении о ряде факторов.
Например, опыт работы в количестве лет. Отталкиваться можно от того, что джун от двух лет опыта работы, миддл от двух до пяти, синьор – более пяти.
Важны также фундаментальные знания и навыки в области фреймворков, инструментарии.
Синьоры могут выступать в роли лидера или наставника, поддерживать команду.
Портфолио из проектов тоже важно. Важен уровень коммуникативности, особенно для синьоров, которые ведут работу с заказчиками.
Разные компании будут предъявлять разные стандарты для классификации, и это дело будет варьироваться от отрасли к отрасли.
Определение уровня разработчика идёт в ходе собеседования или во время оценки его профессиональных навыков и знаний.
У этой системы есть минусы, но она позволяет понять уровень специалистов как самим разработчикам, так и работодателям.
И позволяет двигаться по карьерной лестнице. Понятнее, куда идти, проще строить мотивацию и распределять задачи, ответственность в команде, легче проводить найм, проще вести коммуникацию и сотрудничество командами.
Джуны — это младшие, начинающие ребята. Младшие они не потому, что молодые или у них мало опыта, а потому, что уровень их самостоятельности достаточно низкий. И к ним часто снисходительно относятся более опытные коллеги. Девиз джунов: «Напишите, что нужно сделать, и я попробую».
Далее идут миддлы. Это костяк любой организации. Если хотите, рабочие лошадки. Девиз миддлов: «Поставьте мне задачу, и я её выполню».
Потом идут синьоры. Старшие они не потому, что старые, а потому что часто выполняют роль старшего брата, наставника для менее опытных коллег. Синьоры являются экспертами в своей специализации на уровне всей компании. Даже тимлиды не всегда являются синьорами в чём-то.
При это нередко получается так, что синьоры готовы оставаться на этой позиции до конца карьеры, не желая рост за исключением материального. Девиз синьоров: «Покажите мне проблему, и я её решу».
Зачем вообще вся эта градация? На мой взгляд, это хороший инструмент управления, при котором компаниям может объяснить сотрудникам, почему один разработчик зарабатывает больше другого.
И в то же время это хороший инструмент, чтобы пощекотать эго разработчиков, показав им, что их титул достаточно высок в IT-тусовке.
Джун — это разработчик, который только-только начал работать. Он не сможет нормально развернуть архитектуру проекта, путает базовые вещи, даже в том SDK, в котором он работает.
Джун минус – вчерашний стажёр или студент. Он что-то писал, где-то что-то ковырял, но пока может создать только несложный UI или по образу и подобию прокинуть какие-то методы между классами, например. Это не даёт гарантии, что всё заработает.
Джун обыкновенный — один из самых самоуверенных видов. Он считает, что всё осознал, может написать сложную архитектуру с нуля, что он самый крутой разработчик на планете. Спасает от этого оплеуха или от старших товарищей, или от жизни. Как правило, в 99% он берётся за ум и начинает читать документацию. Как правило, это перспективные ребята.
Джун плюс — понял, что он джун после предыдущего подуровня.
Активно общается с коммьюнити, задаёт глупые вопросы, при проблемах пытается разобраться, спрашивает менторов. Начинает понимать важность документации, знаний в сети и пр.
Миддл — уверенный разработчик. Может проконсультировать, внедрить что-то новое.
Миддлы часто долго остаются в этом грейде, потому что знают, что всегда смогут найти работу, и спокойно работают, не парятся о чём-то глобальном. Им нравится просто программировать, не хочется расти до синьора, где нужно принимать много серьёзных, ответственных решений.
Синьор — прожжённый моряк. В своей области он, как рыба в воде. Поверхностно знает смежные области, что позволяет ему быть более гибкими и принимать достаточно серьёзные решения.
Если у него завышено ЧСВ, с ним будет невозможно общаться.
Если синьор крутой и без завышенного ЧСВ, он будет для всех добрым папой. Или мамой, что тоже бывает.
Я намеренно не говорю о навыках управления, потому что, например, не каждый синьор может быть ведущим. Он может быть Богом в своей области, но у него не будет навыков управления командой. У него могут быть плохие софтскиллы, он не будет понимать, как собрать и удерживать команду.
Подходим к самому интересному — зачем нужно это деление? Во-первых, вы сможете сохранить сотруднику зарплату на уровне рынка и не потеряете его.
Во-вторых, они помогают правильно собирать команду под конкретный проект, чтобы она была эффективной и оптимальной по финансам.
В-третьих, вы поддержите ЧСВ сотрудника. В этом нет ничего плохого, чувство собственной важности — это хорошо. Вы позволите ему не жить с синдромом самозванца, но при этом не позволите слишком сильно задирать нос.
В-четвёртых, вы можете с помощью матрицы компетенций, таблицы грейдирования, планировать индивидуальный план развития или индивидуальный рост каждого разработчика.
На мой взгляд, это достаточно синтетическая история. Основное различие в количестве ответственности, которое можно поручить человеку.
Джуниор — такой немножко котёночек, который подслеповатый, тыкается, не знает, куда идти, и ему сложно выполнять свои обязанности без гайденса.
Миддл — это самостоятельная единица, которой можно поручать сложные задачи.
Синьор – человек, которому гайденс уже не нужен и даже вреден. Он может сам гайдить и наставлять сотрудников.
Кому и зачем нужна эта градация? Мне кажется, чтобы умещать сотрудников в систему, рейты, внутренние процедуры. Функциональная зона между этими позициями достаточно сильно размыта и сильно зависит от компании.
Программисты — инженерно-производственная специальность. Аллегория с разрядами слесарей и сварщиков не подходит. Недостаточно сдать норматив и получить доступ к более сложным задачам.
Что важно знать? Специалист не может сам себе назначить грейд. Даже самый начальный грейд, джун, должен быть присвоен в процессе аттестации. Но единой системы аттестации для всей отрасли или отдельного направления не существует.
Отсюда вторая особенность: грейды у айтишников — очень сложная вещь. В нашей компании есть четыре грейда – джун, миддл, миддл+ и синьор. Тимлиды и техлиды в эту градацию не входят.
Случается так, что к нам приходит программист из другой компании, который был в статусе синьора, а по нашей градации он будет миддл, даже не миддл+.
Измерять грейд, исходя из количества лет опыта работы с определённым стеком, тоже неправильно. Но, как ни парадоксально, именно этот критерий наиболее показательный. Из нашей практики, переход из джуна в миддл происходит не менее, чем за три года. Стать синьором с опытом менее пяти лет практически нереально.
Ну не за выслугу же лет дают грейды? Нет. Есть индивидуальный план развития для тестировщиков, девопсов, программистов, а там аттестация и переаттестация.
Джуниору достаточно уметь хорошо выполнять типовые задачи в рамках его рабочей технологии, которые ему назначают. За их качеством наблюдает более опытный специалист в команде.
Миддл имеет большую свободу в принятии решений. За качеством его кода уже не так пристально наблюдают, и ему всё ещё не зазорно обратиться к старшим коллегам за помощью со сложными задачами.
Миддл+ хорошо знает не только свою базовую технологию или основной фреймворк, но и смежные технологии, библиотеки, фреймворки, имеет хороший кругозор, знает в теории и умеет применять на практике паттерны, лучшие практики. Чаще всего именно миддл и миддл+ помогают джунам стать более опытными специалистами.
Синьор – эволюционировавшая версия миддл+. Он отлично знает фреймворки, имеет большой опыт работы со сложными задачами с самостоятельными решениями. У него развито системное мышление, он может выстроить архитектуру приложения, сервиса. Может помочь определить задачи, также как менеджеры декомпозируют задачи, можно самому оценить риски и выбрать стек для проекта.
Обычно грейды кроме направления для отработки практических навыков обозначают зоны роста софтскиллов — навык аргументации, способность к планированию, лидерские качества.
Зачем всё это надо? Для программистов сейчас будет обидно, приготовьтесь. Программист для менеджера – это ресурс. Вы можете отлично общаться, играть в настолки, ходить и пить крафт, но на проекте программист – ресурс, который позволяет реализовать проект и желательно в срок.
Грейды нужны как минимум для того, чтобы, исходя из задач, оценить объём и сформировать команду. Например, для сборки лендинга оверкилл привлекать синьора. Это невыгодно. Отдавать миддлу серьёзную задачу — это риск провалить весь проект в дальнейшем.
Второе: это важно для самого сотрудника. Грейды позволяют программисту понять карьерный рост. Он знает, что будет на следующем уровне, и может ориентироваться в том, что ему подтянуть, чтобы самосовершенствоваться.
Во многих компаниях грейды связаны с заработной платой. Это не общая практика и не правило.
Если обобщить, грейды нужны как самой компании, так и программистам. Деление на джунов, миддлов и синьоров – вещь условная. Она меняется от компании к компании, зависит от многих факторов, стеков, времени и кучи всего. Но лучше способа у нас нет.
Грейды – бесполезная штука, необходимая абсолютно всем.
Руководству нужно понимать, какую зарплату ты платишь сотруднику сейчас, какую будешь платить через год, пять и так далее.
Сотруднику нужно понимать, куда ему расти в скиллах, деньгах, как это положить в сроки.
Грейды внутри компании определяют путь сотрудника и его развитие, необходимое для этой компании, а не сотруднику. Поэтому вся сила грейдов остаётся внутри компании и, как только выходит на рынок, разбивается о суровую реальность. У меня человек может быть джуном, а в другом месте он будет синьором, и наоборот.
Для меня грейды – мера моего доверия сотруднику. Джуну я дам задачу, буду ходить за ним по пятам, мидлу дам задачу и приду к нему в срок, синьору пишу, что я хочу по бизнесу.
На мой взгляд, это современная адаптация классических ремесленнических градаций – ученик, подмастерье и мастер.
Ученик — это джун. Он может делать задачи под присмотром, когда они хорошо описаны. По шагам, сделай тут и не делай тут, сделай вот так и не делай вот так.
Подмастерье — это миддл. Может делать задачи с более верхнеуровневым описанием. Он понимает, что и как нужно делать и как не нужно.
Синьор может придумывать как нужно и как не нужно делать, рассказывать другим.
Зачем это нужно рынку? Это нужно работодателю, менеджер и самим сотрудникам как система координат.
Сотруднику: я миди и стою столько-то. Работодателю: это миддл, он стоит столько-то и может делать такие-то задачи. Менеджеру: это миддл, он может делать такие задачи, а чтобы сделать что-то изобретательское нам нужен синьор.
Нанимающие менеджеры получают бюджеты на джунов, миддлов, синьоров и могут делать офферы, руководствуясь системой.
Во-первых, стоит сказать, что официального, утверждённого и принятого всеми разграничения между ними не существует.
Можно сказать, что джуниор обладает в основном теоретическими знаниями и скромным опытом по их применению. Человек, который очень мало участвовал в коммерческих проектах.
Джуну можно доверять простые задачи под надзором более опытных коллег. Нужно вкладываться в его обучение, чтобы он перешёл в следующий грейд.
Важная особенность: у джуна бесполезно спрашивать оценки задач, потому что всё, с чем он сталкивается, он видит в первый раз.
Миддл — более опытный сотрудник, который способен решать задачи средней сложности. Про задачи высокой сложности он скажет, что не знает, сколько их нужно выполнять, но задачи средней и простой сложности он оценивает достаточно точно.
Синьор — высший грейд. Человек, который уже мыслит архитектурно и способен работать над сложными задачами, вытаскивать проекты даже в одиночку.
Зачем эта классификация вообще нужна, если нет общего стандарта? В первую очередь, в IT её используют при найме. Она позволяет сделать грубое деление кандидатов. Мы понимаем, что нам нужен человек, который обладает очень высокими способностями, большим опытом, и говорим эйчару, что ищем синьора. Это отсекает большое количество резюме.
Внутри компании грейды применяются, чтобы компания и сотрудник понимали прогресс и профессиональное развитие. Естественно, от грейда зависит его компенсация.
Для начала скажу, что разработчик — профессия, где люди при помощи аналитического мышления решают алгоритмические задачи, используя приёмы, практики, инструменты для разработки.
Приведу пример на школьниках. Когда человек приходит в школу, ему дают азы аналитического мышления, говоря, что 2+2+2=6. Это джун. Его учат таким аналитическим задачам.
Следующий этап: школьнику дают инструмент – таблицу умножения. Теперь 2*3=6. Вот тебе инструмент, пользуйся им, и миддл им пользуется.
Синьор использует подобного рода инструменты уже неосознанно, и это уже мастерство.
А зачем вообще нужна такая градация? В первую очередь, она нужна для позиционирования специалистов. Какой опыт и какой уровень решения задач специалист может взять на себя, какие задачи он уже может решать, какие ему ещё рано.
Крайне прискорбно видеть ситуацию, когда синьоры решают задачи, которые может решить джуниор. Есть такое расхожее выражение — микроскопом орехи колоть. Это примерно про то же самое.
Кому и как она помогает? Во-первых, техническим архитекторам и руководителям проекта — для верного распределения потока задач.
И самим разработчикам. Джуниор понимает как ему прийти к миддлу, у него строится план развития теоретической и практической части. Ему это помогает определить вектор движения и развития.
В каждой компании своя внутренняя градация.
У нас бы я бы охарактеризовал её так: джуны — разработчики, за которыми должен быть прикреплён ментор, который проверяет весь их код и помогает развиваться, вырасти примерно до миддла.
Миддлы – самостоятельные разработчики, хорошие специалисты в своём базовом направлении, за которым не требуется постоянный контроль. На этом уровне специалист не боится взять новые языки, технологии, фреймворки и достаточно быстро может их освоить.
Синьор. В современном мире удалёнки ему важны софтскиллы, так как ему работать с джунами, выращивать из них миддлов. Естественно, любой синьор должен иметь немалый опыт в разных технологиях, чтобы правильно подбирать инструменты.
Кому эта градация нужна и для чего она полезна? Один из вариантов — менеджерам. Например, начинается проект. В ходе декомпозиции сроков становится понятно, что на проекте должно быть четыре бэкенд-разработчика. Логичнее всего в команду взять одного синьора, двух миддлов и одного джуна. Зачастую это будет самая сбалансированная команда.
Это не что иное, как табель о рангах.
Джун выполняет самую простую работу.
Миддлы уже занимаются больше самостоятельной работой, но всё ещё находятся под прицелом старших товарищей.
Синьоры больше задействованы в инновационной работе.
Это управление ожиданиями. От джуна мы ждём, что он знает основы языков программирования и базовые фреймворки, способен что-то написать.
От миддла мы ожидаем, что он может писать код, способен принимать самостоятельные решения, у него неплохо развитые хард и софтскиллы.
От синьора мы ожидаем самостоятельности в выборе фреймворка, способа решения задач и достижения цели. Как правило, синьоры отвечают за какой-то кусок своего продукта или за весь продукт целиком.
Эту градацию принесли эйчары, которым в какой-то момент времени нужно было найти специалистов под конкретные задачи.
С другой стороны, внутри компании деление на джунов, миддлов и синьоров служит компасом для того, чтобы сориентироваться, к кому из специалистов с какой задачей идти.
Грейд — это система классификации сотрудников. Он позволяет определить уровень софт и хардскиллов, а также показать точки роста сотрудника.
Сегодня всё чаще встречаются вариации грейдов: мидл+, джуниор+, мидл-. Эти границы условные, потому что синьор в одной компании может едва дотягивать до миддла в другой.
Джуниор занимается задачами под присмотром старших. Можно сказать, что это не самостоятельная боевая единица.
Миддл уже делает задачи самостоятельно, может иметь в подчинении юного падавана, но всё равно за ним присматривают более опытные разработчики.
Синьор — полностью самостоятельная боевая единица. Он занимается сложными, высокоуровневыми задачами.
Зачем нужен грейд? Он помогает чётче определить требования к должности, даёт прозрачный критерий для зарплаты и бонусов и позволяет установить прозрачный процесс повышения.
Синьор, мидл и джун — это совокупность хард и софтскиллов. В каждой компании мера определения этих показателей будет разная.
Для меня джун — человек, который только вошёл в IT или ему не хватает времени на самообучение, либо это студент. Ему точно нужно подтягивать матчасть. За его действиями нужно следить. Он должен больше слушать, чем говорить.
Миддл — это такой крепыш, который научился писать код и теперь задумывается, как его работа влияет на конечных пользователей. Ему можно доверять джунов. В команде он имеет большой вес, может влиять на процессы внутри проекты.
Синьор — сын маминой подруги. Человек, который может сходу погрузиться в задачу и, возможно, даже решить её или предложить решения.
Его багаж знаний и опыт коммерческой разработки позволяет быстро находить узкие места не по багрепортам, а при чтении самой задачи.
Ему можно доверять наставничество миддлов, он им помогает развиваться.
Он может влиять на процессы не только внутри проекта, но и вне его, и вне своего отдела.
Кому полезно это разбиение? Разработчикам — чтобы они понимали свои скиллы внутри компании. Менеджерам — чтобы понимать, с кем они работают и как нужно работать с разработчиками, нужно ли досконально объяснять каждую задачу или достаточно кинуть ТЗ в Фирме. И компании, чтобы она определяла стратегию найма сотрудников.
Выводы
А их не будет, потому что для них слишком мало мнений.
Вместо выводов выделим, что общего прослеживается в комментариях:
мера доверия,
понимание проблемы,
способность решать задачи самостоятельно и на разных уровнях,
опыт,
навыки,
ориентир для наёма,
ориентир для зарплаты,
план и ориентир роста,
критерии для формирования команды проекта.
Добавите что-нибудь?
Чтобы не пропускать наши новые статьи, подписывайте на наш Телеграм-канал.
