Мы собрали требования к грейдам разработчиков и базу учебных материалов: вот что получилось
Если вы читаете эту статью, то, скорее всего, вы — разработчик, тимлид, 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-продукт силами внутренней команды. Но если говорить о заказной разработке, где команда работает над сторонними продуктами и имеет дело с большим стеком технологий, то ей нельзя ориентироваться на абстрактные звания и жестко фиксированный пул навыков.
С нашей стороны было бы самонадеянно считать, что мы изобрели нечто, что сразу перевернет рынок IT. Говорить о стандартизации требований в сфере, где практически не найти двух одинаковых компаний, пока не приходится. К тому же, для себя мы выделяем несколько проблем, которые только предстоит решить:
чем быстрее растет список требований, тем страшнее он выглядит. Очевидно, что для получения грейдов необязательно знать весь указанный стэк. Поэтому мы думаем о том, как помочь с выбором именного того, что нужно;
- тому, кто хочет проверить свой уровень или прокачаться под конкретного работодателя, необходимо понимать, какие требования пригодятся, а какие нет. Пока что все требования обезличены;
- если стать джуниором на одних знаниях технологий еще теоретически возможно, то расти дальше без навыков командной работы, коммуникации, аналитического и стратегического мышления будет трудно. Как учитывать софт-скиллы в грейдах — еще только предстоит придумать.
Идея общего каркаса для оценки грейдов выглядит классно. Но как бы технически не был “прокачан” человек, я никогда не смогу его отнести к миддлу или синьору, если его софт-скиллы (дисциплина, ответственность, лидерские компетенции и т.п.) стремятся к нулю.
И, конечно, изучением одной лишь базы знаний не обойтись:
Никакая система не заменит джуниорам наставников-кураторов, которые обучают и развивают специалиста не только исходя из плана развития, но и из его индивидуальных особенностей.
Тем не менее, работодателям база данных может быть полезна даже в виде MVP. Ведь они имеют на руках список компетенций, составленный профессионалами. HR-специалисту остается лишь показать его своему CTO и попросить выбрать именно те технологии, которые актуальны для задач компании.
Какие есть альтернативы
Мы далеко не единственная и уж точно не первая компания, которая использует систему грейдов и собирает базу знаний для их получения. Большинство коллег, с которыми мы общались, в той или иной степени создали ее “под себя”.
В этом году мы обновили свои карты компетенций дизайнеров, программистов и руководителей проектов (прошлогодняя — здесь). Что важно знать при их внедрении:
1. Обновлять раз в год, а раз в полгода — вносить корректировки.
2. Заполнять их приватно, чтобы не превращать в соревнование.
3. Адаптировать под бизнес-задачи компании.
4. Использовать их лишь как повод к общению с сотрудником для его дальнейшей прокачки.
Однако, если вы не компания, а разработчик, то узнать о требованиях и оценить свой уровень применительно к потенциальному работодателю — непросто. Конечно, в интернете можно найти массу предложений по прохождению сертификации. Нельзя сказать, что они плохи, но вопросы вызывают критерии оценки.
В нашем случае база не только наполняется самими разработчиками, но и оказывается скорее образовательным проектом. Уже готовы несколько роадмапов, по которым можно прокачаться до минимально необходимого уровня. Альтернатив нашей базе (тем более бесплатных) мы пока не нашли.
Самое сложное в подобных инициативах — много лет подряд сохранять объективность взгляда, инвестировать в проект и терпеть негатив от компаний, которые всю жизнь хотели сделать что-то подобное, но «тормозили», а теперь будут критиковать вместо помощи.
В предложениях стандартизации главное то, что они заставляют задуматься и начать шевелиться игроков индустрии и смежных рынков, и провоцируют обширную дискуссию. Идея регламентировать грейды насчитывает два десятка лет, и пока что это не удалось ни государству, ни образовательным институтам, ни ассоциациям, ни конкретным игрокам рынка.
Могу только пожелать терпения.
Как проект будет развиваться
- Сейчас мы собрали материалы по Frontend-разработке и NodeJS. На подходе — требования для Java, PHP, Android и iOS-разработчиков;
- Как было сказано выше, можно отметить уже имеющиеся навыки. Правда, пока что отметки хранятся только в кэше, но мы планируем запуск полноценного личного кабинета;
- В перспективе будет реализована механика лайков/дизлайков за каждый навык. Так можно будет увидеть, какие знания обязательны, а какие можно отнести скорее к дополнительным;
- Чтобы узнать требования конкретного работодателя, мы планируем ввести фильтр по компаниям;
- Ну и, конечно, мы постараемся учесть софт-скилз. И тут мало сомнений, что разночтения между компаниями будут минимальными — от инициативного, общительного программиста с лидерскими качествами мало кто откажется.
Такой инструмент позволит разработчикам любого уровня формировать персональный план развития, отмечать белые зоны (явное незнание), понимать что надо прокачать для перехода в другую область. Но прежде чем это станет возможно, необходимо провести огромную подготовительную работу: собрать навыки, откалибровать их по грейдам, подобрать материал.
Как я уже говорил, наш проект — это открытая база данных как в плане получения информации, так и наполнения ею. Это значит, что любой разработчик может внести свой вклад, добавив требования, полезные ссылки для изучения технологий или просто высказав свое мнение. Я буду очень рад, если вы присоединитесь к нам и поможете сформировать актуальные отраслевые стандарты. Жду ваших комментариев и предложений на GitHub!
Уж очень кривая штука. Только выбрал что-то обычное из ноды для джунов и хоп я сеньйор фронтенда. Началь дальше набирать базовые джуновские и хоп я сеньйор и в ноде и в фронте. Мистика. И это я до реактов всяких не дошёл даже
Скиллы часто пересекаются, например, навыки рефакторинга нужны, пожалуй, везде. Если вы думаете, что чего-то не хватает или что-то неверно — пишите хоть тут, в комментах, учтем и добавим/исправим. Текущее состояние — это MVP, которое мы собрали и структурировали с учетом мнений разных компаний: их СТО и тимлидов.
У меня возник вопрос.Почему в составлении списка принимают участие компании, которые мало относятся к серьезной разработке? Где ЕПАМ, DataArt и прочие лидеры рынка, у которых есть такие компетенции?.
P.S. Посмотрел код данного одностраничного чуда на гитхабе, вопросов больше нет, это очередная попытка группы компаний подмять под себя рынок разработчиков.
Коллега, вы не правы.
1. Как минимум 2 компании из перечисленных входят в топ 10 компаний, или вы плохо знаете рынок.
2. Не во всех крупных компаниях есть хорошие грейды. Есть средние компании у которых сетка грейдов куда развитее, и в нее инвестированно больше.
3. Ребята попытались, и за это респект.
Но формат конечно мне тоже не нравится. Тема грейдов намного сложнее чем представленный функционал. Он скорее вызовет много споров чем даст реальный профит. Нужно больше гибкости.
И ни в коем случае не анонимное голосование, право голоса давать только CTO, профили которых которых предварительно проверять, и голоса должны быть подписаны и аргументированы.
Юзаем лычки только чтобы поржать или потроллить. Аутсорсерам вероятно будет полезно, но все конторы впаривают по своему гребцов, соответсвенно и критерии будут впаривать свои.
А так есть инженегр и есть специализация
клепаешь быстрее - больше бабла, тупишь - меньше бабла.
Исходя из этого критерии - автономый, резво делающий, качественно. В последнее время автономный превышает все остальные скиллы.
Считаю архи не продуктивно вываливать список херни на соискателей, потому что у всех контор свои велосипеды и стек. В итоге берешь резюме и видишь кучу страшных слов которые автор видел, по факту работающее ничего сделать не может, даже без бэм бестпрактис и других модных шняг.
Было бы более полезно, по-моему, в процентах или типа того востребованность определенных скиллов в рунете или конторах + реальные проекты хотя бы описание как эти скиллы используются.
Я к тому что люди реальные задачи хотят чаще закрыть, а пишут все общими словами что надо.
Было бы более полезно, по-моему, в процентах или типа того востребованность определенных скилловА это интересно, спасибо!
Я как менеджер по продажам aka гуманитарий aka простой смертный, надеюсь, что подобное появится и для менеджеров в IT-компаниях🤔Может быть не прям с тремя левлами, но хотя бы понимать, что ты становишься круче и компании могут оценить тебя относительно других кандидатов/сотрудников. Понятно, что софт-скиллы мерить сложно, но как минимум техническую базу менеджеров (термины, принципы и процесс разработки) можно было бы померить🧐🙈