HR HRу рознь. Обычно, чем крупнее компания, тем формальнее процесс найма разработчиков. Мы не говорим, что отсутствие профильного диплома является стоп-фактором, и так же не говорим, что его наличие открывает все двери. Но то что сегодня почти в каждом техническом ВУЗе работают представители IT-компаний (проводятся курсы, олимпиады, читаются лекции, предоставляются программы прохождения производственной практики и т.д.) вряд ли вызовет споры. И часто вместе с дипломом можно получить еще и офер в одну из этих компаний. А вот после курсов или самостоятельного обучения, доказывать свои технические навыки придется с нуля.
Так же не забываем, что фундаментальные знания, которыми как раз и пренебрегают зачастую отрицающие высшее образование, не сильно влияют в начале карьерного пути, но прямо или косвенно задействуются уже на синьорных уровнях. Умение системно мыслить, работать с дедлайнами, искать нестандартные пути решения проблем, делать необходимые задачи, которые тебе не сильно нравятся, да и просто наличие широкого кругозора - важные навыки для айтишников высокого уровня. И да, их можно освоить самостоятельно, но зачем, если есть специальные места и люди, которые помогут сделать это куда быстрее и качественнее.
Это самое сложное. Большая часть всегда остается непроверенной. Но есть моменты, которые можно уточнить. Например, был ли у кандидата опыт менторства или обучения, общения с заказчиком, проведения собеседований, выступления внутри или вне компании и т.д. На такие вещи как коммуникабельность, умение рассуждать и доносить свою мысль можно обратить внимание если задавать дискуссионные вопросы.
Вообще в МК мы стараемся вносить только такие формулировки софт-скиллов, которые хоть как-то можем измерить. Например, у нас в ней нет таких компетенций, как Ответственность, Зрелость, Адекватность и т.п. Они очень субъективные и их тяжело будет оценить. А вот, например, какой-нибудь Тайм-менеджмент уже поддается оценке, как минимум можно проверить знание основных подходов, узнать о личных практиках или попросить спланировать день.
Софт-скиллы - это такие же навыки, как умение писать код на любимом языке программирования. Самое главное, чтобы в матрицу не попадали абстрактные понятия. Нужно для каждой компетенции иметь хоть какую-то шкалу дл измерения.
Теперь понятно)) От подтверждения компетенций вы перешли к аттестации зрелости. У нас сейчас тоже начались разговоры в эту сторону, но пока не придумали как это сделать не снижая градус объективности. Спасибо, что поделились опытом, для нас очень полезно!
У вас вообще нет подтверждения? Опираетесь только на самооценку сотрудника? И как вообще выглядит процесс смены грейда? Поделитесь, пожалуйста, если это возможно. Очень интересно!
По поводу второго апдейта. У нас такие были. Грейд и ЗП снизить мы не можем, да и не хотим к этому прибегать. А вот дальнейший рост одного и второго уже зависит от получения конкретных навыков и качеств. И тут компания оказывала помощь в формировании плана развития, покупала курсы и другие учебные материалы. А дальше уже выбор самого сотрудника.
Это та самая первая версия, которую мы собрали. У нас она с тех пор немного поменялась, но как фундамент более чем подходит. Есть бонус - таблицы для проведения интервью. У нас они работают до сих пор.
Идеальных инструментов не существует. Процесс доработок и эволюции бесконечен. Если есть идеи по улучшению, очень буду рад послушать и, возможно, применить на практике.
В матрице нет особого смысла, если целевая группа маленькая. У нас было несколько разных направлений открыто и каждой шло по одному и тому же пути: сначала приходит крутой специалист, вокруг него собирается команда, вместе они начинают заниматься проектом, затем формируются видение будущего этого направления в рамках компании и потребность в конкретных скиллах. И вот только на этом этапе зарождаются матрица компетенций. Но и тут стоит учесть, что если дальнейшего роста численности этой группы не планируется, то и матрицу может заменить простой список требований, как в вакансиях обычно пишут.
Заполняет новую матрицу всегда технический лид, затем она проходит ревью у тимлидов и синьоров. Так формируется первая версия, которую заполняют несколько представителей разных грейдов. После калибровки получается готовый инструмент. Важно помнить, что сложность технологий не всегда пропорциональна важности для конкретной компании. То, что у одих может быть в строке стронг мидла, у других может быть для синьора или даже стронг синьора. Калибровка под текущее реальное состояние команды обязательна.
Специально выделенного периода для актуализации матрицы нет. Она обновляется по запросам, чаще всего самих сотрудников. У разработчиков чаще, у тестировщиков и аналитиков реже, у HR и PM крайне редко. Так как инструмент используется часто и во многих процессах, матрица обновляется естественным путем непрерывно. Например, появляется 2-3 проекта с новой технологией или версией. Вопросы по ней нужно использовать при собеседованиях. Интервьюеры просят добавить в матрицу. Или так бывает при повышении грейда, когда приходит понимание, что какие-то темы перестали затрагиваться, так как потеряли актуальность. Убираем их или актуализируем формулировки.
Уровень формализма целенаправленно контролируется. Даже сами определения компетенций сильно абстрактнее, чем могли бы быть. Весь этот процесс после его становления помог не только во взаимодействии внутри команды, но даже больше при коммуникация между разными отделами. Если брать МК со трудников из производства (разработчики, тестировщики, аналитики, дизайнеры и пр.), то взаимодействие на уровне продаж и руководством проекта/продукта вышло на другой уровень.
Этот инструмент как и все остальные не идеален и имеет ряд своих минусов, один из них, да, дополнительная бюрократия. Но в нашем случае игра стоила свеч. Вангую, что не все, но кому-то этот опыт, надеюсь, будет полезен и применим.
Формализуется не сотрудник, а видение той роли, которую он занимает в глазах всех людей, работающих с ним. Это дает, например, возможность однозначно понимать кто, какого уровня и с какими навыками придет в проект, если была объявлена вакансия на стронг мидла. Или, например, утвержденный кандидат с рынка точно подойдет в любой проект без дополнительных собеседований. Когда все однозначно понимают что из себя представляет грейд, это ускоряет коммуникацию, уменьшает ошибки в следствие недопонимания и помогает экономить время на формальных процедурах. Проще один раз провести внутреннее собеседование на грейд, чем каждый раз собеседовать в новый проект.
Что касается необходимости этих самых собесов на грейд, то, к сожалению, оценить себя объективно и трезво могут далеко не все. Одно дело думать, что в чем-то разбираешься, а другое - действительно разбираться в этом. К тому же, сам факт общения на определенные темы со старшим коллегой, позволяет поднимать новые вопросы и посмотреть на те же задачи с другой стороны, это очень полезно для профессионального роста.
Матрица - это и есть в каком-то смысле roadmap. Более конкретный, чем обычно, с возможностями маневрирования в пути, но все-таки roadmap. Но доходят до очередного чекпоинта сотрудники примерно в одном состоянии. Это дает предсказуемость и управляемость на уровне отдела или компании. Но, с другой стороны, матрица не является жесткой трубой, по которой пролезают все сотрудники, превращаясь в одинаковые безликие ресурсы. Можно выбирать направления развития, менять технологии, да и отделы в конце концов, тут ограничений нет.
По плану развития: у нас он на 100% добровольный. Его заполняет меньше трети сотрудников. Это инструмент который помогает расти и развиваться тем, кому это действительно нужно. Там была проделана не меньшая работа для выстраивания всех процессов, которая заслуживает, наверно отдельной статьи. Тут мне хотелось показать важный момент - матрица не только показывает общую картину, но так же помогает найти в ней свой уникальный путь, обозначить его и контролировать свой прогресс.
HR HRу рознь. Обычно, чем крупнее компания, тем формальнее процесс найма разработчиков. Мы не говорим, что отсутствие профильного диплома является стоп-фактором, и так же не говорим, что его наличие открывает все двери. Но то что сегодня почти в каждом техническом ВУЗе работают представители IT-компаний (проводятся курсы, олимпиады, читаются лекции, предоставляются программы прохождения производственной практики и т.д.) вряд ли вызовет споры. И часто вместе с дипломом можно получить еще и офер в одну из этих компаний. А вот после курсов или самостоятельного обучения, доказывать свои технические навыки придется с нуля.
Так же не забываем, что фундаментальные знания, которыми как раз и пренебрегают зачастую отрицающие высшее образование, не сильно влияют в начале карьерного пути, но прямо или косвенно задействуются уже на синьорных уровнях. Умение системно мыслить, работать с дедлайнами, искать нестандартные пути решения проблем, делать необходимые задачи, которые тебе не сильно нравятся, да и просто наличие широкого кругозора - важные навыки для айтишников высокого уровня. И да, их можно освоить самостоятельно, но зачем, если есть специальные места и люди, которые помогут сделать это куда быстрее и качественнее.
Это самое сложное. Большая часть всегда остается непроверенной. Но есть моменты, которые можно уточнить. Например, был ли у кандидата опыт менторства или обучения, общения с заказчиком, проведения собеседований, выступления внутри или вне компании и т.д. На такие вещи как коммуникабельность, умение рассуждать и доносить свою мысль можно обратить внимание если задавать дискуссионные вопросы.
Вообще в МК мы стараемся вносить только такие формулировки софт-скиллов, которые хоть как-то можем измерить. Например, у нас в ней нет таких компетенций, как Ответственность, Зрелость, Адекватность и т.п. Они очень субъективные и их тяжело будет оценить. А вот, например, какой-нибудь Тайм-менеджмент уже поддается оценке, как минимум можно проверить знание основных подходов, узнать о личных практиках или попросить спланировать день.
Софт-скиллы - это такие же навыки, как умение писать код на любимом языке программирования. Самое главное, чтобы в матрицу не попадали абстрактные понятия. Нужно для каждой компетенции иметь хоть какую-то шкалу дл измерения.
Теперь понятно)) От подтверждения компетенций вы перешли к аттестации зрелости. У нас сейчас тоже начались разговоры в эту сторону, но пока не придумали как это сделать не снижая градус объективности. Спасибо, что поделились опытом, для нас очень полезно!
У вас вообще нет подтверждения? Опираетесь только на самооценку сотрудника? И как вообще выглядит процесс смены грейда? Поделитесь, пожалуйста, если это возможно. Очень интересно!
По поводу второго апдейта. У нас такие были. Грейд и ЗП снизить мы не можем, да и не хотим к этому прибегать. А вот дальнейший рост одного и второго уже зависит от получения конкретных навыков и качеств. И тут компания оказывала помощь в формировании плана развития, покупала курсы и другие учебные материалы. А дальше уже выбор самого сотрудника.
Спасибо что спросили! Ссылка должна была быть в тексте статьи, забыли добавить. Исправляюсь. https://docs.google.com/spreadsheets/d/1pNpi49LxiPlIp_dmtcM3doD5hhH9MIf9yX5GiaNwlQM/edit#gid=1335088504
Это та самая первая версия, которую мы собрали. У нас она с тех пор немного поменялась, но как фундамент более чем подходит. Есть бонус - таблицы для проведения интервью. У нас они работают до сих пор.
Владимир, спасибо!
Идеальных инструментов не существует. Процесс доработок и эволюции бесконечен. Если есть идеи по улучшению, очень буду рад послушать и, возможно, применить на практике.
В матрице нет особого смысла, если целевая группа маленькая. У нас было несколько разных направлений открыто и каждой шло по одному и тому же пути: сначала приходит крутой специалист, вокруг него собирается команда, вместе они начинают заниматься проектом, затем формируются видение будущего этого направления в рамках компании и потребность в конкретных скиллах. И вот только на этом этапе зарождаются матрица компетенций. Но и тут стоит учесть, что если дальнейшего роста численности этой группы не планируется, то и матрицу может заменить простой список требований, как в вакансиях обычно пишут.
Заполняет новую матрицу всегда технический лид, затем она проходит ревью у тимлидов и синьоров. Так формируется первая версия, которую заполняют несколько представителей разных грейдов. После калибровки получается готовый инструмент. Важно помнить, что сложность технологий не всегда пропорциональна важности для конкретной компании. То, что у одих может быть в строке стронг мидла, у других может быть для синьора или даже стронг синьора. Калибровка под текущее реальное состояние команды обязательна.
Специально выделенного периода для актуализации матрицы нет. Она обновляется по запросам, чаще всего самих сотрудников. У разработчиков чаще, у тестировщиков и аналитиков реже, у HR и PM крайне редко. Так как инструмент используется часто и во многих процессах, матрица обновляется естественным путем непрерывно. Например, появляется 2-3 проекта с новой технологией или версией. Вопросы по ней нужно использовать при собеседованиях. Интервьюеры просят добавить в матрицу. Или так бывает при повышении грейда, когда приходит понимание, что какие-то темы перестали затрагиваться, так как потеряли актуальность. Убираем их или актуализируем формулировки.
Уровень формализма целенаправленно контролируется. Даже сами определения компетенций сильно абстрактнее, чем могли бы быть. Весь этот процесс после его становления помог не только во взаимодействии внутри команды, но даже больше при коммуникация между разными отделами. Если брать МК со трудников из производства (разработчики, тестировщики, аналитики, дизайнеры и пр.), то взаимодействие на уровне продаж и руководством проекта/продукта вышло на другой уровень.
Этот инструмент как и все остальные не идеален и имеет ряд своих минусов, один из них, да, дополнительная бюрократия. Но в нашем случае игра стоила свеч. Вангую, что не все, но кому-то этот опыт, надеюсь, будет полезен и применим.
Формализуется не сотрудник, а видение той роли, которую он занимает в глазах всех людей, работающих с ним. Это дает, например, возможность однозначно понимать кто, какого уровня и с какими навыками придет в проект, если была объявлена вакансия на стронг мидла. Или, например, утвержденный кандидат с рынка точно подойдет в любой проект без дополнительных собеседований. Когда все однозначно понимают что из себя представляет грейд, это ускоряет коммуникацию, уменьшает ошибки в следствие недопонимания и помогает экономить время на формальных процедурах. Проще один раз провести внутреннее собеседование на грейд, чем каждый раз собеседовать в новый проект.
Что касается необходимости этих самых собесов на грейд, то, к сожалению, оценить себя объективно и трезво могут далеко не все. Одно дело думать, что в чем-то разбираешься, а другое - действительно разбираться в этом. К тому же, сам факт общения на определенные темы со старшим коллегой, позволяет поднимать новые вопросы и посмотреть на те же задачи с другой стороны, это очень полезно для профессионального роста.
Матрица - это и есть в каком-то смысле roadmap. Более конкретный, чем обычно, с возможностями маневрирования в пути, но все-таки roadmap. Но доходят до очередного чекпоинта сотрудники примерно в одном состоянии. Это дает предсказуемость и управляемость на уровне отдела или компании. Но, с другой стороны, матрица не является жесткой трубой, по которой пролезают все сотрудники, превращаясь в одинаковые безликие ресурсы. Можно выбирать направления развития, менять технологии, да и отделы в конце концов, тут ограничений нет.
По плану развития: у нас он на 100% добровольный. Его заполняет меньше трети сотрудников. Это инструмент который помогает расти и развиваться тем, кому это действительно нужно. Там была проделана не меньшая работа для выстраивания всех процессов, которая заслуживает, наверно отдельной статьи. Тут мне хотелось показать важный момент - матрица не только показывает общую картину, но так же помогает найти в ней свой уникальный путь, обозначить его и контролировать свой прогресс.