Performance review для сотрудников мы проводим более 10 лет, и проходили мы этот путь не без ошибок. Хорошо, что на ошибках можно учиться — из них мы сложили анти-топ и используем его как чек-лист для подготовки ревью.  

Как мы проводим performance review

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

• Оценивает результаты работы по проектам и предыдущим целям
• Обсуждает и проясняет с сотрудником результаты работы и обратную связь
• Даёт пояснения и рекомендации по поводу разрешения проблем в работе
• Обсуждает видение дальнейших карьерных планов и развитие сотрудника
• Ставит сотруднику цели по развитию на следующие 6 месяцев

Результат встречи – отчёт о ревью, где описаны все эти пункты. Он отправляется сотруднику.

Теперь перейдем к ошибкам, которых мы насовершали.

Ошибка 1 — Проводить performance review просто чтобы было

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

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

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

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

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

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

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

Ошибка 2 — Проводить не регулярно

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

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

Ошибка 3 — Не готовиться

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

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

Ошибка 4 — Директивный стиль

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

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

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

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

Ошибка 5 — Не собрать нужные отзывы от ключевых людей

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

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

Ошибка 6 — Давать всем отзывам одинаковый вес

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

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

Ошибка 7 — Поверхностные отзывы и самооценка

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

Ошибка 8 — Не проверять результаты 

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

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

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

Ошибка 9 — Заминать негативный фидбек

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

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

Ошибка 10 — Забывать хвалить и благодарить

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

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

Ошибка 11 — Давать неконструктивный абстрактный фидбек

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

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

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

Ошибка 12 — Ставить цели без учёта целей компании

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

Ошибка 13 — Ставить нечёткие цели для развития без понятных индикаторов

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

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

Ошибка 14 — Ставить не амбициозные цели 

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

Ошибка 15 — Не выполнять задачи, определённые по итогам ревью

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

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

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