Перевод материала «P2P Salary Review».

Как и почему я реализовал P2P опрос для расчета зарплат в корпорации: конкретный пример

Цель: честная оптимизация

CEO компании поднял минимальную зарплату в компании до £45,000, и некоторые сотрудники покинули компанию из-за этого. Знаете почему? Потому что образованные, вкалывающие люди отказались принимать факт того что обычные работяги, не инвестирующие в свое развитие столько сил и времени стали получать те же деньги.

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

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

Честность это самый важный аспект любой зарплатной системы. Честность, это то, ради чего мы оптимизируем.

Имейте ввиду, то что ваша компания это часть большой системы (индустрии). Этой системе не важно как ты справедлив, но ты не можешь недоплачивать своим людям. Ты должен быть честным и конкурентным. В противном случае, восторжествует справедливость, которая называется «найти работу получше», и накажет вас.

Осознание своего невежества

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

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

Какие варианты у меня есть?

Люди разбиваются на малые самоорганизующиеся группы. Вы должны дать им возможность оценивать друг-друга, по каждой из специфических ролей, например Team Lead, Product Owner или Scrum Master. Как бы то ни было, но Scrum Master и Product Ownerне имеют достаточно технической экспертизы, чтобы оценить разработчика правильно. Они зацикливаются на «софт-скиллз», что лишь половина картины. Team Leader смотрит как раз в обратную сторону. И происходит то, что я по прежнему должен оценивать эти «специальные» роли.

А самая большая проблема в том, что как только ты возлагаешь полномочия о контроле заработной платы в руки другого человека, ты не можешь больше применять к нему тот же подход. Таким образом, моя самоорганизованная команда будет тяготеть к «Менеджеру проекта, со своими миньйонами».

Это старый добрый способ централизованного стиля управления с репортами-контролем, отсутствием доверия и сотрудничества.
«Я также обратил внимание что разные страны и культуры ставят во главу угла разные ценности». Некоторые, например UK ценят контроль и сдержанность, тогда как другие (например, Скандинавия) ценят свободу и инициативу." [Software Architecture for Developers; Simon Brown; Leanpub 2014]

Мне не нравится это. Это очень непродуктивно.

Клиент, рынок и акционеры

Если не Product Owner, не Scrum Master, и определенно, не менеджер, то кто может делать оценку? Кто может дать гарантию что люди работают тяжело, эффективно, компетентны и ценны для компании?

Теоретически, наши клиенты либо рынок может отражать это. Мы можем анализировать, приносят ли люди прибыль, либо помогают нам приблизится к нашей цели. К сожалению, это может работать, только если команда может определить над чем конкретно работает этот сотрудник и какие возможности для бизнеса открывает. Но даже в таком случае, это будет вероятно не честно.
Вы не должны наказывать людей за то, что они рискуют или ошибаются. Вы хотите, чтобы они не боялись экспериментировать, ошибаться и извлекать уроки из этого. По крайней мере, пока они не разрушают ваш бизнес. Если они хотят экспериментировать на таком уровне, то пусть делают это со своим бизнесом.

Я работаю в корпорации. Решения о продуктах, которые мы производим приняты на уровне Executive Committee. Оценка моих разработчиков базирующаяся на прибыли будет не честной.

P2P

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

Наши ограничения

Для работников весь процесс может занимать более 30 мин, но по возможности, в большинстве случаев, не дольше 15. И это для оценки ВСЕХ сотрудников. В противном случае, цена огромна, поскольку каждый должен пройти через эту процедуру (и это скучно).
Для менеджера, сбор и анализ информации не должен занимать более одного дня.
нужно чтобы системы было сложно обмануть (поскольку у нас тут довольно хитрые ребята).
Было бы неплохо, если система давала нам что-то более чем уровень зарплат. Было бы отлично если бы система говорила нашим сотрудникам, что они должны делать для того чтобы зарабатывать больше. Насколько это возможно.

Влияние

Отлично, у нас есть ограничения. Что конкретно мы измеряем?

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

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

Как насчет оценки ВЛИЯНИЯ, отдельного индивидуала на компанию? Имеет смысл? Если мы измерим влияние и свяжем это с деньгами, система должна быть честной.

Ты выкладываешься на работе каждый день чтобы двигать компанию вперед? Ты занимаешься самообразованием потому что ты самомотивирован? Твой код в продакшене? Получите, распишитесь.

Вы впахиваете целый день, но гениальная идея посещает вас вечером, вы реализовываете её утром, это решает кучу проблем для всех и позволяет достигнуть результата?
Почему нет? Хотите, без проблем. Только принимайте душ. А потом делайте со своими деньгами все что угодно.

Вы гений, ваше эго размером с планету, вы читаете правильные книги, вы можете свернуть горы благодаря вашем знаниям и экспертизе? У вас степень доктора по аджайлу и реактивный-node.js-экспресс эксперт но не можете работать с людьми, которые вас окружают и выкатывать ваши супер-идеи в продакшн? Мешаете команде? Люди не хотят с вами работать? Извините, но тут никакого влияния, или, даже негативное. Никаких денег.

