Чтобы сохранить контекст, придется кратко рассказать, что же такое performance review и как оно проходит в Юле. Не буду расписывать подробности, перечислю лишь основные этапы:
Self review: каждый сотрудник описывает и оценивает свои достижения за последние 6 месяцев. Следом выбирает коллег, которые смогут оценить и подтвердить эти достижения.
Peer review: коллеги оценивают результаты сотрудника, после чего у нас получается набор оценок по каждому сотруднику.
Калибровка: об этом этапе я хотел бы рассказать подробнее в этой заметке.
Донесение результатов performance review до каждого сотрудника.
Калибровка, как мне кажется, самый малоизвестный и слабопонятный этап во всем performance review. Если с self review и peer review всё более-менее ясно и не вызывает вопросов, то с калибровкой всегда есть недопонимание. Почему так? Наверное, из-за того, что большинство разработчиков никогда не присутствовали на калибровке лично. Из-за этого появляются догадки и домыслы, которые я хотел бы развеять. Давайте попробуем вместе разобраться, что же это за калибровка и как она происходит у нас в Юле.
Что дано?
Несколько команд, у каждой из которых есть свой руководитель (engineering manager).
Руководители направлений (руководители engineering manager’ов).
Лиды функций (frontend, backend, iOS, Android, QA).
СТО.
Результаты self и peer review в виде списка достижений каждого сотрудника с оценками.
Команд достаточно много, людей тоже немало, поэтому мы решили проводить калибровку в разрезе функции (frontend, backend, iOS, Android, QA), то есть сравнивать и оценивать между собой функционально близких ребят. Нам показалось, что будет сложно сравнивать backend-разработчика и iOS-разработчика.
Калибровочная сессия
Перед калибровочной сессией все участники получают сводную информацию для ознакомления. Это единый файл с таблицами по каждому сотруднику. В них приведены достижения и оценки из self review, оценки непосредственного руководителя (engineering manager) и оценки peer reviewers (без указания, кто и как оценил, только числа).
Разработчики в файле отсортированы по категориям от младшего к старшему, т.е. от Junior к Principle. Это нужно для того, чтобы в ходе калибровочной сессии рассматривать ребят в таком порядке и не терять фокус ожиданий, прыгая между категориями. Ведь нужно помнить, что требования и ожидания от junior-разработчика совершенно другие, чем от senior.
Когда все участники калибровочной сессии собираются, начинается презентация и обсуждение. Engineering manager представляет члена своей команды, рассказывает о том, что сделал этот человек, какие результаты показал, как повлиял на результат команды, как взаимодействовал с коллегами и т.п. Представление длится недолго, в зависимости от размера команды может идти от минуты до трех.
Сразу после этого все желающие могут и должны задавать вопросы про этого сотрудника. Цель этапа — получить максимально объективное мнение о заслугах и результатах работы сотрудника. На вопросы отвечает не только непосредственный руководитель, но и любой, кому есть что сказать о разработчике, находящемся в фокусе внимания. Этот этап может занимать от пяти до десяти минут. Иногда приходится прерывать обсуждения, когда «на сцене» какой-то неоднозначный персонаж, повлиявший на жизнь и работу большого количества коллег.
Затем настаёт время голосования. Используется техника planning poker. И так же как и при оценке задач, после вскрытия карт люди, давшие минимальную и максимальную оценки, аргументируют их. При необходимости проводится повторное голосование. Финальная оценка считается совместной и все участники голосования понимают, почему выставлена именно она.
Стоит отдельно сказать несколько слов про шкалу оценок. Мы выбрали:
2 — результаты работы сотрудника оказались ниже ожиданий от его текущей категории (грейда);
3 — результаты полностью соответствуют текущей категории и ожиданиям от сотрудника;
4 — результаты превзошли ожидания от текущей категории, такой кандидат достоин повышения (если такая оценка получается на первом performance review, скорее всего, сотрудник перейдет в следующую категорию);
5 — результаты работы превзошли все ожидания, это очень крутой результат и мы согласны, что этот сотрудник перерос свою текущую категорию.
Что мы получаем по завершению калибровочной сессии
У нас появляется список всех сотрудников с оценками, выставленными коллегией руководителей. Эти оценки максимально объективны, насколько могут быть объективны любые оценки, выставляемые одним человеком другому. Мы можем быть уверены, что эти оценки лишены протекционизма или, наоборот, специально занижены. На основании этих оценок принимаются решения о смене грейда каждого сотрудника. И руководителю проще подготовиться ко встрече, посвященной результатам оценки, потому что вклад каждого сотрудника в общий результат становится более наглядным и формализованным.
В любом процессе, где оценки выставляются людьми, присутствует субъективизм. Но performance review помогает снизить влияние личного мнения отдельных руководителей на результаты оценки работы сотрудника. Без калибровки, если бы оценки выставлял только руководитель, это было бы максимально субъективно. Например, ваш руководитель заморачивается по поводу пунктуальности, а вы считаете, что начинать рабочий день можно в любое время до утреннего командного стендапа, лишь бы работа делалась, да и компания в целом к этому относится нормально. Велик шанс, что какие-то ваши «бытовые» косяки будут влиять на оценку вашей работы, если для оценивающего эти косяки важны и существенны. В случае коллегиальной оценки руководителю будет сложнее повлиять на общий результат, если в компании не принято наказывать за «бытовые» косяки. Вас будут оценивать за результаты работы, а не за внешний вид, манеру говорить или любовь к несмешным мемам.
Может показаться, что очень многое в результате зависит от качества представления результатов работы, которое проводит engineering manager перед участниками калибровочной сессии. Не буду лукавить, хорошая презентация играет некоторую роль. Опытный менеджер может топить за своих ребят лучше, чем новичок. Но когда начинается сессия вопросов и ответов, когда менеджера начинают закидывать уточняющими вопросами, откровенный обман и сильное приукрашивание вскрываются. Невозможно плохого сотрудника представить хорошим, а прекрасно работающего — потопить.
Можно пытаться сломать систему, например, добавив в peer reviewers людей, которые будут лишь хвалить и ставить максимальные оценки. Но такой результат, скорее, вызовет лишние вопросы на калибровке.
Внимательный читатель задаст резонный вопрос: «Если окончательная оценка зависит лишь от калибровочной сессии, зачем нужны эти self и peer review? Почему менеджеры не могут просто собраться и договориться о повышениях?» Могут, более того, во многих компаниях так и происходит. Кажется, что более распространен радикальный вариант, когда решение принимается не коллегиально, а единолично каким-то руководителем. Но это плохой путь! Во-первых, крайне полезно попросить каждого сотрудника рефлексировать о своей работе, оглянуться назад и посмотреть, что удалось сделать и чего добиться. Во-вторых, калибровка помогает менеджеру увидеть зоны роста для каждого члена команды. Понять, что вот тут хорошо бы обратить внимание на это и приложить дополнительные усилия. В Юле мы считаем, что одна из основных задач менеджера — помогать сотрудникам расти и развиваться. Performance review очень хорошо помогает в этом процессе. Конечно, если сам сотрудник склонен к развитию и стремится к нему.
JustDont
Весь абзац звучит, как сферические единороги в вакууме, уж извините.
Во-первых, представление чьих-то результатов другим человеком — всегда будет больше зависеть от представления, чем от результатов, если только у этих результатов нет конкретного практического выхлопа, который все участники этого собрания уже сами пощупали.
Во-вторых — окей, систематически скорее всего не выйдет представить хорошего сотрудника плохим и наоборот. А как насчёт "представить хорошего сотрудника обычным"?
В оценке сотрудников главная проблема далеко не в драмах и накале страстей а-ля "пришел в контору, сделал офигенно, а меня уволили". А в ползучей недооценке/переоценке, где личная (не)совместимость с конкретными людьми (в вашем случае — с представляющим) может значить гораздо больше, чем профит от сотрудника для компании.
Aist Автор
Отчасти все так, представление результатов работы кем-то другим — это риск для сотрудника. Но мы постарались это учесть. На калибровке каждый видит, во-первых, ачивки сотрудника (что он сделал и что он сам про себя написал), во-вторых, все видят оценки пиров. Поэтому, получается чуть объективнее.
Возможно, специфика наших команд такова, что мы ± понимаем результаты друг-друга, т.е. ачивки для нас говорят о результатах сотрудника. Поэтому мы видим крутых ребят и их сложно представить обычными (наоборот тоже не получится).
Было бы интересно услышать варианты, которые сделают систему еще лучше, прозрачнее и удобнее для всех.
JustDont
Из того, что видел лично я и на своем опыте — всякого рода "объективная оценка" это всё такая же субъективная оценка, только оценивающих больше. И всякий профит от усреднения результатов нивелируется тем, что части оценивающих пофиг (а части — и вовсе глубоко пофиг), т.к. у них у всех совсем разная мотивация. И по факту всё равно оценивает очень ограниченный круг заинтересованных лиц. И в итоге всё идёт точно так же, как и в традиционной схеме через представление начальника, только при этом все радостно рассказывают по кругу, какие же они офигенно объективные.
Aist Автор
А помогает ли сотруднику полученная оценка пиров и колибровочной сессии? Ты разработчик, сидишь пилишь фичи, потом пишешь набор достижений, которые должны показать, почему ты молодец. В итоге получаешь в ответ оценки от пиров и от engineering manager’ов по каждой ачивке. Тут появляется возможность понять: «ага, вот эта штука мне казалась мега крутой и успехом, а коллеги это оценили вовсе не так. А тут — наоборот.» Новые вводные и обратная связь от системы :) Разве это не лучше, чем просто слова от прямого руководителя: «ну, Вася, ты в общем-то молодец, давай так же и дальше!»
zloddey
Это обычное дело. Сколько людей — столько и мнений. Если твоя работа влияет на большое количество людей, критики найдутся всегда, что бы ты ни делал. Начнёшь подстраиваться под их мнение и делать всё иначе, так тут же заденешь чувства людей с другого фланга. Как же тогда быть?
Aist Автор
Не стоит подстраиваться, тут я согласен. Но может быть ситуация, например, такая. Ты сделал какое-то хорошее дело (с твоей точки зрения), внедрил линтер в пайплайн, допустим. Но, естественно, это вызвало боль у окружающих, кто привык жить без этого годами. На ревью пиры тебе наставили плохих оценок этой ачивке. Твои действия? Кажется, в этот момент будет правильным задуматься: «команда не хочет улучшать процессы или я чего-то не понимаю и стоит об этом поговорить?» Я вот про эту обратную связь, а не про то, что «в следующий раз я не буду ничего делать, чтобы не получить плохих оценок».
И да, это дополнительная нагрузка на тимлида, которому нужно с каждым поговорить и узнать, как каждый воспринимает результаты ревью.
YChebotaev
Ну если про линтер мы знаем, что это в целом хорошо, то как быть с какой-то штукой, которая не так очевидна? Допустим, использовал я сегрегацию интерфейса при решении одной из задач и получил сдержанные оценки. Как это интерпретировать?
Aist Автор
А что говорит ваш тимлид? :) простите, недостаёт контекста. Но все это может и должно решаться в команде
zloddey
А что мешало пирам самим поговорить о том, что им неудобно? Если процесс разработки выстроен адекватно, то для этого даётся куча возможностей: митинги, командные ретроспективы, small talk на кофе-пойнте (увы, наша главная потеря в ковидные времена), внутрикомандные рассылки и чатики. В конце концов, цепочка 1on1 для самых деликатных ситуаций.
Если же вопросы такого уровня выносятся на уровень performance review, тут уже, скорее, стоит спросить себя: почему не работают более быстрые циклы обратной связи? Но нет, нам некогда, мы тут не процессы улучшать пришли, а людей в покер разыгрывать.
В общем, я пока что не готов покупать аргумент, будто бы процесс "пир ревью+калибровка" дают какой-то радикально более продвинутый фидбек для сотрудника. Да, менеджмент (особенно верхнеуровневый) получит больше информации о взаимоотношениях работников (потому что адекватно построенные процессы позволяют разруливать конфликты на уровне команды). Но поможет ли эта информация принимать менеджменту правильные решения, или же является обычным шумом?
JustDont
Конечно помогает. Когда есть какая-то мотивация к оценке, а обычно её нет.
Вася сделал фичу для продукта, а я пилю другой продукт? Мне плевать на оценку Васи. Вася сделал фичу для продукта, и я пилю этот же продукт, но в другой части? Мне плевать на оценку Васи, если его фича не прибавит мне работы и не запорет продукт каким-то очевидным даже мне образом. Вася сделал фичу для продукта, а я работаю в этой же зоне, и считаю, что фичу надо было бы делать иначе? Оооо, мотивации тут может быть дофига, но вот непредвзятости — нисколько.
И так далее. Когда есть мотивация для оценки коллег — это же обычно означает и пропорциональное уменьшение непредвзятости. Когда мотивации нет — всем пофиг и оценки ставят буквально от балды, или не ставят вовсе (если в этом нет обязаловки).
Так у вас в конторе что — фичи пилят для коллег? А не для успешности бизнеса в целом? Я к тому, что по вопросам "штука показалась крутой, а успеха нет" — тут вообще не на субъективные оценки надо смотреть, а на объективные цифры — либо финансовый результат, либо что-то ближе к продукту, но однозначно связываемое с финансовым результатом.
Aist Автор
В посте я не писал, но каждый сотрудник сам выбирает ревьюверов для своих ачивок, а менеджер может кого-то добавить (фактически, он старается прибавить объективности будущим оценкам). Вряд ли ачивки будет оценивать кто-то, кто совсем не в курсе того, что делал конкретный сотрудник.
mvv-rus
Вообще говоря, такой подход дает просто бездну простора для создания и борьбы враждебных группировок внутри организации. Не опасаетесь?
Aist Автор
Нет, не сильно опасаемся. Ведь если решение принимает один человек, так же есть коррупционные варианты. Но я, если честно, не слышал о таком никогда в ИТ компаниях.