Трибуна
Nikita Ryazantsev
3599

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Nikita Ryazantsev", "author_type": "self", "tags": [], "comments": 51, "likes": 16, "favorites": 64, "is_advertisement": false, "subsite_label": "tribuna", "id": 93268, "is_wide": false, "is_ugc": true, "date": "Tue, 19 Nov 2019 09:37:51 +0300", "is_special": false }
0
{ "id": 93268, "author_id": 177984, "diff_limit": 1000, "urls": {"diff":"\/comments\/93268\/get","add":"\/comments\/93268\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/93268"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199116, "last_count_and_date": null }
51 комментарий
Популярные
По порядку
Написать комментарий...
4

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

Ответить
0

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

Ответить
1

Я про то, что когда я отмечал у меня исчезали колонки джун\мид, перескакивало на ноду, а отмеченные вовсе исчезали в итоге. Сейчас зашёл - вроде всё норм

Ответить
3

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

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

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

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

Ответить
0

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

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

Ответить
2

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

Ответить
3

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

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

Ответить
2

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

Ответить
3

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

Ответить
0

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

Ответить
2

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

Ответить
1

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

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

Ответить
0

Зависит от задачи. Есть области, где они не нужны.

Ответить
0

О, ну конечно! Как и в медицине, есть области, где знания биохимии не нужны (нет).

Ответить
0

В вашем мире junior без базовых знаний не может приносить пользу в проекте? Senior коллеги не смогут провести code review? Junior нельзя отдать простую часть, где сложно ошибиться?
Давайте таких junior мне, я найду им применение. Вот прямо сейчас пара на проекте таких.

Ответить
0

 А по вашему senior будет тот, кто выучил кучу умных слов.

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

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

Ответить
–1

Никогда не видели крутых архитекторов, которые из названий паттернов проектирования знают только "синглетон"? Или миддлов, которые с гитом никогда не работали? А они есть.

Ответить
1

Элитные "велосипедисты"? Миддл, который не знает гит в 2019, наверное никогда не работал в команде?

Ответить
0

Есть другие системы контроля версий.

Ответить
0

git/mercurial/svn не суть, в тех специализациях, которые сейчас заполнены (веб фронтенд, например) стандартом является именно git. в java-энтерпрайзах гита вполне может не быть, тут у меня нет экспертизы чтобы отвечать.

Ответить
0

Так и писали бы -  требование к миддлу - одно из "git/mercurial/svn". 

Ответить
0

К миддлу фронтенда требования именно знать git. К JAVA-миддлу могут быть другие требования.

Ответить
0

То есть если человек работал над фронтендом и там по определённым причинам использовался Perforce, а с git'ом он не работал и его не видел - то он не имеет права называться миддлом? 

Ответить
0

В те компании, с которыми мы общались при составлении состава грейдов, на миддла без знаний гита фронтендера не возьмут. Задача сервиса дать объективную картину, без крайностей. Понятно что есть особенности у каждой компании, но база то плюс-минус одинаковая.

Ответить
0

 Никогда не видели крутых архитекторов, которые из названий паттернов проектирования знают только "синглетон"?

Крутых? Архитекторов? Нет, не видел. Видел мидлов, которые не знаю названия, но знают реализацию и умеют ими пользоваться. Только никто обычно и не требует "названий", требуют, как раз, реализацию и умение пользоваться. Если человек не знает, что такое "фабрика", но постоянно её использует там, где нужно, ему скажут что-то вроде "хэй, смотри, ты же используешь фабрику!".
Кажется статья не про вызубривание названий, а про скилы, разве нет?

Ответить
0

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

Ответить
0

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

Я смотрел статистику, сколько людей на определённом грейде владеют той или другой технологией. Понятно, что почти 100% Senior Java Developer знают Java (хотя не 100%, были те, кто пишет на Scala или Clojure просто попали в эту должность). Но остальных технологий там даже близко к 100% не было.

Ответить
0

"Грейд был про второе. Первое - менее важно." - Тот случай, когда зарплата по грейдам. 

Ответить
0

Зарплата по грейдам, грейд "по уровню ответственности и способности решать задачи". В итоге зарплата "по уровню ответственности и способности решать задачи". С этим что-то не так?

Ответить
0

Описанная схема не является "хорошей" или "плохой". Это одна из возможных реализаций. Акцент на soft-skills.

Ответить
2

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

Ответить
1

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

Ответить
1

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

Ответить
1

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

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

Ответить
–1

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

Ответить
1

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

Ответить
2

В итоге заказчик берет разработчика в другой компании..

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

Ответить
0

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

Ответить
1

вот довольно известная матрица: https://sijinjoseph.com/programmer-competency-matrix/

кажется своя есть у ЕПАМа, вместе с внутрикорпоративными программами обучения

Ответить
3

Слишком абстрактная и не привязана к технологиям. По факту для каждого направления нужна своя.

Ответить
1

Не скажу за остальные области, так как в них нет опыта, но раздел Java надо дробить по областям ответственности и предметным областям. Например, если это веб, то там свои фреймворки и знания (веб-ИБ, всякий devops и тд), если Bigdata, то свои (map-reduce, hadoop, spark) если ML, то свои и тд.

Ответить
2

В остальных областях тоже надо делить.

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

Ответить
2

 data-science - почему этот скил в мастхев у джуна фронта?))

Этого скила у джуна фронта нет, есть "Computer science (basics)", это совершенно разные вещи.

Ответить
1

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

Ответить
1

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

Ответить
0

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

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

Ответить
0

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

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

Ответить
4

Потому что 3 грейда — мало. Так называемым «джуниором» может быть как тот, кто написал хелоу ворд на Реакте, так и тот, кто пишет на тайпскрипте, нормально верстает, пишет тесты, etc. Грейдов должно быть больше. Но вообще не вижу смысла в этом, роадмапы давно есть — https://github.com/kamranahmedse/developer-roadmap#frontend-roadmap

Ответить
1

Джун/миддл/сеньор это стандартная на рынке структура. Мы у себя в компании дробим еще на уровни (jun1,2,3 и тд), и исходим из того, что джун - тот, кто может работать под контролем более старшего специалиста и может отвечать за свои задачи. Миддл - может самостоятельно решать любые задачи своей зоны ответственности. А Сеньор может брать ответственность еще и за джунов, ревьювить их код и помогать им + разрабатывать общую архитектуру проектов.

Этот роадмэп тоже использовали. По опросу специалистов и общению на собеседованиях заметил кстати, что начинающие почти никогда про него не знают. 

Ответить
1

Хорошо же начали про UX, а закончили про статичный роадмап в картинке. Про этот роадмап знаем, но это не удобно, не гибко, не интерактивно и не так интересно. А это важно в процессе обучения — чтобы было интересно.

В планах есть детализация грейдов более, чем на 3 уровня. Кроме того, если в сервисе появится привязка к потребностям компаний или сфер, то можно развиваться целенаправленно под то, чем интересно заниматься (интересно не Node.js, а Биг дата в медицине, например).

Ответить
0

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

Ответить

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

{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }