Как аккуратно войти в матрицу компетенций: что писать в скиллы?
Ключевая фигня с матрицей компетенций - что писать в скиллы.
Первый подход к снаряду - а давайте напишем то, чему реально нужно научить новичков? Получаем монстра типа такого: http://reqcenter.pro/wp-content/uploads/2017/05/competency_model.jpg
Тыкаемся-тыкаемся, и всё время обнаруживаем, что оценка весьма поверхностная. Сотрудники - разные, они прошли разную историю проектов. А если это ещё и хардкорные инженеры, а вы только-только пробуете запустить оценку - словите кучу троллинга в свой адрес.
Окей, давайте обощим!
Получаем что-то типа https://www.intervolga.ru/upload/medialibrary/cfe/cfe1b345b0493bfe34d7080dc7f766cd.png
Конечно, пример утрирован, чаще всего приходят к чему-то вроде такого: https://docs.google.com/document/d/1FVvoSY35YD4BfAkv-XYGRITFbE17pA7A-R6S76UVsBQ/pub
но проблемы останутся:
- часть реально имеющихся навыков пролетят мимо вашей картинки
- что-то будет слишком общим для вашей реальности
- субъективность оценки для "общих" вещей будет зашкаливать
и, самое плохое: выводы из полученной таблицы будут типа
Что - mysql? Что подтянуть? Нахрена, если в реальной практике у инженера не будет таких задач? Знания, курсы и навыки, которые не востребованы будут забыты уже через две недели.
Я дам вам рецепт, как можно разрубить этот гордиев узел: не надо писать матрицу компетенций. Нужно писать логи и начинать проводить ассесмент на основании этого прогресса. Нужно *выявлять* прогресс людей и хвалить их за этот прогресс, каким бы он ни был. Выявляя - понимать, какие же компетенции нужны компании, чем владеют ваши люди, какие навыки нужно диверсифицировать.
Работа над компетенциями людей начинаются не с матрицы, а с того, что вы методично и правильно учитесь выявлять происходящий сам по себе прогресс.
Ключевая фигня с матрицей компетенций - что писать в скиллы.
Первый подход к снаряду - а давайте напишем то, чему реально нужно научить новичков? Получаем монстра типа такого: http://reqcenter.pro/wp-content/uploads/2017/05/competency_model.jpg
Тыкаемся-тыкаемся, и всё время обнаруживаем, что оценка весьма поверхностная. Сотрудники - разные, они прошли разную историю проектов. А если это ещё и хардкорные инженеры, а вы только-только пробуете запустить оценку - словите кучу троллинга в свой адрес.
Окей, давайте обощим!
Получаем что-то типа https://www.intervolga.ru/upload/medialibrary/cfe/cfe1b345b0493bfe34d7080dc7f766cd.png
Конечно, пример утрирован, чаще всего приходят к чему-то вроде такого: https://docs.google.com/document/d/1FVvoSY35YD4BfAkv-XYGRITFbE17pA7A-R6S76UVsBQ/pub
но проблемы останутся:
- часть реально имеющихся навыков пролетят мимо вашей картинки
- что-то будет слишком общим для вашей реальности
- субъективность оценки для "общих" вещей будет зашкаливать
и, самое плохое: выводы из полученной таблицы будут типа
ну, Вася, надо тебе подтянуть MySQL.Что - mysql? Что подтянуть? Нахрена, если в реальной практике у инженера не будет таких задач? Знания, курсы и навыки, которые не востребованы будут забыты уже через две недели.
Я дам вам рецепт, как можно разрубить этот гордиев узел: не надо писать матрицу компетенций. Нужно писать логи и начинать проводить ассесмент на основании этого прогресса. Нужно *выявлять* прогресс людей и хвалить их за этот прогресс, каким бы он ни был. Выявляя - понимать, какие же компетенции нужны компании, чем владеют ваши люди, какие навыки нужно диверсифицировать.
Работа над компетенциями людей начинаются не с матрицы, а с того, что вы методично и правильно учитесь выявлять происходящий сам по себе прогресс.