О чем поговорим?

Всем привет! Сегодня в статье мы обсудим, что такое Центр Компетенций (далее ЦК), и как он делает жизнь менеджера и tech/team лида проще.

Вы найдете ответы на вопросы:

• Как получить в команду именно того сотрудника, который тебе нужен?
• Как вырастить из своей команды суперменов?
• Как ЦК добавит счастья не только лиду, но и разработчику?
• В каких компаниях стоит внедрять ЦК и как “продать” эту идею руководству?
• Как внедрить ЦК у себя?

И конечно же расскажем о нашем опыте внедрения ЦК.

Что такое ЦК (кратко)

ЦК - это специальный отдел, который занимается развитием сотрудников и не дает им заскучать.

Позже обсудим подробнее…

Проблемы при найме и развитии

Обычно сотрудник в компании проходит через такие этапы, как найм и адаптация, работа и развитие, и в конце увольнение. Принимая во внимание эти этапы, мы можем сформировать список вопросов, связанных с развитием сотрудника. Такие вопросы обычно возникают у людей на должностях manager/pm, tech/team lead и hr.

Итак:

• Как оценить будущего сотрудника, чтобы предложить адекватную заработную плату, соответствующую навыкам и рынку?
• Как помочь ему адаптироваться в коллективе и быстро погрузиться в предметную область?
• Как делиться с ним ранее накопленным знанием и опытом?
• Как вообще аккумулировать эти знания и опыт в компании?
• Как мониторить развитие сотрудника, обновлять его грейд/должность и изменять зарплату?
• Как удержать сотрудника от ухода из компании?
• И самый главный вопрос: как организовать и управлять этим?

Что такое ЦК (подробнее)

Центр компетенции (ЦК) - это структура в организации, которая занимается развитием специалистов и накоплением информации.

Про это можно почитать в разных источниках (тык, тык и тык).

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

Давайте перечислим список обязанностей ЦК, и как он помогает ответить на вопросы из жизненного цикла разработчика.

• Найм и адаптация:
• Составление материала для собеседования, такого, как вопросы и тестовое задание.
• Составление плана с чек-листом по онбордингу сотрудника.
• Создание единой базы знаний по компании/отделу/направлению, содержащей информацию о сотрудниках, проектах, процессах и регламентах.
• Сбор статистики по найму с возможностью изменения процесса для оптимизации.
• Развитие:
• Формирование матрицы компетенций, способов оценки и развития конкретной компетенции.
• Организация технических интервью с формированием индивидуального плана развития для последующей оценки грейда.
• Введение практики 1 to 1 для дополнительных точек синхронизации с сотрудником.
• Участие и проведение митапов. Отправка сотрудников на внешние активности.
• Создание стажировки внутри компании.
• Увольнение:
• Хранение всех знаний и опыта проекта в базе знаний.
• Управление:
• Создание отдела ЦК, который состоит минимум из руководителя ЦК, лидов направлений и hr специалиста.

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

Мы рассматриваем идеальную картину с адекватной зарплатой (хотя бы средней по рынку). При оплате труда ниже средней никакое удержание не поможет. В данном случае уходит вовлеченность и интерес к нематериальным вещам и остается только денежный.

Целевые компании для внедрения

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

Можно точно сказать, что вне зависимости от вида деятельности в компаниях со штатом менее 30 человек ЦК не нужен. Вы можете внедрять некоторые практики, но создавать отдельную структуру не следует. Слишком рано и избыточно.

Во всех остальных случаях можно смело внедрять ЦК. Причем с ростом количества людей в компании необходимость в ЦК также растет. Например, при штате в 40 человек необходимость в оптимизации процесса найма ниже, чем при штате в 400 человек.

Как было у нас до ЦК

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

Во времена до появления ЦК были некоторые процессы по развитию сотрудников. А именно:

• небольшой чек-лист по онбордингу,
• редкие 1 to 1 сотрудника с менеджером,
• ППР раз в 9 месяцев (но временами забывали про него),
• составление индивидуального плана развития (ИПР),
• организация и участие во внешних и внутренних митапах,
• индексация зарплаты по результатам ППР.

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

Стоит признаться, с планом развития у нас были проблемы. Во всяком случае в направлении разработки. Пример:

Такой план развития плох по нескольким причинам:

• цели развития плохо связаны с реальными навыками,
• критерии достижения цели трудно оценить,
• нет конкретики в задачах, просто “большая задача” и “компонентный компонент” на ППР (с ним была беда).

Этапы по созданию и внедрению ЦК

Давайте пройдем вместе весь путь, который необходим для внедрения ЦК в компанию, и который проходили мы.

Шаг первый, организационный

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

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

Шаг второй, грейдирующий

Необходимо сформировать единую систему грейдов для всех направлений.

Все мы знаем об общепринятой 3х уровневой системе: junior, middle и senior. Довольно часто ее расширяют добавляя middle+. В более крупных компаниях эта система еще больше расширяется.

Ранее в RNDSOFT было 3 грейда, но мы поняли, что этого недостаточно, и вот почему. При грейдировании раз в год, в 3х уровневой системе у сотрудника из года в год будет уровень - middle. Отсутствие понимания реального уровня плохо и для компании, и для сотрудника. Middle бывает разный. И хочется видеть изменения при оценке раз в год.

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

Каждый из навыков необходимо разбить на несколько уровней. И желательно при разбиении на уровни использовать Таксономию Блума.

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

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

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

