Как не надо проводить performance review

Принесли вам анти-топ из ошибок, на которых мы выучились правильно проводить PR’ы. Его можно использовать как чек-лист при подготовке к ревью или повесить на стену в переговорке 🙂

Смешно, но иногда легко уйти в «карго-культ». Чтобы это избежать, важно ответить на вопрос: «Зачем?».

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

Для сотрудника:

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

Для руководителя:

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

Легко отодвинуть HR процессы на второй план, когда горит проект. Чем больше пропущенных ревью, тем хуже соотношение ожиданий и реальности. Сотрудник не понимает, насколько хорошо он справляется с работой и растёт ли, а руководитель ждёт результатов, на которые сотрудник может вовсе не ориентироваться. Как итог – разочарование с обеих сторон.

Да и обратную связь сложно собрать, если все уже забыли, что там было на тех проектах… Сотрудники начинают думать, что про них забыли.

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

Важно выделить время заранее и отрефлексировать: оценить вклад сотрудника в целости, вывести общие и наиболее важные достижения, отметить зоны роста, продумать речь.

Руководитель зачитывает свое заключение-приговор и отпускает сотрудника переваривать. Так многие новички и представляют ревью.

Одна из наших ценностей – «Общение на равных». На трудовые отношения это тоже распространяется. Мы выстраиваем партнёрские отношения и договариваемся о взаимных ожиданиях на старте. Важно сохранять этот диалог и после трудоустройства.

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

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

Бывает, что HR собрал отзывы по сотруднику, и, не дождавшись отзывов от одного N, мы провели ревью с максимально положительным фидбеком. Позже оказалось, что этот N как раз руководил проектом, где работал сотрудник, и N очень негодует: сотрудник совершенно не справился с задачами.

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

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

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

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

Сотрудник говорит: «Я сделал ABC», а ревьюер ему верит на слово и говорит: «Вот и молодец!».

Это редкость в командах, где ревьювер плотно работает со всеми сотрудниками. У нас ревьювер – это, например, руководитель направления .NET разработки, который(ая) может напрямую не работать с сотрудником на проектах. Поэтому часто достижения и результаты мы просим подтвердить, например:

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

Давать негативный фидбек и получать его не нравится никому. Но без него бывает не обойтись.

Здесь главное обсуждать не человека, а его работу и результаты.

«Вроде как Федя справляется со всем, всё нормально, ну так и должно быть, можно расходиться…»

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

Такой фидбек давать легко. Для конструктивного и конкретного придётся заранее покопать и проанализировать информацию.

Свойства конструктивного и конкретного фидбека

• Ясно и прямо описывает результаты работы или поведение сотрудника, а не личность.
• Приводит конкретные и недавние примеры из работы.
• Дополнительно может описывать последствия поведения (чем помогло или повредило_.

Отталкиваемся не от того, что кажется важным ревьюеру и не от того, что делалось в команде или на проекте раньше. Цели – это всегда что-то про будущее. Спросите своего руководителя о них.

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

Если этого не делать будет ошибка 8.

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

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

• Офис-менеджер: купить новое рабочее кресло.
• Руководитель разработки: подключить сотрудника к следующему проекту на Next.js.
• HR менеджер: забронировать и оплатить онлайн-курс по TypeScript.

Важно потом не забыть всё сделать. У нас за этим следит HR. Иначе сотрудники подумают, что ревью это профанация.