Проведение ежеквартального тестирования знаний сотрудников

Я – руководитель. Начало

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

Итак, меня назначили на должность тимлида группы тестирования, состоящей из 8 человек (далее «команда»): 1 ведущего, 3 старших и 4 «обычных» специалистов. Имея экспертные знания о продукте, я пока еще не представлял уровень подготовки членов команды, из-за чего не был уверен в качестве тестирования сложных задач и не мог правильно выделить время на их проверку. Задача выбора исполнителя для каждой доработки и оценки трудозатрат решалась непросто и далеко не всегда эффективно. Работа шла по схеме «сами берите в работу те задачи, которые лучше знаете».

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

Как я справился с этой проблемой?

Возникла необходимость срочно придумать механизм, с помощью которого можно было понять уровень знаний каждого из членов команды и спланировать работу (для начала – хотя бы на день и на неделю). Я принял решение разработать алгоритм оценки на основе когда-то проводимой аттестации сотрудников, нашел черновики аттестации специалистов тестирования и провел их анализ на актуальность. Как выяснилось, информация частично устарела, а главное – в ней не было конкретики о тестируемом продукте.

Я актуализировал общие вопросы и критерии их оценки, добавил раздел «Знания тестируемого продукта» и два типа оценок – оценка сотрудника и оценка руководителя. Выглядело это примерно так:

  • функциональные навыки (знания MS Office, навыки работы и настройки СУБД, знания нормативной базы тестируемого продукта, общие знания IT);

По клику на картинку откроется полная версия.

  • технические навыки (основы СУБД, sql, xml, знание техчасти тестируемого продукта и т.д.);

По клику на картинку откроется полная версия.

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

По клику на картинку откроется полная версия.

  • способность к работе с дополнительными задачами (смоделированными логическими проблемами в тестируемом ПО), которые невозможно решить лишь хаотичным нажатием кнопок без знания логики работы модулей;

По клику на картинку откроется полная версия.

  • знания тестируемого продукта (перечень модулей тестируемого продукта и критерии оценки их знаний);

По клику на картинку откроется полная версия.

При вычислении процента знаний сумма оценок руководителя делилась на максимальную оценку (максимальная оценка – это произведение количества заданий на максимальный балл).

Как применять подготовленные вопросы?

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

Я отправил членам команды вопросы и озвучил сроки, за которые каждый должен был выставить оценки самому себе. После этого были назначены персональные встречи. Еще до встречи я знакомился с ответами сотрудников, частично выставлял свои предварительные оценки (оценки руководителя), делал пометки по спорным оценкам. Во время беседы каждый рассказывал о своих знаниях, применяемых в работе в рамках каждого вопроса. При необходимости сотрудник демонстрировал свои навыки на ПК. Я старался разъяснить работнику большинство непонятных ему вопросов. После выставления в ходе встречи оценок руководителя на отдельной странице автоматически подсчитывались проценты

и выводился общий уровень знаний сотрудника (колонка «Уровень»)

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

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

Оценил. И что в итоге?

Итоги первой проверки вызвали у меня легкий шок… Уровень знаний некоторых сотрудников совершенно не соответствовал их должности: например, иногда старший специалист умел меньше, чем «обычный». Стало видно, кто на что способен. Как правило, в слабой подготовке не были виноваты только сами люди, ведь некоторых перевели с другого проекта без оценки навыков, и руководство не заботилось о получении ими обязательных знаний, их интересовали только сроки закрытия задач.

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

На основе всей полученной информации для каждого сотрудника были составлены KPI по повышению уровня знаний, учитывающие пробелы обязательных знаний и личные пожелания. Например, одному специалисту ставилась задача изучить один из модулей системы, а другому – обучить коллегу или научиться «разворачивать систему» (сервер и клиент) в ОС Windows и Linux. Срок выполнения KPI, привязанный к очередной ежеквартальной оценке, мог корректироваться на 1-2 недели в зависимости от текущей загрузки на проекте. KPI составлялись таким образом, чтобы ими можно было заниматься в рабочее время, не отвлекаясь от рабочих задач. От выполнения KPI зависели премии сотрудников.

Таким образом, по итогам встреч-бесед улучшалось взаимодействие сотрудников с руководителем. Не секрет, что при работе над текущими задачами далеко не всегда удается просто поболтать, выяснить какие-либо пожелания и недовольства – теперь же у меня появились ответы на важные вопросы: чего каждый подчиненный ждет от работы? в какой области он хочет развиваться? У сотрудников возросла мотивация, так как они получали больше интересных им задач и понимали, что при правильном и своевременном их решении могли претендовать на дополнительное премирование.

Создаем зоны ответственности и развиваем персонал

Далее была составлена таблица зон ответственности сотрудников за тестирование различных модулей ПО. На каждую зону назначались основной и дополнительный сотрудники с большим и меньшим (или минимальным) уровнем знаний соответственно:

Новые задачи распределялись в соответствии с этой таблицей: более сложные поручались основным, менее сложные – дополнительным. Дополнительный сотрудник при необходимости консультировался у основного в своей зоне ответственности, но мог обратиться также к ведущему специалисту или к тимлиду. Менее сложные задачи могли передаваться сотрудникам из другой зоны ответственности в том случае, если весь объем работ невозможно было распределить равномерно по таблице. Со временем на каждый модуль системы стало выделяться несколько основных и дополнительных сотрудников; такой подход позволил избавиться от проблемы незаменимых сотрудников, всегда имея в запасе как минимум одного заменяющего.

Для выполнения KPI сотруднику назначалась задача в баг-трекере. Перед началом работы для него проводилась консультация (это делал либо тимлид, либо специалист, у которого в KPI было указано обучение коллег). Только после консультации сотрудник приступал к решению задачи; при необходимости он мог обращаться за дополнительными разъяснениями. После завершения процесса работник отчитывался о задачах, способах и результатах тестирования; если все было выполнено в полном объеме, задача закрывалась. Задачи в рамках KPI назначались снова и снова до тех пор, пока сотрудник не начинал решать их самостоятельно, не отвлекая других на консультации. Некоторым сотрудникам была поставлена задача изучить процесс формирования отчетной документации.

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

Итоги

Итак, проделанная работа позволила повысить как уровень знаний сотрудников, так и скорость и качество тестирования в целом на проекте. Понимание уровня подготовки членов команды позволило планировать работу на месяц и более, на несколько релизов вперед; появилась возможность заранее сообщать руководству о потребностях в ресурсах. У руководства, в свою очередь, появилась возможность понимать риски, менять приоритеты задач и что-то переносить на следующий релиз. Необходимость задерживаться на работе в дни перед сдачей релиза постепенно свелась к минимуму. Сотрудникам стало легче жить, они начали тестировать программы, обладая знанием логики работы их модулей и понимая конечное предназначение продукта (какие заказчики и для чего его используют).

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

Сколько времени необходимо выделить на самооценку сотрудника и проведение встречи с каждым? По моему опыту – не менее часа; далее все зависит от количества и сложности заданий. Период проведения тестирования в моем случае был привязан к времени начисления премии. На каждом проекте он может назначаться индивидуально, все будет зависеть от наличия возможности для его проведения и от интенсивности развития тестируемого ПО (для достижения понимания того, кто и как быстро схватывает новую информацию).

Спасибо, что потратили время на мою статью! Удачи Вам!

Об авторе

В IT с 2011 года. За это время успел побывать во внедрении, функциональной и технической поддержке, в тестировании вырасти от рядового тестировщика до руководителя групп тестирования на государственных и коммерческих проектах. Сейчас выполняет роль тест-менеджера и аккаунт-менеджера "Лаборатории качества".

Поиск
Облако меток
8 марта (1)api (5)Game of testers (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (1)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (1)Опрос (1)ПОИНТ (2)Приёмочное тестирование (1)РИТ (1)Юмор (2)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (2)баги (4)банковские приложения (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (2)ежемесячный отчет (13)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (20)лайф-хаки (3)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (10)обучение (7)оптимизация тестирования (13)оффлайн тренинги (1)поздравление (1)поздравления (6)пользовательские истории (1)пример (1)проблемы (2)проектные риски (1)проекты (4)процесс тестирования (25)развитие команды (5)разработчики (1)распределенная команда (3)решения (2)ритейл-приложения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (46)тестирование безопасности (3)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (4)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (3)
Получите совет