Pull to refresh

Comments 10

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


Легенда:
0 — не знает, не умеет
1 — может разобраться самостоятельно, может решать инциденты (знает общую концепцию, где взять дополнительную информацию без отвлечения коллег)
2 — знает, может обучить, может выполнять локальные изменения
3 — знает хорошо, внедряет новое, может выполнять глобальные изменения (знает как изменения влияют на другие области, может все переделать)

Когда начали заполнять таблицу — она влезала на один экран — сейчас уже необходимо менять структуру.
Заполняют эту матрицу сами разработчики, заявляя свой уровень.
Цель составления матрицы — поднять показатель bus factor хотя бы до 3 (достаточно уровня компетенций 1), т.е. у меня, как тимлида, была задача провести обучение разработчиков, чтобы разработчик самостоятельно мог взять обязательства по выполнению задач какого-либо направления.
ссылка

Спасибо огромное за инпут! Будет круто, если разные команды будут делиться своими наработками, кстати, по ссылке на github (https://gist.github.com/lananovikova10/954ab6351bc919c1b66fec6e0d1d9e43) я накидала еще разных версий для разных языков программирования, разных позиций, на которые мы опирались в процессе.
Делал когда то такую матрицу, к сожалению, до конца довести не удалось, в прод не пошло.
Описание оценок делал сразу, поскольку первоначальный вариант предполагал самостоятельное заполнение специалистами, поэтому им нужно было дать подсказку, как правильно себя оценить.
Сразу дам хинт, который не предусмотрел в своем проекте — описания должны идти отдельно, не в самой матрице, в матрице для каждой компетенции (строки) должна быть ссылка на описание оценок. Так лучше делать, чтобы не дублировать описания — у разных компетенций могут быть одинаковые наборы, на моем примере это было примерно так:
  • Продукт 1
    • Умение установить и сконфигурировать
    • Знание предметной области
    • Настройка под задачи бизнес-заказчика
  • Продукт 2
    • Умение установить и сконфигурировать
    • Знание предметной области
    • Настройка под задачи бизнес-заказчика

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

Звучит как будто это исключающие состояния. Человек, который не хочет делиться знаниями по причинам типа «это займёт много времени, а реальные задачи компании решаться не будут» или «передать свои видение, интуицию и т. п. как надо делать лучше для решения задач компании я не смогу, а „студенты“ всё испортят» разве не лоялен компании? А принуждение к шарингу он ведь может вопринять даже не как «звоночек», а как «колокола» гремящие о том, что его собираются увольнять или переводить на другую позицию (пускай даже на повышение, но он его не хочет).
Так о принуждении речи не идет, с такими людьми обычно лучше работать с аргументацией — ты же не хочешь, чтобы к тебе джуниоры ходили пачкой с вопросами, тбее же проще кинуть в них ссылкой, кодом чем-то еще, чтобы они приходили с более продуманными вопросами? Ты же хочешь ходить в отпуск спокойно, чтобы не приходилось отвлекать тебя вопросами в нем? Ты бы хотел может заниматься разными задачами, а часть этой передать, научить? Но тут сильно зависит от личности. Вот в том конкретном описанном кейсе мы сработали на тщеславии, представили «шаринг» как создание документации как фреймворк, подали часть функциональности, которую он создал как отдельный сервис, который мы хотим портировать в другие проекты, поэтому нужна «внешняя» документация: архитектрное описание, апи.
Спасибо за описание интересного инструмента. Мы в небольшой команде для визуализации зон ответственности, процессов и басфактора использовали RACI матрицу, где в столбцах вместо ролей были указаны сотрудники — получилось достаточно информативно. Можно выдавать новым сотрудникам, чтобы знали по какому вопросу к кому обращаться. Пожалуй, можно еще в нее добавить числовой уровень компетентности по вопросу.
Некоторфые называют это «матрицей/картой коммуникации» и она дополняет матрицу компетенций.
Отличный материал. Спасибо.

В англоязычных источниках для каждого скилла часто вводят дополнительную оценку — «желание/намерение прогрессировать» — интерес к области/скиллу.
т.к. матрица компетенция позволяет создавать «план обучения», а не все скиллы могут быть обязательными.
Или они могут быть обязательными, но при подборе людей на проект/команду этот параметр позволит не брать при возможности тех, кто «умеет но не любит»
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.ontico.ru
Employees
11–30 employees
Registered

Habr blog