Comments 14
Зачем это вообще нужно? Ну хочется руководству ввести грейдовую систему, так для менеджеров есть объективный показатель в виде их прошлых проектных достижений. А тут такое впечатление, как будто вы пытаетесь оценить толпу людей, о которых вам вообще ничего не известно. А каждый из них ведь наверняка имеет известную и вам, и всем остальным репутацию.
Могу, кстати, занедорого проконсультировать, как получить ачивку #senior "Счастье команды". Правда, результатов у проекта не будет, но это не оценивается.
Конечно, прошлый опыт сотрудника внутри компании — это удобно для управления небольшими командами. Но при обсуждении дальнейшего развития или анализе новых специалистов, хочется иметь более объективную систему чем субъективная репутация.
Объективная система – это рентабельность работы. Вы предлагаете назначить сотруднику больше зарплаты, чем он зарабатывает дохода, на том основании, что он много знает?
Что касается новых специалистов, их грейд будет однозначно следовать из результата зарплатного торга при приёме на работу, тут нет места для вариативности. Если я устраиваюсь к вам на работу, мне пофиг, как вы считаете грейд; у меня есть мои зарплатные ожидания, выраженные в денежных единицах, и именно их я буду добиваться.
Работаю в фирме с несколькими тысячами сотрудников и грейдовой системой, и хочу сказать, что вы всё переусложняете. Грейд выбирается так, чтобы в момент его назначения не получить резкого скачка оплаты труда, вот и всё. Иначе обиженные уволятся, а излишне поощрённые бесполезно растратят деньги собственника.
По-настоящему интересный вопрос состоит не в назначении грейда, а в правилах текущего премирования и перехода между зарплатными и должностными клетками.
Вы хотите полностью посчитать менеджера, при этом осознаете что обьективно оценить софт скилы вы не сможете. Насколько абъективны харды, тоже вопрос. А самое главное, не понятно, как вы разрулите ситуацию когда у менеджера отлично идут проекты, но ему до фанаря, че том с ДНС. Поставите тот же грейд как у менеджера у которого проекты не идут, но он шарит в ДНС. Поверьте мне, не молодому, попытки выстроить KPI которые бы учитывали бы все все-все, никчему хорошему не приводят, народ перестает работать, а начинатет надрачивать на свои KPI. Как бы банально не звучало, выделите минимальное кол-во параметров, и они должны для менеджера быть вообще не софт,и хард - а из области бизнеса. Условно говоря, сколько денег приносит конкретный менеджер, вот что важно для бизнеса. А КАК он это делает - это его дело.
А новых как набрать?
Наврать могут что угодно
для теории конечно очень круто, но на практике получить такие знания, применять их и т.д. очень сложно. Но как некий роадмап - использовать можно. Понравились всякие вещи типа:
Защита идей Agile #senior
Счастье команды #senior
Очень крутое дерево навыков
Но, пожалуй, основная проблема менеджмента
Quis custodiet ipsos custodes?
Без обратной связи, и возможности оценки компетенций менеджмента снизу, любые личные показатели стремятся немедленно потерять объективность, приводя к тому, что менеджеры оцениваются по успешности проекта, вне зависимости от наличия связи с их компетенцией.
Ценность юнита в нашем космическом РПГ зависит в основном от конкретной ситуации, и в меньшей от абстрактных скиллов или экономики отдельных проектов. Есть планово убыточные вещи, требующие особых навыков, но которые дают компании другие плюшки (тот же саппорт). Есть жирные клиенты, где можно собирать монетки вообще не напрягаясь. Есть те, кто хорошо говорит и проходит любые собесы. А есть кто работает работу и за себя, и за остальных товарищей коллег.
Матрица скиллов удобна, чтобы создавать мотивацию для развития этих самых скиллов. Ну или объяснять, почему их зарплата пока не так высока как бы всем нам хотелось (но это прокатывает не со всеми) - на этом вся связь с финансами заканчивается.
Более реалистичную оценку даст рассчет сколько будет стоить замена при наличии более дешёвого кандидата - с обязательной ротацией время от времени, чтобы держать повестку для менеджера актуальной. Можно подкидывать кусок от сэкономленных средств в виде бонуса, чтобы не затосковал.
Я скажу неуютную для многих мысль, но вообще система оплаты труда в коммерческой организации (лишённая коррупции) – это решение задачи поиска максимума рентабельности основного капитала, и не более того. Там в идеале должны быть числовые коэффициенты при денежных суммах, а не всякие умные слова про скиллы.
Другое дело, что, как верно отмечено выше, не все бизнес-процессы имеют проектный характер. В частности, саппорт по своей сути не является проектом. А также формальное деление на проекты не в полной мере отвечает реальности, из-за чего существуют планово-убыточные проекты (в действительности являющиеся частью прибыльной метадеятельности) и т.п.
Карта больше похожа просто на набор всего что может пригодится когда либо, особо я бы уделил внимание IT скилам, но алгоритмы, osi, вы забыли только SIEM и вот все что связано с ИБ и полный комплект.
Если обратиться к PMI и прочим серьёзным организациям работающими с менеджерами мирового уровня там вы такого не найдёте, безусловно менеджер должен знать домпнную область, но не надо ему давать то что ему не нужно, он нанесёт больше вреда чем пользы...
В проектах, любых, все крутится вокруг трех вещей - цели(ожиданий заказчика от проекта), бюджета и ресурсов. Вот ими управляет менеджер, а знания sql+join ему совсем не нужны, он вместо решения своих задач будет постоянно лезть в разработку.
Грейды для менеджеров