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

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

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

Решением является составление и поддержание в актуальном состоянии матрицы компетенций.

Шаг № 1

Выделить критичные части предметной области.

Шаг № 2

Выявить уровень навыков сотрудников.

Шаг № 3

Обработать риски.

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

Для контрольного примера возьмём семь компетенций:

  1. Отчёты RS
  2. Отчёты на базе сводных таблиц
  3. Обмен данными
  4. C Sharp
  5. Веб сервисы
  6. Оптимизация
  7. Архитектура

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

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

 

Отчёты RS

Отчёты сводные

Обмен данными

C Sharp

Веб сервисы

Оптимизация

Архитектура

Митчелл

2

2

1

0

0

1

0

Хойт

1

1

0

2

1

2

0

Абу Бакр

3

3

2

1

0

3

1

Примус

0

0

0

3

0

2

1

Батье

2

2

3

0

1

1

3

ИТОГ

8

8

6

6

2

9

5

 

Из таблицы можно сделать следующие выводы:

  1. У нас нет никаких проблем с реализацией отчётов.
  2. С обменом данными также всё в порядке. Господина Батье вполне может подменять мистер Бакр.
  3. Относительно C Sharp также нет проблем, функции дублированы.
  4. Мы толком не можем делать веб-сервисы, есть лишь два ученика. По всей видимости, специалист был, но он уволился, а предыдущий менеджер матриц компетенций строить не умел.
  5. С оптимизацией всё в полном порядке.
  6. Полноценным архитектором является только господин Батье, есть два ученика, но подменить его они не могут.

 

Управленческие решения:

  1. Направить Батье и Хойта на обучение разработке веб-сервисов.
  2. Попросить Батье поднять навки Примуса и Бакра в архитектуре.
  3. Особенно чутко наблюдать замотивированность господина Батье.

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