Если вы читаете эту статью, то, скорее всего, вы — разработчик, тимлид, 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!
То, что вы написали - не имеет отношения к грейдам. Вообще.
К грейдам относится умение решать задачи.
От junior ожидается умение закодить что-то простое с помощью опытных коллег, от middle - самостоятельно писать код, от senior - принимать грамотные технические решение в проекте и писать сложные куски кода. Конечно, везде своя специфика, но принцип - такой.
А по вашему senior будет тот, кто выучил кучу умных слов. А тот, кто работал с похожими технологиями и в состоянии за пару дней освоить нужные - не будет.
Есть такое понятие, как "фундаментальные знания", к которым относятся, например, базовые алгоритмы и структуры данных. И без этих знаний от джуниора на проекте будет больше вреда, чем пользы.
Зависит от задачи. Есть области, где они не нужны.
О, ну конечно! Как и в медицине, есть области, где знания биохимии не нужны (нет).
В вашем мире junior без базовых знаний не может приносить пользу в проекте? Senior коллеги не смогут провести code review? Junior нельзя отдать простую часть, где сложно ошибиться?
Давайте таких junior мне, я найду им применение. Вот прямо сейчас пара на проекте таких.