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

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

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

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

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

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

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

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

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

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

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

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

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

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

Направления

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

Навыки

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

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

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

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

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 человек.

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

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

^{_{[ссылка удалена мод.]}}