Привет, Хабр! Меня зовут Женя. Десять лет назад я стартанул агентство аутсорс-тестирования «Кавычки». У нас в компании нет и никогда не было деления тестировщиков на джунов, мидлов и сеньоров. Хотя были попытки. Расскажу, почему так получилось и как можно жить без грейдов.
Спойлер: жить – не тужить
Disclaimer
Многие IT-компании используют грейды (они же градации, ранги, классификации и т. д.) — такой способ поиска, оценки и мотивации людей. Окей, система выглядит вполне логичной. Если ты мидл — ты должен знать вот это, уметь вот это, а твоя зарплатная вилка вот такая. И было бы всем счастье, если бы это действительно работало.
Еще на старте я понял, что в моей компании с грейдами не срастется. Сколько бы я с этим не сталкивался, они не оказывались чем-то внятным, кроме как строчкой в резюме. Здесь все-таки стоит сделать небольшую пометку: мы занимаемся аутсорс-тестированием и работаем с разными проектами. В нашем случае грейдирование оказалось бесполезным. Возможно, компаниям, которые развивают только свой продукт силами внутренней команды, эта история подойдет.
Внедрять грейды или отказаться от них — каждый решает сам. Я на личном опыте убедился, что без них можно круто развиваться и расти. И хочу рассказать, как построить работу в команде без градаций и что от этого ждать. Если кому-то мой опыт будет полезен — отлично. Для этого и пишу. Если нет — тоже сойдет.
Откуда ноги грейды растут или немного лирики
К 20 веку корпорации стали больше интересоваться методами эффективного управления командой. Тогда не существовало единой и понятной схемы, как определить взаимосвязь между ценностью, которую сотрудник приносит в компанию, и его зарплатой. Был такой психолог и владелец консалтинговой компании — Эдвард Хэй. Когда он в очередной раз оценивал сотрудников клиента, его светлую голову посетила идея разработать методику, позволяющую рассчитывать эти показатели.
Непонятная схема или пример подстановочных таблиц (по Hay Job Evaluation and Profile Method)
Это балльно-факторная система оценки должностей в виде таблиц. Все требования к должности разделены на факторы и измеримые параметры. По каждому параметру выставляются баллы. Чем больше баллов, тем выше грейд и оклад. Это если коротко, а если не коротко — можно почитать, например, здесь. Со временем из метода Хэя (в народе его называют зарплатанометр) стали вырастать похожие методики и адаптироваться под разные виды компаний.
В IT система грейдов по классике состоит из трехуровневой модели — джун, мидл и сеньор. Правда, встречаются и более замороченные варианты: джуниор+, мидл+, мидл++ — для знатных приверженцев грейдов. Часто компании формируют необходимый перечень навыков и подстраивают грейды под себя. Как итог — на рынке много джунов, мидлов и сеньоров, но все они разные. И из-за этого и появляются запросы на грейд уровня + или ++. Потому что хрен ты сможешь оценить специалиста точно в указанные рамки. И вот здесь начинается Адъ и Израиль.
Что не так с грейдами
Первое, чо я понял — их не существует
Когда я начал нанимать ребят в штат, то все чаще сталкивался с одной и той же ситуацией. На собеседование приходит человек с большим опытом — на прошлом месте он был на позиции «сеньор». Он хочет за свою работу высокую з/п, ведь он сеньор. Тогда я прошу его рассказать, за что он хочет такие деньги, что он умеет? В итоге понимаю, что знаю гораздо больше, но работаю за меньшие деньги. И опыт на тот момент у меня был небольшой — около 5 лет. Тогда кто я, если обладаю большим объемом знаний, чем сеньор в тестировании? Может быть, дурак, который дёшево себя продает? Или, получается, что объективных градацией для меня просто не существует. Возможно, уровень «сеньор» должен определяться тем, что человек может решить любую задачу, потому что он не только имеет опыт, но и склад ума к solving problems. Посмотрим на это ниже.
Но я же мидл…или нет?
Есть еще одна боль с этими классификациями. Тестировщики на позициях «джуниор», «мидл», «сеньор», работая в одной компании, как правило, сидят на одном продукте. В рамках одного продукта сложно прокачать разносторонние навыки. Если тестировщик работает с приложением только на десктопе, то он заточен под тестирования этого приложения. И да, возможно, в этой области он очень хорош — знает инструменты, подходы, как проверить производительность и т. д. Но если понадобится сделать то же самое в вебе или в мобильном приложении — будет больно. Потому что нет знаний о вебе, о мобильном, о клиент-серверной архитектуре и тп. Ну и кто же он тогда? Джун?
Что мы получаем:
- Система грейдов негибкая и необъективная
В некоторых компаниях формируют свои требования для каждой ступени грейдов. Но эта система работает только в рамках этой компании и для определенного продукта. И кроме того, согласитесь, что требование solving problems очень размытое.
- Грейд ничего не говорит о настоящем уровне знаний
Сеньор может пытаться устроиться в другое место с более сложными проектами, но не пройдет даже на джуна. Потому что не обладает подходящими навыками.
- Грейды ограничивают
Зачастую компании используют эту систему, чтобы привязать зарплату к грейду и стажу. И тем самым ограничивают человека. Для перехода на новую ступень, в копилочке должен быть определенный стаж работы. Сиди и жди. Но разве количество лет определяет уровень знаний?
- Грейды всех путают
При поиске работы многие люди осознанно выбирают вакансии не по уровню знаний и навыков, а по размеру зарплаты, которая как бы соответствуют их грейду. Итог: разочаровываются обе стороны.
Окей, тогда как оценивать работу
Ну отказались мы от грейдов, чо дальше? Если работать по модели предоставления аутсорс-услуг, то нет смысла привязывать з/п к званию и стажу. Потому что в компанию приходят проекты с разным уровнем сложности, и работа над ними требует постоянного апгрейда навыков. Здесь логичнее смотреть на то, какие задачи может взять сотрудник, и сколько денег он принесет в компанию.
По каким параметрам оценивать сотрудника:
- количество задач, которые он может взять;
- уровень сложности, неопределенности и стоимость этих задач;
- востребованность навыков, которыми он владеет;
- общая прибыль компании.
Как это работает у нас: мы предоставляем клиенту команду тестировщиков на проект. Поэтому на собеседовании мы смотрим на навыки тестировщика и сопоставляем, на каких проектах можем их применить и под какие задачи. У нас есть диапазон з/п, в разрезе которого мы готовы обсуждать оклад. В этом диапазоне мы и определяем фикс в зависимости от проектов, на которых тестировщик сможет работать.
Если к нам приходит человек с хорошими знаниями, и мы понимаем, что можем применить их на максимум — зарплата будет высокой. Но если к нам придет мидл или сеньор, а его знания закрывают задачи на 40 тыс. рублей, то и зарплата будет соответствующей. Потому что придется вложить время и силы в его обучение.
А что с мотивацией и ростом
Компания, которая не привязывает з/п к должности и стажу, дает большое пространство для развития. Хочешь расти и больше зарабатывать — все в твоих руках: учись, бери новые проекты, работай над сложными задачами. Например, если наши тестировщики хотят поднять з/п, то мы с каждым обсуждаем: на какой проект для этого нужно пойти, какие задачи взять, чему научиться.
Чтобы такой подход работал, нужно создать все условия для этого. Как минимум странно, не предлагая никаких возможностей, ожидать, что все ломанутся на дорогостоящие курсы. В компании должна быть четкая взаимосвязь между точками роста и возможностями для этого:
- Чтобы увеличить з/п, нужно постоянно учиться, прокачивать навыки.
Для этого компания должна помогать сотрудникам — проводить внутреннее обучение и оплачивать курсы, сертификации, тренинги.
- Чтобы увеличить з/п, должна быть возможность взять новый проект или более сложный.
Важно сформировать внутри компании прозрачную коммуникацию, чтобы каждый сотрудник мог открыто говорить про свои карьерные ожидания и новые проекты.
Человек учится, переходит на другой проект или берет еще проект, потому что на прошлом наладил все настолько хорошо, что его присутствие там требуется в меньшем объеме, и вместе с ним растет его з/п. Это же гораздо лучше и интереснее, чем сидеть, считать стаж, сдавать тесты на профпригодность и знания, которые ты потом никогда не будешь использовать. Или вовсе потерять интерес к профессии, упоровшись на одном проекте. А упарываясь на одном проекте, упираясь в потолок, люди будут покидать компанию.
Как-то все слишком красиво, где боль
Конечно, все не так безоблачно. Иногда случается конфликт интересов, ведь такой подход — не для всех. Некоторые сотрудники просто не приживаются в компании, потому что не понимают, как им двигаться. Если решитесь уйти от градаций, будьте готовы к этому.
Кому-то сложно работать без понимания, какой у него грейд. Без четкой инструкции, что нужно сделать; сколько проработать, чтобы добраться до нового уровня. И в этом нет ничего плохого — такой тип мышления. Но я уверен, что без грейдирования и компания, и сотрудники могут достигнуть более крутых результатов, чем с ним. Потому что такой подход притягивает в команду целеустремленных и свободомыслящих людей. И они готовы действовать без каких-либо инструкций и рамок. К слову, на эту тему есть интересное исследование, что ждет компанию, которая откажется от жесткой иерархии и градаций. Возвращаясь к конфликту интересов, я вижу только два решения: либо найти компромисс и точки роста с помощью новых проектов и задач, либо попрощаться. Каждому свое.
Что еще важно или история про понты
Может казаться, что без грейдов нет прозрачности в росте. Я думаю, что как раз эта система и мешает росту. Мы не завязаны на том, какой у нас ранг, звание и другие «понты» — это дает нам стимул развиваться и расти в наших знаниях. Мы не думаем, чего мы достигли. Мы ищем, чему еще нужно научиться. Я сталкивался с историей, когда человек с высоким грейдом считал, что развиваться уже некуда, ведь он и так красавчик.
«Сказал а, говори б». Окей, вот история из жизни:
На конференции по тестированию я познакомился с одним сеньором. Всю беседу он гнул пальцы, рассказывая, какой он классный сеньор, как он на линуксе что-то поднимал.
«Ну хорошо, а на виндоус можешь это сделать?» — спросил я.
«Нет, виндоус — говно».
«Ну подожди, а если задача такая будет, что ты будешь делать?» — не успокаивался я.
«Я буду на линуксе это делать».
Занавес.
Ну вот как работать с человеком, который будет делать только то, что ему нравится? Как он будет развиваться и узнавать что-то новое? Какая мне разница сеньор он или не сеньор, если он не может сделать то, что нужно проекту?
Профессия тестировщика — это не профессия, которая определяется грейдом. Да и в целом профессии в IT невозможно оценивать только в рамках должности и стажа. Нашу работу определяют знания и постоянное стремление двигаться вперед. Нужно обладать широким кругозором, интересоваться всем: от поведенческой психологии пользователя до разработки. С каждым годом проекты становятся все сложнее и требуют новых навыков и знаний. И при таком раскладе упереться в то, что ты всего достиг и больше ничего не нужно — значит выбрать путь в никуда.
