Я – руководитель. Начало
Каждый руководитель должен понимать, на что способна его команда в целом и каждый сотрудник в отдельности. Понимание это достигается применением тех или иных техник, и сейчас я расскажу Вам о своей практике на примере одного из проектов, на котором я работал еще до поступления в ЛК.
Итак, меня назначили на должность тимлида группы тестирования, состоящей из 8 человек (далее «команда»): 1 ведущего, 3 старших и 4 «обычных» специалистов. Имея экспертные знания о продукте, я пока еще не представлял уровень подготовки членов команды, из-за чего не был уверен в качестве тестирования сложных задач и не мог правильно выделить время на их проверку. Задача выбора исполнителя для каждой доработки и оценки трудозатрат решалась непросто и далеко не всегда эффективно. Работа шла по схеме «сами берите в работу те задачи, которые лучше знаете».
В какой-то момент от руководства стали поступать запросы на предоставление плана тестирования будущих релизов, и такая схема организации просто потеряла актуальность. И действительно, при составлении плана приходилось учитывать только даты релизов без учета необходимого количества часов на каждую задачу в отдельности; из-за этого ближе к выходу релиза оставалось мало времени и много задач, а сотрудникам часто приходилось работать сверхурочно. Руководство справедливо указывало на то, что сроки релиза были известны заранее, а я не мог в доступной форме показать нехватку ресурсов. Такое положение не устраивало никого, и меня, в том числе.
Как я справился с этой проблемой?
Возникла необходимость срочно придумать механизм, с помощью которого можно было понять уровень знаний каждого из членов команды и спланировать работу (для начала – хотя бы на день и на неделю). Я принял решение разработать алгоритм оценки на основе когда-то проводимой аттестации сотрудников, нашел черновики аттестации специалистов тестирования и провел их анализ на актуальность. Как выяснилось, информация частично устарела, а главное – в ней не было конкретики о тестируемом продукте.
Я актуализировал общие вопросы и критерии их оценки, добавил раздел «Знания тестируемого продукта» и два типа оценок – оценка сотрудника и оценка руководителя. Выглядело это примерно так:
- функциональные навыки (знания MS Office, навыки работы и настройки СУБД, знания нормативной базы тестируемого продукта, общие знания IT);
- технические навыки (основы СУБД, sql, xml, знание техчасти тестируемого продукта и т.д.);
- деловые навыки (общение в команде, личное желание развиваться и помогать развитию коллег, умение выражать свои мысли и взаимодействовать с другими сотрудниками, умение избежать конфликтов и т.д.);
- способность к работе с дополнительными задачами (смоделированными логическими проблемами в тестируемом ПО), которые невозможно решить лишь хаотичным нажатием кнопок без знания логики работы модулей;
- знания тестируемого продукта (перечень модулей тестируемого продукта и критерии оценки их знаний);
При вычислении процента знаний сумма оценок руководителя делилась на максимальную оценку (максимальная оценка – это произведение количества заданий на максимальный балл).
Как применять подготовленные вопросы?
На следующем шаге необходимо было понять, что же делать дальше с этими вопросами, как их применить, каким образом собирать оценку знаний и как часто ее проводить. Нужна была матрица, определяющая уровень знаний сотрудника для каждой области, и я ее разработал. В матрице содержался перечень уровней знаний и диапазон оценок для его достижения:
Я отправил членам команды вопросы и озвучил сроки, за которые каждый должен был выставить оценки самому себе. После этого были назначены персональные встречи. Еще до встречи я знакомился с ответами сотрудников, частично выставлял свои предварительные оценки (оценки руководителя), делал пометки по спорным оценкам. Во время беседы каждый рассказывал о своих знаниях, применяемых в работе в рамках каждого вопроса. При необходимости сотрудник демонстрировал свои навыки на ПК. Я старался разъяснить работнику большинство непонятных ему вопросов. После выставления в ходе встречи оценок руководителя на отдельной странице автоматически подсчитывались проценты
и выводился общий уровень знаний сотрудника (колонка «Уровень»)
Таким образом я смог оценить знания сотрудников в каждой области. Теперь стало понятно, задачи какого типа и уровня может решить каждый специалист.
Для некоторых такой опрос стал сложным испытанием. При этом у меня не было цели кого-то уволить – наоборот, хотелось вырастить хороших специалистов. Встречи проводились в позитивной обстановке, сотрудники задавали интересующие их вопросы, рассказывали, какие направления и какие модули им наиболее интересны, и что для себя новое они хотят изучить.
Оценил. И что в итоге?
Итоги первой проверки вызвали у меня легкий шок… Уровень знаний некоторых сотрудников совершенно не соответствовал их должности: например, иногда старший специалист умел меньше, чем «обычный». Стало видно, кто на что способен. Как правило, в слабой подготовке не были виноваты только сами люди, ведь некоторых перевели с другого проекта без оценки навыков, и руководство не заботилось о получении ими обязательных знаний, их интересовали только сроки закрытия задач.
Стоит отметить, что во время бесед я расспрашивал членов команды о том, какие модули системы им интересны, и в каком направлении они бы хотели развиваться.
На основе всей полученной информации для каждого сотрудника были составлены KPI по повышению уровня знаний, учитывающие пробелы обязательных знаний и личные пожелания. Например, одному специалисту ставилась задача изучить один из модулей системы, а другому – обучить коллегу или научиться «разворачивать систему» (сервер и клиент) в ОС Windows и Linux. Срок выполнения KPI, привязанный к очередной ежеквартальной оценке, мог корректироваться на 1-2 недели в зависимости от текущей загрузки на проекте. KPI составлялись таким образом, чтобы ими можно было заниматься в рабочее время, не отвлекаясь от рабочих задач. От выполнения KPI зависели премии сотрудников.
Таким образом, по итогам встреч-бесед улучшалось взаимодействие сотрудников с руководителем. Не секрет, что при работе над текущими задачами далеко не всегда удается просто поболтать, выяснить какие-либо пожелания и недовольства – теперь же у меня появились ответы на важные вопросы: чего каждый подчиненный ждет от работы? в какой области он хочет развиваться? У сотрудников возросла мотивация, так как они получали больше интересных им задач и понимали, что при правильном и своевременном их решении могли претендовать на дополнительное премирование.
Создаем зоны ответственности и развиваем персонал
Далее была составлена таблица зон ответственности сотрудников за тестирование различных модулей ПО. На каждую зону назначались основной и дополнительный сотрудники с большим и меньшим (или минимальным) уровнем знаний соответственно:
Новые задачи распределялись в соответствии с этой таблицей: более сложные поручались основным, менее сложные – дополнительным. Дополнительный сотрудник при необходимости консультировался у основного в своей зоне ответственности, но мог обратиться также к ведущему специалисту или к тимлиду. Менее сложные задачи могли передаваться сотрудникам из другой зоны ответственности в том случае, если весь объем работ невозможно было распределить равномерно по таблице. Со временем на каждый модуль системы стало выделяться несколько основных и дополнительных сотрудников; такой подход позволил избавиться от проблемы незаменимых сотрудников, всегда имея в запасе как минимум одного заменяющего.
Для выполнения KPI сотруднику назначалась задача в баг-трекере. Перед началом работы для него проводилась консультация (это делал либо тимлид, либо специалист, у которого в KPI было указано обучение коллег). Только после консультации сотрудник приступал к решению задачи; при необходимости он мог обращаться за дополнительными разъяснениями. После завершения процесса работник отчитывался о задачах, способах и результатах тестирования; если все было выполнено в полном объеме, задача закрывалась. Задачи в рамках KPI назначались снова и снова до тех пор, пока сотрудник не начинал решать их самостоятельно, не отвлекая других на консультации. Некоторым сотрудникам была поставлена задача изучить процесс формирования отчетной документации.
В конце квартала подводились итоги (кто чего достиг), и весь процесс начинался снова. Очень скоро стал виден ощутимый прогресс в уровне знаний всех сотрудников.
Итоги
Итак, проделанная работа позволила повысить как уровень знаний сотрудников, так и скорость и качество тестирования в целом на проекте. Понимание уровня подготовки членов команды позволило планировать работу на месяц и более, на несколько релизов вперед; появилась возможность заранее сообщать руководству о потребностях в ресурсах. У руководства, в свою очередь, появилась возможность понимать риски, менять приоритеты задач и что-то переносить на следующий релиз. Необходимость задерживаться на работе в дни перед сдачей релиза постепенно свелась к минимуму. Сотрудникам стало легче жить, они начали тестировать программы, обладая знанием логики работы их модулей и понимая конечное предназначение продукта (какие заказчики и для чего его используют).
Таким образом, я считаю необходимым введение подобного тестирования сотрудников. Это позволяет руководителю постоянно иметь представление о том, кто на что способен, понимать методы работы с каждым (описать задачу в двух словах или пояснять максимально подробно, контролировать каждый шаг или бегло проверять итоги).
Сколько времени необходимо выделить на самооценку сотрудника и проведение встречи с каждым? По моему опыту – не менее часа; далее все зависит от количества и сложности заданий. Период проведения тестирования в моем случае был привязан к времени начисления премии. На каждом проекте он может назначаться индивидуально, все будет зависеть от наличия возможности для его проведения и от интенсивности развития тестируемого ПО (для достижения понимания того, кто и как быстро схватывает новую информацию).
Спасибо, что потратили время на мою статью! Удачи Вам!
