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