{"id":13637,"url":"\/distributions\/13637\/click?bit=1&hash=6eb6f4cc0fd514248f67334eed9cf9b381eca4ced68925ecf0d4e37273ec5a7a","title":"Ozon \u0440\u0430\u0437\u0432\u0435\u043d\u0447\u0438\u0432\u0430\u0435\u0442 \u043c\u0438\u0444\u044b \u043e \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0445 \u0440\u0430\u0441\u043f\u0440\u043e\u0434\u0430\u0436\u0430\u0445","buttonText":"\u041f\u043e\u043a\u0430\u0436\u0438\u0442\u0435","imageUuid":"7d00f3f0-9073-5cd7-b901-ee3a06a62041","isPaidAndBannersEnabled":false}
Трибуна
Nikita Ryazantsev

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

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

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

Уж очень кривая штука. Только выбрал что-то обычное из ноды для джунов и хоп я сеньйор фронтенда. Началь дальше набирать базовые джуновские и хоп я сеньйор и в ноде и в фронте. Мистика. И это я до реактов всяких не дошёл даже

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

Скиллы часто пересекаются, например, навыки рефакторинга нужны, пожалуй, везде. Если вы думаете, что чего-то не хватает или что-то неверно — пишите хоть тут, в комментах, учтем и добавим/исправим. Текущее состояние — это MVP, которое мы собрали и структурировали с учетом мнений разных компаний: их СТО и тимлидов.

Ответить
Развернуть ветку
1 комментарий
Andrey Morgunov

У меня возник вопрос.Почему в составлении списка принимают участие компании, которые мало относятся к серьезной разработке? Где ЕПАМ, DataArt и прочие лидеры рынка, у которых есть такие компетенции?.
P.S. Посмотрел код данного одностраничного чуда на гитхабе, вопросов больше нет, это очередная попытка группы компаний подмять под себя рынок разработчиков. 

Ответить
Развернуть ветку
Иван Поддубный

Коллега, вы не правы.
1. Как минимум 2 компании из перечисленных входят в топ 10 компаний, или вы плохо знаете рынок.
2. Не во всех крупных компаниях есть хорошие грейды. Есть средние компании у которых сетка грейдов куда развитее, и в нее инвестированно больше.
3. Ребята попытались, и за это респект.

Но формат конечно мне тоже не нравится. Тема грейдов намного сложнее чем представленный функционал. Он скорее вызовет много споров чем даст реальный профит. Нужно больше гибкости.
И ни в коем случае не анонимное голосование, право голоса давать только CTO, профили которых которых предварительно проверять, и голоса должны быть подписаны и аргументированы.

Ответить
Развернуть ветку
Вадим Чиняев

Юзаем лычки только чтобы поржать или потроллить.  Аутсорсерам вероятно будет полезно, но все конторы впаривают по своему гребцов, соответсвенно и критерии будут впаривать свои. 

А так есть инженегр и есть специализация
клепаешь быстрее - больше бабла, тупишь - меньше бабла. 
Исходя из этого критерии - автономый, резво делающий, качественно. В последнее время автономный превышает все остальные скиллы.

Считаю архи не продуктивно вываливать список херни на соискателей, потому что у всех контор свои велосипеды и стек. В итоге берешь резюме и видишь кучу страшных слов которые автор видел,  по факту работающее ничего сделать не может, даже без бэм бестпрактис и других модных шняг.

Было бы более полезно, по-моему, в процентах или типа того востребованность определенных скиллов в рунете или конторах + реальные проекты хотя бы описание как эти скиллы используются. 
Я к тому что люди реальные задачи хотят чаще закрыть, а пишут все общими словами что надо.  

Ответить
Развернуть ветку
Artyom Ivanov
Было бы более полезно, по-моему, в процентах или типа того востребованность определенных скиллов

А это интересно, спасибо!

Ответить
Развернуть ветку
Maria Rodionova

Я как менеджер по продажам aka гуманитарий aka простой смертный, надеюсь, что подобное появится и для менеджеров в IT-компаниях🤔Может быть не прям с тремя левлами, но хотя бы понимать, что ты становишься круче и компании могут оценить тебя относительно других кандидатов/сотрудников. Понятно, что софт-скиллы мерить сложно, но как минимум техническую базу менеджеров (термины, принципы и процесс разработки) можно было бы померить🧐🙈

Ответить
Развернуть ветку
Nikita Ryazantsev
Автор

