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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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