Улучшая performance review

    Про то, как в Avito работает performance review, я очень много раз рассказывал внутри компании, а этой весной ещё и на двух конференциях — TeamLeadConf и CodeFest. Мы активно вкладываемся в доработку процесса, проводим много экспериментов и собираем кучу полезных данных, поэтому каждое новое выступление стабильно включает в себя какой-то новый контент. Цель этой статьи — не выдать вам готовое коробочное решение, а поделиться всеми практиками и инсайтами, которые мы обнаружили на своем пути.



    TL;DR


    Статья получилась достаточно объёмной. Чтобы привлечь внимание, вот список того, о чем я рассказываю.


    • Из каких этапов состоит процесс performance review в Avito, как писать хороший self review и зачем разбивать респондентов на разные роли.
    • Как быть с вопросами анонимности и постепенно приводить команду к культуре открытой обратной связи.
    • Какие данные и аналитику мы вытащили из собранных 10.000 оценок.
    • Как автоматически определять тех, кто спустя рукава относится к performance review, систематически занижает или завышает оценки.
    • Что такое нормализация и корректировка оценок и как это работает.
    • Какие бывают стандартные антипаттерны в фидбэке, и как их можно выявить.
    • Какой набор шаблонов использовать для быстрого старта в вашей компании и как подходить к вопросу автоматизации процесса.

    Введение


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


    Мы в Avito для целеполагания используем методологию OKR. Это что-то вроде MBO на стероидах. Мы выстраиваем дерево целей всей организации со стратегического уровня и до конкретной команды. Цели определяют ценность для бизнеса или клиента, а ключевые результаты устанавливают измеримые и однозначные признаки достижения целей. Там в комплекте идут ещё разные принципы: амбициозность целей, отвязка от материальной мотивации, публичность, измеримость — но не суть, мой рассказ не об этом, хотя почитать про OKR подробнее сильно рекомендую.


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


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



    Получаем стандартную ситуацию. В теории оценка человека по результатам — это красиво, а на практике при подходе в лоб не работает. С этим я и столкнулся, когда пришел в Avito. У нас было много команд, все работали по OKR, но мы не умели оценивать качество и эффективность работы конкретных людей. Изучив опыт других компаний, мы пришли к необходимости внедрения процесса performance review, который в первом приближении очень сильно напоминал модели, используемые в Google и Badoo. Про Google можно почитать в замечательной книге Ласло Бока «Работа рулит», а про Badoo — почитать статью или послушать доклад Алексея Рыбака. Но, что очень важно, мы не стояли на месте. Взяв за основу готовую модель, мы постепенно, проводя ряд экспериментов и собирая данные, стали её улучшать.


    Как работает performance review



    Сейчас performance review мы проводим раз в квартал, и в среднем от начала до конца на это у нас уходит около двух-трех недель.


    Процесс состоит из пяти основных шагов:


    • подготовка self review,
    • определение респондентов,
    • запуск процесса,
    • проведение оценки,
    • подведение итогов.

    Self review


    В первую очередь оцениваемый сотрудник готовит self review. Это важный момент рефлексии, когда ты садишься и вспоминаешь, чем занимался последние несколько месяцев. Сразу могу сказать, что процесс долгий и болезненный — на это уходит не менее часа-двух. Удобно взять плед, налить какао, отключить уведомления в мессенджере и готовиться к появлению легкого налета депрессии — по себе знаю, что результаты могут довольно сильно расстроить.


    Для того, чтобы респондентам проще было работать с вашим потоком мыслей, я рекомендую разбивать self review на четыре секции.


    Первая секция. Роли и ожидания. Включает в себя описание ожиданий от ваших позиций и ролей. В нашем случае это документы в Confluence с подробным описанием задач и качеств, ожидаемых от сотрудника. Здесь может быть информация о функциональных ожиданиях от инженеров, описание роли наставника, спикера, участника образовательной программы, юнит лидера или тех. юнит лидера — короче говоря, любой позиции и роли, в которой вы выступаете. Эти данные призваны помогать респондентам писать корректные отзывы и понимать, что от вас ожидает компания.


    Вторая секция. Что делали. Краткие результаты последнего периода оценки. Это ключевая секция, в которой вы перечисляете все проекты и деятельность, которой занимались. Это могут быть цели вашей команды, на которые вы фактически повлияли, проекты, над которыми вы работали, детали выполнения ваших базовых функциональных обязанностей. Здесь же стоит упомянуть про свои планы по росту и развитию и подчеркнуть, что вы делали, чтобы достичь желаемого. Всякие дополнительные активности вроде выступления на митапах или участия в хакатонах тоже добавляются сюда. Старайтесь не лить воды, а говорить только о фактах. Если кому-то из респондентов не будет хватать информации для оценки, он спокойно сможет у вас её получить. Пусть люди оценивают факты, а не красивые слова.


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


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


    Посмотрим на несколько хороших и плохих выдержек из self review. Часть была выдумана, часть — взята из реальных примеров.


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

    Это — хороший пример. Оцениваемый в явном виде указывает, каким проектом занимался и до какого состояния его довел.


    «Слишком мало времени уделял наставничеству, из-за чего ввод Иванова в компанию проходит гораздо хуже, чем запланировано».

    Это — тоже пример хорошего заполнения. Чётко обозначенная ошибка — мало времени уделялось наставничеству, подчёркнут результат — ввод в компанию нового сотрудника прошел плохо.


    «Даже не знаю… Просто работал, задачи делал».

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


    «Косячил пару раз, но вроде все норм».

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


    Определение респондентов


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



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


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


    3. Пиры
    Обычно самая многочисленная группа — это пиры. Сюда Костя включил всех своих коллег по команде, с которыми он работает над своими задачами — это несколько iOS-разработчиков, android- и backend-разработчик, дизайнер и тестировщик. Пару раз за последние несколько месяцев Костя пересекался по общей задачи с ребятами из платформенной команды, но решил их сюда не включать, потому что поработать вместе они успели сравнительно мало. Также Костя не стал включать тех ребят, с кем он просто ходит на обед и по барам — он понимает, что их оценка его продуктивности не имеет ничего общего с его рабочими успехами. Костя молодец, будьте как Костя.


    4. Подчиненные
    И последняя группа респондентов — это подчиненные. Косте повезло, подчиненных у него нет. Сюда стоит добавлять даже неформальных подчиненных. К примеру, вы ведущий разработчик, и часть времени менторите джуниора.


    Запуск процесса


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



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


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


    Затем руководитель стартует ревью в нашем инструменте для performance review. Всем участникам приходят уведомления в slack и начинается период оценки.


    Проведение оценки


    Теперь пора переключить майндсет и перейти в роль респондентов. Посмотрим на то, как Костю оценивает его коллега. Он читает self review, смотрит на список приложенных ожиданий и отмечает релевантные для себя — те стороны его деятельности, с которыми он имел дело и может адекватно оценить.


    У нас действует такая градация оценок.


    • (1) Значительно ниже ожиданий
    • (2) Ниже ожиданий
    • (3) Соответствует ожиданиям
    • (4) Выше ожиданий
    • (5) Значительно выше ожиданий
    • (0) Затрудняюсь дать оценку


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


    Оценка:
 «Ниже ожиданий»

    Комментарии к оценке:


    «Вместо того, чтобы обратиться за помощью, неделями закапывается в проблему сам. Кроме того, пока не начал ориентироваться в компании».

    Что начать делать:
    • больше изучать платформенную разработку,
    • наладить коммуникацию со своими коллегами,
    • преодолеть страх спрашивать совета.


    Что перестать делать:
    • играть в PS по ночам,
    • молчать на общих синк-апах, бояться высказывать свою точку зрения,

    • пытаться решить все проблемы самостоятельно.

    В итоге он ставит Косте оценку «Ниже ожиданий». Судя по комментарию, коллега считает, что основная проблема Кости как разработчика — это нежелание обращаться к товарищам за помощью в решении проблем. Вторая проблема заключается в неумении ориентироваться в компании, что тоже является несоответствием ожиданиям.


    В комплекте идут несколько советов по развитию — активнее изучать платформенную разработку, а не закапываться в Танненбаума, наладить коммуникацию с коллегами и преодолеть страх спрашивать совета. Последние два пункта напрямую коррелируют с его комментарием. И в секции «что перестать делать» респондент затрагивает еще один интересный момент — молчание на общих встречах, нежелание активно высказывать и продвигать свою точку зрения. Обратная связь выглядит конструктивной и полезной — менеджер Кости спокойно сможет начать с ней работать и помогать ему исправить ситуацию.


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


    Оценка:
 «Выше ожиданий»

    Комментарии к оценке:


    «Костя — лучший. Он помог выстроить процессы планирования в юните и предложил кучу отличных идей по достижению наших OKR-ов. Если бы не Костя, наш юнит в этом квартале не справился бы».

    Что начать делать:

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


    Что перестать делать:

    • работать по выходным — такими темпами можно выгореть через полгода,
    • пить энергетики,
    • парить вейп в переговорках.

    Оценка Павла тоже сильно отличается — «выше ожиданий», отличный результат. Комментарий написан абсолютно в другой тональности, Павел очень доволен Костей и приводит кучу примеров его пользы для команды. Заметьте — здесь ни слова не говорится о тех недостатках, с которыми имел дело предыдущий респондент. Это просто другая сторона человека.


    Советы по развитию у Павла тоже другие, касаются роста в сторону продуктового анализа и кроссфункционального взаимодействия. И секция «что перестать делать» довольно стандартная — из всех ревью, что я видел, в каждом втором человека просят взять отпуск, перестать работать по ночам или выходным. Мораль такова — нужно стараться подключать к оценке очень разных людей — это поможет вам собрать критику о разных сторонах вашей деятельности.


    Подведение итогов


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



    Как я уже рассказывал, все респонденты разбиты на четыре группы: менеджер, стейкхолдеры, пиры и подчиненные. Для каждой группы подсчитывается средняя оценка, затем — средняя по всем группам с учетом равновесного распределения. И получившееся число преобразуется в одну из уже знакомых категорий — ниже ожиданий, соответствует ожиданиям… Получившаяся оценка и доносится до сотрудника.


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


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


    Практики performance review


    Анонимность


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


    Вообще анонимность в performance review — это довольно сложная тема. Навскидку, доступны несколько разных способов реализации.


    Первый, самый простой: все видят всё. Каждому сотруднику доступен полный фидбэк от всех его пиров. Он знает, кто и что ему написал, какую оценку поставил. Из плюсов — исчезает эффект сломанного телефона. Оцениваемый всегда может понять, к чему относился отзыв, исходя из личности того, кто его оставил. А если не понял, то всегда может подойти и узнать детали лично. Из минусов — при недостаточном уровне зрелости коллектива это может спровоцировать серьезные конфликты и обиды. Кроме того, люди могут начать умалчивать о проблемах, предпочитая обойтись «троечкой» (соответствует ожиданиям) и пустым комментарием.


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


    Ну и совсем хардкорный вариант. Менеджер самостоятельно обрабатывает все-все отзывы и сводит это в набор рекомендаций формата «что было хорошо», «что надо улучшить». Плюсов особых нет — на самом деле при любом из этих подходов менеджер должен проделать такое упражнение хотя бы даже просто для себя. А минус основной в том, что теряется контекст. Менеджер может пропустить что-то важное, личное, что может понять только оцениваемый, либо неверно интерпретировать какие-то факты.



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


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


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


    Работа с данными



    Адекватные данные мы начали собирать с момента первой крупной раскатки ревью — это второй квартал 2017 года. За это время мы собрали больше десяти тысяч оценок от 1000 респондентов.



    Жесткого ограничения на количество респондентов в ревью мы изначально не ставили, обозначив примерный порог в 10 человек. В итоге всё само пришло к этому числу. Причины понятны — это, по-сути, two-pizza-size team, плюс несколько респондентов снаружи команды. «Хвосты» здесь — это либо менеджеры, на которых висит много проектов и коммуникаций, либо инженеры из совсем небольших команд.



    А вот это — гистограмма количества оценок, которые люди ставят в один период ревью. Видно, что для большинства оно колеблется от 1 до 11 оценок. С учетом средней продолжительности ревью порядка 25 минут, получается, что на проставление оценок своим коллегам нужно убить не больше 6 часов за квартал, причем с учетом фокус-фактора в 0,5. Это достаточно немного, поэтому людям дается вполне легко.



    Теперь давайте изучать, как менялось распределение оценок во времени. Это — гистограмма за первый квартал проведения ревью. Налицо сильный перекос в сторону добра, количество четверок («выше ожиданий») приближается к тройкам («соответствует ожиданиям»). Было две гипотезы — либо у нас много недооцененных суперпрофессионалов, либо мы не умеем критически мыслить и правильно подходить к оценке.



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



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



    Был ещё ряд интересных экспериментов. К примеру, про изучение наличия межгрупповых конфликтов или неприязни. Я сравнил средние оценки, которые все респонденты ставят членам своей команды с оценками, которые они ставят членам других команд. В итоге: серьёзных расхождений практически нет, в среднем оценки обеим группам примерно равны, на концах интервалов есть расхождения максимум в 0,5 балла. Гипотеза того, что люди склонны завышать оценки своей команде и занижать другим, не подтвердилась.



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


    Эти результаты сильно коррелируют с распределением оценок в первом квартале. Видно, что у менеджеров изначально было гораздо более четкое понимание того, как нужно подходить к оценке. Из-за того, что до остальных сотрудников мы слабо довели всю методологию, и получился перекос в сторону оценок «выше ожиданий».


    Оценочные профили


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


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


    Справедливость — та же история, но наоборот. Ищем людей, поставивших меньше 2,7, не ставивших оценки выше средней и сделавших более четырех ревью. Сразу скажу, что таких существенно меньше, по крайней мере в нашем случае. Ну и, кстати, попадание в эту группу может быть маркером того, что человеку неуютно работать в его текущей команде.


    Последний профиль — трудолюбие — это самый тяжелый случай. Сюда мы относим людей, которые провели сравнительно много ревью, средняя оценка — три, и дисперсия нулевая. Ну и как дополнительный фильтр — смотрим на размер оставленных комментариев и фокусируемся на тех, кто пишет сильно меньше среднего объема. Этот набор характеристик явно указывает на людей, которые не заморачиваются обдумыванием чужого ревью, а проставляют средние оценки, вставляют простую отписку и движутся дальше.


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



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


    Нормализация оценок


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



    Нормализованная оценка, по сути своей, показывает отклонение текущей оценки от средней оценки, которую обычно ставит респондент. Важно отметить, что за аксиому принят тот факт, что если все сотрудники находятся на своих местах, то оценка большинства будет стремиться к 3 («соответствует ожиданиям»).


    Разберем, как такая формула работает на добряках. Есть парень, который любит всех вокруг, и его средний балл за ревью в этом периоде — 4,3. Из-за этого мы считаем, что его оценки девальвированы. Если он поставит очередную четверку, то после нормализации она превратится в 2.7.


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



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


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



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


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

    Корректировка оценок


    Вообще в теории все звучит красиво. Респонденты молодцы, пишут объективные ревью, всегда ориентируются на ожидания от роли и никогда не сачкуют. Тем не менее, я уже рассказал про кучу встречаемых нами девиаций, и ими весь список не ограничивается. Когда оценка в ревью выставлена явно неадекватно, либо хотя бы вызывает вопросы, в процесс включается менеджер и начинает процедуру детализации фидбэка. В ряде случаев все проходит быстро. Респондент одумывается, пишет конструктивный отзыв, исправляет оценку. Но иногда случаются проблемы — человек уходит в отпуск, отказывается идти на контакт, жёстко стоит на своем. Так мы и пришли к необходимости введения возможности ручной корректировки оценки менеджером.


    У менеджера есть возможность поменять выставленный респондентом балл на любой другой, в том числе и на состояние «затрудняюсь оценить». При введении такой фишки доверие сотрудников к системе может начать подрываться. Да и в любом случае, не исключена ситуация, когда менеджер не по злому умыслу, а от банальной лени начнет самостоятельно корректировать множество оценок без попытки выяснить причины их проставления. Чтобы этого избежать, мы отслеживаем факт корректировки. В базе хранятся все версии оценок, выставленные в рамках одного ревью. Ретроспективно мы смотрим, какие менеджеры злоупотребляют инструментом, и при необходимости вмешиваемся. Чтобы вы понимали масштаб проблемы — в предыдущем раунде ревью, где мы проработали 3.977 оценок, скорректированы менеджером были всего 62, 80% из которых не более, чем на один балл.


    Антипаттерны


    Помимо выделения общих профилей на основе аналитики, есть ряд стандартных антипаттернов, которые выявляются качественной оценкой — просмотром фидбэка от человека.



    Впечатлительный.
    Оценивает, основываясь на одном ярком впечатлении.
    Оценка:
 «Сильно превысила ожидания».
    Комментарии к оценке: 
