Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.

Это следующие причины:

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

  • Не всегда было очевидно, какие пробелы в знаниях и опыте есть у сотрудника.

  • Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.

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

Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.

Профиль тестировщика

В профиле тестировщика все компетенции разделены по 3 категориям:

  • Навыки в тестировании — создание тест-кейсов, локализация багов, тестирование мобильных приложений и т.д.

  • Технические навыки — знание интернет технологий, работа с базами данных и т.д.

  • Soft skills — ответственность, коммуникации, стрессоустойчивость и т.д.

Отдельным дополнительным блоком идет мотивация — новые задачи, стабильность, коллектив и т.д. Весь профиль представляет собой Excel-документ или Google-таблицу. Компетенции и навыки по каждой категории перечисляются на отдельном листе документа.  Для компетенции описываются следующие атрибуты:

  • Название.

  • Вес – насколько часто компетенция требуется на проектах компании. В нашей версии вес имеет 5 градаций:

    • 0 — нет проектов, где требуется навык;

    • 1 — единичные проекты, где требуется навык;

    • 2 — навык требуется для менее половины проектов;

    • 3 — навык требуется для более половины проектов;

    • 4 — навык требуется почти во всех проектах.

  • Оценка уровня владения компетенцией для сотрудника. Есть 5 вариантов оценки:

    • 0 — no experience — нет опыта;

    • 1 — novice — новичок;

    • 2 — intermediate — средний уровень;

    • 3 — advanced — продвинутый уровень;

    • 4 — expert — эксперт.

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

Рассмотрим пример оформления навыка “Регрессионное тестирование”. Вес установлен в “4”, поскольку навык нужен на всех проектах компании. Оценка сотрудника установлена в “1” - это значит, что он имеет незначительный опыт проведения регрессионного тестирования на проектах. Для навыка описаны все критерии, по которым можно определить свой уровень.

Заполнение профиля

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

Как мы создавали шаблон? У нас была базовая версия, полученная на курсе по тест-менеджменту. Сначала мы проанализировали набор навыков — нужно ли какие-то убрать или добавить. Затем проверили критерии на соответствие проектам нашей компании, часть из них обновили. Установили вес для каждой компетенции. И далее на протяжении нескольких лет добавляли туда новые компетенции, которые требовались на разных проектах. Например, мы расширили блоки тестирования мобильных приложений, нагрузочного тестирования, управления командой.

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

Пример оценок по техническим навыкам:

Постановка целей по обучению

Цели ставятся на основе профиля по следующему принципу:

  • Сотрудник выбирает несколько навыков, по которым можно укрепить знания или повысить уровень. Навыки обязательно должны соотносится с текущим проектом.

  • Цель – повышение/укрепление оценки по компетенции.

  • Цель должна быть SMART.

  • Руководитель и сотрудник обсуждают, какие из отобранных навыков взять в виде целей. Например, можно отобрать 5 навыков, а взять 1 или 2.

  • При выборе навыков учитываем, чтобы цели были достижимые, оцениваем загрузку сотрудника на проекте.

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

  • Описываются критерии достижения — шаги, при выполнении которых цель считается выполненной. Как и в квартальных целях, критерии могут быть теоретические и практические. Например, прохождение курса и применение знаний на проекте.

Цели оформляются на отдельном листе документа с заполненным профилем тестировщика. Пример поставленных целей:

Проверка выполнения цели происходит примерно 1 раз в 1.5-2 месяца. После того как цель выполнена — новая оценка по навыку переносится в профиль тестировщика. И ставится следующая цель. Таким образом, у руководителя и сотрудника есть не только матрица компетенций сотрудника, но и наглядная картина развития этих компетенций. 

В этом подходе не всё сразу шло “как по маслу”. Проблем практики квартальных целей мы постарались избежать. Но встретились с новыми.

Много мелких целей

Одна из них — это постановка большого количества мелких целей. Такая ситуация у нас чаще всего возникала в двух ситуациях:

  • Для джуниор-тестировщиков с небольшим опытом;

  • Когда QA специалист брался за совершенно новый для него вид тестирования.

В этих случаях действительно можно отобрать много навыков из профиля, по которым за несколько месяцев можно поднять уровень с 0 до 1. Проблема заключается в том, что ещё на этапе планирования обучения происходила “потеря фокуса”. Непонятно, за что браться в первую очередь. Также в совокупности время на изучение небольших задач может превратиться в большое число и мы придем к недостижимым целям. 

