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. Иначе сотрудники подумают, что ревью это профанация.
А какие у вас есть заметки для проведения полезного ревью? Давайте обсудим в комментариях :)
Комментарии (7)
Nialpe
27.03.2024 11:20+6не нашел ничего про принятие решения об увеличении/уменьшении грейда и/или зарплаты. только словесные пляски - развитие, планы, отзывы...
неужели я один такой меркантильный и наивный? или невнимательный?
andrey_stepanov1 Автор
27.03.2024 11:20+1Нет, не вы один, конечно. ЗП - это очень важно. Процесса грейдирования, которым я был доволен пока нет, поэтому про это не пишу. Если кратко, то сейчас процесс такой: performance review, затем руководитель определяет грейд - 1 раз в год или 2 раза в год для джунов, дальше эти грейды являются вводными для планирования зарплат команды руководителем на следующий год.
SeeeRgo
27.03.2024 11:20+1А за какой срок у вас проходит весь процесс ревью? Не сталкивались с тем, на бумаге каждая стадия ревью должна происходить в рамках одной недели, но систематически занимает около или больше месяца? Если сталкивались то какие выявили причины и как боролись/боретесь?
andrey_stepanov1 Автор
27.03.2024 11:20Сейчас немного перестраиваем процесс, поэтому опишу то что было раньше и получалось от начала самооценки до встречи 1-2-1 с руководителем проходило 3-4 недели. Ревью всей команды старались размазывать равномерно по всему годую. Но да были проблемы - @async_void_returnниже все расписал про них.
zagayevskiy
Прикольно, конечно, но какие тогда цели у этих двоих?:) не "закончить задачи по фронтеду в срок" ли?
andrey_stepanov1 Автор
Да, именно так. Но этом пункте идея в том что нужно ставить цели по развитию, а не по выполнению задач на текущем уровне. В примере: имеется ввиду перейти на роль лида команды.