Кстати, имеет право на жизнь. Frontend в режиме «Менеджмент» — квалификация на знание основополагающих вещей (Markdown, азы Html/Css, Json, Bootstrap и тд.). Или общую техническую квалификацию, чтобы не усложнять.

Ответить
Развернуть ветку
Иван Поддубный

Мы у себя начинаем понемногу разрабатывать сетку для ПМов, но это куда сложнее чем было с разработчиками.
Да, технические скилы для ПМов куда проще обозначить, но у ПМов больше софтскилов, которые куда сложнее измерить. Поставить по ним "зачет".
Для защиты каждого скила в сетке разработчиков нужна система зачета. Это практическая работа или теоритический экзамен. С софт скилами сложно =)

Ответить
Развернуть ветку
Антон Васильев

То, что вы написали - не имеет отношения к грейдам. Вообще.
К грейдам относится умение решать задачи. 
От junior ожидается умение закодить что-то простое с помощью опытных коллег, от middle - самостоятельно писать код, от senior - принимать грамотные технические решение в проекте и писать сложные куски кода. Конечно, везде своя специфика, но принцип - такой.
А по вашему senior будет тот, кто выучил кучу умных слов. А тот, кто работал с похожими технологиями и в состоянии за пару дней освоить нужные - не будет.

Ответить
Развернуть ветку
Николай Сладкий
То, что вы написали - не имеет отношения к грейдам. Вообще. К грейдам относится умение решать задачи. От junior ожидается умение закодить что-то простое с помощью опытных коллег

Есть такое понятие, как "фундаментальные знания", к которым относятся, например, базовые алгоритмы и структуры данных. И без этих знаний от джуниора на проекте будет больше вреда, чем пользы.

Ответить
Развернуть ветку
3 комментария
Artyom Ivanov
 А по вашему senior будет тот, кто выучил кучу умных слов.

Ни в коем случае! Каждый грейд — это новый уровень ответственности: за таску в жире, за часть проекта, за весь проект.

Задача сервиса — помочь специалисту решать эти задачи и дать ресурсы для этого. Тот же сеньор вряд ли составит адекватную архитектуру проекта, если он не в курсе паттернов проектирования. Или миддл без знаний гита.

Ответить
Развернуть ветку
9 комментариев
Nikita Ryazantsev
Автор

Вы правы, все так. Но это не отменяет необходимость оценивать наличие уже освоенных технологий. И не все они осваиваются "за пару дней", и не все могут быть в принципе опробованы на начальном грейде.
Софт скилы это важная часть, которой сейчас в сервисе не хватает. Над этим планируем работать тоже. Если эта тема интересна, то можете предложить более подробно на гитхабе — нам это поможет, когда будем наполнять софт скилы.

Ответить
Развернуть ветку
4 комментария
Saucedo Puetz

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

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

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

Ответить
Развернуть ветку
4 комментария
Andrei Kiladze
В итоге заказчик берет разработчика в другой компании..

Плохие продажники, вот и факапите.

Ответить
Развернуть ветку
Alexey Praskovin

Вынужден согласиться. Компетенции разработчиков подрядчика в РФ оценивают в момент расторжения договора :) А в момент подписания имеет значение только компетенция продажников. Sad, but true...

Ответить
Развернуть ветку
Bulat Ziganshin

вот довольно известная матрица: 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 - почему этот скил в мастхев у джуна фронта?))
Вообще не объективно для рынка, узкая профильная специализация)

Ответить
Развернуть ветку
1 комментарий
Кирилл Крайнов

Интересно посмотреть, как эти грейды будут распределены среди iOS-разработчиков в вашей системе)

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

Будем рады, если предложите свои наработки/идеи: issue, pull-request или хоть комментом тут/на почту — welcome!)

Ответить
Развернуть ветку
Arthur N

Кликать на кнопку и потом ещё раз на кнопку в модальном окне — ад, сделайте рядом какой-нибудь плюсик, чтобы не открывать модалку каждый раз.

Ну и да, пишу с дивана, но это никогда не будет нормально работать.

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

Спасибо за мнение. Да, это первое на очереди по UX )
Основной задачей было структурировать эти скиллы и собрать базу знаний, а фичу с отметками "я знаю" прикрутили совсем недавно.

Почему думаете что это не будет работать?

Ответить
Развернуть ветку
3 комментария
Pavel Popovich

Норм материал. Жаль для PMов такую штуку не сделать - слишком творческая профессия)))

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

Комментарий удален модератором

Развернуть ветку
Читать все 51 комментарий
null