Системы грейдов есть в разных отраслях: взять хоть тех же сварщиков с их разрядами или даже каратистов с поясами. Кто-то однажды придумал, что есть разработчики уровней junior, middle и senior.
Но градация субъективна: известны случаи, когда человек сидел над одним проектом и был его почтенным сеньором, а потом мог устроиться в более технологичную компанию и стать там джуном.
Так давайте же разберемся:
- зачем тогда разработчикам в компаниях присваивают грейды;
- какие грейды есть;
- как выстроить систему грейдов для разработчиков у себя: подскажем ряд советов.
Но для начала расскажем о себе. Neogenda – это консалтинговая компания. Мы помогаем компаниям освоить современные подходы и методы менеджмента. Наши клиенты – это Сбер, МТС, Тинькофф, Билайн, Raiffeisen Bank, Магнит, Яндекс, Авито, Азбука Вкуса и другие компании, которые вам скорее всего тоже известны. На нашем счету более 100 управленческих кейсов, 5 000 учеников и 40 лет практики. Если вы считаете, что ваш бизнес может стать прибыльнее за счет грамотного внедрения современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.
Пика-Пика!
Зачем разработчикам в компаниях присваивают грейды
- Чтобы оценить стоимость работы сотрудника. От грейда может зависеть месячный оклад или стоимость часа работы программиста. Зная грейд, вы сможете платить сотруднику достойно, не тратя слишком много средств или не демотивируя сотрудника маленькой оплатой.
- Чтобы удерживать сотрудников. Как правило, системы грейдов внедряют в крупные компании, где будут десятки, а то и сотни разработчиков. Если компания растет, штат нужно расширять: через годы позиции старших сотрудников часто занимают бывшие джуны. Система грейдов дает четкое понимание сотрудникам, что они могут в компании идти дальше по карьерной лестнице. Это помогает удержать сотрудников, потому что найти хороших разработчиков не так-то просто. А оперативно найти замену разработчику, который покидает рабочее место и оставляет горящий проект, еще сложнее.
- Чтобы формировать эффективные проектные группы. Если к системе грейдов привязан тест, который позволяет оценить навыки разработчика, управленцы в компании могут объективнее оценить свой кадровый состав. С этим они могут эффективнее собирать группы под конкретные проекты. Такие команды обаладают всеми нужными навыками и укладываются в проектные рамки, потому что там нет чересчур опытных специалистов с избыточными знаниями, которые стоят дорого.
Какие грейды есть
В разных компаниях свои требования к разработчикам: они могут отличаться от задач, технологического стека и так далее. То есть, если мы сравним двух мидлов из разных компаний, у них могут быть совершенно разные навыки.
Нередко специалистов ранжируют по количеству отработанных лет: мол, джун – это 1-3 года работы, мидл – 3-5 лет и так далее. Это неправильно: есть люди без амбиций, которые стоят на месте и решают задачи с одинаковым уровнем сложности и ответственности на протяжении нескольких лет. Такие специалисты могут остаться вечными мидлами, а то и джунами, если они не стремятся к развитию.
Но все же можно выделить наиболее характерные черты, присущие джунам, мидлам и сеньорам из разных компаний. Разберем их подробнее, а еще расскажем о дополнительных грейдах и должностях разработчиков, которые могут вам встретиться.
Junior
Чем-то похожи, да?
Джуны (Junior-разработчики) – это специалисты с небольшим практическим опытом, которые могут выполнять только несложные задачи. Например, написать какой-то небольшой участок кода.
Джуны всегда получают задачи от более опытных сотрудников и чаще всего за джунами эти задачи проверяют, потому что они с большой вероятностью могут ошибиться.
Если говорить о кодинге, то у джунов часто получается тяжелый синтаксис кода, потому что они еще не умеют элегантно решать поставленные задачи. Если джун совсем неопытный, его лучше «помикроменеджерить»: ставить больше контрольных точек для проверки задач и направлять в нужное русло. Джун не умеет мыслить в рамках системы, поэтому нужно помочь ему сделать так, чтобы его работа встала нужным элементом в общую мозаику.
По большей части, джуны – это инвестиции в компанию. На них приходится тратить время старшим сотрудникам, а еще джуны будут медленнее справляться с задачами, нежели более опытные разработчики. С другой стороны, мидлы могут быть сами по уши в задачах и декомпозиция задач на джунов – меньшее зло. Чтобы джуны отрабатывали эффективнее, к каждому из них лучше приставить ментора – так они будут быстрее обучаться и брать все на себя более сложные задачи.
Есть и большое преимущество джунов: они становятся очень лояльными к организации, если их обучают, а еще если им обеспечивают достойные условия и сулят карьерный рост. Порой компании проще вырастить джуна «под себя», нежели искать специалиста со стороны, который всегда может «свинтить» из-за оффера послаще.
Главные качества, которые должны быть у джуна – большой интерес к работе и высокая обучаемость. Ну, и разумеется, развитые софт-скиллы – без чужой помощи он вряд-ли задержится на рабочем месте. Если это все есть, после пары лет упорной работы он сможет стать уверенным мидлом в своей компании. Для этого ему нужно пару раз пройти полный цикл разработки, чтобы наступить на всевозможные «грабли», которые учтет мидл с более богатым практическим опытом.
👉 Читайте также: «Управление командой проекта»
Middle
Именно мидлы зачастую проверяют и менторят неопытных джунов
Мидлы (Middle-разработчики) – это специалисты среднего уровня, которые могут брать на себя достаточно сложные задачи. Если за джунами нужно приглядывать, мидлы способны сами себя организовывать и доводить задачу до нужного результата. Они хорошо разбираются в технологиях своего стека и пишут более качественный код. Также специалисту такого уровня под силу изучить какие-то новые технологии, если это нужно для выполнения проекта.
Разработчик уровня Middle способен находить разные способы решения задач. Поэтому подробные ТЗ могут даже навредить эффективности выполнения задачи. Другое дело, что мидл скорее всего не сможет предложить лучшее архитектурное решение для выполнения проекта.
Зачастую хорошие разработчики так и остаются мидлами, потому что они не хотят брать на себя ответственность за стратегические решения. А те, кто не боятся – становятся сеньорами.
Senior
Хм, а может быть граф?
Сеньор (Senior-разработчик) – это специалисты высокого уровня, которые могут решить любую задачу, если та касается их профессиональных навыков. Но кодинг – это то, чем старшие специалисты занимаются меньше всего.
Сеньоры руководят процессом: помогают разрабатывать требования, проектируют архитектуру ПО, участвуют в переговорах с заказчиком, помогают рассчитать бюджетные и временные рамки и так далее. И при необходимости такой спец мог бы в одиночку разработать проект с нуля, но у него есть дела поважнее.
Если сеньор вдруг добирается до среды разработки, начинается магия: из под клавиш вылетает простой и легко читаемый код. Легкий синтаксис сеньора – полная противоположность коду джуна-зазнайки, который чему-то научился и думает, что теперь знает все, выдавая высокоуровневые абстракции. Опытный разработчик знает, что код нужно писать для других людей, чтобы его удобно было обслуживать и масштабировать.
Новички думают, что сеньоры – это такие крутые хакеры, которые используют самые современные инструменты, работая исключительно над интересными проектами. Но реальность чаще противоположна – сеньоры поддерживают легаси-код больших и сложных сервисов, существующих не один год. Делая это просто потому, что никто на это больше не способен. При этом синьоры все равно держат руку на пульсе – технологии и практики находятся в постоянном развитии, и если не быть в теме, можно через пару лет обнаружить себя в мидлах.
Но софт-скиллы куда важнее для сеньора, нежели хард-скиллы. Ведь большая часть работы старших специалистов состоит не из кодинга, а из составления требований к работе над ПО, переговоров и менторинга. Самое главное качество сеньора – способность чувствовать себя комфортно в среде с высокой неопределенностью. В отличие от мидла, сеньор не боится рисковать и способен брать на себя большую ответственность.
С сеньорами прояснили, теперь поговорим о фантастических грейдах, которые где-то, да обитают: Junior+, Middle- и так далее.
👉 Читайте также: «Управление бэклогом продукта: методы, инструменты и советы»
Промежуточные грейды
В больших компаниях могут встречаться промежуточные грейды, которые помогают еще детальнее структурировать кадровый состав. Бывает даже, что в компаниях могут быть джуны, мидлы и сеньоры разных рангов: наверное, так делают дотошные кадровики, которые любили играть в RPG. Например, можно встретить какого-нибудь Junior+++, но это уже дебри.
Безумие
Вот наиболее популярные из промежуточных грейдов:
- Junior+ – обычно это джуны, которые не нуждаются в микроменеджменте и способны самостоятельно закрывать небольше задачи.
- Middle- – этот грейд обычно используют для того, чтобы мотивировать джунов развиваться и стать наконец мидлом, хоть и авансом. Такие спецы уже лучше разбираются в технологиях, нежели джуны с плюсом и могут решать еще более сложные задачи.
А теперь разберем должности разработчиков, которые часто путают с грейдами, хотя это просто отдельные рабочие направления. Отметим, что такие должности чаще всего занимают синьоры – у менее квалифицированных исполнителей для этого недостаточно опыта.
Какие должности часто путают с грейдами
Тимлид – это руководитель команды разработчиков. Обычный синьор тоже может менторить и делегировать задачи, но тимлид куда больше вовлечен в управление разработчиками, а также их поддержку и наставничество.
Техлид – это разработчик, который задает требования к ПО. Он не управляет командой, но занимается составлением технической документации, по которой потом будут работать специалисты меньшего ранга.
И напоследок перейдем к прикладной части: поделимся советами, которые помогут выстроить эффективную систему грейдов в вашей компании.
👉 Читайте также: «User story mapping: зачем нужны пользовательские истории и как их правильно писать»
Как выстроить систему грейдов у себя: советы
Разработчики не могут сами себе назначить грейд мидла или синьора – это будет необъективно. Поэтому о создании системы грейдов заботятся кадровики компании, руководители или наиболее опытные специалисты.
Подготовили короткие советы, которые помогут вам не наступить на грабли других компаний:
- Чтобы оценить грейд ваших специалистов, нужно разработать большой тест с перечнем открытых вопросов. В тест должны входить вопросы как о софт-, так и о хард-скиллах, потому что «мягкие» навыки не менее важны для работы, нежели уровень владения технологиями. Вопросы должны быть открытыми, потому что тесты с вариантами ответов не позволят вам «докопаться» до разработчика, чтобы оценить его реальный уровень понимания того или иного рабочего аспекта. Вопросы должны соотноситься с практическими задачами разработчика: скажем, если он программирует на C#, то и вопросы должны быть по этому языку.
- Нужно интервьюировать сотрудников. Если оставить им решать тест на дому, то они с большей вероятностью спишут правильные ответы. Опрашивать специалистов должна экспертная группа, которая сможет точно определить уровень разработчиков.
- Систему оценивания нужно тестировать. С большей вероятностью, в первый раз вы создадите тест, который нужно будет переделывать. Например, вы забудете добавить в тест вопросы о познании какого-нибудь ООП или сделаете оценочную шкалу, по которой будет трудно выставлять объективные оценки сотрудникам.
- Результаты тестов лучше обнародовать. Если сотрудник знает, в чем он разбирается хорошо, а в чем плавает, он будет знать, какие навыки ему нужно подтянуть. Поскольку прохождение теста будет влиять на грейд сотрудника, оно будет влиять и на зарплату – у разработчиков будет мотивация развивать свои навыки.
- Нужно делать регулярную переоценку. Поскольку специалисты со временем будут обрастать опытом, оценивать их навыки нужно в динамике, чтобы давать более высокий грейд спецам, которые этого заслуживают. Оптимально – проводить тест раз в полгода. Более того, данные в динамике позволят вам выделить сотрудников, которые растут быстрее остальных – таких лучше держать поближе.
- К результатам тестов нужны отдельные дополнения. Есть рабочие аспекты, которые тяжело учесть в тесте: например, один разработчик может спасать горящие проекты, а другой умеет хорошо менторить. Эти данные лучше занести в «досье» сотрудника и иметь их в виду.
Надеемся, что статья поможет вам определить, кто есть кто в вашей организации. Если вашему бизнесу необходимы организационные перемены, обращайтесь в Neogenda за бесплатной консультацией. Мы являемся экспертами во внедрении современных управленческих практик: руководим процессом, учим и консультируем.