«Помог мне почистить айфон от вирусов. Он — один из лучших в компании».


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


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



    Злопамятный.
    Оценивает все время работы с сотрудником, а не последний квартал.
    Оценка: 
«Ниже ожиданий».
    Комментарии к оценке: 
«В 2014 году, когда мы сидели в одной комнате, он много курил. А еще весь прошлый год уделял больше внимания коду, а не потребностям бизнеса».


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


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



    Конформист.
    Не может оценить, но оценивает.
    Оценка:
 «Соответствует ожиданиям».
    Комментарии к оценке: 
«—».


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


    Мы лечим это возможностью отказаться от участия в ревью на уровне инструмента. Кроме того, такие ребята имеют повышенный шанс засветиться в аналитике в группе «Трудолюбие».



    Жалостливый.
    Не дает конструктивной обратной связи, жалеет сотрудника.
    Оценка:
 «Соответствует ожиданиям».
    Комментарии к оценке:
«Справляется со своими обязанностями, не хуже и не лучше других».


    Этот вариант, к сожалению, очень распространен. Респондент не хочет обижать оцениваемого, уменьшая его оценку или присылая негативный отзыв о его работе, поэтому ставит «соответствует ожиданиям» и отмазывается общими словами.


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



    Субъективный.
    Оценивает по субъективным ожиданиям.
    Оценка: 