Хорошо, но оценка реального влияния достаточно сложна. Даже более того, вероятно не будет справедливой. Это командный спорт и лучшие люди могут быть не так хороши в глазах непродуктивных сотрудников, в следствии каких-то изменений бизнеса, вы же знаете, «дерьмо случается». Реальное влияние, так же как и оценка прибыли, будет не честной, и тогда, лучшие люди страдают в силу обстоятельств над которыми они не имеют контроля.

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

Навыки

Как измерить потенциальное влияние кого-либо? В IT, потенциальное влияние базируется на навыках. Чем лучше навыки, тем выше потенциальное влияние, при этом не все навыки эквивалентны. Как адекватно измерить навыки в разумное время?

К счастью, я уже решил эту проблему однажды. В процессе набора в TouK, когда я целыми днями кодил в паре с другими программистами (отличный, но достаточно дорогой способ), я пришел к выводу что для того чтобы давать рекомендации по зарплате, я хочу сравнивать новых людей с теми которых знаю, по шести группам навыков, которые, я полагаю важны для разработки ПО.

Группы

Hard Programming Skills (включает в себя навыки знания языков программирования, OOP/FP, фреймворков, методологий типа XP, TDD, DDD и т.д.)
Hard DevOps Skills (including: Linux administration, deployment/build pipelines, JVM/GC tuning, database tuning, etc.)
Communication (Насколько просто взаимодействовать? Вам нравится работать с этим человеком? Вас раздражает этот парень? Умеет ли он/она читать ваши мысли?)
Understanding (Как быстро проходит понимание новых, сложным штук. Как быстро учится?)
Self-sufficiency (Может ли делать все сам или нужна помощь и контроль? Могу ли я просто отдать ему проблему и получу результат? Это включает в себя понимание домена, широкий кругозор, ориентация на результат, самоанализ и способность к адаптации)
Focus & Motivation (Некоторые люди могут свернуть горы усилием своей воли. Они само-мотивированы. Ты просто убираешь барьеры с их пути и позволяешь сделать дело.
Другие более распыленные, недостаток само-мотивации или смысла, нуждаются в указании направления, склонны к прокрастинации или в худшем случае требуют постоянного контроля и большого количества отчетов)

Это может быть сюрпризом, но hard skills это только треть. Из моего опыта, большинство разработчиков могут делать очень сложные штуки при наличии достаточного количества времени. Но проблема в том что многие из них имеют тенденцию фокусируясь на одной проблеме упускать остальное (самодостаточность), для некоторых я просто не могу позволить «достаточное количество времени», многие не смогут поделиться своим знанием с коллегами.

Да, увы, но IT это не только о программировании. По крайней мере вы должны работать как команда. Программирование это основной навык, но не единственный.

А что здорово, это то что за исключением двух групп hard skills, вы также просто можете оценивать Product Owners и Scrum Masters. Что делает весь процесс проще и более целостным.

Этап 1. Сравнение.

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

Поскольку вы не работаете со всеми, вы должны оценивать только тех людей которых можете, и только если можете оценить эти навыки.

Результат выглядит как-то так:

Отлично, у нас есть кое-какие данные. Время фильтровать шум.

Этап 2: Черновая и финишная обработка данных.

После этого, я хотел бы взять каждого по отдельности, и попросить пояснить собственную картину. Мы можем поговорить о «соседях» находящихся на 20% сверху и снизу.
Обо всех проблемах с другими людьми (как правило коммуникации). Спрашивал как оценки людей могут улучшить их ситуацию. Собирал отзывы.

Потом я нормализировал и кластеризировал результаты значениями -2..+2. Вот так:

Потом я нормализировал и кластеризировал результаты

Ручная нормализация и кластеризация данных заняла много времени даже для двадцати людей.

В другой раз я решил использовать абсолютные значения от 0 до 4 и использовать google forms для того чтобы собрать отзывы. Я боялся что без постоянного масштабирования у люжей будут проблемы с сравнением. Оказалось напрасно. Это IT. У людей нет проблем с пониманием кластеризации. Дискретные значения вполне работают.

Я также добавил поле с заметками, для каждого из навыков, таким образом люди могли описать свои мысли о верхних-нижних 20%.

Я также добавил поле с заметками, для каждого из навыков, таким образом люди могли описать свои мысли о верхних-нижних 20%

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

Однако, я проводил встречи один-на-один со всеми. Полностью автоматизированная система была бы запросто «обманута». Система где ты должен дать свою оценку другому человеку, сложнее сломать. Гораздо более одушевленно. Таким образом, пока мои люди делали кластеризацию данных автоматически, я делал нормализацию и проверки сам.

Этап 3: Анализ данных.

Итак, что мы имеем в конце? Кучу цифр.

Каждая колонка, это сотрудник. Каждый ряд, это уровень. Каждая клетка, отображает голоса для переданного набора навыков в определенном уровне. Цвет зависит от значения, что позволяет быстро заметить пиковые значения.

Простая формула в excel и вы имеете номер для каждого набора навыков, для каждого сотрудника. Вы даже можете просуммировать и получить одну метрику. Эта метрика отражает «звездность». Насколько работник хорош, правда?

