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

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

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

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

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

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

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

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

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

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

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

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

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

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

Направления

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

Навыки

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

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

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

 Схема собранная в MindNode
Схема собранная в MindNode

Скиллсет с указанием грейдов

Hard-skills

Project-skills

  • Каскад

    • Планирование этапов

      • Принципы #junior

      • Диаграммы #middle

      • Циклические этапы #middle

      • Контрольные точки #junior

      • Риски #senior

      • Корректировка планов #middle

    • Методики оценок

      • Опора на прошлое #junior

      • Planning poker #junior

      • Нормализованная оценка #middle

      • PERT #senior

      • Декомпозиция #junior

    • Выбор и оценка исполнителей #middle

    • Контроль исполнения #junior

    • Контроль качества #junior

      • V-model

    • Поддержка #middle

  • Agile

    • Ценности

      • Основные идеи #junior

      • Защита идей Agile #senior

      • Проблемы и критика #middle

      • Соответствие ценностям заказчика #senior

    • SCRUM

      • Устройство команды #junior

        • PO

        • SM

        • Dev

      • Спринты и цели спринтов #middle

      • Принципы постановки задач #junior

      • Церемонии

        • Грумминг #middle

        • Планирование #junior

        • Дейли #junior

        • Демо #middle

        • Ретроспективы #middle

      • Счастье команды #senior

    • Kanban-method

      • Основные идеи #junior

      • Отличия kanban / kanban-method #middle

      • Необходимые ограничения #middle

      • Как достигается гибкость? #middle

    • Другой agile #senior

      • DSDM

      • FDD

      • TDD

      • XP

      • Lean SD

  • Практика декомпозиции и планирования #junior

    • Уточнение требований

      • Единичность

      • Завершенность

      • Последовательность

      • Атомарность

      • Отслеживаемость

      • Актуальность

      • Выполнимость

      • Недвусмысленность

      • Обязательность

      • Проверяемость

IT

  • Алгоритмы

    • Синхронные #junior

    • Асинхронные #senior

  • Сети

    • Модель OSI #junior

    • TCP/UDP #middle

    • IP адреса и маски подсетей #middle

    • Домены и DNS #junior

    • VPN #middle

    • Kubernetes #senior

      • Что такое? #middle

      • Docker #middle

      • Особенности Ingress #senior

  • Платформы клиентов

    • Old web #junior

    • SPA #junior

      • CORS #middle

    • Android #junior

    • IOS #junior

    • Desktop #junior

  • Системы контроля версий

    • Git-flow #junior

    • Web-интерфейс #middle

    • Локальное использование

    • Ветки #junior

    • CI/CD #middle

  • SQL

    • Базовые запросы #junior

    • Фильтры и сортировки #middle

    • Join’s #middle

  • Тестирование

    • Разновидности тестирования #junior

    • Оценка времени тестирования #middle

    • Среды #junior

    • Навыки функционального тестирования #addition

    • Приоритезация багов #junior

  • API и его аналитика

    • Виды API #junior

    • Анатомия запросов #junior

    • Авторизация #middle

    • GraphQL #middle

  • 1 язык программирования

    • Синтаксис и базовые концепции #junior

    • Менеджеры пакетов #middle

    • Создание веб-сервера #middle

    • Взаимодействие с базами #senior

  • Интерфейсы, UI и UX

    • Способы оценки UI/UX #junior

    • Подходы к проектированию UI #middle

    • Adaptive web #middle

      • Desktop

      • Mobile

      • Tablet

      • Mobile version

    • Android #junior

      • Особенности навигации

      • Нативные средства интерфейса

    • iOS #junior

      • Особенности навигации

      • Нативные средства интерфейса

  • Excel

    • Базовые операции #junior

    • Формулы #junior

    • Сводные таблицы #middle

    • Макросы #senior

  • Веб-аналитика и метрика

    • Google Analytics #junior

    • Yandex Metrika #junior

    • Firebase #junior

    • Цели #junior

    • Рекламные сервисы #addition

    • Когортный анализ #addition

Soft-skills

Коммерческие

  • Навыки продаж

    • СПИН-продажи #middle

    • Основы маркетинга #middle

  • Ведение деловых переговоров

    • Звонки #junior

    • Личные встречи #junior

    • Групповые встречи #junior

  • Ведение деловой переписки

    • Email #junior

    • Мессенджеры #junior

    • Договора и документы #middle

    • Коммерческие предложения #senior

  • Контроль прозрачности использования ресурсов

    • Результативность #junior

    • Эффективность #junior

    • Производительность #middle

    • Качество #junior #middle

    • Активность исполнителей #junior

    • Затраты типов ресурсов #middle

    • Прибыль #middle #senior

  • Тренды профессиональной сферы и рынка #junior #middle #senior

