Если ты зашел сюда, то скорее всего уже знаешь, что такое performance review и скорее всего ты недоволен его результатами:

According to Gallup, only 14% of employees strongly agree their performance reviews inspire them to improve

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

А зачем нужен performance review? Простой вопрос, но ответ на него найти так же сложно, как и ответ на вопрос почему информация о зарплатах в компании является тайной за семью печатями (что, кстати, не является законным).

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

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

Итак, зачем нужно ревью? Сергей говорит, для справедливого распределения ограниченного бюджета на блага сотрудников. Хорошая мотивация, быть может все справедливо и просто ты на самом деле заслуживаешь править легаси до крови из глаз, и получать среднюю оценку, пока другие написали уже по пять новых js фреймворков каждый и приносят ‘реальную пользу компании’?

Давай разбираться.

Краткое описание процесса performance review

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

  1. Ты можешь прийти ВНЕЗАПНО, встретив начальника в хорошем расположении духа, а сам ты заблаговременно произведешь хорошее впечатление на него, поднеся с утра кружку горячего кофе, или показав очень красивую презентацию своих достижений. В итоге, зарплату тебе поднимут иди дадут премию не за весь период твоей работы, а конкретно за этот день.
  2. У начальника может не быть информации для сравнения тебя с другими коллегами
  3. У компании может не быть бюджета, чтобы вознаградить твой труд
  4. Тебя оценивает один руководитель, который может быть предвзят по отношению к тебе

Совокупность этих проблем должно решать performance review. И как же оно их решает?

  1. Оценивание твоих заслуг происходит раз в пол года
  2. Одновременно с тобой будут оценивать всех твоих коллег
  3. Компания заблаговременно выделяет бюджет на поощрение
  4. Тебя оценивают несколько руководителей (WTF??)

Рассмотрим каждое решение отдельно.

Оценивание раз в полгода

В теории эта мера предотвращает принятие решений твоим руководителем в состоянии аффекта от твоей текущей деятельности, но что мешает подсуетится перед датой икс начала оценивания (спойлер: оно так и происходит)?

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

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

Одновременно с тобой будут оценивать всех твоих коллег

В теории, эта мера позволит более справедливо оценить твоему руководителю твои навыки и выдать справедливую оценку.

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

Но может быть сама система оценки позволяет адекватно оценивать твои возможности?

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

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

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

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

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

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

Обсуждение моего дела в комитете по продвижению.
— Я написал документацию по этому компоненту, который никто не понимал, как использовать.
— Любой может написать документацию. Какие метрики показывают пользу для Google?
— Этот ненужный код постоянно ломал наш билд. Я потратил две недели, чтобы вычистить его.
— Удалить код может каждый, и только по-настоящему достойные повышения кандидаты могут написать его.
— Никто не решался испытать новую фичу, которую выкатил Дейв, так что я написал пару end-to-end тестов.
— Вот это достойно повышения!

«Сертификат на повышение ДЛЯ ДЕЙВА, который смело выпустил новую фичу без end-to-end тестов»

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

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

Компания заблаговременно выделяет бюджет на поощрение

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

Тебя оценивают несколько руководителей

Еще одним отличием ревью от классической схемы является то, что твой руководитель может совещаться с другими руководителями по поводу твоей оценки. Какая мотивация руководителю другого отдела обсуждать твои оценки - не понятно, но Сергей Бережной считает это возможностью убрать точку отказа в объективной оценке. В тоже время горизонтальную прозрачность оценки считает неправильной идеей, т.к. ты не компетентен. Откуда компетенция у руководителей других отделов оценивать твои задачи - не ясно, но на твою оценку может влиять не только твой руководитель и теперь тебе нужно иметь “хорошие отношения” со всем руководством компании.

Получается, и эта мера нужна руководителям, а не тебе.

Performance review - личный опыт

Кажется, что в теории процесс performance review не несет тебе никакой выгоды, но может быть на практике дела обстоят по-другому? Поскольку процесс прохождения performance review является закрытым, мне придется поделиться личным опытом.

Всего мне доводилось проходить performance review в 3-х компаниях - о них и пойдет речь

Американская компания с русскими корнями

В этой компании ревью проводилось еще тогда, когда это не было мейнстримом - все-таки головной офис в США давал о себе знать и в российском филиале.

Я попал в ключевую команду, которая разрабатывала ядро всей системы - сервер ip телефонии. Ip-телефония и являлась бизнесом компании (очень успешным на рынке США) и именно с этого сервера началась история компании.

Казалось бы, просто идеальные условия для классного performance review?

Но давайте, для начала, я вкратце опишу, с чем нашей команде приходилось работать:

  1. Сервер разрабатывался с 90-х, и похоже, что ядро сервера не переписывалось с этого времени
  2. Сервер создавал около 1500 потоков на проде и работал в дебаг сборке - в релиз сборке он просто падал
  3. 3000 строк в методе класса было нормой, как и машины состояний, логгеры и прочие крутые штуки на макросах
  4. Компилировался он только в Microsoft Visual Studio 2004 - в этой среде и приходилось работать (и это в 2к16)
  5. Гигантские оракловые хранимые процедуры на тысячи строк, в которых разбирались только пара человек в компании

Я думаю, ты уже имеешь достаточное представление о проекте, чтобы понять - 99% времени я тратил на то, чтобы вставить в нужном месте костыль для разработки нового или поддержания существующего функционала.

В целом, адовость этого сервера понимало и руководство, поэтому медленно и постепенно распиливало этот сервер на микросервисы которые разрабатывали другие команды - с нуля, на современных стеках технологий, модно, спортивно и молодежно!

Каждые полгода проводилось перформанс ревью и вот что мне было писать в нем? Как я героически искал место в коде (ололо отладка), чтобы не сломать существующее легаси? Это было проблемой для всех участников нашей команды, мы каждые полгода выдавливали из себя наши заслуги и smart-цели (отдельный вид “практик”, в которых мы ставили себе цели на следующие полгода, которые начинали выполнять только перед самим ревью).

Надо ли говорить, что performance review у наших коллег из других команд проходило гораздо успешнее? Они наперебой демонстрировали фешенебельный набор технологий, которые они осилили - node.js, c++14, rabbitmq, http rest api, docker, redis, qubernetes, erlang и т.д., хвастались, какие большие нагрузки могут выдержать их продукты (наш-то сервер мог выполнять не более 5 запросов в секунду, что очень напрягало прод. инженеров), как они классно внедрили новые подходы разработки и так далее и тому подобное.

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

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

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

Что можно было сказать о процессе ревью в этой компании - соответствовало ли оно целям справедливого распределения благ? Конечно нет. Пытался ли я побороть обстоятельства и показать хороший результат? Конечно пытался, например, я написал утилиту которая значительно облегчала нашу работу и работу тестировщиков, распространилась среди моих коллег и переросла в мой open source проект (естественно, я мог ее написать только в свое свободное время, потому что в рабочее я фиксил и костылял) - но она не несла бизнес value для компании.

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

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

Но почему никаких мер не предпринималось? Да потому что performance review выгоден компании, чтобы снять с себя ответственность за твою не успешность. Это не компания не создает условий для твоего роста, это исключительно ты не можешь проявить себя. А если ты пытаешься побороть обстоятельства, это тоже выгодно компании - вдруг ты реально принесешь “на халяву” фирме какой то профит?

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

Финтех, который очень хотел стать мировым брокером

Российская компания, которая ВНЕЗАПНО разбогатела на не совсем эко методах в финтехе, но потом очень сильно хотела стать мировым финансовым брокером.

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

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

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

Здесь performance review был очень продвинутым - твоего мнения даже не спрашивали. Ну т.е. могли в один прекрасный день сказать: “Парень, мы подумали и решили, что-то ты не очень, давай до свиданья” (и это я не утрирую - одной из популярных тем за обедом, были ставки - кого уволят следующим) и на самом деле это даже честнее - по факту на твое мнение наплевать в любом случае, но тут этого даже не скрывали.

И вот, как то, отдел перспективных мировых практик решил начать традицию “открытых” performance review раз в квартал - составления в конце каждого периода рейтинга команд.

Всего было порядка 20 команд, но как вы думаете, какие места могли получить в конце первого периода оценивания следующие команды:

  1. Desktop девелоперы - команда, которая делала gui (графики, контролы, кнопочки) на базе готового движка
  2. Финансовое вычислительное ядро - команда, которая предоставляла интерфейс для совершения сделок, по сути и есть основной и самый рисковый функционал компании
  3. Геймификаторы - fullstack команда, которая реализовывала различные сервисы геймификации (лидерборд, оналйн мониторинг текущих сделок и т.д.) как и gui, так и backend.
  4. И, наконец, инфраструктурная команда, инфраструктурой которой никто не пользовался, кроме финансового вычислительного ядра - для них цена ошибки была огромной и им приходилось этим пользоваться для тестирования своего сервиса, в то время как остальные сразу выкатывали фичи в прод (которые, ожидаемо, часто не работали)

Рейтинг команд распределился следующим образом.

1-ое место. ИНФРАСТРУКТУРНАЯ КОМАНДА

