понедельник, 18 января 2016 г.

О грейдах

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

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

Раз:
Стажер-тестировщик
Младший инженер по тестированию
Инженер по тестированию
Старший инженер по тестированию
Главный инженер по тестированию
Ведущий инженер по тестированию
Руководитель группы
Два:
Стажер (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 системы". Но в разных обстоятельствах-проектах эти признаки имеют разный вес. И даже если этот вес зафиксирован - есть еще разные этапы развития команды. Ценность навыков будет меняться и я не представляю как можно будет взять средний для компании.

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

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

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

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

10 комментариев:

  1. Интересно. Только не понял связи между грейдами и обучением. Грейд - это все-таки про наличие навыков, неважно как они получены.

    ОтветитьУдалить
    Ответы
    1. Грейды могут тонко намекнуть, какие навыки одобряет компания. И получение нового грейда - один из мотивов освоения нового.

      Удалить
    2. То есть ты ЗА грейды?)

      Удалить
    3. Этот комментарий был удален автором.

      Удалить
    4. Нет. Есть способы лучше. В нашем контексте.

      Удалить
  2. Ты к нам случайно недавно не устроился? =) Ввели с этого года грейды. Для всех. Впрочем, на мой взгляд, для программистов это такая же глупая затея, как и для тестировщиков, и работает только в качестве демонстрации того, что отдел кадров не сидит без дела, а придумывает всяческие "полезные" штуки.

    ОтветитьУдалить
    Ответы
    1. А напомни, к вам это куда? Я то ли забыл, то ли не следил =( Содержание и описание грейдов секретно?

      Удалить
    2. Скорее не знал) Я в Спб в Netrik'е.

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

      Возьмем, к примеру, возможные карьерные маршруты внутри компании. От младшего к мидлу, затем к старшему, ведущему, руководителю группы.
      Тут вроде всё понятно и относительно логично. Но если выходить за пределы тестирования, то старший/ведущий автоматизаторы или руководитель группы (который необязательно автоматизатор, кстати) могут перейти в программисты. Но только в бэкенд программисты. Да, реальность у нас такова, что все тесты пока пишутся на питоне, как и разработка, но мне казалось, грейды и все эти переходы должны быть написаны не под конкретных существующих в компании людей, а учитывать какие-то более общие возможности.

      Названия ролей, кстати, в точности такие же как в первом описанном тобой варианте, только без "главного инженера".

      Теперь про грейды. Все от уровня мидла не опаздывают на работу =) Непроизводственные затраты не более 1 часа в день. Стандартное про то что умеет самостоятельно работать.
      Самое интересное в части про квалификацию тестировщиков. Для ведущего и старшего описание одинаковое "владение инструментами тестового цикла Jira/Redmine, Confluence, TestComplete, экспертиза в ручном или автоматизированном тестировании веб-интерфейсов в рамках опыта". Мидл отличается от них только отсутствием фразы "в рамках опыта". И тут получается, у меня совершенно незаслуженно в трудовой написано "старший". Ибо тесткомплит я знать не знаю (возможно, у нас есть одна команда, которая его использует), да и конфлюенсом не пользюсь, так что не владею, можно сказать.
      Примечательно, что для программистов написаны более общие фразы, без упоминания конкретных языков и инструментов.

      В общем, описанные у тебя характеристики вполне адекватны на фоне наших.

      Удалить
  3. Привет!

    Судя по посту, какие-то веяния внутри УР проходят мимо меня, однако я всегда считал достоинством Контура, что грейды, родившись во чреве кадровиков, остались исключительно их игрушкой и не просочились к людям на производстве. И в разговорах о зарплате всегда фигурируют деньги, а не номера грейдов.

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

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

    А вторая проблема — не проблема вовсе, если информация о зарплатах в компании не публична. А так как она не публична, то попытка сочинить суррогат публичности за счёт грейдов ничего кардинально не меняет. Предположим, что сотрудник на должности «тестировщик» может иметь грейд от 6 до 10 (и, соответственно, зарплату от 50 до 150 попугаев, ведь грейд — это не цифра, это «вилка»). Как поможет повысить прозрачность то, что мы знаем диапазон зарплаты? Не поможет.

    Если кардинально иной подход к решению этой проблемы — сделать информацию о зарплатах публичной. И ещё сделать публичным способ её расчёта. Например, так сделано в стартапе Buffer: https://open.buffer.com/transparent-salaries/

    ОтветитьУдалить
    Ответы
    1. Похожий пример, http://www.yegor256.com/2014/10/29/how-much-do-you-cost.html

      Удалить