профессиональные компетенции команды

Для каждой должности необходим специалист с определенными компетенциями

Вариантов управленческих решений всего четыре:

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

Схема наглядно отображает, что относится к soft и hard skills

Soft skills – личные качества, которые зависят от характера человека и приобретаются с жизненным опытом. Такие универсальные компетенции трудно измерить количественными показателями. Они практически не зависят от специфики конкретной работы, но помогают строить карьеру. К ним относятся интеллектуальные, социальные и волевые компетенции:

• критическое мышление;
• решительность;
• аналитические способности;
• лидерство;
• коммуникабельность;
• креативность;
• умение работать в команде;
• многозадачность;
• пунктуальность и т. п.

К примеру, для соискателя на должность секретаря на первый план выходят такие soft skills, как коммуникабельность и многозадачность, для дизайнера – креативность и критическое мышление, для менеджера проектов – умение работать в команде, решительность и аналитические способности. Hard skills – профессиональные навыки, которые необходимы для выполнения конкретной работы. Этим навыкам обучают в колледжах, институтах, на курсах, их можно измерить путем проведения экзамена. К простейшим hard skills относится умение писать и читать, в эту же копилку идут знания иностранного языка, продукта, рабочей программы, стандартов и регламентов, вождение автомобиля и т. К примеру, для фронтенд-разработчика hard skills выглядят так: владение HTML и CSS, знание JavaScript, умение разбираться в фреймворках и библиотеках, составлять SQL-запросы и т. Методы оценки компетенций, или Как определить нужного человекаОстановимся подробнее на методах оценки компетенций персонала, которые дают наиболее объективное представление о личных и профессиональных качествах сотрудников:

• Тестирование – самый простой метод оценивания сотрудников и соискателей. На практике используют психологические и профессиональные тесты. Первые позволяют определить личные качества – soft skills, вторые – профессиональные, hard skills. Главный плюс метода – возможность проводить тестирование дистанционно.
• Интервью – устное собеседование в форме вопросов и ответов. Может быть неструктурированным: проводится в свободной форме, позволяет определить эмоциональную реакцию на вопросы. Структурированное интервью предполагает использование модели STAR: S (situation) – ситуация, Т (task) – задача, А (action) – действия опрашиваемого, R (result) – результат. Предлагается вспомнить случай из прошлой профессиональной практики, и дается оценка действиям соискателя по 10-балльной шкале.
• Анкетирование – заполняется стандартная форма с набором вопросов, после чего анализируется отсутствие или наличие у анкетируемого конкретных черт. Плюс методики – экономичность с точки зрения временных затрат и бюджета, минусы – низкая информативность и субъективность.
• Аттестация – определение уровня соответствия квалификации работника занимаемой должности или месту, на которое он претендует. Порядок проведения аттестации должен быть описан в утвержденных руководством компании документах. Как правило, она проводится в форме экзаменационного испытания и собеседования. По итогам аттестации может быть принято решение о повышении сотрудника, увеличении или уменьшении заработной платы, увольнении (ст. 81 Трудового кодекса РФ).
• Оценка экспертами – предполагает привлечение экспертов, которые, полагаясь на собственный опыт, анализируют характеристики сотрудников и выдают заключение. Возможна внутренняя оценка с привлечением непосредственного руководителя и коллег, которые хорошо знают сотрудника, и внешняя – с участием кадровых экспертов со стороны.
• Ассессмент-центр – проведение деловой игры с моделированием спорных рабочих ситуаций для оценки поведения сотрудников в нестандартных условиях. Оценки выставляет экспертная комиссия. Кроме того, ассессмент-центр может включать интервью и тестирование. Комплексный подход исключает субъективность и позволяет получить достоверный результат.
• Методы «180, 360, 540 градусов» – оценка поведения в реальных ситуациях:

• Оценка «180 градусов» – опрос сотрудника и руководителя.
• Оценка «360 градусов» – опрос сотрудника и его делового окружения: руководителя, подчиненных, коллег.
• Оценка «540 градусов» – «360 градусов» + опрос клиентов и поставщиков.

Один из вариантов оценки компетенций в Mirapolis HCM

Как провести оценку компетенций: план действийЧтобы эффективно оценивать сотрудников, нужно разработать систему оценки персонала. В первую очередь определить конкретные и понятные поведенческие индикаторы: требования к личности сотрудника, который будет работать на той или иной должности, какие ценности он должен разделять, чтобы вписаться в корпоративную культуру. Сделать это необходимо для всех категорий персонала: рабочих, менеджеров, руководителей, а также претендентов на эти должности. Индикаторы и то, как они проявляются в поведении, важно описать простыми словами, чтобы они были понятны и легко измеримы. Каждый индикатор должен быть однозначен и не иметь двойного толкования. Формулировки в стиле «общается эффективно» весьма расплывчаты. Как измерить эффективность в этом контексте? Нужны критерии. Есть два подхода к разработке компетенций:

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