Командные

  • Решение конфликтов

    • Межличностные #junior

    • Внутрикомандные #middle

    • Межкомандные #middle #senior

  • Лидерство

    • Типы сообществ и их лидеров #junior

    • Вдохновление последователей #middle

    • Независимость #middle

    • Визионерство #senior

  • Проведение встреч

    • Организация #junior

    • Планирование #junior

    • Сбор участников #junior

    • Организация повестки #junior

    • Контроль процесса обсуждения #middle

    • Фиксация результатов встреч #junior

  • Навыки публичных выступлений

    • Устные презентации #junior

    • Графические презентации #middle

    • Ораторское мастерство #senior

  • Общие навыки коммуникации

    • Как завоёвывать друзей и оказывать влияние на людей #junior #middle #senior

  • Фасилитация

    • Практика фасилитации #middle #senior

  • Эмоциональный интеллект

    • Самоуважение #junior

    • Осознанность #middle

    • Самовыражение #junior

    • Эмпатия #middle

    • Гибкость #junior

Product-skills #senior

Для взаимодействия с овнерами

Продуктовое виденье

  • Проблемы которые решает продукт

  • Понимание своего customer

  • Как продукт меняет жизнь customer

  • Какие есть альтернативы

Бизнес-модель продукта

Презентация важности (цели) продукта

Обновление целей

Выстраивание roadmap

  • Майлстоуны

  • Время на развитие

  • Реакции и связи составлящих

Достигаемые продуктом метрики

  • Conversion Rate

  • Customer Acquisition Cost

  • Customer Lifetime Value

  • Growth Rate

  • Return Rate

  • Cancellation Rate

  • Net Promoter Score

  • Daily/Weekly/Monthly Active Users

Заключение

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

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

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

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

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

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

[ссылка удалена мод.]

Комментарии (10)


  1. vadimr
    18.10.2022 14:48
    +4

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

    Могу, кстати, занедорого проконсультировать, как получить ачивку #senior "Счастье команды". Правда, результатов у проекта не будет, но это не оценивается.


    1. Morayg Автор
      18.10.2022 14:55
      -2

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


      1. vadimr
        18.10.2022 15:16
        +5

        Объективная система – это рентабельность работы. Вы предлагаете назначить сотруднику больше зарплаты, чем он зарабатывает дохода, на том основании, что он много знает?

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

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

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


      1. DisM
        18.10.2022 22:57
        +3

        Вы хотите полностью посчитать менеджера, при этом осознаете что обьективно оценить софт скилы вы не сможете. Насколько абъективны харды, тоже вопрос. А самое главное, не понятно, как вы разрулите ситуацию когда у менеджера отлично идут проекты, но ему до фанаря, че том с ДНС. Поставите тот же грейд как у менеджера у которого проекты не идут, но он шарит в ДНС. Поверьте мне, не молодому, попытки выстроить KPI которые бы учитывали бы все все-все, никчему хорошему не приводят, народ перестает работать, а начинатет надрачивать на свои KPI. Как бы банально не звучало, выделите минимальное кол-во параметров, и они должны для менеджера быть вообще не софт,и хард - а из области бизнеса. Условно говоря, сколько денег приносит конкретный менеджер, вот что важно для бизнеса. А КАК он это делает - это его дело.


  1. GromovBI
    18.10.2022 14:55

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

    Защита идей Agile #senior
    Счастье команды #senior


  1. sunnybear
    18.10.2022 15:36

    Очень крутое дерево навыков


  1. Lexicon
    18.10.2022 16:00

    Грейды выглядят вполне разумными.
    Но, пожалуй, основная проблема менеджмента

    Quis custodiet ipsos custodes?

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


  1. funca
    18.10.2022 16:32
    +1

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

    Матрица скиллов удобна, чтобы создавать мотивацию для развития этих самых скиллов. Ну или объяснять, почему их зарплата пока не так высока как бы всем нам хотелось (но это прокатывает не со всеми) - на этом вся связь с финансами заканчивается.

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


  1. vadimr
    19.10.2022 11:20

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

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


  1. reinmaker1990
    21.10.2022 09:06

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

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