На практике мы вывели следующую формулу — потенциально для обучения/повышения уровня можно отбирать из профиля столько навыков, сколько хочется. Но на временной период брать максимум 2-3 навыка, самых важных для проекта. А после их выполнения — делать переоценку навыков из шаблона. Возможно, по некоторым из них удалось повысить оценку.

Нерегулярность проверок

В первые полгода внедрения практики мы немного расслабились и допустили 2 ошибки:

  • Забывали про запланированные промежуточные проверки.

  • Устанавливали долгие временные отрезки между проверками (2.5-3 месяца).

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

Какие выводы для решения проблем я сделала:

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

  • Напоминания следующей проверки лучше оформлять в виде встречи в календаре.

  • Опытным путём установили, что контрольная точка 1 раз в месяц — это часто. Нужно учитывать отпуска, праздники, загруженные периоды на проектах. Плюс у сотрудника может появиться ощущение “обязаловки”. Не хочется в людях убивать желание учиться. Поэтому стали проводить проверки реже, 1 раз в 1.5-2 месяца.

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

Не хватает времени на обучение

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

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

Чаще встречалась ситуация, когда сотруднику хватало навыков для работы, но он хотел повысить свою квалификацию, эффективность или сменить вектор развития — например, с ручного на автоматизированное тестирование. И когда этого не получалось достичь из-за отсутствия времени на обучение, сотрудник был демотивирован.

Как мы пытались решать эту проблему? Опять же, привлечением дополнительного тестировщика на проект. Можно ставить менее глобальные цели, которые не будут требовать больших временных затрат. Например, не получается сейчас с полноценной автоматизацией. Давайте изучим базовые возможности автоматизации в Postman. Можно временно отказаться от участия в практике обучения, можно оставить цель в том виде, в каком она была, если сотрудник очень хочет продвинуться и готов тратить на обучение личное время. Если такая ситуация продолжается несколько временных периодов подряд, лучше планировать ротацию на другой проект. Чтобы избежать выгорания и разочарования. 

Главный вывод — невыполнение цели по этой причине не сказывается на результатах годовой аттестации. Учитывается в первую очередь качество работы сотрудника на проекте.

У наставника не хватает времени на проверки целей

Наш отдел тестирования начинался с нескольких человек. С проверкой результатов у 3-4 человек я справлялась. Но при росте группы тестирования мне как руководителю перестало хватать времени на проверку целей. Для группы в 15-20 человек проверка одной промежуточной точки растягивалась на несколько недель.  

Второй проблемой являлся тот факт, что руководителю в определенный момент не будет хватать навыков в тестировании для объективной проверки результатов обучения. Редко можно встретить тестировщика, который будет профи и в ручном, и в нагрузочном, и в автоматизированном тестировании. Для решения ситуации мы выработали следующий подход:

  • Выделение маленьких групп тестировщиков в 3-4 человека и назначение для каждой группы people manager - ментора или наставника;

  • Передача проверки целей по обучению внутри маленьких групп менеджерам;

  • Менеджеры проверяют цели друг у друга, либо руководитель проверяет цели у менеджеров;

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

Сравнение двух подходов — квартальные цели и профиль тестировщика

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

Практика обучения дала следующие плюсы для компании:

  • Более высокий уровень качества тестирования, что ведёт к более высокой удовлетворенности заказчика.

  • Участие в новых тендерах по тестированию, запросах на QA от заказчиков, которые раньше были нам недоступны из-за отсутствия подходящих специалистов в штате.

  • Получение сертификатов о прохождении курсов. В аутсорсинговой компании сертификаты полезны для участия в тендерах.

  • Практика обучения помогла сформировать программу интернатуры.

Сотрудникам единая практика обучения даёт следующие преимущества:

  • Наглядная картина своих компетенций, выявление потенциальных мест для развития, повышения квалификации.

  • Контроль обучения под руководством опытного наставника.

  • Переиспользование успешных подходов к обучению.

  • Ретроспектива своего роста за временной промежуток, например, за год.

Итог

  • Практики обучения универсальны. Подходят для всех IT специальностей. Любая компания может адаптировать практики под себя.

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

  • Цели по обучению должны соотноситься с проектом и приносить ему пользу.

  • Не нужно брать много мелких целей, лучше взять 1-2 основных.

  • Промежуточные проверки лучше проводить регулярно, 1 раз в 1.5-2 месяца.

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

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

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

Я поделилась своим опытом и наблюдениями. Оставляйте свои комментарии и вопросы, а также делитесь своими историями. Спасибо, что уделили время прочтению статьи.