К примеру, в отделе закупок работают 10 человек. Ранжирование по эффективности проводится по проценту брака, отсрочке платежей по договорам и другим объективным параметрам. Выявляют лучших работников и определяют особенности их поведения на рабочем месте. Это поведение и будет моделью компетенции – «эталоном» закупщика. После того как определены компетенции и поведенческие индикаторы, разрабатывают систему оценки для каждого метода, который будет использоваться. Чтобы была возможность сравнить поведение сотрудника, допустим, в оценке «360 градусов» или ассессмент-центре с поведенческими индикаторами и сделать вывод, насколько развита компетенция. Затем определяют периодичность проведения оценки компетенций сотрудников и назначают ответственных экспертов. Все это можно делать вручную, тратить деньги и время, а можно автоматизировать процесс с помощью Mirapolis HCM, сэкономив бюджет на 20–30 %. В системе управления талантами Mirapolis HCM есть отдельный блок, помогающий  оценивать компетенции сотрудников, развивать их, тем самым мотивируя на достижения более высоких показателей. Инструментарий помогает HR-специалисту проводить аудит человеческих ресурсов, видеть общую картину по кадровому потенциалу компании, моральному климату в ней, понять  причины текучести персонала и разницы в эффективности работы подразделений. Собранные в системе аналитические данные дают  не только HR, но и топ-менеджерам представление о кадровой политике в компании и возможность сравнить уровень компетенций у специалистов разных подразделений, оценить эффективность сотрудников и соотнести результаты работы и затраты на персонал. Эта актуальная информация помогает принимать верные управленческие решения. Вот как это работает:

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

Оценка 360 в Mirapolis HCM

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

Матрица потенциала в системе Mirapolis HCM

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

В системе формируются сводные и индивидуальные отчеты по сотрудникам. Они доступны в личном кабинете в виде наглядных схем и доступны для скачивания в форматах Excel и PDF. Формы аналитической отчетности можно настроить в виде сводных таблиц или выгружать документы с диаграммами. По итогам проведенной оценки система позволяет формировать рекомендации по индивидуальным планам развития: назначить курсы, изучение определенных материалов, занятия с тренером. Mirapolis HCM дает возможность выстроить в компании гибкий и прозрачный процесс проведения оценочных процедур, что позволяет существенно сэкономить время и трудовые ресурсы.

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

Алексей Трошин (morroz) в профессии почти 20 лет, в качестве Project и Product manager трудится с 2002 года. За это время работал в разных компаниях, руководил командами от 2 до 150 человек, а сейчас руководит разработкой в компании «ФИНАМ». Здесь Алексей выстроил систему, которая помогает не только распространять знания, но и мотивировать разработчиков расти в нужном бизнесу и команде направлении. Впрочем, система применяется не во всех командах. Почему? Об этом, как и применяемых подходах, узнаем под катом. Статья основана на докладе Алексея Трошина на Saint TeamLead Conf, в котором рассказывается, как в «ФИНАМ» распространяются знания: как растёт Сила и мастерство Джедаев, как обучают Падаванов и что происходит на Тёмной стороне Силы (куда же без неё).

Продукты и команда «ФИНАМ IT»

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

Сайт Finam. ru — сайт №1 по финансовой тематике, содержащий множество различных разделов с финансовой информацией, а также полезные сервисы, например, интернет-магазин акций. Можно, к примеру, прикупить одну акцию Apple и подарить её кому-нибудь на день рождения.

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

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

Соцсеть для трейдеров и многое другое.

«ФИНАМ IT» — это 150 человек, разделённые на 25 команд. Разработка только внутренняя, мы почти не привлекаем сторонние компании для наших нужд. Заглавная картинка отлично показывает, как у нас всё устроено. Состав команд может быть разным: в одних командах есть Product Owner, но нет, например, тестировщиков, в других есть тестировщики, но нет Product Owner, зато есть аналитики.

В разработке мы используем разные стеки технологий:

• Фронтенд: React.js, VUE.js.
• Языки: C#, PHP, С++, Java, mobile.
• Базы данных: MSSQL, PostgreSQL, Oracle.

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

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

Свой рассказ буду вести на примерах двух команд, условно назову их команда 1 и команда 2.

Команда 1

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

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

Команда 2

Вторая команда разрабатывала несколько внутренних систем:

