У нас, в компании 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 человек.
Если кто-то из читателей уже ходил той же дорогой и может подсказать авторов, которых стоит изучить, прошу подсказать в комментариях.
продолжение следует
[ссылка удалена мод.]
