Привет, Хабр! Меня зовут Алексей Рыбак, я – глава разработки в Badoo. В феврале в нашем московском офисе Badoo проходил Techleads-митап, где я рассказывал про наш процесс Performance Review. Эта статья написана по мотивам моего выступления.

Performance review – тема крайне спорная. В России до сих пор распространено мнение, что никакие KPI, “измерения”, performance review – в программистских компаниях не только не работают, но и вовсе вредны. Эта категоричность меня всегда удивляла, но окончательное решение осветить эту тему подробно созрело у меня после прочтения статьи аж на самом РБК.

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

Бесспорную ценность этих отрицательных примеров для объективности стоить дополнить примерами других компаний: Google, Facebook и многих других, – в которых Performance Review как раз успешно работает. Это лишь иллюстрирует, что можно внедрить процесс ревью как успешно, так и неуспешно. Поэтому основной целью этой статьи является рассказать об одном из подходов, который приводит к работающему ревью. В Badoo этот подход работает уже почти семь лет, и, пользуясь случаем, я хочу выразить большую благодарность Жене Соколову (ex-Google, ex-Badoo), который нас этим подходом “заразил”.

В этом посте я:

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

Ревью и ценности компании

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

Ценности Badoo

Однако прежде чем приступить к ревью, необходимо рассказать пару слов о Badoo и о наших ценностях. У каждой компании есть какие-то свойства – внешние или внутренние – которые нельзя или очень сложно изменить. Примерами таких “граничных условий” могут быть направление деятельности, как именно компания зарабатывает деньги, какие ценности превалируют в ее корпоративной культуре. В разных компаниях “быть эффективным” означает разное, поэтому обсуждение ревью в отрыве от ценностей практического смысла не имеет.

Badoo занимается разработкой dating-приложений и социальных сетей для знакомства с новыми людьми. Наши основные продукты находятся в нише “dating”, но мы также развиваем проекты в области social discovery – поиск поблизости людей по интересам. В некотором смысле Badoo представляет платформу, на базе которой делается много разных приложений. Внутри проекты могут быть очень сложные, но снаружи всё выглядит достаточно просто. Очень большое количество команд в мире одновременно делают примерно такие же проекты. Таким образом, на рынке, на котором мы работаем, нужно быть очень быстрым: очень быстро пилить фичи, тестировать их, если они не пошли – закрывать, если пошли – что-то подкручивать и снова повторять цикл экспериментов. Это определяет всю культуру нашей компании. И всю боль инженеров: им достаточно сложно найти баланс между этой скоростью и комфортной неспешной разработкой, когда везде, что называется, соломка постелена.

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

Таким образом баланс между скоростью и инженерными ценностями определяет культуру компании. И мы стараемся всем сотрудникам регулярно объяснять свои ценности; человеку со стороны они могут показаться варварскими. Нельзя сказать, что они идеально подходят всем инженерам: это сильно зависит от характера.

На данном этапе наша система ценностей состоит из трёх составляющих.

Ценность 1: Delivery

Самое главное для нас – это delivery, доставка рабочего продукта до пользователей. В какой-то степени нам даже неважно, насколько он идеален в использовании во всех аудиториях. Мы стараемся максимально использовать всякие фичи-флаги для запуска в какой-то части кластера или в какой-то аудитории, что-то измерять в процессе. Если мы не понимаем, как фича должна работать на какой-то части аудитории, нам будет проще пустить её только на “понятной” нам части: вдруг она вообще окажется бесполезной.

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

Ценность 2: Quality

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

Ценность 3: Retention

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

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

Кому и для чего нужно ревью?

Дайте теперь вернемся к Performance Review. Какие бы хорошие люди в компании ни работали, чем больше она становится, тем сильнее усложняется взаимодействие. Если представить любую компанию в виде модели, мы получим такую ветвистую структуру, когда из одной части в другую идёт много условных стрелочек. Чем больше компания, тем больше этих стрелочек и тем больше потерь на этих стрелочках – на взаимодействии, коммуникации.

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

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

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

Но вернёмся к “ревью”. Это некий процесс, часть фреймворка, который показывает вам, где у вас что тупит. Ключевой вопрос здесь – наличие людей, которые оценивают других людей и не просто дают фидбэк, а получают детальную информацию об их проектах.

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

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

Итак, ревью:

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

Ревью плохое и хорошее

Несколько слов о плохом ревью. Самое ужасное – когда оно слишком бюрократичное и сложное. «Оно бюрократично всегда», – скажете вы и будете правы. Но здесь, как и во всём, должна быть мера.

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

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

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

Таким образом, хорошее ревью

• просто;
• применимо к любой ситуации;
• быстро/актуально и регулярно;
• понятно;
• приятно ($).

