Мы собрали требования к грейдам разработчиков и базу учебных материалов: вот что получилось
Если вы читаете эту статью, то, скорее всего, вы — разработчик, тимлид, HR или руководитель компании, который думает, как нанять специалистов необходимого уровня.
Объявления о вакансиях пестрят требованиями: «талантливый и обучаемый Junior», «крепкий Middle» или «уверенный Senior».
Правда, когда дело доходит до собеседований, то часто выясняется, что заявленное отличается от реального. Причем, в обе стороны. Поэтому возникает логичный вопрос: как соискателю оценить свой реальный уровень, а работодателю — правильно составить требования?
Для меня, как владельца диджитал-продакшна из Самары, эта проблема выглядела так. Нанимаемые разработчики довольно быстро уходили в другие компании, потому что у нас их рост был ограничен отсутствием программы развития. И напротив: всякий раз, когда нам требовалось масштабировать команду на более сложный проект, приходилось искать сотрудников с более высокими компетенциями, а не растить их внутри. Поняв, что это, по сути, проблемы одного порядка, мы решили внедрить систему грейдов. Оставалось решить, какие из множества технологий действительно важны как базовые знания, что может понадобится в процессе усложнения проектов, и как вообще ориентироваться в куче разнообразных требований у разных компаний и клиентов.
Ниже моя история о том, с чего мы начали сбор информаци и во что все это вылилось в итоге. Заодно мы поговорили с экспертами рынка веб- и мобильной разработки про их подход к системе грейдирования и возможности создания универсальной базы знаний.
С чего мы начали
Мы не стали изобретать новую систему оценки и взяли привычную трехуровневую: junior, middle, senior. Первым делом выделили актуальные для наших задач технологии и собрали обучающие материалы по ним. Так, например, для самого первого уровня для нас были важны знания о фундаментальных вещах: сomputer science, алгоритмы, навыки слепой печати и комментирования кода. В свою очередь, специалист мог бы соответствовать верхнему грейду только при наличии опыта в более узких областях: например, работа с протоколами или утечками памяти, с которыми редко сталкиваешься без практики.
Далее вместе с тимлидами установили индивидуальные квартальные планы развития для разработчиков с понятным и измеримым результатом. Стимулы, как и санкции, — тоже были прописаны.
Таким образом, система грейдов в какой-то мере решала проблему роста сотрудников и их оценки. Но вопрос о том, как искать именно тех, кто нам нужен, оставался открытым. Ведь в каждом продакшене — свои правила:
Мы постоянно сталкиваемся с проблемой разночтений касаемо уровней специалистов, особенно когда нет четких требований к кандидату. Например, клиент просит нас выделить синьор-разработчика. В процессе оказывается, что под эти задачи нужен был миддл, да еще и дешевле. В итоге заказчик берет разработчика в другой компании, потому что у конкурента синьор равен по уровню нашему миддлу, с соответствующей себестоимостью. Или наоборот, когда технические специалисты на стороне клиента всех меряют по себе.
Некий общий стандарт для оценки уровней с общепризнанными наборами компетенций помог бы нам разговаривать на одном языке.
Андрей Рыжкин
CTO в AGIMA
Поэтому мы решили изучить опыт других агентств и попытаться создать общую базу требований к разработчикам, основанную на коллективном опыте.
Откуда мы взяли данные
Мы поговорили не только с веб- и мобильными продакшенами, такими как AGIMA, Сибирикс, Mediasoft, Redmadrobot, Mad Brains, Firecode и Dex, но и с дизайн-студиями Everest и Pinkman. И, разумеется, искали информацию от крупных IT-компаний в открытых источниках.
Наш главный вопрос звучал так:
Какой стек технологий необходим для получения разработчиком того или иного грейда по конкретной специализации?
Как это работает
Итак, мы собрали базу требований и знаний для развития IT-шников по классическим грейдам. Мы не только определили, что, например, для уровня Middle-фронтендера в большинстве компаний нужны хотя бы знания JavaScript и Angular, а Senior должен уметь программировать на Linux и использовать React Native, но и собрали массу полезных ссылок и обучающих материалов по технологиям: статьи, видеоуроки, официальную документацию, учебники.
Можно не только получить новые знания, но и отметить для себя освоенные навыки. Это пригодится, например, при составлении резюме или просто для самопроверки.
Все данные мы разместили в открытом доступе, а новая информация появляется через простые пулл-реквесты на GitHub. Это opensource-база, которая может наполняться всеми, кто хочет поделиться знаниями: разработчиками, тимлидами, CTO.
Это хороший заход на структурирование информации, которой настолько много, что разобраться в ней тяжело даже опытным специалистам. Это можно и нужно делать коллективно, и это точно пойдет всем на пользу.
Макс Десятых
Партнер в Redmadrobot
Что можно улучшить
Есть, правда, и альтернативные мнения:
Мы не используем грейды у себя в компании. Нельзя сказать, что грейдирование совсем не имеет смысла. Оно вполне подойдет компании, которая развивает собственный IT-продукт силами внутренней команды. Но если говорить о заказной разработке, где команда работает над сторонними продуктами и имеет дело с большим стеком технологий, то ей нельзя ориентироваться на абстрактные звания и жестко фиксированный пул навыков.
Сергей Полуэктов
CЕО в MediaSoft
С нашей стороны было бы самонадеянно считать, что мы изобрели нечто, что сразу перевернет рынок IT. Говорить о стандартизации требований в сфере, где практически не найти двух одинаковых компаний, пока не приходится. К тому же, для себя мы выделяем несколько проблем, которые только предстоит решить:
чем быстрее растет список требований, тем страшнее он выглядит. Очевидно, что для получения грейдов необязательно знать весь указанный стэк. Поэтому мы думаем о том, как помочь с выбором именного того, что нужно;
тому, кто хочет проверить свой уровень или прокачаться под конкретного работодателя, необходимо понимать, какие требования пригодятся, а какие нет. Пока что все требования обезличены;
если стать джуниором на одних знаниях технологий еще теоретически возможно, то расти дальше без навыков командной работы, коммуникации, аналитического и стратегического мышления будет трудно. Как учитывать софт-скиллы в грейдах — еще только предстоит придумать.
Идея общего каркаса для оценки грейдов выглядит классно. Но как бы технически не был “прокачан” человек, я никогда не смогу его отнести к миддлу или синьору, если его софт-скиллы (дисциплина, ответственность, лидерские компетенции и т.п.) стремятся к нулю.
Гульназ Ахметшина
CEO в Cerebro
И, конечно, изучением одной лишь базы знаний не обойтись:
Никакая система не заменит джуниорам наставников-кураторов, которые обучают и развивают специалиста не только исходя из плана развития, но и из его индивидуальных особенностей.
Александр Богданов
CEO в AGIMA
Тем не менее, работодателям база данных может быть полезна даже в виде MVP. Ведь они имеют на руках список компетенций, составленный профессионалами. HR-специалисту остается лишь показать его своему CTO и попросить выбрать именно те технологии, которые актуальны для задач компании.
Какие есть альтернативы
Мы далеко не единственная и уж точно не первая компания, которая использует систему грейдов и собирает базу знаний для их получения. Большинство коллег, с которыми мы общались, в той или иной степени создали ее “под себя”.
В этом году мы обновили свои карты компетенций дизайнеров, программистов и руководителей проектов (прошлогодняя — здесь). Что важно знать при их внедрении:
1. Обновлять раз в год, а раз в полгода — вносить корректировки.
2. Заполнять их приватно, чтобы не превращать в соревнование.
3. Адаптировать под бизнес-задачи компании.
4. Использовать их лишь как повод к общению с сотрудником для его дальнейшей прокачки.
Владимир Завертайлов
CEO в Сибирикс
Однако, если вы не компания, а разработчик, то узнать о требованиях и оценить свой уровень применительно к потенциальному работодателю — непросто. Конечно, в интернете можно найти массу предложений по прохождению сертификации. Нельзя сказать, что они плохи, но вопросы вызывают критерии оценки.
В нашем случае база не только наполняется самими разработчиками, но и оказывается скорее образовательным проектом. Уже готовы несколько роадмапов, по которым можно прокачаться до минимально необходимого уровня. Альтернатив нашей базе (тем более бесплатных) мы пока не нашли.
Самое сложное в подобных инициативах — много лет подряд сохранять объективность взгляда, инвестировать в проект и терпеть негатив от компаний, которые всю жизнь хотели сделать что-то подобное, но «тормозили», а теперь будут критиковать вместо помощи.
В предложениях стандартизации главное то, что они заставляют задуматься и начать шевелиться игроков индустрии и смежных рынков, и провоцируют обширную дискуссию. Идея регламентировать грейды насчитывает два десятка лет, и пока что это не удалось ни государству, ни образовательным институтам, ни ассоциациям, ни конкретным игрокам рынка.
Могу только пожелать терпения.
Алексей Раменский
Главный редактор, управляющий партнер в Тэглайне
Как проект будет развиваться
Сейчас мы собрали материалы по Frontend-разработке и NodeJS. На подходе — требования для Java, PHP, Android и iOS-разработчиков;
Как было сказано выше, можно отметить уже имеющиеся навыки. Правда, пока что отметки хранятся только в кэше, но мы планируем запуск полноценного личного кабинета;
В перспективе будет реализована механика лайков/дизлайков за каждый навык. Так можно будет увидеть, какие знания обязательны, а какие можно отнести скорее к дополнительным;
Чтобы узнать требования конкретного работодателя, мы планируем ввести фильтр по компаниям;
Ну и, конечно, мы постараемся учесть софт-скилз. И тут мало сомнений, что разночтения между компаниями будут минимальными — от инициативного, общительного программиста с лидерскими качествами мало кто откажется.
Такой инструмент позволит разработчикам любого уровня формировать персональный план развития, отмечать белые зоны (явное незнание), понимать что надо прокачать для перехода в другую область. Но прежде чем это станет возможно, необходимо провести огромную подготовительную работу: собрать навыки, откалибровать их по грейдам, подобрать материал.
Евгений Пешков
Software Development Engineer в Dodo Pizza Engineering
Как я уже говорил, наш проект — это открытая база данных как в плане получения информации, так и наполнения ею. Это значит, что любой разработчик может внести свой вклад, добавив требования, полезные ссылки для изучения технологий или просто высказав свое мнение. Я буду очень рад, если вы присоединитесь к нам и поможете сформировать актуальные отраслевые стандарты. Жду ваших комментариев и предложений на GitHub!
Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.
Уж очень кривая штука. Только выбрал что-то обычное из ноды для джунов и хоп я сеньйор фронтенда. Началь дальше набирать базовые джуновские и хоп я сеньйор и в ноде и в фронте. Мистика. И это я до реактов всяких не дошёл даже
Скиллы часто пересекаются, например, навыки рефакторинга нужны, пожалуй, везде. Если вы думаете, что чего-то не хватает или что-то неверно — пишите хоть тут, в комментах, учтем и добавим/исправим. Текущее состояние — это MVP, которое мы собрали и структурировали с учетом мнений разных компаний: их СТО и тимлидов.
Я про то, что когда я отмечал у меня исчезали колонки джун\мид, перескакивало на ноду, а отмеченные вовсе исчезали в итоге. Сейчас зашёл - вроде всё норм
Юзаем лычки только чтобы поржать или потроллить. Аутсорсерам вероятно будет полезно, но все конторы впаривают по своему гребцов, соответсвенно и критерии будут впаривать свои.
А так есть инженегр и есть специализация
клепаешь быстрее - больше бабла, тупишь - меньше бабла.
Исходя из этого критерии - автономый, резво делающий, качественно. В последнее время автономный превышает все остальные скиллы.
Считаю архи не продуктивно вываливать список херни на соискателей, потому что у всех контор свои велосипеды и стек. В итоге берешь резюме и видишь кучу страшных слов которые автор видел, по факту работающее ничего сделать не может, даже без бэм бестпрактис и других модных шняг.
Было бы более полезно, по-моему, в процентах или типа того востребованность определенных скиллов в рунете или конторах + реальные проекты хотя бы описание как эти скиллы используются.
Я к тому что люди реальные задачи хотят чаще закрыть, а пишут все общими словами что надо.
У меня возник вопрос.Почему в составлении списка принимают участие компании, которые мало относятся к серьезной разработке? Где ЕПАМ, DataArt и прочие лидеры рынка, у которых есть такие компетенции?.
P.S. Посмотрел код данного одностраничного чуда на гитхабе, вопросов больше нет, это очередная попытка группы компаний подмять под себя рынок разработчиков.
Коллега, вы не правы.
1. Как минимум 2 компании из перечисленных входят в топ 10 компаний, или вы плохо знаете рынок.
2. Не во всех крупных компаниях есть хорошие грейды. Есть средние компании у которых сетка грейдов куда развитее, и в нее инвестированно больше.
3. Ребята попытались, и за это респект.
Но формат конечно мне тоже не нравится. Тема грейдов намного сложнее чем представленный функционал. Он скорее вызовет много споров чем даст реальный профит. Нужно больше гибкости.
И ни в коем случае не анонимное голосование, право голоса давать только CTO, профили которых которых предварительно проверять, и голоса должны быть подписаны и аргументированы.
Я как менеджер по продажам aka гуманитарий aka простой смертный, надеюсь, что подобное появится и для менеджеров в IT-компаниях🤔Может быть не прям с тремя левлами, но хотя бы понимать, что ты становишься круче и компании могут оценить тебя относительно других кандидатов/сотрудников. Понятно, что софт-скиллы мерить сложно, но как минимум техническую базу менеджеров (термины, принципы и процесс разработки) можно было бы померить🧐🙈
Кстати, имеет право на жизнь. Frontend в режиме «Менеджмент» — квалификация на знание основополагающих вещей (Markdown, азы Html/Css, Json, Bootstrap и тд.). Или общую техническую квалификацию, чтобы не усложнять.
Мы у себя начинаем понемногу разрабатывать сетку для ПМов, но это куда сложнее чем было с разработчиками.
Да, технические скилы для ПМов куда проще обозначить, но у ПМов больше софтскилов, которые куда сложнее измерить. Поставить по ним "зачет".
Для защиты каждого скила в сетке разработчиков нужна система зачета. Это практическая работа или теоритический экзамен. С софт скилами сложно =)
То, что вы написали - не имеет отношения к грейдам. Вообще.
К грейдам относится умение решать задачи.
От junior ожидается умение закодить что-то простое с помощью опытных коллег, от middle - самостоятельно писать код, от senior - принимать грамотные технические решение в проекте и писать сложные куски кода. Конечно, везде своя специфика, но принцип - такой.
А по вашему senior будет тот, кто выучил кучу умных слов. А тот, кто работал с похожими технологиями и в состоянии за пару дней освоить нужные - не будет.
То, что вы написали - не имеет отношения к грейдам. Вообще. К грейдам относится умение решать задачи. От junior ожидается умение закодить что-то простое с помощью опытных коллег
Есть такое понятие, как "фундаментальные знания", к которым относятся, например, базовые алгоритмы и структуры данных. И без этих знаний от джуниора на проекте будет больше вреда, чем пользы.
В вашем мире junior без базовых знаний не может приносить пользу в проекте? Senior коллеги не смогут провести code review? Junior нельзя отдать простую часть, где сложно ошибиться?
Давайте таких junior мне, я найду им применение. Вот прямо сейчас пара на проекте таких.
А по вашему senior будет тот, кто выучил кучу умных слов.
Ни в коем случае! Каждый грейд — это новый уровень ответственности: за таску в жире, за часть проекта, за весь проект.
Задача сервиса — помочь специалисту решать эти задачи и дать ресурсы для этого. Тот же сеньор вряд ли составит адекватную архитектуру проекта, если он не в курсе паттернов проектирования. Или миддл без знаний гита.
Никогда не видели крутых архитекторов, которые из названий паттернов проектирования знают только "синглетон"? Или миддлов, которые с гитом никогда не работали? А они есть.
git/mercurial/svn не суть, в тех специализациях, которые сейчас заполнены (веб фронтенд, например) стандартом является именно git. в java-энтерпрайзах гита вполне может не быть, тут у меня нет экспертизы чтобы отвечать.
То есть если человек работал над фронтендом и там по определённым причинам использовался Perforce, а с git'ом он не работал и его не видел - то он не имеет права называться миддлом?
В те компании, с которыми мы общались при составлении состава грейдов, на миддла без знаний гита фронтендера не возьмут. Задача сервиса дать объективную картину, без крайностей. Понятно что есть особенности у каждой компании, но база то плюс-минус одинаковая.
Никогда не видели крутых архитекторов, которые из названий паттернов проектирования знают только "синглетон"?
Крутых? Архитекторов? Нет, не видел. Видел мидлов, которые не знаю названия, но знают реализацию и умеют ими пользоваться. Только никто обычно и не требует "названий", требуют, как раз, реализацию и умение пользоваться. Если человек не знает, что такое "фабрика", но постоянно её использует там, где нужно, ему скажут что-то вроде "хэй, смотри, ты же используешь фабрику!".
Кажется статья не про вызубривание названий, а про скилы, разве нет?
Вы правы, все так. Но это не отменяет необходимость оценивать наличие уже освоенных технологий. И не все они осваиваются "за пару дней", и не все могут быть в принципе опробованы на начальном грейде.
Софт скилы это важная часть, которой сейчас в сервисе не хватает. Над этим планируем работать тоже. Если эта тема интересна, то можете предложить более подробно на гитхабе — нам это поможет, когда будем наполнять софт скилы.
Ага.
В паре больших компаний, где я работал, сотрудники оценивались по двум шкалам независимо - по уровням владения технологиями и техническим навыкам и по уровню ответственности и способности решать задачи. Грейд был про второе. Первое - менее важно. Мне не нравится, что у вас одно и другое слиплось.
Я смотрел статистику, сколько людей на определённом грейде владеют той или другой технологией. Понятно, что почти 100% Senior Java Developer знают Java (хотя не 100%, были те, кто пишет на Scala или Clojure просто попали в эту должность). Но остальных технологий там даже близко к 100% не было.
Зарплата по грейдам, грейд "по уровню ответственности и способности решать задачи". В итоге зарплата "по уровню ответственности и способности решать задачи". С этим что-то не так?
Почему "поменьше"? Смысл как раз в том, чтобы платить "побольше", но не потому что "я работаю уже пол года и теперь хочу больше денег", а потому что человек развивается, получает новые знания и может применять их в своей работе. Любой активно развивающейся компании выгодно, чтобы специалисты развивались, потому что их время можно дороже продавать. А любым специалистам выгодно развиваться, чтобы больше зарабатывать.
Разве прозрачные договоренности хуже субъективной оценки?
- Эй, я хочу больше получать
- Окей, смотри, вот грейды, закрой эти скиллы и мы сможем продавать твое время дороже
По-моему прозрачнее некуда. Полная противоположность с тем, когда повышают по причине личного отношения, подхалимства или кумовства.
Вынужден согласиться. Компетенции разработчиков подрядчика в РФ оценивают в момент расторжения договора :) А в момент подписания имеет значение только компетенция продажников. Sad, but true...
Не скажу за остальные области, так как в них нет опыта, но раздел Java надо дробить по областям ответственности и предметным областям. Например, если это веб, то там свои фреймворки и знания (веб-ИБ, всякий devops и тд), если Bigdata, то свои (map-reduce, hadoop, spark) если ML, то свои и тд.
React разработчик - один стек
Angular - другой набор скилов и библиотек
Плюс React native - может разработчик вообще не использовать и писать только веб-приложения. Можно отдельные профиль React с уклоном в mobile.
PHP
У нас например middle php - это разработчик который знает как минимум 1 FW + Bitrix (реалии российского рынка и нашего стека).
Т.е. можно было бы профили
Middle PHP - чистый, там выбор одного из двух FW (laravel/symphony)
Middle Bitrix - это помесь FW + Bitrix. Да, мы считаем что Bitrix разработчик который не знает MVC FW - это в плохой разработчик, и он будет изобретать велосипеды в силу ограниченности знаний.
data-science - почему этот скил в мастхев у джуна фронта?))
Вообще не объективно для рынка, узкая профильная специализация)
Спасибо за мнение. Да, это первое на очереди по UX )
Основной задачей было структурировать эти скиллы и собрать базу знаний, а фичу с отметками "я знаю" прикрутили совсем недавно.
Потому что 3 грейда — мало. Так называемым «джуниором» может быть как тот, кто написал хелоу ворд на Реакте, так и тот, кто пишет на тайпскрипте, нормально верстает, пишет тесты, etc. Грейдов должно быть больше. Но вообще не вижу смысла в этом, роадмапы давно есть — https://github.com/kamranahmedse/developer-roadmap#frontend-roadmap
Джун/миддл/сеньор это стандартная на рынке структура. Мы у себя в компании дробим еще на уровни (jun1,2,3 и тд), и исходим из того, что джун - тот, кто может работать под контролем более старшего специалиста и может отвечать за свои задачи. Миддл - может самостоятельно решать любые задачи своей зоны ответственности. А Сеньор может брать ответственность еще и за джунов, ревьювить их код и помогать им + разрабатывать общую архитектуру проектов.
Этот роадмэп тоже использовали. По опросу специалистов и общению на собеседованиях заметил кстати, что начинающие почти никогда про него не знают.
Хорошо же начали про UX, а закончили про статичный роадмап в картинке. Про этот роадмап знаем, но это не удобно, не гибко, не интерактивно и не так интересно. А это важно в процессе обучения — чтобы было интересно.
В планах есть детализация грейдов более, чем на 3 уровня. Кроме того, если в сервисе появится привязка к потребностям компаний или сфер, то можно развиваться целенаправленно под то, чем интересно заниматься (интересно не Node.js, а Биг дата в медицине, например).
