Мы собрали требования к грейдам разработчиков и базу учебных материалов: вот что получилось
Если вы читаете эту статью, то, скорее всего, вы — разработчик, тимлид, HR или руководитель компании, который думает, как нанять специалистов необходимого уровня.
Объявления о вакансиях пестрят требованиями: «талантливый и обучаемый Junior», «крепкий Middle» или «уверенный Senior».
Правда, когда дело доходит до собеседований, то часто выясняется, что заявленное отличается от реального. Причем, в обе стороны. Поэтому возникает логичный вопрос: как соискателю оценить свой реальный уровень, а работодателю — правильно составить требования?
Для меня, как владельца диджитал-продакшна из Самары, эта проблема выглядела так. Нанимаемые разработчики довольно быстро уходили в другие компании, потому что у нас их рост был ограничен отсутствием программы развития. И напротив: всякий раз, когда нам требовалось масштабировать команду на более сложный проект, приходилось искать сотрудников с более высокими компетенциями, а не растить их внутри. Поняв, что это, по сути, проблемы одного порядка, мы решили внедрить систему грейдов. Оставалось решить, какие из множества технологий действительно важны как базовые знания, что может понадобится в процессе усложнения проектов, и как вообще ориентироваться в куче разнообразных требований у разных компаний и клиентов.
Ниже моя история о том, с чего мы начали сбор информаци и во что все это вылилось в итоге. Заодно мы поговорили с экспертами рынка веб- и мобильной разработки про их подход к системе грейдирования и возможности создания универсальной базы знаний.
С чего мы начали
Мы не стали изобретать новую систему оценки и взяли привычную трехуровневую: junior, middle, senior. Первым делом выделили актуальные для наших задач технологии и собрали обучающие материалы по ним. Так, например, для самого первого уровня для нас были важны знания о фундаментальных вещах: сomputer science, алгоритмы, навыки слепой печати и комментирования кода. В свою очередь, специалист мог бы соответствовать верхнему грейду только при наличии опыта в более узких областях: например, работа с протоколами или утечками памяти, с которыми редко сталкиваешься без практики.
Далее вместе с тимлидами установили индивидуальные квартальные планы развития для разработчиков с понятным и измеримым результатом. Стимулы, как и санкции, — тоже были прописаны.
Таким образом, система грейдов в какой-то мере решала проблему роста сотрудников и их оценки. Но вопрос о том, как искать именно тех, кто нам нужен, оставался открытым. Ведь в каждом продакшене — свои правила:
Поэтому мы решили изучить опыт других агентств и попытаться создать общую базу требований к разработчикам, основанную на коллективном опыте.
Откуда мы взяли данные
Мы поговорили не только с веб- и мобильными продакшенами, такими как AGIMA, Сибирикс, Mediasoft, Redmadrobot, Mad Brains, Firecode и Dex, но и с дизайн-студиями Everest и Pinkman. И, разумеется, искали информацию от крупных IT-компаний в открытых источниках.
Наш главный вопрос звучал так:
Как это работает
Итак, мы собрали базу требований и знаний для развития IT-шников по классическим грейдам. Мы не только определили, что, например, для уровня Middle-фронтендера в большинстве компаний нужны хотя бы знания JavaScript и Angular, а Senior должен уметь программировать на Linux и использовать React Native, но и собрали массу полезных ссылок и обучающих материалов по технологиям: статьи, видеоуроки, официальную документацию, учебники.
Можно не только получить новые знания, но и отметить для себя освоенные навыки. Это пригодится, например, при составлении резюме или просто для самопроверки.
Все данные мы разместили в открытом доступе, а новая информация появляется через простые пулл-реквесты на GitHub. Это opensource-база, которая может наполняться всеми, кто хочет поделиться знаниями: разработчиками, тимлидами, CTO.
Что можно улучшить
Есть, правда, и альтернативные мнения:
С нашей стороны было бы самонадеянно считать, что мы изобрели нечто, что сразу перевернет рынок IT. Говорить о стандартизации требований в сфере, где практически не найти двух одинаковых компаний, пока не приходится. К тому же, для себя мы выделяем несколько проблем, которые только предстоит решить:
чем быстрее растет список требований, тем страшнее он выглядит. Очевидно, что для получения грейдов необязательно знать весь указанный стэк. Поэтому мы думаем о том, как помочь с выбором именного того, что нужно;
- тому, кто хочет проверить свой уровень или прокачаться под конкретного работодателя, необходимо понимать, какие требования пригодятся, а какие нет. Пока что все требования обезличены;
- если стать джуниором на одних знаниях технологий еще теоретически возможно, то расти дальше без навыков командной работы, коммуникации, аналитического и стратегического мышления будет трудно. Как учитывать софт-скиллы в грейдах — еще только предстоит придумать.
И, конечно, изучением одной лишь базы знаний не обойтись:
Тем не менее, работодателям база данных может быть полезна даже в виде MVP. Ведь они имеют на руках список компетенций, составленный профессионалами. HR-специалисту остается лишь показать его своему CTO и попросить выбрать именно те технологии, которые актуальны для задач компании.
Какие есть альтернативы
Мы далеко не единственная и уж точно не первая компания, которая использует систему грейдов и собирает базу знаний для их получения. Большинство коллег, с которыми мы общались, в той или иной степени создали ее “под себя”.
Однако, если вы не компания, а разработчик, то узнать о требованиях и оценить свой уровень применительно к потенциальному работодателю — непросто. Конечно, в интернете можно найти массу предложений по прохождению сертификации. Нельзя сказать, что они плохи, но вопросы вызывают критерии оценки.
В нашем случае база не только наполняется самими разработчиками, но и оказывается скорее образовательным проектом. Уже готовы несколько роадмапов, по которым можно прокачаться до минимально необходимого уровня. Альтернатив нашей базе (тем более бесплатных) мы пока не нашли.
Как проект будет развиваться
- Сейчас мы собрали материалы по Frontend-разработке и NodeJS. На подходе — требования для Java, PHP, Android и iOS-разработчиков;
- Как было сказано выше, можно отметить уже имеющиеся навыки. Правда, пока что отметки хранятся только в кэше, но мы планируем запуск полноценного личного кабинета;
- В перспективе будет реализована механика лайков/дизлайков за каждый навык. Так можно будет увидеть, какие знания обязательны, а какие можно отнести скорее к дополнительным;
- Чтобы узнать требования конкретного работодателя, мы планируем ввести фильтр по компаниям;
- Ну и, конечно, мы постараемся учесть софт-скилз. И тут мало сомнений, что разночтения между компаниями будут минимальными — от инициативного, общительного программиста с лидерскими качествами мало кто откажется.
Как я уже говорил, наш проект — это открытая база данных как в плане получения информации, так и наполнения ею. Это значит, что любой разработчик может внести свой вклад, добавив требования, полезные ссылки для изучения технологий или просто высказав свое мнение. Я буду очень рад, если вы присоединитесь к нам и поможете сформировать актуальные отраслевые стандарты. Жду ваших комментариев и предложений на GitHub!
Уж очень кривая штука. Только выбрал что-то обычное из ноды для джунов и хоп я сеньйор фронтенда. Началь дальше набирать базовые джуновские и хоп я сеньйор и в ноде и в фронте. Мистика. И это я до реактов всяких не дошёл даже
Скиллы часто пересекаются, например, навыки рефакторинга нужны, пожалуй, везде. Если вы думаете, что чего-то не хватает или что-то неверно — пишите хоть тут, в комментах, учтем и добавим/исправим. Текущее состояние — это MVP, которое мы собрали и структурировали с учетом мнений разных компаний: их СТО и тимлидов.
У меня возник вопрос.Почему в составлении списка принимают участие компании, которые мало относятся к серьезной разработке? Где ЕПАМ, DataArt и прочие лидеры рынка, у которых есть такие компетенции?.
P.S. Посмотрел код данного одностраничного чуда на гитхабе, вопросов больше нет, это очередная попытка группы компаний подмять под себя рынок разработчиков.
Коллега, вы не правы.
1. Как минимум 2 компании из перечисленных входят в топ 10 компаний, или вы плохо знаете рынок.
2. Не во всех крупных компаниях есть хорошие грейды. Есть средние компании у которых сетка грейдов куда развитее, и в нее инвестированно больше.
3. Ребята попытались, и за это респект.
Но формат конечно мне тоже не нравится. Тема грейдов намного сложнее чем представленный функционал. Он скорее вызовет много споров чем даст реальный профит. Нужно больше гибкости.
И ни в коем случае не анонимное голосование, право голоса давать только CTO, профили которых которых предварительно проверять, и голоса должны быть подписаны и аргументированы.
Юзаем лычки только чтобы поржать или потроллить. Аутсорсерам вероятно будет полезно, но все конторы впаривают по своему гребцов, соответсвенно и критерии будут впаривать свои.
А так есть инженегр и есть специализация
клепаешь быстрее - больше бабла, тупишь - меньше бабла.
Исходя из этого критерии - автономый, резво делающий, качественно. В последнее время автономный превышает все остальные скиллы.
Считаю архи не продуктивно вываливать список херни на соискателей, потому что у всех контор свои велосипеды и стек. В итоге берешь резюме и видишь кучу страшных слов которые автор видел, по факту работающее ничего сделать не может, даже без бэм бестпрактис и других модных шняг.
Было бы более полезно, по-моему, в процентах или типа того востребованность определенных скиллов в рунете или конторах + реальные проекты хотя бы описание как эти скиллы используются.
Я к тому что люди реальные задачи хотят чаще закрыть, а пишут все общими словами что надо.
А это интересно, спасибо!
Я как менеджер по продажам aka гуманитарий aka простой смертный, надеюсь, что подобное появится и для менеджеров в IT-компаниях🤔Может быть не прям с тремя левлами, но хотя бы понимать, что ты становишься круче и компании могут оценить тебя относительно других кандидатов/сотрудников. Понятно, что софт-скиллы мерить сложно, но как минимум техническую базу менеджеров (термины, принципы и процесс разработки) можно было бы померить🧐🙈
Кстати, имеет право на жизнь. Frontend в режиме «Менеджмент» — квалификация на знание основополагающих вещей (Markdown, азы Html/Css, Json, Bootstrap и тд.). Или общую техническую квалификацию, чтобы не усложнять.
Мы у себя начинаем понемногу разрабатывать сетку для ПМов, но это куда сложнее чем было с разработчиками.
Да, технические скилы для ПМов куда проще обозначить, но у ПМов больше софтскилов, которые куда сложнее измерить. Поставить по ним "зачет".
Для защиты каждого скила в сетке разработчиков нужна система зачета. Это практическая работа или теоритический экзамен. С софт скилами сложно =)
То, что вы написали - не имеет отношения к грейдам. Вообще.
К грейдам относится умение решать задачи.
От junior ожидается умение закодить что-то простое с помощью опытных коллег, от middle - самостоятельно писать код, от senior - принимать грамотные технические решение в проекте и писать сложные куски кода. Конечно, везде своя специфика, но принцип - такой.
А по вашему senior будет тот, кто выучил кучу умных слов. А тот, кто работал с похожими технологиями и в состоянии за пару дней освоить нужные - не будет.
Есть такое понятие, как "фундаментальные знания", к которым относятся, например, базовые алгоритмы и структуры данных. И без этих знаний от джуниора на проекте будет больше вреда, чем пользы.
Ни в коем случае! Каждый грейд — это новый уровень ответственности: за таску в жире, за часть проекта, за весь проект.
Задача сервиса — помочь специалисту решать эти задачи и дать ресурсы для этого. Тот же сеньор вряд ли составит адекватную архитектуру проекта, если он не в курсе паттернов проектирования. Или миддл без знаний гита.
Вы правы, все так. Но это не отменяет необходимость оценивать наличие уже освоенных технологий. И не все они осваиваются "за пару дней", и не все могут быть в принципе опробованы на начальном грейде.
Софт скилы это важная часть, которой сейчас в сервисе не хватает. Над этим планируем работать тоже. Если эта тема интересна, то можете предложить более подробно на гитхабе — нам это поможет, когда будем наполнять софт скилы.
Что только не придумают чтобы денег поменьше платить
Почему "поменьше"? Смысл как раз в том, чтобы платить "побольше", но не потому что "я работаю уже пол года и теперь хочу больше денег", а потому что человек развивается, получает новые знания и может применять их в своей работе. Любой активно развивающейся компании выгодно, чтобы специалисты развивались, потому что их время можно дороже продавать. А любым специалистам выгодно развиваться, чтобы больше зарабатывать.
Комментарий недоступен
Вынужден согласиться. Компетенции разработчиков подрядчика в РФ оценивают в момент расторжения договора :) А в момент подписания имеет значение только компетенция продажников. Sad, but true...
вот довольно известная матрица: https://sijinjoseph.com/programmer-competency-matrix/
кажется своя есть у ЕПАМа, вместе с внутрикорпоративными программами обучения
Слишком абстрактная и не привязана к технологиям. По факту для каждого направления нужна своя.
Не скажу за остальные области, так как в них нет опыта, но раздел 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 - почему этот скил в мастхев у джуна фронта?))
Вообще не объективно для рынка, узкая профильная специализация)
Интересно посмотреть, как эти грейды будут распределены среди iOS-разработчиков в вашей системе)
Будем рады, если предложите свои наработки/идеи: issue, pull-request или хоть комментом тут/на почту — welcome!)
Кликать на кнопку и потом ещё раз на кнопку в модальном окне — ад, сделайте рядом какой-нибудь плюсик, чтобы не открывать модалку каждый раз.
Ну и да, пишу с дивана, но это никогда не будет нормально работать.
Спасибо за мнение. Да, это первое на очереди по UX )
Основной задачей было структурировать эти скиллы и собрать базу знаний, а фичу с отметками "я знаю" прикрутили совсем недавно.
Почему думаете что это не будет работать?
Норм материал. Жаль для PMов такую штуку не сделать - слишком творческая профессия)))
Комментарий удален модератором