Из чего состоит ревью

Я смотрю на ревью как на процесс вокруг какого-то фреймворка. Из чего он состоит? 3 части:

• peers – коллеги;
• сам процесс review;
• ladders – карьерные уровни; а также brackets – привязанные к ним зарплатные “вилки”.

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

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

Есть совсем простые формулы, есть улётные варианты с хитрыми KPI. Я придерживаюсь принципа простоты, поэтому считаю что лучше всего выстроить шкалу либо вокруг степеней “хорошо”, либо вокруг степеней “соответствия ожиданиям”. Например, сотрудник полностью соответствует ожиданиям, или с какими-то предложениями по улучшению, или не соответствует им, или наоборот превышает ожидания, или превышает ожидания настолько, что заслуживает продвижения (promotion) и так далее. Promotion – это долгосрочная часть фреймворка, которая позволяет двигать человека по карьерной лестнице.

Карьерная лестница в больших компаниях зачастую достаточно длинная, с кучей цифр: вице-президент №1, вице-президент №2 и так далее. Мы в Badoo практикуем более простую систему и, как многие софтверные компании, даём возможность инженерам двигаться как по карьерной лестнице менеджера, так и по карьерной лестнице инженера. И одна из самых важных составляющих документа, который это регламентирует, – работа с ожиданиями сотрудника. Если он хочет расти как эксперт, вот ему описание уровней по этой лестнице. Таким образом, у человека есть понимание, на какой ступени карьерной лестницы он находится. Это довольно скучная история, но в компаниях с большим количеством сотрудников без этого не обойтись.

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

Сам процесс ревью

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

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

У нас есть OKRs (objectives and keys results) для сотрудников, которые работают над долгосрочными задачами. Иногда мы занимаемся сравнением того, что мы планировали и что сделали, но в целом эти показатели отвязаны от ревью. Повторюсь, это очень важно, потому что может приводить к серьезному раздражению. Поскольку Badoo – очень динамичная компания, мы не можем использовать такой подход. Поэтому ревью делается по факту: сделано это и то.

Пиры (peers)

Чтобы получить оценку, сначала нужно собрать отзыв от коллег. Самая важная часть фреймворка – пиры (peers). Сотрудники выбирают пиров, коллег, с которыми работали на проектах, тестировщиков, с которыми тестировали задачи, членов продуктовой команды, с которыми взаимодействовали, – кого угодно, кроме их менеджера. После этого менеджер смотрит на пиров и говорит что-то вроде: «Слушай, а почему я не вижу ни одного QA-инженера здесь? У тебя была важная задача, был хороший (или не очень хороший) фидбэк. Хотелось бы получить отзыв QA-инженера для полноты картины». Происходит некий процесс согласования, менеджер может добавить или убрать сотрудника.

Причём «убрать» – это довольно распространенная история: если в граничном случае все добавят в пиры всех, получится такая бюрократия, что мотивация сотрудников будет стремиться к нулю. Желательно, чтобы пиров было три–пять; в крайнем случае – семь, но, на мой взгляд, семь – это уже много.

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

Калибрация

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

Личная беседа

И это тоже ещё не всё! Главное – разговор один на один, который обязательно должен провести менеджер с каждым членом своей команды: рассказать, что и почему получилось, что ожидается, что необходимо изменить.

Так в целом работает наш фреймворк.

Кстати, у Badoo два офиса: один – в Москве, другой – в Лондоне, оба занимаются разработкой. В московском офисе с 2011 года, когда мы переехали и сильно выросли, число команд не меняется, а вот лондонский – растёт. И сначала мы запустили ревью в Москве, обкатали этот процесс: договорились, что и как, добились синхронизации между менеджерами, решили для себя, что означает та или иная оценка, и так далее. Только после этого был подключён лондонский офис.

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

Проблемы ревью

Проблема 1: бонусы

Первая проблема, с которой мы столкнулись, – разное отношение к бонусам. Здесь есть два подхода. Один подход (он особенно популярен на Западе) опирается на почти гарантированный годовой бонус: в процентах к годовому он у тебя составляет столько-то, и если всё нормально, он выплачивается в полном объёме. Если есть какие-то вопросы или были установлены какие-то KPI, то, как говорится, возможны варианты… В общем, при таком подходе бонус, как правило, выплачивается либо полностью, либо почти полностью – то есть изменение бонуса однозначно является “наказанием”. Но чем сильнее пытаться играть им, тем хуже, потому что сотрудник ожидает, что эта часть дохода ему гарантирована.

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

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

Кстати, помимо текстовых описаний, у нас есть ещё номера, которые мы используем для более короткой записи. И это является для нас проблемой. Если человек мыслит в категориях школьных оценок, он думает: «Почему у меня не максимальный балл? Он должен быть максимальный! Я всегда был отличником, я – самый крутой. Почему у меня не самая крутая оценка?» Над изменением такого мышления нужно работать всем: менеджерам и эйчарам.