Комментарии (7)


  1. Sovka31
    07.04.2022 07:49
    +1

    Спасибо за статью, было интересно прочитать. Есть пара вопросов:

    1) Есть ли критерии к этой матрице, по которым назначается грейд сотруднику? Хотелось бы их увидеть для личной оценки

    2) Развитие скиллов по данной матрице привязано к годовой премии? Если часто бывают периоды, когда у сотрудников из-за загрузки нет времени на обучение, то такая система развития не особо справедлива


    1. UseTech Автор
      07.04.2022 15:04

      Добрый день, спасибо за обратную связь и вопросы. Отвечает Елена:

      1) Я пыталась связать матрицу и грейды, но решение не отладила. Так что рабочую схему предоставить не смогу.
      В том подходе, что я пробовала, для определения грейда учитывались факторы:
      - опыт работы в годах,
      - навыки в тестировании — например, минимум половина навыков уровня 2-intermediate и выше,
      - технические навыки — например, минимум половина навыков уровня 2-intermediate и выше,
      - soft skills - например, по всем навыкам оценка 2-intermediate и выше,
      - уровень самостоятельности и способности решать проблемы,
      - для лидов оценка по навыкам управления командой,
      - отзыв коллег — на какой грейд интуитивно оценивают коллеги сотрудника.

      2) Раз в год есть аттестация, на которой обсуждается индексация зарплаты. Как я указала в статье в разделе "нехватка времени на обучение" — невыполнение цели по этой причине прямо не сказывается на результатах годовой аттестации. Учитывается в первую очередь качество работы сотрудника на проекте. Грубо говоря, если сотрудник хорошо работал, все в команде довольны, аттестация происходит успешно.

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


  1. tundrawolf_kiba
    07.04.2022 13:33
    +1

    На моей предыдущей работе тоже была матрица компетенций, но многие компетенции были сформулированы так, что в зависимости от проекта и времени проведённом на проекте — могли сильно варьироваться вверх и вниз. А у вас как я понял — всё же больше упор в технические компетенции, которые не так сильно зависят от проекта?


    1. UseTech Автор
      07.04.2022 15:05

      Добрый день, упор в компетенции по тестированию и в технические. Технические оценить легче. Компетенции в тестировании — сложнее. Но всё же они описаны так, чтобы можно было почти однозначно установить свой уровень. При переходе на другой проект уровень владения компетенцией не меняется. Например, если по написанию тест-кейсов был advanced, он таким и останется. Единственное, что мы не учитываем в профиле — это знание предметных областей. Думаю, это больше подходит продуктовым компаниям.


  1. Cherticc
    07.04.2022 22:20

    Здравствуйте, подскажите пожалуйста, а как происходит оценка сотрудника по матрице руководителем ? На основании опыта совместной работы либо проводится интервью ? Спасибо


    1. UseTech Автор
      08.04.2022 07:58

      Здравствуйте, мы используем следующий подход: оценка происходит после испытательного срока в 3 месяца, за который у руководителя и сотрудника накоплен некоторый опыт совместной работы или взаимодействия. Сначала оценки заполняет сам сотрудник — он должен постараться объективно себя оценить. Далее руководитель просматривает результаты и отмечает для себя навыки, по оценкам которых у руководителя есть вопросы. После происходит встреча/созвон сотрудника и руководителя, на котором в формате беседы обсуждаются и уточняются оценки. Руководитель просит сотрудника подробнее рассказать про опыт работы, а затем совместно принимается решение об оценке по каждому навыку. Если есть сомнения, лучше выбрать оценку ниже и договориться, что через определённое время работы (например, полгода), будет переоценка навыка.

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

      Советую минимум 1 раз в год актуализировать профиль. Для более объективных
      оценок можно привлекать QA, работающих вместе с сотрудником на одном проекте.


  1. Vikulishna
    08.04.2022 16:46

    Спасибо за статью. На каждой из работ тоже имели матрицу компетенций.

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

    По поводу процедуры самой оценки. В предыдущей компании у нас у каждого сотрудника, не только отдела QA, была матрица компетенций, причем у всех был доступ. При проверке компетенции можно было привлечь сотрудников для помощи с оценками повыше, если руководитель не обладал таковой в полной мере. И плюс при обучении тоже можно было спросить совета у профессионалов.

    Правильно ли я понимаю, что если цели не были достигнуты, то могло быть повышение за по итогу года, но при этом не повышался грейд или это идёт вместе?