Занимает первое место с большим отрывом:

  1. Лучшие agile практики - по счастливому совпадению, начальник отдела лучших современных практик был, по совместительству, скрам мастером в этой команде (ого, как повезло ребятам)
  2. Лучшее качество - но никто им не пользовался, кроме вычислительного финансового ядра
  3. Все задачи в срок - но ни одна из них не шла в прод, т.к. это была внутренняя инфраструктурная команда
  4. Лучшее тестирование - каким образом это выяснилось, я не знаю, поскольку весь сервис состоял в предоставлении сервиса песочниц, когда ты мог собрать у себя локально микросервисную архитектуру и протестировать в этом виртуальном окружении свой сервис, но пользоваться этим было невозможно, поскольку требовалось очень большое время, чтобы поднять все сервисы в этом виртуальном окружении - они постоянно не работали по разным причинам.

2-е место. Desktop девелоперы

Кто больше всех доставляет фич в прод? Конечно они, респект им, новый день и новая кнопка в проде!

3-е место. ГЕЙМИФИКАТОРЫ

В этой команде был я, и на самом деле мы заняли место где-то близкое к 20-му (полный список состоял примерно из 20-ти команд), но когда я узнал, на каком месте оказалось финансовое ядро, я даже как то возгордился!

Последнее место. ФИНАНСОВОЕ ЯДРО

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

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

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

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

Так закончилось первое и последнее “открытое” performance review компании, которая очень хотела стать мировым брокером, после которого мы гордо называли себя одной из самых херовых команд компании.

Отвечало ли такое ревью требованию справедливого распределения благ? Конечно нет, в этой компании вопрос справедливости вообще никогда не стоял, поэтому даже говорить об этом смешно. Но как только сам процесс оценивания попытались сделать открытым, это показало весь его сюрреализм и очень ярко обнажило проблемы оценивания - вот это важный и показательный вывод. Ведь Сергей Бережной утверждает, что скрывать оценки нужно потому что ты не компетентен, но кто знает, сколько бы шуму наделало performance review, будь оно публично в том же Яндексе.

Компания, привет из СССР

Крупная российская, или даже еще советская (основана под закат СССР) компания.

Performance review в этой компании очень похож на тот, что проходил в американской компании с русскими корнями. Отличием является то, что я еще могу оценить своих коллег. Кого именно оценивать - решает руководство.

Однако, я так и не понял, на что влияет результаты ревью!

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

Если в начале я пытался серьезно относится к ревью, то потом оно стало источником для приколов и лулзов.

Например, была в моей практике такая история.

Как то к нам перевели нового сотрудника из другой команды - Тамерлан (все совпадения с реальными именами являются случайными) и он начал вливаться в наш проект. Отличительной особенностью нашего проекта от его предыдущего было:

  1. Кросс-платформенная разработка
  2. Большее количество инструментов отладки

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

И вот, когда Тамерлан столкнулся с проблемой в разработке, я подошел к нему “помочь”, и начал объяснять, как ему решить эту проблему:

  • Значит так, открывай git kraken переходи на мой коммит в этой ветке, в отдельной консоли зарегистрируй сервис в системе, тут нужна консоль с админскими правами, запускай в ней сервис, иначе будет требовать разрешить открыть порты, в обычной консоли запускай вот этот тест, он проинициализирует сервис, здесь надо запустить wireshark чтобы перехватить траффик, тут в дебаге из clion перехвати запущенный сервис, там точки останова поставь здесь, потом посмотри тут на wiki формат запросов и отправь их из postman по локальному порту, открывай winevents смотри чтобы сервис перешел в нужный режим и следи за ошибками, потом …

  • Твою мать, я запутался в окнах! Почему у меня на проекте раньше хватало только трех окон - почта, браузер и ide, а тут штук 20 уже открыто и все еще не хватает??77

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

И вот, когда настал момент оценивания Тамерлана, я написал в его оценке:

“Тамерлану стоит преисполниться в многооконной разработке приложений”

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

Зачем нужен performance review в этой компании? Честно говоря, ощущение такое, что хотели сделать как в других ‘крутых международных компаниях’.

Необходимость в этом ревью кажется еще более странным, на фоне инструмента поощрения, с которым я столкнулся впервые именно в этой компании:

Максимальную премию получает вся команда, если … выпускает продукт в срок!

И что, и это все? Да, и это все!

