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

Меня зовут Миша Соколов, я старший специалист по тестированию в Контуре. Расскажу, как у нас трансформировалась система оценки QA-инженеров. Спойлер: это был путь от плоской Excel-таблички со скиллами из актуальных вакансий на рынке до разветвлённой структуры из пяти треков развития и распределённого матричного управления для 270+ QA-инженеров. 

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

Опыт 2017 года: почему сквозная Excel-табличка без грейдов быстро превратилась в «инвентаризацию склада»

В 2017 году отдел тестирования насчитывал около 80 тестировщиков из 25 команд разработки с разными стеками, предметными областями и культурой разработки. У нас полностью отсутствовали грейды, а специалисты по тестированию имели разную предметную область. Нам требовалась сквозная система оценки.

Мы пробежались по вакансиям на рынке, взяли скиллы, которые, как нам казалось, отражали потребности Контура, и составили Excel-табличку, по которой хотели оценивать сотрудников. Она выглядела примерно так: 

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

У этого подхода было три недостатка:

1. Опасный бас-фактор. Один человек должен был два раза в год поднимать контекст по 80 сотрудникам и аккумулировать его в своей зоне ответственности.

2. Сходство оценки сотрудников с инвентаризацией. Процесс напоминал работу кладовщика со сканером кодов: быстро, удобно, но чтобы узнать реальное влияние тестировщика на продукт, нужно достать «товар» из коробки и посмотреть на него в других разрезах и задачах.

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

Система оценки сегодня: треки развития и чёткое разделение грейдов

С первой попытки создать систему оценки прошло больше 9 лет. За это время система менялась плавно и постепенно. Прежде чем смотреть на неё, расскажу, как изменилась функциональная зона тестирования в Контуре за это время:

Пять треков развития QA-инженеров

Чтобы сквозная система работала справедливо на большой и разнообразный отдел тестирования, мы выделили 5 портретов (узких специализаций), которые в нашем понимании отображают всю полноту развития тестировщика внутри Контура. Мы предлагаем развиваться по одному или сразу по нескольким трекам:

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

• Техника — фокус на «техномясе». Сюда относится всё, что связано с кодом: от написания автотестов до проверки сложных технических гипотез, разработки инструментов в общие библиотеки или фреймворки, а также нагрузочное тестирование.

• Мобильность — трек про то, что пользу можно приносить не только внутри своей команды, но и ходить на стажировки в те продукты, где требуется принести пользу. Со временем можно перейти в Бюро тестирования. Это тестировщики без конкретной продуктовой команды, они ходят по стажировкам на контрактной основе. Их задача — закрывать горящие потребности, организовывать процессы, писать автотесты или разгребать завалы там, где команда сама не справляется.

• Люди — трек для тех, кто хочет развиваться в управлении людьми внутри функциональной зоны. Сюда мы относим тимлидов крупных команд и руководителей кластеров (мини функциональные руководители на одном из направлений разработки).

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

Разные требования: базовые знания для мидлов и глобальный масштаб для лидов

Постепенно мы пришли и к сквозному пониманию роста специалиста по тестированию в линейке грейдов:

• От Junior до Middle+. На этом этапе специалист по тестированию нарабатывает базу от минимума до полного понимания основ в нашем представлении. Из чего эта база строится? Приемлемые скорость и качество самостоятельного тестирования, экспертиза в проекте или продукте, личная зона ответственности, умение обозначать проблемы и предлагать процессные истории для их решения там, где это возможно.

• От Senior до Lead+. А здесь, как раз, идёт выбор специализации или трековое развитие. Человек сам выбирает, кем он хочет стать, когда вырастет, и работает над развитием в этой области и решением задач уровнем выше. Здесь надо оговориться, что специализация у тестировщиков Контура не снимает базовый контекст, который был наработан до М+. В дополнение к потоковому тестированию задач проекта люди могут попробовать себя в треках развития. Задачи становятся глобальнее, вызовы — масштабнее вплоть до зоны ответственности на уровне функциональной зоны тестирования, например, руководство группой найма или ответственность за обучение всех специалистов по тестированию в компании.

Процесс оценки: как «контроль в аэропорту» распределяет контекст и защищает от субъективности

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

В системе Контура правила оценки тоже едины для всех, а сам процесс распределён на три независимых потока:

1. Оценка Junior — Middle+: децентрализация через руководителей кластеров

За неё отвечают руководители кластеров. Руководитель кластера — это тот же функциональный руководитель, но в рамках бизнес-контекста одного направления, например, продукты 1С, инфраструктура, внутренние сервисы. 

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

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

2. Перевод на Senior — Lead+: асинхронная комиссия экспертов и защита промодоков

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

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

• Состав комиссии: в неё входят эксперты, которые сами ранее успешно прошли такую же комиссию по этому треку. Они обладают насмотренностью и компетенцией, чтобы сравнить чужой опыт со своим, с опытом коллег по прошлым тактам комиссии.

Что если комиссия выносит отрицательное решение?

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

3. Внешний найм: сквозная синхронизация требований с внутренним рынком

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

Магия динамики: почему живой человек и его нестандартные кейсы заставляют систему эволюционировать

Внимательный читатель спросит: «Мы говорим про систему и процессы, а где здесь место человека?».

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

Пример из практики:

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

Костюм индивидуального пошива: кому и почему категорически не подойдёт система Контура

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

Пять признаков того, что вам нужна совершенно другая система оценки:

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

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

• За найм и оценку отвечают только HR. Мэтчить профили внешнего рынка с внутренними требованиями без участия лидов тестирования будет тяжело.

• Управление тестировщиками находится вне функциональной зоны QA. Менять и вводить процессы в таком подходе просто невозможно.

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

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

А как устроен процесс ревью в вашей компании? Буду рад обсудить в комментариях.