• Один сотрудник — это эксперт в одних системах.
• Другой сотрудник — эксперт в других системах.
• А некоторые системы разрабатывались обоими сотрудниками вместе.

Про экспертов

Выше в тексте неслучайно выделено слово «эксперт», хочу уточнить, кто такой эксперт в рамках этого разговора. Как магистр из «Звездных войн», этот человек обладает Силой: глубокой компетенцией в своей предметной области, в технологии, в продукте. Для бизнеса обычно это удобно, потому что дает одну точку входа: эксперта спрашивают, как сделать или когда будет сделано, — если речь идёт о новых задачах, или обращаются с вопросами, если что-то сломалось или работает не так.

Такого эксперта я представляю себе как магистра Джедая из фильма «Звёздные войны» — он может всё (ну или почти всё).

Но у эксперта-Джедая есть и минусы:

• Его надо долго «растить», чтобы он принял эту Силу.
• Когда он уходит в отпуск, это всегда:«Что же мы все будем делать?».

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

Нашей главной головной болью был вопрос «Что будет, если с экспертом что-то случится, как с магистром Йодой на картинке ниже?»

А ещё вы наверняка слышали о понятии Bus factor.

Bus factor

Bus factor — это мера сосредоточения информации среди отдельных членов проекта.

В определении из Wikipedia написано, что этот фактор определяет количество участников проекта, после потери которых проект не сможет быть завершён оставшимися участниками. Условно это означает, сколько человек должен переехать автобус, чтобы с проектом произошла непоправимая беда.

Когда у вас эксперт один, то Bus factor равен одному, то есть все риски проекта находятся в руках одного человека, и это плохо.

Пример из истории: в 2010 году под Смоленском произошла авиакатастрофа, в которой погибло 96 человек, включая высшее руководство Польши. После этого события в Польше было утверждено правило — четыре высших руководителя государства (президент, премьер-министр, спикер сената, спикер сейма) ни при каких обстоятельствах не должны летать вместе. Это вариант защиты от Bus factor.

Как вы понимаете, в командах 1 и 2 эксперты не были взаимозаменяемы, и это создавало потенциальные проблемы. Нужно было что-то делать, чтобы увеличить Bus factor, а компетенции Джедаев-экспертов расширить. Мы предприняли следующие шаги.

Шаг 1. Увеличиваем Bus factor

Джедай не должен быть один. Поэтому необходимо тренировать и обучать Джедаев, чтобы их стало больше.

Уточню, что Джедай — это роль, а не компетенция. Джедая можно вырастить. Вторая роль (если уж говорить в терминах «Звездных войн») — это Падаван, ученик Джедая. Он стремится к полноте знаний Джедая и замещает его, когда тот в отпуске. Причем, Падаван может быть не один — если команда большая, мы можем взращивать сразу несколько Падаванов. Но Джедай всё равно остаётся главным ответственным лицом, принимающим ключевые решения.

Когда определились, кто становится Джедаем, договариваемся о Падаванах, распределяем роли и визуализируем их в менеджерской таблице:

Здесь по горизонтали продукты, области или модули. Например, если продукт — 1С, это могут быть «Зарплата и кадры» или «Бухгалтерский учёт» или другие модули. По вертикали в столбцах указаны сотрудники. На пересечении вписываем роли — кто Джедай, кто Падаван. Так получается понятное распределение.

Есть некоторые правила, о которых мы договорились для начала распределения.

Правила распределения, ч

• Один продукт, область или модуль — один Джедай. Мы же помним, что хотим сохранить удобство «одного окна», эксперта и ответственного.
• Не менее одного Падавана. Это как раз про Bus factor, чем их больше, тем лучше.
• Равномерное распределение Джедаев. Чтобы не перегружать сотрудников, по справедливости.

Вроде бы всё логично распределили, и получилось так:

В первой команде, работавшей над одним продуктом, один человек занимался старым продуктом (Sunset), другой — новым (Sunset 2. В «своей» версии продукта сотрудник считался Джедаем, в «чужой» — Падаваном, учеником другого сотрудника.

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

Шаг 2. Контролируем обмен знаниями

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

Фиксируем знания

Для этого мы фиксируем знания по нашим продуктам: составляем список всех знаний и складываем в таблицу. По каждому из продуктов на отдельной странице Confluence просто записываем те знания, из которых состоит продукт и декомпозируем их. Декомпозировать знания можно по-разному, и я напомню, что эти таблицы рисуются под страницей с распределением Джедаев и Падаванов. Например, для команды 1, одна страница для знаний Sunset, другая страница для знаний Sunset 2.

Дальше несколько скриншотов из нашего Confluence с примерами декомпозиции.

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

По функциональности. Тут единицы знания мы расписали по страницам и разделам системы.

По техническим знаниям. Некоторые продукты мы раскладывали просто по техническим знаниям команды.

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

Добавляем документацию

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

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

Добавляем оценки

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

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

В первой версии у нас было пять оценок — школа приучила считать от 1 до 5. Но потом выяснилось, что хватает четырёхбалльной системы, на ней и остановились.

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

Шаг 3. Визуализируй это

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

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

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

После этого мы ещё немного доработали наши правила.

• Джедаи должны «позеленеть» первые. То есть делаем упор на прокачке Джедаев. Главный ответственный должен максимально быстро стать компетентен. Особенно в случае, если это новый сотрудник.
• Хотя бы один Падаван должен быть зелёным, закончившим обучение полностью. Но он может не спешить догонять знания Джедая, тут главное не останавливаться.
• Остальные Падаваны могут быть в процессе обучения. Наша задача — не забывать «размазывать» знания, делать так, чтобы области знаний сотрудников пересекались и покрытие было максимальным.

Дифференцируем требования

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

Давайте вспомним оценки: Падаван получает зеленую метку за «тройку», если он делал хоть что-то в данной области, а Джедай должен в этой же области ориентироваться отлично, на «четвёрку». Также, для Джедая плохо (красный цвет) если не получены доступы, не написана документация и т. , то есть нижний порог у него «два». Этот подход иллюстрирует таблица ниже.

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

И вот наши таблички окрасились и всё стало интереснее и понятнее:

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

Когда мы добавляли новую функциональность, появлялись красные плашки. Тогда на следующей тимлидской встрече мы проверяли, остались ли они красными. Если да, то начинали выяснять, почему за две недели обучение не продвинулось. Если красный ушёл, остались серые квадратики, мы периодически и их проверяли. Результаты тимлидской встречи записывали в Confluence в чек-листы, где отмечался статус. Например:«Сотрудник 1 — прокачка 10 из 20». Если за две недели эти значения не изменились, смотрели, почему.

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

Шаг 4. Прокачка знаний и навыков

Заполнение документации

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

В этой таблице как раз видно неидеальное описание. Это значит, областей знаний в левой колонке слишком сильная детализированы, а с правой стороны, вероятно, один большой лист документации, который сложно читать и по которому сложно обучаться. То есть, прочли одну страницу документации, и прокачали сразу 5 строк знаний — нелогично как-то получается. Лучше, чтобы одна строка соответствовала одной странице в Confluence. Так проще поставить галочку (число) о том, что вся страниц изучена и усвоена.

Мы используем два способа наполнения:

• Пишем по памяти (экспертный способ). Тот, кто знает, как что-то делать, садится и начинает записывать свои шаги, например, дополняя описание скриншотами.
• Второй способ — исследовательский — что вижу, то пишу. Таким способом мы воспользовались, когда работали с системой, о которой никто не помнил, что с ней делать. Сотрудник сел разбираться и по шагам записывал всё, что делал: тут надо запросить права, а тут написать письмо и т.д. Таким образом заполнилась документация по той части, которую он исследовал.

Бывает, интересы разработчиков в плане саморазвития не совпадают с тем, что нужно компании. Здесь можно поиграть с коэффициентами. Например, вам нужна прокачка навыков аналитики, значит, на аналитику ставим коэффициент 0,5. Становится понятно, что там можно быстрее «позеленеть». А вот там, где интереснее самим сотрудникам, но не команде, коэффициенты больше. В этих разделах на прокачку уйдёт больше времени.

Помимо работы с документами, мы проводим tech talks. Но документация — основное. Я считаю, это лучший способ проконтролировать все процессы. В документации всё раскладывается по полочкам, видна полная картина и можно влиять на распространение и накопление знаний.

Итак, мы задокументировали всё, что нужно. Следующий этап — актуализация.

Актуализация

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

Если ваша команда в вашем пространстве Confluence подписана на эти изменения, она получит уведомления, где что дополнилось, изменилось, улучшилось, потому что в Atlassian Confluence есть:

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

Удобно, что есть удаление через корзину. Если кто-то случайно нажмёт «Удалить страницу», она всё равно не потеряется. Её можно восстановить и разобраться, почему кто-то пытался эти знания выкорчевать из вашего пространства.

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

Основной критерий качества обмена знаниями для меня — это уход сотрудника в отпуск. Если человек уходит в отпуск, и мне никто не пишет, не звонит и ничего не спрашивает, то я считаю, что в этой команде всё в порядке.

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

Надо понимать, что документация — это не всегда о том, что надо что-нибудь прочитать или узнать. Часто нужно что-то сделать: запросить доступ, установить программу, что-то открыть в программе. По ходу этих действий происходит актуализация. Например, пришёл новый человек, стал запрашивать доступ по инструкции. Сотрудник, который раздавал доступы раньше, уже не работает, нашли другого сотрудника. Документация обновилась.

Использование

Зачем всё это делать?

Легче распределять баги и задачи

Это очень хороший инструмент для распределения нагрузки на сотрудников. Очень удобно с этими таблицами обосновывать приоритизацию задач и сроки для бизнеса. Мы можем говорить о том, что оценили задачу в 4 часа, если ей займётся наш Джедай. Но мы будем делать её полтора дня, потому что хотим, чтобы ещё хоть кто-то в ней разобрался. Иначе, если Джедай пойдёт в отпуск, у нас будет беда. Когда у нас есть такая матрица, руководство начинает видеть процессы глазами команды, повышается прозрачность критериев для принятия решений. Вы приходите и объясняете, почему сейчас надо притормозить и заняться обучением.

Ещё одно достоинство нашей системы в том, что тимлид начинает видеть реальную загруженность каждого разработчика. Он может с этим пойти к руководству и сказать: «У меня есть человек, он загружен задачами по этой области. Давайте его разгрузим, пусть он начинает всё документировать и передавать знания коллеге».

Надо помнить, что Джедай — это роль, а не уровень технической прокачки. Если один опытный разработчик в роли «Джедай», второй человек в этой же области знаний может быть Падаваном, даже если он не уступает Джедаю по технических скиллам. У человека в роли Падавана может не хватать времени на прокачку, мы это понимаем и говорим: «Сейчас ты Падаван вот этой системы, но давай ты начнёшь поглядывать в документацию. Потому что в случае чего к тебе же прилетят проблемы с проекта».

План развития новичков

Это также очень хорошая помощь для развития новичков. Например, говорите новому сотруднику, что в первый месяц нужно по строчкам таблицы 1, 2, 3, 4 хотя бы прочитать документацию. Человек чётко понимает, где эта документация, что именно ему надо прочитать и сделать. Требуется меньше времени на вводные объяснения. Критерии чёткие и понятные, известно, что значит 1, 2, 3, 4. В каких частях системы новичку надо разбираться тоже известно.

Мотивация «морковка спереди»

Если в вашей компании есть система KPI, то вы можете вешать морковку спереди и говорить: «Чтобы в конце квартала добиться такого-то KPI в этой области, нужно сделать то-то и то-то по тем знаниям, которые уже расписаны». Если человек просит повышения, можно показать, что люди, зарабатывающие больше, выполняют вот столько. Больше ответственности — больше денег.

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

Уменьшить Bus factor

У меня сейчас есть кейс: на одном проекте есть всего один разработчик, который делает систему. Я понимаю, что риск bus-фактора здесь равен единице, но сейчас нет никого, кто бы в этой системе горел разбираться, такая вот проектная команда из одного человека. И мы договорились о следующем: все его завершённые задачи не закрываются, а скапливаются в одном месте. Примерно раз в месяц мы заводим отдельную задачу на документирование, где он описывает всю логику своей работы по этим накопленным задачам. Код в этом случае ревьюить бесполезно, так как перед этим нужно разобраться, как система работает. Но всё, что пишет, он комментирует. Задача по документации у него занимает от полудня до дня раз в месяц. Тимлид другой команды со смежным стеком технологий читает документацию и говорит: «Да, в принципе я понимаю. Если что-то здесь сломается, я починю».

Тёмная сторона Силы

Хочу предостеречь от Тёмной стороны Силы, которая проявится, когда начнёте пользоваться этим инструментом. Он позволяет вытащить знания из ключевых сотрудников (экспертов) и перераспределить их. Но бывают сотрудники, которые много знают, но не спешат делиться знаниями. Желательно не использовать этот инструмент для Тёмной стороны (распределить знания и избавиться от человека). Так люди будут бояться и недобросовестно работать с базой знаний. Вообще, страх — это плохо. Расширение опыта не должно быть угрозой.

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

Выводы

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

«Но остерегайтесь Тёмной стороны Силы! Она может всё испортить». Это мой вольный перевод слов Чубакки. Но Чубакка фигни не посоветует!

Важный инструмент для мотивации команды

Меня зовут Иван Антипин, я заместитель технического директора AGIMA. На рынке сложилась тяжелая ситуация: многие компании закрываются, а сработанные и крепкие команды распадаются под давлением обстоятельств. В этой статье расскажу об инструменте управления рисками — о матрице компетенций. Этот подход помогает распределять задачи с учетом балансировки нагрузки, избегать выгорания и неожиданной потери ключевых компетенций в команде.

Управлять компетенциями важно

Каждый тимлид однажды сталкивается с неожиданными проблемами. Еще вчера все было под контролем, а сегодня Senior-разработчик говорит, что уходит из команды, потому что не видит развития. В то же время приходит перспективный Junior и заявляет примерно то же самое: не понимает, как расти дальше и что делать — и уже начал терять интерес и мотивацию.

Бывают и более общие ситуации. Например, бизнес-заказчик просит перераспределить команду между двумя проектами, а как это сделать — непонятно. Тут уберешь разработчика — первый проект упадет, а этого переставишь — там всё сломается. Еще хуже, когда из команды уходит человек с уникальными навыками и заменить его пока некем — так называемый Bus-фактор. Совсем плохо, если это происходит неожиданно и времени передать дела не так много.

Все эти ситуации неприятные, но есть хорошая новость. Справится с ними простой инструмент — матрица компетенций.

Что такое матрица компетенций

Это таблица с ролями и навыками, важными для командной цели. Примерно такая:

Цифры в таблице показывают, насколько хорошо у сотрудников развиты нужные компетенции. Это могут быть как Hard Skills, так и Soft Skills. Выглядеть таблица может как угодно. Иногда ее оформляют в виде диаграммы, чтобы увидеть, какая компетенция выделяется в команде, а какую нужно подтянуть. Выглядит это вот так:

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

Как оценивать навыки

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

На нем мы видим 4 сектора. Каждый обозначает отдельный этап познания:

• Неосознанное незнание: человек не знает, нужен ему какой-то навык или нет, либо вообще не знает о существовании этого навыка.
• Осознанное незнание: человек уже понял, что ему нужно получше разобраться в вопросе и освоить что-то новое, но пока этого не сделал.
• Осознанное знание: человек получил новый навык, но пока не довел его до автоматизма, он знает, как делать, но ему нужно прикладывать усилия.
• Неосознанное знание: человек довел умение до автоматизма и перестал отдавать себе отчет, как он решает задачу — решает и всё.

Эта модель поможет оценить знания и навыки сотрудников. Самый простой подход — взять числа от 0 до 3 и присвоить каждой стадии. Тогда получится, что неосознанное незнание — это 0, а неосознанное знание — 3. Но можно использовать и другие диапазоны: например, от 0 до 10 — незнание, от 10 до 20 — знание и т. Главное, чтобы шкала подчинялась одной логике и правилам для всех.

Как составить матрицу

Работа над матрицей состоит из 3 этапов. На каждом свои особенности и нюансы.

I этап. Выделить необходимые навыки.

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

• по технологиям (фреймворки, базы данных и т. п.);
• по подходам (паттерны проектирования и т. п.);
• по ролям в команде (Frontend, Backend, тестирование и т. п.);
• по классам решаемых задач (SQL для питониста).

Важно, чтобы каждый навык был не просто задекларирован, но и детально описан. Что он в себя включает? Какие критерии вы учитываете? Как будете оценивать? Ответы на эти вопросы нужно зафиксировать.

II этап. Оценить каждого сотрудника.

К этому процессу есть несколько подходов.

• Оценка 360. Каждый, кто взаимодействует с сотрудником, делится мнением о том, насколько хорошо тот владеет навыками из списка. Опрос можно проводить письменно и устно. Удобно делать это через Google-форму. Чем больше людей опросите, тем более объективной будет оценка. Но учитывайте, что очень профессионального, но грубого человека оценят почти наверняка ниже, чем он заслуживает. Поэтому лучше использовать этот инструмент для оценки Soft Skills.
• Тестирование. Вы составляете вопросы и предлагаете человеку ответить. Вопросы должны быть корректными и правильными — отражать потребности проекта. Ваша задача — объективно оценить именно навыки, нужные для конкретных задач, а не познания в PHP.
• Самооценка. Вы предлагаете сотрудникам самим поставить себе баллы по важным компетенциям. Шкалу можно определить самостоятельно — главное, чтобы для всех она была одинаковой. Здесь нужно учесть нюансы: есть люди, которые завышают себе оценки, а есть те, кто не может побороть синдром самозванца и оценки занижает. Поэтому разумно попросить наставников или более опытных коллег эти оценки проверить. Это может стать отдельным способом оценить команду.
• Оценка наставников. Кураторы и наставники оценивают менее опытных членов команды по шкале, которую вы для них зададите. Из их мнения складывается матрица.

III этап. Актуализировать матрицу.

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

• у вас открывается новое направление;
• у вас расширяется команда;
• вы начинаете использовать новый стек;
• вы запускаете новый продукт;
• у вас появляется еще одна команда.

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

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

Как применять матрицу

Матрица компетенций в первую очередь помогает принимать управленческие решения. Рассмотрим на примере. У нас матрица на троих человек и четыре навыка. Кто из них самый эффективный?

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

Если мы разделим навыки на классы задач, которые решает сотрудник, то выясним, что Иван более эффективен во Frontend-задачах, а Михал — в Backend-задачах. А общая сумма не важна. Больше значения имеет, насколько они хороши в задачах, которые решают каждый день.

Чтобы сотрудники понимали свой уровень, можно положить матрицу в основу грейдирования. Если по классу задач минимальная оценка сотрудника — двойка, то он Middle-разработчик. Если тройка — то Senior. Тогда матрица приобретет привычный вид. А еще будет проще понять, кто и в каком стеке у вас Senior, кто Middle, а кому нужно освоить какие-то технологии, которые пригодятся ему в будущем.

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

Как с помощью матрицы распределять ресурсы

Ситуация: ваш бизнес-заказчик открывает новое направление. Теперь вам нужно быстро подготовить инфраструктуру и нанять 2 новых сотрудников. Это проблема: поставить новичков в изолированную команду на изолированный модуль нельзя. Они не знают правила работы, не знакомы с инфраструктурой и не понимают ваш код-стайл. Скорее всего, придется выделить одного разработчика из действующей команды. Как это сделать, не навредив налаженному процессу?

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

Тогда вы увидите, что забирать сотрудника из команды №4 нельзя — по ним это ударит сильнее всего. А вот забрать из команды №3 можно — это несильно повлияет на средний уровень навыка, команда не так сильно потеряет в качестве и скорости.

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

Допустим, для проекта важны 3 навыка: Angular, React и Vue. У вас 4 разработчика, которые разбираются в этих темах на разном уровне. Матрица показывает, что Angular — ваше узкое место.

Это значит, что вам не очень выгодно вести разработку на Angular. Но если у вас уже есть код и компоненты, которые на нем разработаны, то стоит задуматься, как расширить эту экспертизу и кому передать знания. Матрица показывает, что ближе всего к этому разработчик №4 — его и стоит обучить.

Как сбалансировать навыки в команде

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

На диаграмме выше видно, что в команде плохо знают Angular. Если вы переходите с него на Vue, то это нестрашно. Но если на Angular разработан ваш core-функционал, то вам явно пора увеличивать компетенции в этой теме внутри команды.

Еще важно следить за балансом по грейдам. Если у вас много Junior-специалистов и всего один Senior, то последнему скоро станет скучно. Но когда наоборот — много Senior-разработчиков и всего один Junior — тоже плохо. Более опытные не смогут делегировать простые задачи и будут решить их сами. Перекосы по технологиям тоже мешают команде. Если один сотрудник хорошо знает MySQL, а другой — PostgreSQL, то это почва для конфликта. Оба сотрудника будут считать, что их инструмент наиболее эффективен.

Чем полезна матрица компетенций

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

• Контролировать уровень знаний в команде.
• Распределять ресурсы эффективно и безболезненно для остальных команд.
• Мотивировать сотрудников и планировать их развитие (составлять индивидуальные планы развития, планировать KPI).
• Снижать риски потери знаний, если они сосредоточены у одного человека.
• Заложить основу для разработки грейдов или валидировать их объективность и актуальность.

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

А если вы знаете подобные инструменты, которыми пользовались и которые тоже показали эффективность, расскажите о них в комментариях.

Почему в Confluence?

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

В этой статье я расскажу, как мы строили матрицу навыков (компетенций) команды, как она эволюционировала, и какие вопросы мы теперь с её помощью решаем.

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

Первое, что пришло на ум, — это сделать таблицу, где в строчках сотрудники, а в колонках навыки/продукты. Встал вопрос, где вести такую таблицу?

• Excel — сложно организовать совместное редактирование
• Google Docs — не рекомендован к использованию в компании.

Подсказку «сделать в Confluence» я нашел в докладе Алексея Трошина (ФИНАМ) «Знания и компетенции в команде: найти, увидеть, прокачать». Кому больше нравится читать — держите конспект доклада от Светланы Новиковой.

Шаг 1. Обычная таблица

В начале я сделал обычную таблицу, где в строчках — навыки, в колонках —сотрудники. На тот момент в команде было 10 человек и с полсотни навыков, сгруппированных по тринадцати темам.

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

Мы для себя выбрали такие (одна – пять звезд):

• Давно изучал и давно не применял на практике
• Прослушал курс/изучал самостоятельно, практики было мало
• Практик, регулярно применяю на практике
• Эксперт, знаю тонкости, готов делится лайфхаками с коллегами
• Гуру, готов выступать на внешних конференциях

После этого все довольно оперативно смогли заполнить информацию по себе.

Итоги после первого шага

Время: От идеи до первичного заполнения прошел один спринт (две недели).

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

Шаг 2. Сводная таблица

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

Для начала создал страницу «Шаблон профиля специалиста».

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

Для примера на картинке выше две группы навыков: Computer languages и Management.

Далее добавил метку (Label) на страницу «Шаблон профиля специалиста». Например, skills.

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

Теперь магия — сводная таблица по свойствам страниц.

Добавил макрос «Вертикальное меню», внутри него макрос «Элемент вертикального меню», внутри него макрос «Отчет по свойствам страницы».

У элемента вертикального списка задал название. Оно может быть любым и может не совпадать с названием свойства страницы.

А вот с макросом «Отчет по свойствам страницы» немного сложнее.

Во-первых, надо указать метку — ту, что навесили на «Шаблон профиля специалиста». Например, skills. Это позволило мне отобрать только нужные страницы.

Во-вторых, стоит ограничить список пространств, в которых будут искаться страницы. Например, текущим.

Наконец, лучше задать название первой колонке в сводной таблице. Я назвал её «Сотрудник»

Повторил для следующей группы навыков. Добавил «Элемент вертикального меню» и внутри него «Отчет по свойствам страницы».

Теперь давайте посмотрим, что у меня получилось?

Итоги после второго шага

Время: На разработку шаблона и сводной таблицы ушло около недели.

Выхлоп: Стало удобнее анализировать полученные данные.

Шаг 3. Продвинутый шаблон

Предупреждение: Для этого улучшения потребуются права администратора пространства.

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

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

Для решения этой проблемы я решил использовать «Пользовательский шаблон».

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

Второе — tooltip. Этот макрос позволил мне сделать всплывающее описание к навыку и будет полезен для просмотра информации на сводной таблице.

В итоге мой шаблон выглядит вот так:

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

Ой, я чуть не забыл рассказать про то, как воспользоваться нашим пользовательским шаблоном. Все просто. Добавляем макрос «Создать из шаблона»

В результате появляется кнопка

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

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

В нашем случае это команды:

• DEV – внутренняя автоматизация
• CI/CD – развитие и эксплуатация таких продуктов как Artifactory, Gitlab, Jenkins и т.д.
• k8s – развитие kubernetes
• TESTZONE – автоматизация пересоздания тестовых зон

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

Итоги после третьего шага

Время: На разработку и тестирование нового шаблона у меня ушло две недели. Основное время на уточнение формулировок критериев для каждого навыка.

Выхлоп: Оценка уровня навыка стала более точной. Есть возможность сравнивать с целевым специалистом и планировать обучение.

Заключение

Вот какие задачи решает матрица компетенций у нас:

• Во-первых, bus factor. Очень не хочется оказаться в ситуации, когда о том, как работает продукт, знает только один человек, и он уходит. Это полезно и для планирования, и для согласования отпусков.
• В-третьих, самообучение. Есть как внутренние курсы, так и множество открытых ресурсов. Главное — определить, какой навык нужно прокачивать и создать на это задачу.
• И, наконец, мы нашли еще одно применение профиля целевого сотрудника: с его помощью мы решаем вопрос подбора персонала. Можем четко объяснить HR, кого мы ищем.

Сбор информации и формирование базы знаний для проведения бенчмаркинга. В базу знаний включено более 50 источников разных категорий:

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

Выделение релевантных источников данных и проведение компаративного анализа их содержания (приложение 2).

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

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

При проведении интервью использовалась глубинная техника «Интервью по получению поведенческих примеров» Дэвида К. МакКлелланда, что позволило эмпирическим путем определить набор компетенций.

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

Метод экспертных групп. Опрос экспертов — профессионалов по ключевым направлениям в сфере цифрового развития как из государственного сектора, так и из бизнес-структур.

Что такое модель корпоративных компетенций?

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

Какие виды компетенции различают?

Можно выделить корпоративные компетенции — необходимые всем сотрудникам компании, менеджерские компетенции — необходимые руководителям компании (всем или только определенного уровня), а также специальные (специфические) компетенции , необходимые только какой-то определенной категории сотрудников (например, менеджерам по