Фронтенд направление.
Верстка, JavaScript, фреймворки, используемые в компании, и тесты.

Бекенд направление.
Ruby, Ruby on Rails и тесты.

Базы данных.
Реляционные и нереляционные.

Современный подход к развертыванию приложения.
CI/CD, контейнерная сборка приложений, оркестрация и т.д.

По итогу получилась эксель табличка, содержащая все навыки по направлению, разбитые на 5 уровней. От 0 (ничего не знаю и не умею) до 4 (все умею и могу научить). Каждый из уровней имеет небольшое описание, которое помогает понять, что требуется.

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

Будем честны, разные навыки имеют разное влияние на грейд. Например, у нас знание и умение работать с CI/CD менее важный навык, чем Ruby и Ruby on Rails. И это влияние редактируется с помощью весов. Вес - это параметр, который используется для оценки профессиональных навыков и компетенций сотрудника. Вес навыка показывает, насколько важен данный навык или компетенция для конкретной должности или уровня грейда и определяется совместно с людьми, имеющими компетенции в этом.

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

Соотношения весов в разных направлениях тоже разное. У нас в направлении разработки 80% весов на хард скиллы и 20% на софты. Может возникнуть вопрос, а как же тимлиды? Почему всего 20%? В компании так исторически сложилось, что тимлидов нет. Есть сильные менеджеры и техлиды. Этого хватает 🙂.

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

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

Итогом процесса грейдирования является помощь компании в развитии слабых навыков сотрудника. И ЦК тут может помочь тем, что создаст базу ИПР.

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

Шаг третий, связующий и образующий сообщество

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

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

Кроме быстрых каналов связи сообществу необходимо место, где можно хранить структурированные данные. Поэтому нужно создать базу знаний. Точнее несколько баз знаний!

В первую очередь необходимо создать базу знаний, доступную всем сотрудникам. Эта база может содержать такую информацию:

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

База знаний направления разработки:

• ссылка на чат направления,
• общие технические процессы и требования в проектах, например именование веток, использование линтеров и т.д.,
• материалы по техническому стэку компании,
• полезная литература.

По остальным направлениям нужны похожие базы знаний.

Шаг четвертый, нанимающий и удерживающий

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

Давайте перечислим места интеграции:

• собеседование

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

Главное не переусердствовать и не превратить обычное собеседование в компании в многоэтапного монстра с кучей алгоритмических задачек уровня FAANG.

• выход на работу

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

• испытательный срок длительностью 3 месяца с периодическими 1 to 1
• грейдирование с ППР и ИПР
• рабочий период в 6 месяцев с периодическими 1 to 1
• повторное грейдирование с ППР и ИПР
• далее повторяем последние 2 пункта каждые 9-12 месяцев

Подробнее про ППР после внедрения ЦК

Процесс ППР после внедрения ЦК у нас претерпел изменения и теперь состоит из нескольких этапов и по времени обычно занимает 2-3 недели.

Поговорим про самые интересные этапы этого процесса.

Оценка навыков сотрудника

Для более объективной оценки в этом процессе участвуют несколько человек.

• Сотрудник проводит самооценку по хард и софт скиллам.
• Техлид на проекте оценивает также хард и софт скиллы.
• Менеджер - софты и некоторые харды в рамках своих компетенций.

Все 3 оценки проводятся заочно. Основываются на работе/личном ощущении.

Лид ЦК проводит очную беседу с сотрудником.

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

Лид видит все 3 оценки, таблицу с вопросами и проверяет адекватность оценки, задавая, в основном, теоретические вопросы. Во время беседы конспектируются различные артефакты беседы. Успехи и сильные стороны сотрудника, а также слабые, в которых есть куда расти.

В итоговом ППР документе есть раздел с обратной связью от компании по каждому навыку:

Составление ИПР
Лид ЦК занимается составлением плана развития сотрудника. Доступ к документу с оценками навыков и базой ИПР сильно упрощает этот процесс.

При составлении плана развития сотрудника нужно учитывать несколько моментов:

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

По итогу желательно генерировать 3 задачи.

ППР

Проводится встреча между сотрудником, техлидом, менеджером и hr.

Итоги. Профиты от ЦК

По итогу мы получили множество плюсов от внедрения ЦК. Их можно заметить в разных этапах и сферах жизненного цикла сотрудника. Но особенно хочется перечислить плюсы от ППР этапа:

Сотрудник

• ППР по расписанию 3, 6, 12 месяцев.
• Пересмотр зарплаты в зависимости от грейда.
• Есть релевантный ИПР, позволяющий развиваться, как специалист.
• Синхронизация с техлидом каждые 3 месяца по ИПР.
• Обратная связь от компании по хард и софт скиллам с комментариями.

Лид и менеджер

• Снятие части ответственности за развитие сотрудника.
• Помощь в составлении ИПР.
• Грейд сотрудника и оценки по каждому навыку.

HR

• Владеет объективным грейдом для составления зарплатных вилок.
• Имеет тревожные звоночки, полученные на 1 to 1.

Компания

• Довольный сотрудник, который не думает об увольнении.

От идеи до разработки навыков и полноценного внедрения нам понадобилось 9 месяцев с загрузкой ЦК лида около 40 часов в месяц. На текущем этапе все процессы поставлены на рельсы, требуется менее 20 часов в месяц на грейдирование и дополнение баз вопросов и развития компетенций.