Проблема 2: поиск алгоритма оценки

Следующая проблема – попытка найти простой “алгоритм оценки”. Большинство программистов по природе своей аналитики и пытаются выстроить чёткую схему получения максимальной оценки. Более того, менеджеры перенимают этот подход и начинают придумывать свои истории о том, как и почему они дали ту или иную оценку, тем самым снимая с себя ответственность (это не я! – это машина тебе посчитала).

Ещё пример такого “аналитического” поведения. Каждый раз, когда мы делаем ревью зарплат, какой-нибудь менеджер обязательно говорит: «Этот сотрудник находится не на медиане. Несправедливо – надо его подтянуть на медиану!». Но если следовать такому подходу, то в результате у сотрудников зарплата может вырасти непропорционально успехам. На самом деле в этой медиане изначально уже заложена очень большая ошибка. Поэтому медиана – это очень приблизительный ориентир, к нему не нужно ничего специально “подтягивать”! А в действительности нужно анализировать очень много факторов в комплексе. В первую очередь, – успехи человека и как повышалась зарплата этому человеку в течение нескольких лет, если он работает в компании достаточно давно.

С тем, что программисты пытаются применять аналитические инструменты, чтобы выдать ту или иную оценку, связано множество проблем. Если у вас есть очень сложные KPI, которые прямо выражаются формулой, то существует большая вероятность того, что люди просто начнут подтягивать свои показатели, чтобы получить балл повыше: «Эх, сейчас как взломаю эту бюрократическую систему!..» – и потирают ручки. Именно поэтому фреймворк должен давать как можно меньше возможностей использовать аналитические инструменты.

Скажу банальность: чем больше компания, тем меньше взаимодействия между разными отделами. И тем больше людей считают, что они не обязаны никому ничего рассказывать – они просто двигают «своих», у них образовались некие маленькие государства. Проблема? Безусловно. И единственная возможность с этим бороться – объяснять всем сторонам необходимость коммуникации. Если же кто-то считает, что они вообще никак не пересекаются, стоит рассмотреть возможность проводить их ревью отдельно с кем-то ещё, просто в офисе не калибровать.

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

Проблема 3: инфляция оценок и уровней

Следующий момент – инфляция. Различают инфляцию оценок и инфляцию уровней.

С инфляцией оценок всё достаточно просто – она происходит, как правило, в нормальном диапазоне. Что такое превышение ожиданий и чем оно отличается от оценки «Полностью соответствует ожиданиям»? Моя позиция такова, что, если было какое-то количество проектов и они все реализованы в срок или с небольшой задержкой (до 25% – но единого правила нет), то это – превышение ожидания. Не мне вам рассказывать, что обычно сроки срываются. :) Некоторые менеджеры придерживаются другого подхода. Но в любом случае, как только речь заходит о сроках, это значит, что в процедуру ревью должен попасть какой-то документ, содержащий информацию о том, какие сроки были установлены и когда в итоге всё было выполнено. Это само по себе очень здорово – приучает к ответственности за дедлайны.

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

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

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

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

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

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

Как понять, нужно ли вам ревью

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

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

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

И ещё один важный момент – сложившаяся культура. Вот пример, несколько гиперболизированный, конечно. Бывают руководители, которые хотят работать только с молодыми людьми. А когда люди взрослеют, обзаводятся семьями, они уже не могут, условно, работать в выходные… Распространённая ситуация: молодые руководители хотят, чтобы сотрудники разделяли их ценности, чтобы они с радостью работали сутками и были готовы организовать хакатон в ночь с пятницы на понедельник.

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

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

Заключение

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

Ревью должно быть регулярным, своевременным, простым и полезным – и для компании, и для сотрудников. Все известные мне "громкие" отрицательные примеры служат не доказательством “неприменимости” ревью, а доказательством наличия ошибок в процессе ревью.

Мучают сложные формулы и KPI? Может, стоит отказаться от них в пользу простых оценок? R&D задачи сложны в планировании? Возможно, стоит научиться планировать исследовательские проекты – независимо от сложности общей задачи каждый проект все равно разделяется на более мелкие подпроекты, планирование которых по отдельности прекрасно укладывается в традиционный подход, даже если это проверка гипотез.

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

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

Если вы хотите подробнее узнать, как устроены системы ревью в других компаниях, рекомендую прочитать книжку Ласло Бока “Работа рулит!”, где в нескольких главах подробно рассматривается система оценки производительности в компании Google (наш процесс во многом повторяет процесс в Google).

А с какими проблемами сталкивались вы? Давайте обсудим это в комментариях.