Pull to refresh

Comments 10

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


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

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

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

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

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

В англоязычных источниках для каждого скилла часто вводят дополнительную оценку — «желание/намерение прогрессировать» — интерес к области/скиллу.
т.к. матрица компетенция позволяет создавать «план обучения», а не все скиллы могут быть обязательными.
Или они могут быть обязательными, но при подборе людей на проект/команду этот параметр позволит не брать при возможности тех, кто «умеет но не любит»
Sign up to leave a comment.