QA матрица компетенций и все такое

Дисклеймер

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

Вступление

Меня зовут @Lendcore, я Lead QA в gamedev студии * название *. Однажды так случилось, что у меня в подчинении оказалось 7 QA специалистов разного уровня и опыта. Казалось бы, не много, но это почти 10% от всей компании, и что-то делать с этим нужно. Прежде всего я со всеми познакомился, а дальше, чтобы структурировать их знания и понять, на сколько у меня теперь крутая команда, я решил интегрировать в проекты (их было несколько и QA были распределены по ним) новый инструмент — Матрицу компетенций. На Хабре видел дцать статей на эту тему и не считаю себя или свой опыт каким то особенным, но так вышло, что я не очень умный и ни одна из статей мне не помогла, из за чего мне пришлось собирать по крупицам информацию об этом инструменте, чтобы понять, как к ней подступиться.

Что вообще такое, эта матрица компетенций?

Мне понравилось, как ее описала Алаева Елена Александровна:

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

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

Зачем нужна эта матрица?

В моем случае она решала несколько задач:

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

2. Снижение Bus фактора

3. Быстрое знакомство с новой командой

4. Структурирование навыков ребят, чтобы в дальнейшем их прокачивать

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

Давай попробуем перейти к ее созданию

Мы поняли, что у нас должно получиться, но где нам взять данные для этой таблицы? Прежде всего нам нужен список специалистов, которые будут в этой таблице. Это наша QA команда, пока все просто.

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

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

Дополнение к описанному выше

В некоторой литературе, у компетенций приводится тоже описание, что и у hard скиллов

Hard skills — это профессиональные навыки, которые нужны только в конкретной профессии. На русском их еще называют жесткими навыками.

Из чего осмелюсь сделать вывод, что они взаимозаменяемы

Вернемся к нашему списку компетенций, который нам нужно создать.

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

1. Инструменты

2. Аналитика

3. Профессиональные навыки

Инструменты

В эту группу компетенций попадают все навыки, которые связаны с инструментами, используемыми в работе QA, например:

• Qase \ testrail и иже с ними

• Jira \ YouTrack …..

• Android studio

• Google play

• Любой другой инструмент, который вы используете в своей работе

Аналитика

Так вышло, что для аналитики у нас использовалось 5 разных сервисов и я все таки решил объединить их в свою группу. Другими словами, вы можете назвать эту группу «Сервисы» и выписать все сервисы, что у вас используются:

• Dev to dev

• Appmetrica

• Google metrics

• И тд.

Профессиональные навыки

Честно говоря, в этот блок я снес все компетенции, что не смог сгруппировать, каюсь.
Что мы сюда относим в итоге:

• Исследовательское тестирование

• Локализация и документирование дефектов

• Оценка и планирование тестирования

• Тестирование наката

• Тестирование платежей

• Тестирование карт

• Написание документации

• И тд

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

Как я понял, что именно нам нужно?

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

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

Наконец то подошли к самому лакомому кусочку, Что делать с тем, что у нас получилось.

Если мы расположим в столбцах специалистов, а в строках компетенции, то у нас получится табличка:

Приоритеты компетенций

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

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

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

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

Ну сделал я таблицу, и что дальше?

А дальше подготавливаем тестирование QA команды на владение компетенциями и выставляем от 1 до 5 баллов в каждой компетенции. Как его проводить и что спрашивать, это слишком индивидуально. У меня была гугл форма, где были открытые вопросы по каждой компетенции, где я смотрел, на сколько человек владеет теми или иными компетенциями, после чего, на 1&1 я закрывал пробелы и неточности. Не лучший способ, я знаю, но зато самый быстрый.

Если вы все сделали как я, то у вас получится такая табличка:

Баллы

Снова упустил кусок повествования, что за оценки, черт побери?

Для оценки специалиста, я ввел 5 балловую систему как в школе, где:

• 1 балл. У сотрудника нет опыта и знаний в данной компетенции

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

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

• 4 балла, это продвинутый уровень, то есть сотрудник имеет солидный опыт и знания, и может выполнять большинство реальных сложных задач. Контроль со стороны менеджера не требуется.

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

Круто! Уже что то получается, так что давайте попробуем проанализировать таблицу:

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

Так же мы видим, что в крашлитике у нас проблемы. Все держится на одном человеке, если Боба уйдет в отпуск, то вся робота по крашлитике со стороны QA может встать, так что надо подтягивать ребят в этом направлении. Зато Android studio вся команда хорошо освоила и любой сотрудник справится с любой задачей, требующей этой компетенции.

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

Хорошо, с таблицей поработали, @Lendcore, а как ты грейды то прикрутил?

Прежде, чем ответить на этот вопрос, я бы хотел озвучить, что считаю, что грейды не работают. Они легко «Хакаются», ограничены навыками лида, сложно анализируются и тд., и тп. (в интернетах есть мнения, как за, так и против грейдов. Вопрос дискуссионный).

Но так как задача «Пьёс @Lendcore Сделай грейды» еще у меня на столе, нужно что то делать.

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

1. Джун, 1 ЛВЛа, должен знать все компетенции 1 приоритета на 2 балла

2. Джун 2 ЛВЛа, должен знать все компетенции 1 приоритета на 2+ балла и компетенции 2 приоритета на 2+ балла

3. Третий ЛВЛ, это мидл и он должен знать все компетенции 1 приоритета на 3+ балла и компетенции 2 приоритета на 2+ балла

4. ЛВЛ, это прокачанный мидл и он должен знать все компетенции 1 приоритета на 3+ балла и компетенции 2 приоритета на 2+ балла, а еще компетенции 3 приоритета на 2+ балла

5. ЛВЛ, это синьор, который должен знать все компетенции 1 приоритета на 3 балла и несколько на 4, так же компетенции 2 и 3 приоритета на 2-3 балла. Средняя оценка сотрудника 3.0+

6. ЛВЛ, это прокачанный синьор, который знает все компетенции 1 приоритета на 4 балла, так же компетенции 2 и 3 приоритета на 3 балла. Средняя оценка сотрудника 3.5

Раз в год проходит перепроверка знаний, когда любой сотрудник может получить Lvlup (хотя можно и чаще). Мне кажется, что это самая справедливая система, которую я способен создать.

Послесловие

Матрица, это некий «Швейцарский нож», применения которого ограничиваются лишь сноровкой самого лида. Мне кажется, что этот инструмент нужен каждому менеджеру, в команде которого 3+ специалиста.

Спасибо за прочтение!