У нас, в компании FINCH, у каждого из отделов есть система грейдов. Система предназначенная для оценки навыков специалистов и зарплатной вилки на которую они могут претендовать, в зависимости от выполняемых задач и роли занимаемой в проекте. До последнего времени у отдела менеджеров не было такой системы и это вызывало непредсказуемые решения в управлении кадрами и распределении проектов. Этим летом, когда количество менеджеров увеличилось, руководством было принято решение реализовать распределение менеджеров по грейдам в соответсвии с их навыками.  Главный вопрос который необходимо было решить мне, руководителю отдела, от чего отталкиваться при разработке этой системы? В работе любого специалиста сходится множество факторов. Это знания, навыки, вовлеченность, коммуникация, ответственность. Что из этого является ключевым при разработке системы грейдов? Во многих технических специальностях во главу угла ставятся как знания различных технологий, так и глубина знаний в каждой из них. Но на технологиях различного уровня хайпа можно реализовывать продукты одинакового качества, это не определяет качество продуктов, только сферу применения специалиста. Умение использовать свой опыт в работе является необходимым условием развития специалиста, обширный опыт и широкий набор навыков позволяет специалисту выбирать оптимальные пути решения задачи. Для менеджера, как и для любого специалиста необходимо принимать правильные решения при планировании, и для этого нужен опыт использования технологий. Да, опыт важен. С точки зрения знаний необходимых менеджеру, являются методологии. Подходы и средства используемые менеджером проектов определяет используемая методология. Но делает ли следование правилам члена команды хорошим менеджером? Как объективно оценить использует ли человек в своей работе свой багаж знаний и опыта? Или каждая новая технология — это строчка в резюме и ничего больше? Мы ведем разные проекты, на разных проектах разные заказчики и разные методологии. Менеджер отлично показывающий себя в каскадных методах ведения проектов может не иметь понимания agile, а ПМ отлично совмещающий роль скрам-мастера, не иметь опыта работы на проектах с продолжительным последовательным планированием. Но они могут быть одинаково полезны на разных проектах. В процессе этих размышлений, мне захотелось сделать систему, похожую на диаграмму навыков из космической РПГ, в которой видно распределение особенностей каждого специалиста. Систему, где для обозначения сильных и слабых сторон используется круговая диаграмма, которая будет показывать наглядно как отличаются навыки специалистов одного и того же грейда. Соответственно необходимо распределить все навыки, которые влияют на ценность специалиста для компании по направлениям и оценить их вхождение в определенный грейд. Тогда будет возможность оценить умения по каждом направлению и выстроить диаграмму, по которой будет понятно, что блокирует специалиста, а что является сильными сторонами, по которым он превосходит свой грейд. Проектный менеджмент состоит из разных областей знаний, каскадные и гибкие методологии, гибридные модели. Уровень погружения на каждом уровне требуется разный, как правильно выделить необходимые компоненты для каждого грейда? Навыки проектного менеджера должны состоять из знаний и навыков не только в менеджменте, но и в профессиональной области, в которой он ведет свои проекты. В нашем случае это IT. Как определить какой погружение достаточно для менеджера? В какие области необходимо погружение? По моему мнению, любому специалисту тем проще и эффективнее работать и коммуницировать с коллегами, чем глубже он погружен в их предметную область. Поэтому чем лучше менеджер разбирается в разработке, доставке, тестировании, дизайне, тем проще ему управлять проектами, включающими эти этапы. Каскад Планирование этапов Принципы #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 Уточнение требований Единичность Завершенность Последовательность Атомарность Отслеживаемость Актуальность Выполнимость Недвусмысленность Обязательность Проверяемость Алгоритмы Синхронные #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 Навыки продаж СПИН-продажи #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 Для взаимодействия с овнерами Проблемы которые решает продукт Понимание своего customer Как продукт меняет жизнь customer Какие есть альтернативы Майлстоуны Время на развитие Реакции и связи составлящих Conversion Rate Customer Acquisition Cost Customer Lifetime Value Growth Rate Return Rate Cancellation Rate Net Promoter Score Daily/Weekly/Monthly Active Users В первой вариации я распределил как оцениваю необходимость каждого из навыков — к грейдам, но в дальнейшем я планирую свести эти показатели к среднему арифметическому по навыкам менеджеров в компании, которые теперь получили грейды. Проблему, которую я не решил в процессе установки грейдов — это необходимость оценки использования тех или иных практик в проектах. Как объективно оценивать используемые знания в той или иной технологии. PS. У меня нет идей как оценивать софты Из открытых вопросов — как объективно оценивать софт-скиллы? В текущей оценке, я пропустил учет софт-скиллов, предложив менеджерам самостоятельно изучить предложенный список и сделать самостоятельные выводы. Есть идея использовать тесты, включающие принятие решений в различных ситуациях, но подобная идея кажется очень объемной для создания подобной системы в отделе размером менее 10 человек. Если кто-то из читателей уже ходил той же дорогой и может подсказать авторов, которых стоит изучить, прошу подсказать в комментариях. продолжение следует   Менеджер проектов