Не так быстро

Пока цифры выглядят неплохо. Нужно проанализировать распределение. почему этот парень ненавидит всех кроме трех человек? Кто эти люди? Какие между ними рабочие отношения? Почему эти трое плохо оценены в этом навыке? Почему другие не имеют оценки в Focus & Motivation? Он проактивен? Агрессивен-пассивен? Что насчет этой девушки, она хороша во всем, кроме DevOps? Она все еще работает на Windows?

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

Вы всегда можете спрашивать. Если вы хотите копнуть глубже, вы можете. Красота той системы в том что вы знаете куда копать. Понимание ситуации играет большую роль в нормализации отзывов.

Влияние != P2P опросу

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

Но это не оценивается в P2P опросе.

Это потому что Влияние и P2P опрос показывают не одно и тоже.

Чтобы упростить это, моя формула влияния выглядит так:

Влияние = нормализированый P2P опрос + персональные качества

Качества

Качества просты. Они могут быть негативными или позитивными. Насколько примеров, чтобы было понятнее:

+ Performance/Security — экспертиза которая нужна раз в год
+ Public Relations (блог, open source библиотека, привлекает к нам хороших разработчиков)
+ Assertiveness/Напористость (помогает поддерживать качество на высоком уровне)
— Submissiveness/Покорность (клиент может давить на него, что приведет к проблеме)
+ Iron Willpower/Железная Воля (не ломается, не зависимо от ситуации)
— Low Willpower/Слабая Воля (паникер)

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

Качества изменяют результат кластеризации навыков. Они обычно добавляют или отнимают единицу к финальному результату.

Связь с зарплатой

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

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

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

Итак, что мы можем делать в корпорации, где мы не можем разглашать зарплаты?

Мы не можем опубликовать зарплаты, но мы можем опубликовать, своего рода, точки отсчета. Есть масса сайтов публикующих объявления с зарплатами или вилками зарплат (например, nofluffjobs.com). Если вы определили 5 разных кластеров, вы можете вероятно каким-то образом их связать с должностями (junior/mid/senior developer, architect, senior architect, principal senior executive architect, и т.д.)
Теперь, все что вам нужно, это опубликовать эти предложения о работе с зарплатами (фиксированными либо вилками) и люди могут сравнить свою ситуацию с целой картиной.

Теперь, если всегда связывать зарплаты с должностями и потенциальным влиянием. Обеспечьте открытость и прозрачность. И теперь, поскольку должности открыты, зарплаты тоже становятся очевидны.

Более или менее. Более если у вас только одна цифра попадает в кластер, менее если это диапазон. Так или иначе, люди будут видеть всю картину и дадут знать если она не достаточно справедлива.

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

Выгода

Система имеет достоинства и недостатки. В первую очередь, достоинства.

Я не должен быть судьей. Я не должен играть роль «вершителя судеб». Как только люди понимают, что не должны производить на меня хорошее впечатление, это значительно меняет суть нашего сотрудничества. Это делает их более открытыми.

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

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

Это занимает 15 минут на разработчика, один день для менеджера. В среднем, потому что зависит от того как глубоко ты захочешь заглянуть в «кроличью нору».

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

И это может быть применено к разработчикам, менеджерам, тестировщикам, системным администраторам… Любому кто имеет коллег.

Недостатки

Всегда есть ложка дегтя.

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

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

Вы не можете сравнивать зарплаты между разными ролями (QA/dev/PO) поскольку это разные разные уровни на рынке. Это не так плохо, но поскольку вы обещали быть честным, что произойдет если кто-то сменит свою позицию с более оплачиваемой на менее оплачиваемую? Scrum Master например перейдет в Product Owner? Особенно, если он по прежнему, будет выполнять свои обязанности (потенциальное влияние остается высоким), но что если нет?

Либо как насчет того что некоторые не учат ничего нового годами? В быстро меняющемся мире разработки программ навыки устаревают еще быстрее.

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

Это также, достаточно сложно объяснить не IT людям (CEO, HR) что кто-то может улучшаться на +40% в год. Они просто не готовы так динамично повышать зарплату. Но это случается в IT.

Еще одна моя ошибка была в том, что я давал недостаточно точек отсчета. Я опубликовал только две вилки зарплат, для middle и senior, в силу того что было не просто изменить в нашей корпорации. В тоже самое время, у меня было 5 кластеров из P2P опроса. Некоторые новые люди на позиции senior ожидали более высокой оценки. На самом же деле 70% высококвалифицированных профессионалов были в начале этого зарплатного диапазона. Мои кластера и опубликованные «точки отсчета» были не «каждый к каждому», и это немного смущало людей. К счастью, люди доверяют мне достаточно, чтобы это не было проблемой. Мне просто приходилось немного прояснять такие моменты.

Но все это ерунда, по сравнению с теми преимуществами которые дает P2P опрос.

И самое главное — эта система работает уже два года и людям она нравится.

По крайней мере в подавляющем количестве отзывов, которые я получил. И это делает меня счастливым.