{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Грейды для менеджеров

У нас, в компании FINCH, у каждого из отделов есть система грейдов. Система предназначенная для оценки навыков специалистов и зарплатной вилки на которую они могут претендовать, в зависимости от выполняемых задач и роли занимаемой в проекте.

До последнего времени у отдела менеджеров не было такой системы и это вызывало непредсказуемые решения в управлении кадрами и распределении проектов.

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

Что в основе системы

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

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

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

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

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

Другие экзистенциальные рассуждения

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

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

Надо основываться на направлениях

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

Направления

Проектный менеджмент состоит из разных областей знаний, каскадные и гибкие методологии, гибридные модели. Уровень погружения на каждому уровню требуется разный, как правильно выделить необходимые компоненты для каждого грейда?

Навыки

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

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

Текущая схема навыков менеджеров

VC не дает загрузить большую картинку

Полный список скиллов читайте на habr.com, там более функциональный редактор текстов.

Заключение

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

Проблему которую я не решил в процессе установки грейдов — это необходимость оценки использования тех или иных практик в проектах. Как объективно оценивать используемые знания в той или иной технологии.

PS. У меня нет идей как оценивать софты

Из открытых вопросов — как объективно оценивать софт-скиллы? В текущей оценке, я пропустил учет софт-скиллов, предложив менеджерам самостоятельно изучить предложенный список и сделать самостоятельные выводы. Есть идея использовать тесты, включающие принятие решений в различных ситуациях, но подобная идея кажется очень объемной для создания подобной системы в отделе размером менее 10 человек.

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

продолжение следует

Компания FINCH

0
3 комментария
Boris Vecherkin

Мдаааа

Ответить
Развернуть ветку
Антон Васильев

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

Ответить
Развернуть ветку
Илья Калугин
Автор

Привязать премию к финансовым показателям проекта довольно просто, но это требует тоже проработанной методологии, так как вызывает дополнительные конфликты.
Конфликты между менеджерами, при распределении проектов и сотрудников. Так же я думаю это усилит конфликты с командой.

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда