Практически каждая компания, в которой я работал или работаю, сразу после моего найма совершает два действия.
- Переезжает
- Вводит грейды тестировщикам
Пять компаний, исключение - одно. Яндекс не переехал. В остальном завидное единодушие. Терпеть не могу переезды, но сегодня предлагаю поговорить о грейдах.
Для начала - примеры названий ярлыков, которые мы будем развешивать. Чтоб придать разговору предметности.
Раз:
Стажер-тестировщик
Младший инженер по тестированию
Инженер по тестированию
Старший инженер по тестированию
Главный инженер по тестированию
Ведущий инженер по тестированию
Руководитель группы
Два:
Стажер (Intern)
Младший тестировщик (Junior test engineer)
Тестировщик (Middle test engineer)
Старший тестировщик (Senior test engineer)
Специалист по тестированию (Expert test engineer)
Ну и для примера возьмем описание - например сеньора или старшего.
Раз:
Знает тестируемый продукт на 85%
Обладает экспертными знаниями в области тестирования и начальными в контроле качества.
Использует разные техники тестирования, в зависимости от задачи.
Обеспечивает доступность (распространение) информации и опыта среди других участников команды.
Обладает навыками тест дизайна
Проводит анализ рисков перед тестированием для обеспечения качества
Обладает всеми необходимыми техническими знаниями
Оптимизирует тестовые сценарии
Возложена определенная ответственность за какой-то процесс или функциональность системы
Умеет эффективно планировать задачи и быстро давать оценки по тестированию
Способен самостоятельно принимать решения
Два.
Условия входа:
Middle test engineer плюс: - обучение стажеров, - консультации коллег по ТС, - принятие решений по архитектуре ТС, - ревью кода тестов программистов. Инициирует работы по развитию тестирования и ТС. Выполняет задачи на исследование. Пресекает некомпетентные распоряжения руководства. Обладает чувством юмора. Самостоятельно локализует проблемы недоконфигурирования сервиса, ОС, оборудования.
Описание:
Задает уровень качества кода ТС. Учитывает и может сформулировать риски и последствия технических решений. Может оценить время выполнения задач. Выполняет задачи, требующие участия сотрудников других групп. В курсе планов развития сервиса. Ориентируется в конфигурационных опциях сервиса и среды, самостоятельно меняет их при необходимости. Способен предложить SLA при отсутствии заданного. Администраторы и разработчики приглашают на встречи по обсуждению архитектуры, инфраструктуры и разработки сервиса.
Мне приходилось наблюдать, как грейды внедряли для групп от 4 до 200 человек.
Успешно - ни разу.
Когда грейды попытались появиться у команды из четырех человек, они не обратили на это внимание и продолжали быть виталиками и данилами, вместо того, чтоб стать сеньорами и экспертами.
Когда грейды ввели в огромную группу очень разных и даже малознакомых людей - каждый со своим проектом, командой, продуктом, целью, ролью, квалификацией и обязанностями - появилось
"99 недовольных и один неблагодарный".
Что-то здесь не так?
Пойдем с начала. Вопрос - а зачем? Какая решается проблема? Чтобы что?
1. В доисторические времена было два вида тестеров: стажер и тестер. Максимум - три, к предыдущей паре добавлялся автотестер. И этого хватало. Но мир поменялся и их стало больше видов, возникли специализации - документация, нагрузка, инфраструктура, генерация кейсов. Также появился серьезный разрыв в качестве работы - для одной и той же роли, обязанности. И если раньше условный лид мог заказать условному hr'у просто тестера, то теперь приходится уточнять, какого именно, на какую роль, что он умеет, а что - не очень.
2. Вторая возникшая проблема - разная квалификация внутри команды и компании. Есть допустим Вася в команде А и он получает 50 денег. А есть Петя в команде Б и он получает вдвое больше. Проекты и бюджеты - разные, команды - разные. А обязанности - похожие. И команды своими Петей и Васей в целом одинаково довольны. Но тут у руководства возникает вопрос - а может они одинаковые? Может мы переплачиваем Пете? Вместе с этим у Васи возникают сомнения в мировой справедливости. Он же тоже хорошо работает, команда довольна... Необходим механизм сравнения тестеров внутри команды. а пуще того - из разных команд. Зачем - чтоб повысить уровень справедливости и снизить напряжение, соответственно раздав зарплаты и бонусы.
3. Третий способ применения грейдов - освещение дальнейшего пути тестировщика в относительно крупных компаниях. Способ сказать, что после того, как ты перестанешь быть стажером - не стоит останавливаться, а нужно учиться дальше - есть один или даже несколько путей роста, каждый со своими вехами, требованиями и особенностями.
Итого, есть версия, что при появлении легитимной системы грейдов, которую поддерживает руководство мы будем легко и изящно указывать hr'ам на грейд который мы изволим нанять. Мы скажем Васе, что он получает вдвое меньше, так как он эльф 20 уровня, в Петя - 80го. Согласно табличке грейдов. И мы покажем Васе, что нужно качать, чтоб докачаться до 80, выдадим алгоритм действий.
Выглядит изящно. Почему же не взлетает?
Реальность сложно описать в четырех, десяти, даже двадцати пунктах. Даже если у каждого есть подробное описание. Особенно, если у каждого есть подробное описание.
- один проект тупо богаче и может себе позволить зарплаты выше
- человека переманивали из другой компании, но зато ему долго не будут повышать зарплату
- просто разная сложность, казалось бы, одних и тех же действий
- на проекте не нужны активности того типа, что указаны в грейдах
- человек не выполняет определенные обязанности, но все знают, что он - может и он периодически страхует команду
- человек занят обучением, наймами, евангелизмом - внепроектной деятельностью - в дополнение к своим основным обязанностям
- для определенного грейда требуется проводить ревью кейсов, участие в разработке архитектуры, анализировать риски, а в конкретном проекте у конкретной команды в этом необходимости нет
Коротко? Если группа небольшая, то все по Жванецкому - фамилия становится должностью и так все ясно. Но чем больше охватываемая группа, тем более гибкими и обтекаемыми должны быть формулировки. Вплоть до того, что у нас появятся два человека с примерно равными зарплатами, уровнем ответственности, сложностью работы, но с совершенно непересекающимися требованиями и обязанностями. например тест-аналитик и нагрузочник.
Вариант - грейды вида: есть 20 разных характеристик. Для первого уровня нужно обладать любыми тремя, для второго у вас их должно быть пять, для третьего - пятнадцать, для 80го - все двадцать.
Но полубогов среди тестировщиков я видел очень мало. Все больше я видел узкую специализацию либо переход в менеджмент тестирования, в котором появляются свои - совершенно ортогональные скилы - за счет того, что начинают деградировать базовые.
Что же получается в реальности?
Найм.Найм "стажеров-младших" происходит не по грейдам, а в режиме "нам нужен еще один". Найм "экспертов-продвинутых" происходит индивидуально, штучно и ни от каких грейдов не зависит.
Сравнение.Я не представляю, как можно сравнить тестеров из разных проектов. Можно выделить наличие или отсутствие тех или иных бинарных признаков, как то "автоматизация/написание кода", "знание бухгалтерии", "nix системы". Но в разных обстоятельствах-проектах эти признаки имеют разный вес. И даже если этот вес зафиксирован - есть еще разные этапы развития команды. Ценность навыков будет меняться и я не представляю как можно будет взять средний для компании.
Версия развития, направления для обучения тестировщика.
А этот вопрос можно решать уже и совсем не только грейдами.
Это повод для разговора, но в общих чертах, тут должны сработать: список специализаций, список людей-примеров этих специализаций, внутренние и внешние спецкурсы, позволяющие изучить ту или иную специализацию.
А еще замечательная штука - жесткая конкурентная среда, в которой каждому тестировщику будет ясно, что без освоения новых и углубления существующих навыков он не только не сможет получить больше ресурсов, но имеет шанс потерять существующие. Но это уже тема следующего поста.
Итого: Вместо грейдов нужно создать программу обучения для тестеров, из внешних и внутренних курсов. Желательно в программу должны входить полезные для конкретных проектов навыки. Не знаю как, но объяснить и показать тестерам и, самое главное, менеджерам проектов, что прохождение и применение этих курсов повышает полезность для проекта.
И тестеры, прошедшие курс получают доступ к нефинансовым ресурсам - допкурсы, переходы в интересующие их стажировки.
Кстати, оказывается, что для этого нужно больше рассказывать о полезной деятельности тестировщиков не самим тестировщикам, а менеджерам и их командам.