Мы собрали требования к грейдам разработчиков и базу учебных материалов: вот что получилось

Если вы читаете эту статью, то, скорее всего, вы — разработчик, тимлид, 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!

0
51 комментарий
Написать комментарий...
Saucedo Puetz

Что только не придумают чтобы денег поменьше платить

Ответить
Развернуть ветку
Николай Сладкий

Почему "поменьше"? Смысл как раз в том, чтобы платить "побольше", но не потому что "я работаю уже пол года и теперь хочу больше денег", а потому что человек развивается, получает новые знания и может применять их в своей работе. Любой активно развивающейся компании выгодно, чтобы специалисты развивались, потому что их время можно дороже продавать. А любым специалистам выгодно развиваться, чтобы больше зарабатывать.

Ответить
Развернуть ветку
Saucedo Puetz

Я гляжу вы горазды сладкие речи толкать.  

Ответить
Развернуть ветку
Artyom Ivanov

Разве прозрачные договоренности хуже субъективной оценки?
- Эй, я хочу больше получать
- Окей, смотри, вот грейды, закрой эти скиллы и мы сможем продавать твое время дороже

По-моему прозрачнее некуда. Полная противоположность с тем, когда повышают по причине личного отношения, подхалимства или кумовства.

Ответить
Развернуть ветку
Saucedo Puetz

Вы прям в каком то идеальном мире живете

Ответить
Развернуть ветку
48 комментариев
Раскрывать всегда