«Соответствует ожиданиям».
    Комментарии к оценке: 
«Он перформил как бешеный, но это соответствовало моим изначально сильно завышенным ожиданиям».


    Респондент оценивает сотрудника, исходя из своих собственных ожиданий и представлений о том, что он должен делать, поэтому его оценка теряет всякую объективность. Стандартный пример, с которым я сталкивался — в команде есть один бесконечно крутой инженер, который овер-перформит, но из-за того, что все к этому привыкли, это воспринимается как должное.


    Следите за появлением в тексте маркеров вроде «по моим ожиданиям» — это чёткое указание на то, что вы столкнулись с этим антипаттерном. Лучший метод лечения здесь — построить простую и понятную систему ожиданий от позиций и ролей.


    Инструменты


    Google Forms



    Как настоящие продуктовоориентированные ребята, мы начинали с MVP. Состоит он из трех частей. Первая и основная — это гуглоформа, в которую менеджер вбивает все данные своего сотрудника, включая self review, и вручную рассылает ее по списку респондентов. Потом он следит за степенью заполнения формы, руками вычисляет тех, кто забыл провести ревью, и пинает их в мессенджерах. Дёшево и сердито, но вполне работоспособно.



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



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


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


    Ссылки на шаблоны: Форма | Результаты команды | Сводный список.


    Автоматизация


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



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


    Известные недостатки


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


    У нас описаны ожидания практически для всех ролей и позиций. К сожалению, в основном это огромные полотна текста, которые тяжело читать и анализировать. Это сильно отталкивает часть людей, и их можно понять — удерживать в голове ожидания от позиций всех в кросс-функциональной команде нереально. Мы думаем об упрощении ожиданий и представлении их в ограниченном наборе тезисов.


    Сейчас в ревью мы просим респондентов заполнять три поля — собственно, комментарий, а также поля «что начать делать» и «что перестать делать». Судя по аналитике, большинство людей ограничиваются заполнением первого поля, а в два других вставляют плейсхолдеры. Мы планируем провести несколько A/B тестов и посмотреть, что изменится, если упростить эту форму.


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


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


    Заключение


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


    • Мы научились оценивать результаты и эффективность работы сотрудников с учетом мнений всех, с кем он взаимодействует.
    • В компании появился прозрачный как для менеджмента, так и для самих сотрудников инструмент роста.
    • Сбор обратной связи и донесение её до сотрудника стал обязательным и регулярным, что сильно помогло в развитии многих.
    • Мы начали развивать культуру открытой обратной связи, что иногда выходит и за пределы performance review. Люди начинают открыто обсуждать свои конфликты, своевременно хвалить друг друга.
    • Self review оказался крутым инструментом для саморефлексии, которой ранее многие пренебрегали.


    Главная мысль, которую я хочу донести в этой статье — вам не нужно строить космолёт с самого начала. Если вашей команде нужен performance review, начните с самого простого варианта. Затем соберите обратную связь, проанализируйте полученные данные, проведите несколько экспериментов по улучшению процесса. И так, двигаясь итеративно, вы сможете раз за разом получать более качественный процесс, адаптированный именно под вашу команду и культуру. Ну а если вам помогут те практики и инсайды, которыми я сегодня делился — будет очень круто!


    Ссылки


    Avito 224,56
    У нас живут ваши объявления
    Поделиться публикацией
    Комментарии 28
      +5
      «Слишком мало времени уделял наставничеству, из-за чего ввод Иванова в компанию проходит гораздо хуже, чем запланировано».
      А в таск трекере менеджер на это завел таску? Программист сам своим временем распоряжается? Программист должен в конце дня завести таску «общался с Ивановым 1 час»?

      ввод в компанию нового сотрудника прошел плохо.
      Это же забота менеджера?
        0
        А в таск трекере менеджер на это завел таску? Программист сам своим временем распоряжается? Программист должен в конце дня завести таску «общался с Ивановым 1 час»?

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

        Это же забота менеджера?

        Зачастую ментором может выступать ведущий разработчик в команде.
          0
          В большинстве случаев работы по наставничеству просто учитываются в фокус-факторе сотрудника.
          Я ответ не понял. Пофантазирую. За «фокус-фактор» приму что время на это не выделялось, а вот если наставник не успеет сделать таску, то ему это больно зачтется, потому он и не наставничал.

          Я не силен в том как делать правильно, но возможно, чтобы была хорошая коммуникация, нужно либо выделять на нее время, что делается уже после беседы, так как никто заранее не знает сколько коммуникация займет времени, а значит и сдвинется дата релиза. Либо перестать учитывать время сотрудников, а просто записывать какие таски сегодня/за неделю делал сотрудник, без разбивки по времени, что тоже не позволяет узнать когда релиз.
          Конечно программисты расслабятся, зато будут больше общаться, да и отдохнувшие разработчики быстрее мыслят.
          Может мне не везло, но за долгие годы работы в разных компаниях, я не видел никаких результатов подобных занятий, но я не менеджер, может менеджеры и видели, но я в этом сомневаюсь.

          Зачастую ментором может выступать ведущий разработчик в команде.
          Если ведущий разработчик не получил указаний и выделенного времени от вышестоящего, скорее всего это не его вина. Да и вообще ничья не вина, а просто были более серьезные дела. Почему этот «косяк» разработчика это не косяк менеджера?
        +2
        На 5 дней задержал релиз
        А как он задержал релиз? Скорее всего просто неправильно расчитали затраты времени, а значит это не он релиз задержал, а релиз назначили на 5 дней раньше.
          0
          Это просто пример :)
          Но вообще, у нас для релизов мобильных приложений (а пример как раз о них) заведен релизный поезд, который ездит строго по расписанию. Из-за ряда особенностей, в том числе потому, что мобильное приложение — монолит by design, возможна ситуация, когда один разработчик может притормозить всю выкатку.
            +3
            А если бы задачу, которая задержала релиз, дали бы другому разработчику, другой разработчик не задержал бы? При условии что оба они не сталкивались с подобным.
            Я думаю такие эксперименты никто не ставил, а потому непонятно что именно оценивается.
            Я особо глубоко не вдавался, но несколько лет попробовал разобраться как оценивать, но так и не понял что собственно мерять, кроме воображения.
            В общем оценка строится на предположении что средние оценки непонятно каких характеристик человека, как то в среднем оценивают полезность сотрудника для фирмы, что на мой взгляд сомнительно.
            Но заставляют сотрудников занижать самооценку и пытаться выполнять бурную деятельность либо ее имитацию.
              +1
              Мы сейчас говорим немного не по существу. Я привел абстрактный пример того, как может выглядеть селф-ревью от разработчика и фидбэк от его коллег. Обсуждать конкретику из такого примера, мне кажется, не имеет смысла.

              Если говорить по существу, то суть оценки как раз таки в перекрестном ревью от очень разных типов коллег – твоего менеджера, заказчиков, пиров и подчиненных. Каждый из них оценивает твою деятельность через призму своего опыта. Нет речи о формализации вроде «Вася ошибается в оценке в среднем на 3 часа, а Петя на 1 час, значит Петя молодец».

              Подробно про такие штуки, кстати, недавно поговорили в подкасте Podlodka. Там как раз обсуждали разные подходы к оценке эффективности, в том числе и операционные метрики.
          +6
          1412 респондентов 1015 оцениваемых

          400 человек ставят оценки, но их никто не оценивает. Некоторые более равны, чем остальные.

          Нормализацию оценок сделали, но про то что оценка стейкхолдера делится на 1 — «Сейчас мы смотрим на это ретроспективно», таак мило.

          Корректировка оценок менеджерами — вообще отлично — «иногда случаются проблемы… человек жёстко стоит на своем». Это явно огромная проблема, приходится корректировать вручную чтобы всё четко сошлось и менеджеру бонус дали.

          62 оценки скорректированы

          80% = 49.6 оценки. Сколько из них были скорректированы в худшую сторону? Как сильно отражается эта коррекция на зарплате?
            0
            400 человек ставят оценки, но их никто не оценивает. Некоторые более равны, чем остальные.

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

            Нормализацию оценок сделали, но про то что оценка стейкхолдера делится на 1 — «Сейчас мы смотрим на это ретроспективно», таак мило.

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

            Корректировка оценок менеджерами — вообще отлично — «иногда случаются проблемы… человек жёстко стоит на своем». Это явно огромная проблема, приходится корректировать вручную чтобы всё четко сошлось и менеджеру бонус дали.

            Да, это действительно проблема – человек может уйти в отпуск, например.

            80% = 49.6 оценки. Сколько из них были скорректированы в худшую сторону? Как сильно отражается эта коррекция на зарплате?

            Тут такое распределение:
            — Уменьшено на 2 балла: 5 оценок
            — Уменьшено на 1 балл: 39 оценок
            — Увеличено на 1 балл: 10 оценок
            — Изменено на «затрудняюсь оценить»: 8 оценок

            На зарплате это никак не отражается, может влиять на бонус – но с учетом примерно равного распределения по группам и общего количества респондентов около 10, изменение одной оценки не оказывает заметного влияния.
              +1

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

                –1
                Это – лишь крайний шаг, которым пользуются в 1% случаев. Мотивация к введению этой фичи, как и способ бороться со злоупотреблением я описал в статье.
                  0

                  Крайний шаг для чего? Если оценка известна, то зачем всё остальное?

                    +1
                    Один из показательных примеров:
                    «Полностью соответствует ожиданиям, молодец», и оценка «Сильно превышает ожидания» (5). Здесь несоответствие принятой системе оценки, где за соответствие ожиданиям принята оценка 3. Затем респондент уходит в отпуск и не может ничего исправить.
                +1
                изменение одной оценки не оказывает заметного влияния

                Если изменение оценки не оказывает влияния, то зачем её изменять без ведома рецензента?

              +1
              «Вместо того, чтобы обратиться за помощью, неделями закапывается в проблему сам. Кроме того, пока не начал ориентироваться в компании».
              А кто не проконтролировал чем занимается ваш сотрудник?
              ориентироваться в компании — это же какая то абстрактная фраза. Что вы имеете в виду под ней?

              Что начать делать:
              больше изучать платформенную разработку,
              На это же фирма должна выделять рабочие часы.
              Сотрудник может сообщить менеджеру «Я в общем щас тут поучу вашу платформу, так как есть несколько непонятных моментов, сколько вы мне выделите оплаченных часов на это?»
              Это же не опенсорс платформа, а скорее всего закрытая, значит за свой счет смысла учить нет, так как кроме этой фирмы нигде больше эти знания не понадобятся.

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

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

              Возможно я в чем то не прав и наивен.
              Вы еще докажите сотруднику что OKR-ы не на что не повлияют, что заведомо не так.
              Мое мнение что кроме текучки сотрудников это ни к чему не приведет.
              Зачем вообще вы это затеяли, «hr-ы» с жиру/безделья бесятся?
              Просто дайте больше отдыха сотрудникам, не морочите их, будут себе работать.
              Большие затраты на ЗП? Конечно понизим ЗП и заставим работать усерднее!
              Хотя если на 45 минут 15 минут отдыхать, то вроде бы нормальный режим, но для фирмы это может выглядеть как «Ох да ну нифига себе, мы же можем заставить работать их на 30% больше!!!1111одинодин», только это будет не больше, а дольше, да меньше.

              «просят взять отпуск, перестать работать по ночам или выходным»
              Почему бы менеджеру «силой» не выгонять сотрудников в отпуск?
              Например каждые три месяца на одну неделю, а летом на две недели, итого 5 недель в год (одну неделю можно и за свой счет).
              Кстати, приходишь домой, а вместо отдыха читаешь книги, что бы «догнать прогресс/других программистов», что в общем то тоже что и работать по выходным/ночам/вечерам, что тоже неплохо бы перестать делать так как для фирмы может быть выгодней когда сотрудник отдыхает по вечерам, а не учиться. Так сотрудник никуда не сбежит на «новые» технологии и возможно другую ЗП.
                0
                Вот мы тут, как и в верхней ветке, ударяемся в частности, обсуждая абстрактный пример :) Здесь можно закопаться очень сильно, рассказывая о том, как построены процессы разработки в Avito, почему у нас разработчик действительно должен думать о проблемах пользователя, откуда ему брать время на обучение и всякое такое.

                Статья немного не об этом – она о самом процессе performance review. А если есть желание узнать больше деталей про то, как вообще работает Avito, приходите к нам на любой митап, с радостью расскажем! :)
                  +1
                  Мне непонятно, почему некоторые моменты что вы описали должны принести выгоду.

                  Мы научились оценивать результаты и эффективность работы сотрудников с учетом мнений всех, с кем он взаимодействует.
                  Денежный профит фирма получила? А какую либо другую выгоду фирма получила? А как вы проверили что модель работает, а не что вы сами себя в чем то убедили? Риторические вопросы.
                  В компании появился прозрачный как для менеджмента, так и для самих сотрудников инструмент роста.
                  Вот прочитал я статью, мне не показалось прозрачным. Я работал в фирмах, где пробовали что то подобное. Самое прозрачное что я заметил, кто лучше дружит с менеджером/hr/начальством и имеет острое желание двигаться по «карьере» — самый действенный инструмент роста, в независимости от скилов, не осуждаю, просто заметил.

                  То что сотрудники научились обсуждать свои конфликты и корректно но доходчиво описывать проблемы коллег, надеюсь более менее объективно, мне это видится большим плюсом.
                    +1
                    корректно но доходчиво описывать проблемы коллег
                    Хочу добавить что если сотрудники переутомлены и/или под цейтнотом то будут заведомо негативно реагировать на малейшую критику. Возможно переутомленных неулыбчивых сотрудников пора отправить в отпуск на недельку другую.
                –1
                Первый раз слышу про performance review. Двоякое чувство… с одной стороны вроде бы можно что-то (непонятно что) улучшать, а с другой — играл в Watch_Dogs 2, там тему деперсонализации довольно хорошо резжевали, в смысле чем это чревато. Вы же понимаете, что эти данные нужны прежде всего корпорациям и будут использованы против конкретного человека. Камеры в туалете уже поставили?
                  –1
                  Видимо никто не играл, раскрою тему. Суть в том, что про людей собирается инфа, разная, статистика и людей категоризируют, по типу «активный», «спортсмен», «любит ситкомы» и т.д. А потом этой инфой пользуются, например, банки и отказывают в кредите, т.к. есть некая «тенденция» для определенной категории людей и выдавать кредит/страховку/брать на работу и т.д. рисковано.

                  Миллиарды людей, терабайты инфы, видео, история и тд. — угадайте для кого. Для вас? Увы нет, против вас.

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

                  А теперь это ревью. Оценки, ошибки, балы. Пока что в одной компании, потом данные передаются другой и понеслась. Пожизненно «клейменный» индивидум.

                  Посыл благой — позволить человеку «расти», метод — публичная оценка, увы, не очень, про самооценку — вообще молчу. Чтобы обьективно оценить — необходимо уделять этому внимание, отсюда коммент про камеры в туалете. А вдруг руки не моет? Нужно срочно отучить от этой плохой привычки!
                  Мы научились оценивать результаты и эффективность работы сотрудников с учетом мнений всех, с кем он взаимодействует.
                  Вы научили сотрудников выбирать такие задачи, которые затрагивают как можно большую аудиторию и только в позитивном смысле. Смысл брать что-то и тратить время, если за это проголосует 2 человека или, не дай бог, заденет кого-то, если можно создать видимость активной работы и заагитировать харизмой (если есть) 100 человек? Третий сезон «Черного зеркала», первая серия, посмотрите что ли.
                  В компании появился прозрачный как для менеджмента, так и для самих сотрудников инструмент роста.
                  Вы добавили RPG забаву и возможность наказывать «неугодных». Ничего прозрачного нет. Про работу HR как и раньше знают только вышестоящие. Вместо работы сотрудники будут играть в стратегию «ты мне — я тебе». Растут балы = мотивирован? Да нифига, просто понял как «гребсти репу лопатой» (повышать рейтинг).
                  Сбор обратной связи и донесение её до сотрудника стал обязательным и регулярным, что сильно помогло в развитии многих.
                  Ну да, понизили рейтинг, снизили зарплату, если не дай бог в ошибке признался или не успел взять «правильную» задачу для следующего ревью. Подлиз развили это точно и довольного HR-а.
                  Мы начали развивать культуру открытой обратной связи, что иногда выходит и за пределы performance review. Люди начинают открыто обсуждать свои конфликты, своевременно хвалить друг друга.
                  Ну еще бы, а попробуй теперь не похвалить. Припомнит ведь. А насчет «открытого» обсуждения, дык естественно — выгодно придумать конфликт, это самый «безопасный» способ перечислить что-то плохое про себя… Ах, ну да, он на самом деле очень полезный сотрудник, просто не сошелся с кем-то характером, будем решать проблему..
                  Self review оказался крутым инструментом для саморефлексии, которой ранее многие пренебрегали
                  Продолжайте заблуждаться и лицемерить.

                  Я бы из такого цирка уволился.
                    +1
                    > А теперь это ревью. Оценки, ошибки, балы. Пока что в одной компании, потом данные передаются другой и понеслась. Пожизненно «клейменный» индивидум.
                    Интересная интерпретация, но пока меня в мировой заговор еще вроде бы не втянули. Но я буду следить за появлением рептилоидов, спасибо :)

                    А по существу всех комментариев попробую ответить. В статье я уже писал, как и говорил в подкасте, на который дал ссылку в другом комментарии, что перфоманс ревью у нас работает в связке с OKR, методологией целеполагания и каскадирования целей с уровня компании до уровня конкретных команд. Именно эта связка позволяет убедиться, что команды ставят важные цели, поддерживающие цели всей компании, и достигают их. Это помогает избежать ситуации, когда все работают не на результат, а на то, чтобы понравиться своим соседям.
                      –2
                      пока меня в мировой заговор еще вроде бы не втянули
                      Это не заговор, это тенденция… фирмы доверчиво переходят на облака, используют корпоративный софт… Алекса «подслушивает» разговоры, Майкрософт еще с выхода Window 10 телеметрию себе шлет. В моем посте уровень паранои может и зашкаливает, но не факт, что к этому не идет.

                      Я работаю на фирме с такими же «баллами» (влияющими на годовую зарплату), но оценкой, по крайней мере, занимается руководитель отдела (не знаю кто оценивает его если чесно).

                      Аналогия (не знаю, удачная ли), представьте себе школу, где оценки ставит не учитель, а другие школьники друг-другу, это вообще умно? Не знаю что за зоопарк у вас там (OKR? методология целепопадания? каскадеры?), но слабо верится, что оно работает. Скорее всего просто создается видимость. Умные люди систему сломают, вы же не дураков нанимаете?
                  +1
                  Егор, здравствуйте, спасибо большое за статью, как раз наткнулись на то, что
                  1) инструмент «дешево и сердито» вполне работает, но отжирает кучу времени));
                  2) надо развивать PR дальше, увеличивать полезность.

                  Для нас сейчас самое главное — синхронизироваться, чтобы мы были уверены в совпадении представлений о работе и ее результатах, но я знаю, что цели PR могут и должны быть больше. Мы работаем сейчас над формулированием ожиданий от ролей и целеполагаением. Какой является главная цель у вас? Расскажите, привязана ли какая-либо система мотивации к PR?
                    +1
                    Основные цели – оценить вклад каждого человека в общий результат и дать ему конструктивный фидбэк про то, что было хорошо, а что можно улучшить. Система мотивации есть, но детали раскрывать, к сожалению, не могу.
                      –2
                      Оцениваемые соглашаются с ихней оценкой или у них нет выбора?
                      Вы их убеждаете что их оценка объективна или просто провозглашаете?
                      Обсуждаете с ними, что бы сотрудник объяснил что задержка релиза на 5 дней это объективная причина, а не проблема сотрудника, а значит и исправить нечего, а значит и оценка ложная?
                    –1
                    Вот из-за этого корпоративно-процессуального бреда стараюсь избегать работы в больших ко мпаниях
                      0
                      очень интересно. спасибо
                        0
                        изучать вопрос оценки нужно, но все способы которые предлогаются это что-то типа поиска логики в результатах лотереи, вроде и всё математически считается и крутые алгоритмы, а на выходе всё равно какая-то хрень которая может совпадать с реальным положением дел, а может нет, всё зависит только от времени и места, стоит что-то поменять и всё валиться, к счастью пока нигде не видел чтоб этот перформанс ревью на чтото бы влиял

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое