Предисловие
«Вы заметили, какое сейчас время? Новая эра, новая эпоха. Век открытых, доступных знаний – было бы желание, как говорится. Все больше и больше людей как будто просыпаются, выходят из длительного сна, состояния стагнация»1 - цитата из книги.
«Без знаний о совокупности талантов и данных, дарованных нам при рождении жизнь похожа на заблудившийся в открытом море корабль»2- взято с одного сайта про Матрицу Судьбы. Почему-то некоторые цитаты, относящиеся к Матрице Судьбы очень хорошо подходят к Матрице Компетенций. Интересно…
Введение
Вопрос грейдов всегда волнует тех, кто занимается разработкой ПО. Как понять самому, а главное доказать руководству, что ты находишься на новом уровне со всеми вытекающими последствиями? Многие из нас интроверты, и идти доказывать что-то кому-то – мало кто хочет. Как убрать фактор “хороших отношений” с руководством у коллег? Да и вообще хочется объективности и прозрачности критериев. Именно этим мы руководствовались в “Рексофт”, когда задумывали такой инструмент как “Матрица компетенций” (МК). Именно про него я хочу вам немного рассказать. Разберёмся в том, что это такое и с чем его едят. Чтобы не быть голословным, посмотрим на реальный пример матрицы, которая активно используется в компании. Возьмем матрицу компетенций Android-программиста, которую я (Олег Иванов, руководитель группы мобильной разработки компании «Рексофт») когда-то составил и стараюсь поддерживать в актуальном виде.
Матрица, грейды, категории и компетенции
Не буду детально останавливаться на том, какие были предпосылки для создания МК. Есть довольно хорошая статья от моих коллег, где подробно описаны первопричины, послужившие появлению матриц компетенций в “Рексофт”.
Матрица компетенций – это, как видно из названия, набор навыков, в нашем случае специалиста в той или иной области. Почему матрица? Потому что МК представляет из себя прямоугольную таблицу, состоящую из строк и столбцов. Звучит довольно просто! Давайте заглянем внутрь.
В нашей компании есть грейды. Грейд – это звание, уровень подготовки программиста, тестировщика, аналитика, девопса и т.д.
Немного о грейдах. Например, у программистов мы выделяем такие грейды: Intern, Junior, Strong Junior, Middle, Strong Middle, Senior, Strong Senior, Expert. Есть также более «специфичные»: Architect и Team Lead. Промежуточные ступени с приставкой Strong выделяются для того, чтобы сотруднику было проще повысить свой грейд, а компании – более точно определить его уровень. Допустим, повысить уровень с Junior до Middle сразу довольно сложно, между ними большой разрыв по количеству знаний и опыту. А получить вначале Strong Junior, а после Middle – выглядит как более простая и структурированная задача. Тем более, что уровень заработной платы у Strong Junior выше чем у Junior. Как раз-таки грейд и является тем самым столбцом в матрице.
В строках располагается группа компетенций или, проще говоря, категория. Компетенция в нашем случае – это навык, знание, умение или качество. Компетенцией может быть «Умение делать xml-вёрстку» макета экрана, «Знание всех примитивных типов в Java». Также в каждой матрице у нас есть категории Soft Skills, навыки работы в команде, руководительские навыки. Ведь хороший специалист – это не только про технологии.
Все компетенции, для удобства восприятия, объединены в категории. Категориями может выступать – язык программирования, фреймворк, работа с UI, Soft Skills, сертификация и т.д. Это зависит от конкретной специализации сотрудника и от количества критериев в матрице. Где-то категории чуть более обширны, чем в МК по другим специализациям.
«Это – наше предназначение, распространить эту ценнейшую информацию и помочь людям найти ответы на свои вопросы и найти главное предназначение человека в мире на его карьерном пути»2– с того же сайта. «Мы точно знаем, что каждый человек уникален. Узнай именно свой путь с методикой Матрица судьбы Матрица компетенций»2.
Внешний вид
Вот так выглядит матрица компетенций Android-программиста в компактном виде. Тут видны названия грейдов в сокращённом виде и группы компетенций. Для компактности набор критериев для каждого грейда обозначен одной ячейкой "по уровню заполненности". Реальная матрица не влезла бы на экран и была бы нечитабельна.
Строки Architect и Team Lead находятся в процессе наполнения. Пока мы применяем данную матрицу к сотрудникам с грейдами от Intern до Expert.
Оценка
Сразу оговорюсь. Все руководители оценивают компетенции в своих матрицах по-разному. Подробнее об этом можно почитать в статье, которую я упомянул в начале. Это связано с особенностями разработки, структурой матрицы и многими другими вещами. Например, вряд ли один фронтенд-программист будет одновременно хорошо знать Angular, React, Node, Vue и ещё кучу других фреймворков и библиотек, да и нужно ли ему это для работы? Возможно, что он хочет сконцентрироваться на конкретных двух-трёх.
Разработчик не должен обладать абсолютно всеми компетенциями конкретного грейда, чтобы заслужить его. Есть определённое дифференцирование. Применительно к матрице Android-разработки, для грейда Middle нужно обладать где-то 65% компетенций из категории Middle, более 80% в категориях Junior и Strong Junior, 100% компетенций из уровня Intern и желательно 5-10% - из уровня Strong Middle. У каждой компетенции есть своя оценка в баллах, зависящая от сложности и «полезности» это самой компетенции. Соответственно, у каждой строки грейда – есть своя оценка в баллах. В процессе оценки на основе процентов, указанных выше, получается балл, необходимый для достижения заданного грейда.
То есть, оценка, указанная выше, применяется для подсчёта необходимого количества баллов для достижения грейда, но набраны эти балы могут по-разному. Условно, закрытие компетенций по такому принципу: 45% для каждой из категорий Intern, Junior, Junior+, Middle и 35% из Middle+ – также будут соответствовать грейду Middle.
Стоит отметить, что все грейды, категории и критерии – видны пользователям системы, то есть сотрудникам, к которым они применяются. Это позволяет им сразу понять, чего от него хочет работодатель. Так называемая «полезность» навыка обычно определяется по принципу спроса и предложения от бизнес-проектов. Чем чаще нужен навык на проектах, и чем меньше сотрудников им владеет – тем он ценнее.
В целом, с течением времени и с появлением новых технологий, с учётом результатов прохождения матрицы конкретными сотрудниками – матрица корректируется. Добавляются новые критерии оценки, меняется вес у существующих критериев и меняется алгоритм подсчёта баллов для достижения конкретного грейда.
Матрица расположена на нашем внутреннем корпоративном портале и любой сотрудник направления может легко её посмотреть, оценить себя, задать по ней вопросы руководителю, обсудить, что ему необходимо прокачать для повышения грейда. При этом рядовой сотрудник видит только свою матрицу. Конфиденциальность соблюдается.
Не буду подробно рассказывать обо всех категориях с их названиями – получится очень долго и нудно много. Для примера давайте рассмотрим одну из категорий. Возьмём категорию «Архитектура».
Пример категории
На позицию Intern в этой категории достаточно знания принципов SOLID и основных принципов ООП. У сотрудника должно быть понимание, что такое приложение, модуль, библиотека, что означает слово import.
На позицию Junior – необходимо непросто знать расшифровку SOLID и ООП, а уже понимать что это такое и зачем нужно. Для SOLID, помимо расшифровки, нужно уметь подробно объяснить каждый из принципов, желательно с примерами. Применять эти принципы на практике. Также на этом уровне надо понимать принципы KISS, YAGNI, DRY, иметь поверхностное представление о Kotlin Code Conventions, знать и использовать парочку шаблонов проектирования (например, Singleton и Observer).
В свою очередь Middle-разработчик должен понимать концепцию Clean Architecture со всеми слоями, понимать отличия между архитектурными паттернами MVC/MVP/MVI/MVVM, иметь хороший практический опыт работы хотя бы с одним из них. Знать, уметь объяснить, пользоваться «базовыми» шаблонами проектирования, такими как адаптер, строитель, итератор, фасад и т.д. Подразумевается, что на этом уровне программист знаком с моделью памяти, работой сборщика мусора (GC), понимает Google Style Guide.
В грейде Strong Senior располагаются такие критерии: умение доходчиво объяснить принцип работы и необходимость использования конкретного шаблона проектирования; знание паттернов Состояние, Компоновщик, Мост; хорошее знание хотя бы одной библиотеки DI (в случае Dagger, умение работать с Hilt), умение писать переиспользуемый для других платформ код (слой), понимание отличий между minor и major collection в GC.
Заполнение матрицы
Матрица Компетенций, как и Матрица Судьбы нужна в следующих случаях: «ищешь свое предназначение; хочешь раскрыть свой потенциал и открыть в себе таланты; хочешь начать новую успешную карьеру; знаешь, какой жизнью хочешь жить, но не знаешь, как этого достигнуть»2.
При заполнении матрицы сотрудник самостоятельно оценивает свои знания по каждому критерию. Для удобства заполнения МК - необязательно заполнять всю матрицу сразу. Можно заполнять её по столбцам (категориям) или по строкам (грейдам). Например, появился у тебя свободный час – оценил свои компетенции в области архитектуры android-приложения, а на следующий день – знания работы с активити и фрагментами.
При заполнении МК будет выглядеть следующем образом:
Балл засчитывается только за те критерии, которые сотрудник знает. После заполнения матрицы она попадает к его руководителю или куратору матрицы. Тот в свою очередь подтверждает или отклоняет критерий. Если куратор не уверен в знании какого-то из критериев разработчиком – он приглашает его на встречу/собеседование и уже в процессе встречи принимает решение.
Выводы
Данный подход и МК в целом призваны обеспечить наиболее объективную оценку сотрудника, а также показать, чего же хочет от вас работодатель на каждом этапе вашей карьеры.
Да, человеческий фактор в лице куратора, конечно же, остаётся. Но появляются вполне чёткие, структурированные и всеобъемлющие критерии оценки способностей сотрудника. Теперь сотруднику нет нужды бегать к своему руководителю, тим-лиду, спрашивать коллег: «А как мне повысить свой грейд?», ему достаточно изучить матрицу и начать действовать! А в случае возникновения каких-то споров или разногласий – под рукой всегда есть доказательная база в виде МК.
А что думаете вы по поводу такого подхода? Какие плюсы и минусы видите. Напишите в комментариях. Будем рады услышать мнение со стороны.
Послесловие
Пока я писал эту статью, «рассчитал» для себя в онлайне Матрицу Судьбы. И вот, что она мне «рассказала»:
«Плохо, если вы накапливаете знания в себе и не отдаете их, не используете на благо людей»2.
«Между тем, более простое, сердечное отношение к людям может помочь в достижении целей больше, чем фактическая информация и логические доводы от вас»2.
Надеюсь, я рассказал всё довольно подробно, поделился знаниями. Логических доводов, разумеется, не будет. Всех поднял, обнял от чистого сердца! Ставьте «плюсики» статье, не хочу, чтобы у меня остался кармический долг.
Ссылки
1) Матрица Судьбы для начинающих, Альбина Матрикс, 2022г, 16+
2) https://matritsa-sudbi.ru
Комментарии (2)
AlexSteelax
18.05.2023 08:52Не раз встречал синьоров, которые и за солид и за ООП и за паттерны пояснить могут, а как открываешь и смотришь их код возникает вопрос: ну и где это всё? Что за фигня, Джонни?
quaer
А как звучит компетенция "ничего не умею, но если надо, напишу приложение"?
Вообще загадка как можно быть экспертом в чём-то при программировании для Android кроме как в копании на Stackoverflow в поиске ответа на вопрос "как сделать" или "почему не работает".