Выглядит это примерно так:

  1. В начале отчетного периода ты согласуешь с продукт менеджером тот набор фич, который сможешь за это время осилить
  2. В течении отчетного периода реализуешь их
  3. ????
  4. Профит!

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

  1. То, чем ты занимаешься и как это выглядит в глазах руководства перестает играть какую либо роль. Разбираешься ты с легаси, или пилишь новый продукт с нуля - все, что от тебя требуется, это умение оценивать свои возможности!
  2. Умением планировать ты реально демонстрируешь все свои лучшие качества в коммуникации, профессиональной экспертизе, сотрудничестве, дисциплине и т.д..
  3. Каждый вознаграждается в соответствии со своим рейтом (уровнем зп) в компании, при этом вопрос рейта решается отдельно, по классической схеме и/или по результатам ревью.

Я, испытав эту систему на себе могу с уверенностью сказать - это наиболее справедливая и мотивирующая система оценивания.

Подведем итоги проведения performance review в компаниях

Как мы видим из моего опыта проведения performance review, в лучшем случае, оно представляет из себя безобидный источник лулзов.

Но может быть это мне так не повезло и вообще нельзя свой личный опыт распространять на инструмент в целом?

Конечно нельзя, но, во первых, как я уже и говорил, само по себе оценивание закрытый внутри компании процесс (а когда его сделали открытым, это было эпично, вспоминаем финтех, который хотел стать брокером), поэтому за неимением более объективной информации приходится прибегать к личному опыту. А во вторых, хоть и Сергей из яндекса пытается давить своим авторитетом и заявляет, что с performance review лучше чем без него (я не сомневаюсь, Сергей, что тебе и другим руководителям стало лучше), но почему тогда так много негативных откликов о яндекс говорит нам о заниженной зарплате и о несправедливом процессе performance review?

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

Performance review - инструмент эксплуатации и занижения твоей реальной стоимости

Как мы выяснили, если тебе не повезло с обстоятельствами, performance review не несет для тебя никакой пользы, а скорее наоборот, как домоклов меч висит над тобой в течении полугода, и ты, в надежде побороть обстоятельства из кожи вон лезешь, чтобы тебя заметили (ну или просто игнорируешь, если корпоративная пропаганда “о справедливости” на тебя больше не действует), но по факту тобой будут манипулировать шантажируя успехом более “успешных” коллег.

Так почему же компании так упорно продолжают использовать и продвигать performance review?

Ну, потому что это выгодно для компании и ее руководителей:

  1. Компании не нужно заботиться о твоем росте, теперь вся ответственность возложена на тебя - расскажи руководству, как ты преодолел обстоятельства и возможно оно тебя вознаградит, при этом не приложив никаких усилий для создания условий для тебя.
  2. Компании проще не повышать тебе зарплату и держать ее ниже рынка - ведь есть “объективная” система, по которой ты не показываешь результата.
  3. Не смотря на то, что тебе скорее всего промывают мозг о важности командной работы, по факту performance review ее разрушает. Помоги Дейву, и Дейв получит премию за лидерские качества, а ты нет. Но зачем компании разрушать командную работу? Ну, потому что сплоченная команда может начать бороться за свои права или, что еще хуже, объединится в профсоюз, и собирать с тебя сверхприбыль и тратить ее на роскошные диваны за 4 млн рублей (яндексу привет) станет значительно сложнее.

Исходя из вышеперечисленного, чтобы тебе не пыталась говорить пропаганда о том, как performance review справедливо оценит твои старания, по факту

performance review - это инструмент эксплуатации и занижения твоей реальной стоимости

и это единственная причина, по которой она применяется в твоей компании.

Что делать?

Итак, если ты ожидаешь, что ничем хорошим очередное performance review для тебя не кончится (по не зависимым от тебя обстоятельствам), то можешь сделать следующее:

  1. Поговори с коллегами. Если вся твоя команда оказалась в заведомо не выигрышном положении для performance review, то лучшего эффекта можно будет добиться, если вся команда откажется от него, требуя прозрачного и по-настоящему справедливого распределения премий для всей команды в целом. Если таких команд несколько, попробуй объединиться и с ними, так будет гораздо эффективнее.
  2. Если ты опасаешься за свою дальнейшую карьеру в компании, то лучше перед этим обратись за помощью, например, в профсоюз Платформа Солидарности, который объединяет работников платформенной экономики, в т.ч. и работников ИТ-отрасли и начни с заполнения анкеты

В начале 2021 года у сотрудников гугл появился свой профсоюз. Значит ли это, что в Яндексе, во всем подражающем гугл, тоже появится свой профсоюз, чтобы возразить Сергею Бережному по поводу эффективности performance review?

Значит ли это, что нужно и дальше мириться с этой бессмысленной и невыгодной для работников практикой или бороться с ней вместе со своим коллективом?

Выбор за тобой.