Привет! Меня зовут Илья Гуров, я директор по аналитике в Авито. За последние 3–4 года департамент аналитики значительно вырос, а мы набили шишек, придумывая и дорабатывая процесс оценки и ревью сотрудников. Про текущий процесс я слышал много хороших отзывов от аналитиков, которые пришли к нам из других компаний, поэтому хочу поделиться опытом.
В статье расскажу, как у нас всё работает в 2023-м и дам пару советов про то, как запустить нечто аналогичное. Думаю, материал будет полезнее всего тем, кто прямо сейчас выстраивает или хочет выстроить процесс оценки у себя в команде.
Что такое ревью
Чтобы каждый сотрудник знал свои сильные и слабые стороны, получал вознаграждение за успехи и понимал, как развиваться, нужна регулярная оценка. В небольшой команде она происходит сама собой: все задачи на виду, руководитель и команда видят, кто справляется, а кто не очень. Но в больших департаментах, где много команд, проблема усложняется: там важно обеспечить единые прозрачные ожидания и понятный карьерный путь. Для этого и нужны ожидания и процесс ревью. Теперь на примере нашего опыта расскажу, как эти ожидания определить.
Как описать ожидания с помощью компетенций
Мы подробно описали, чего ждём от аналитиков на каждом грейде. Любой аналитик может зайти в Confluence и прочитать, что надо уметь и делать, чтобы соответствовать своему грейду, а что уже будет считаться достойным следующего.
💡 Совет
Формальное описание ожиданий — это прекрасно, но для небольшой команды, вероятно, избыточно. Описывать ожидания точно стоит, если аналитики не умещаются в одной команде: работают в нескольких группах и с разными руководителями.
Ещё один маркер: команда выросла до стадии, когда людей сильнее мидла уже становится несколько. В этот момент пора научиться отвечать на вопрос «как стать сеньором и что мы от него ждём» более внятно, чем «ну это, видел, что Олег вчера показывал? Вот когда будешь такие исследования делать, тогда и сеньор».
Наши описания построены на компетенциях. Мы выделяем несколько важных навыков и качеств и описываем разные уровни внутри каждого, а потом собираем из них профиль требований к роли: по каждой компетенции решаем, на каком уровне она должна быть проявлена у джуна, на каком у мидла и так далее.
Если хотите описать такие ожидания у себя, рекомендую следующий алгоритм:
1. Свободно описываем суть грейдов. Нужно качественно сформулировать, чем уровни отличаются между собой. На этом этапе не пытаемся сделать идеальные точные определения, просто выгружаем из головы общее представление.
Например: «джуну надо ставить задачи, а мидл может взяться за открытую проблему». Точное определение объекта «проблема» и возможность надёжно отличить его от объекта «задача» сейчас не важны.
2. Придумываем компетенции. Исходя из чувства прекрасного и тех мыслей, которые у нас появились в процессе описания грейдов, определяем список компетенций. Это должны быть достаточно общие качества и навыки, которые могут быть проявлены на разном уровне и которые помогут различить грейды. Для первой итерации их можно взять из интернета, например, использовать наши 🙂
Есть хардовые компетенции — к ним относим всё, что касается непосредственно решения задач, в том числе умение самому найти проблему, решение которой принесёт пользу бизнесу. Есть софтовые компетенции — это всё, что связано с поведением. Например, умение держать заказчиков и прочих заинтересованных лиц в курсе своих планов и прогресса по задачам.
Обобщённый список хардовых и софтовых компетенций, которые мы ждём от аналитиков
3. Раскладываем требования по компетенциям. Теперь наводим формализм: описываем уровень развития каждой компетенции, который требуется от представителя грейда. Фокусируемся на том, что различает грейды: если мидл должен уметь что-то, чего не обязан уметь джун, то оно должно быть проявлением одной или нескольких компетенций.
4. Оцениваем результат. Если у нас есть компетенция, по которой грейды не различаются, то либо она не нужна, либо мы плохо описали различия. Если есть грейды, которые по компетенциям не различаются, то либо один из них не нужен, либо мы потеряли какую-то важную компетенцию. В этих случаях обновляем список компетенций, отправляемся на шаг 1 и повторяем до достижения просветления. Обычно нужно повторить цикл два–три раза.
👉🏻 Статья по этой теме от моего коллеги: «Middle или Senior: какой ваш уровень в аналитике?»
В итоге получается такая конструкция:
- Есть компетенции, которыми должны обладать аналитики.
- У каждой компетенции есть разные уровни развития.
- Из уровней развития компетенций складываются грейды.
Что такое хорошие ожидания
Хорошие требования к грейдам должны отвечать двум критериям:
Доказуемость. Нужно договориться о способе, которым можно показать соответствие и несоответствие требованиям. Часто ожидания формулируют как «знает статистику» или «следит за качеством данных» — такие утверждения довольно трудно доказать или опровергнуть.
Вместо того чтобы рассуждать, следит ли аналитик за качеством данных, лучше посчитать инциденты с данными. А вместо «знания статистики» потребовать решённую задачу, в которой использовались соответствующие методы.
❌ Понимает методику АБ-тестирования → ✅ Самостоятельно провёл АБ
Результат, а не процесс. Участие в процессе можно продемонстрировать, но само по себе ценности оно не имеет. Например, «проводит собеседования»: очевидно, что это доказуемо, но проводить собеседования можно хорошо, плохо, а можно вообще в паре с другим собеседующим сидеть и молчать. Таких требований нужно избегать, лучше сосредоточиться на том, зачем эти собеседования вообще проводятся.
❌ Проводит собеседования → ✅ Нанял аналитика уровня X
Как доказывают компетенции
Чтобы компетенции удовлетворяли свойствам выше, мы требуем доказательство с помощью артефакта или обратной связи от коллег.
Артефакт. Это основной вид доказательств — объект, для создания которого требуется владение компетенцией. Для хардовых навыков это обычно код или оформленное исследование. Например, чтобы подтвердить, что человек может написать витрину, необходимо и достаточно предъявить работающую витрину, которую он написал.
Проявление софтовых компетенций тоже вполне можно доказывать артефактом. Например, чтобы подтвердить навык планировать крупный проект масштаба квартала, можно предъявить выполненную задачу и план. Важный для руководителей навык растить команду можно показать документом с предыдущего ревью, где он защитил подчинённого на промо.
Доказательством может быть и отсутствие артефакта. Например, если ожидается поддержка какого-то критичного регулярного процесса, то доказательством провала будут инциденты, когда процесс ломался. Нет таких — значит, требование выполнено.
Обратная связь. Для некоторых компетенций она тоже может служить прямым доказательством. Например, если заказчик пишет, что ему непонятно, чем занимается команда и когда будет готов ключевой проект, значит, налицо проблемы с компетенцией «управление ожиданиями».
Но я не советую строить ожидания и оценку так, чтобы фидбек был единственно возможным подтверждением компетенции и напрямую влиял на оценку. Коллеги не знают точных ожиданий от аналитиков — и это нормально. Даже если они их прочитают, не факт, что смогут потом понять, например, какой математический метод общепринятый, а какой технически сложный и требовал адаптации.
Также важно, что большинство людей склонны замалчивать проблемы и давать только положительный фидбек. Этот эффект особенно усиливается, если известно, что оценка, бонус и промо человека зависят от обратной связи. Критики в таком случае можно совсем не ждать, а обратную связь без критики и проблем проще вообще не собирать.
Вот пример компетенции «управление ожиданиями», которую мы разложили на пять уровней. В качестве доказательства на любом уровне требуется предъявить артефакт — проект соответствующего масштаба, для которого аналитик составил и выполнил план.
Как устроен процесс ревью в Авито
Процесс ревью в идеале должен быть прозрачным и справедливым. Прозрачность означает, что сотруднику и руководителю понятно, что ожидается в текущей роли и что надо сделать, чтобы получить бонус побольше или повышение. Справедливость означает, что эти требования для людей в одной роли более-менее одинаковы и не зависят от личных предпочтений руководителя или заказчика в конкретной команде.
Описание ролей — необходимое, но не достаточное условие для прозрачности и справедливости. Нужно ещё и правильно пользоваться описанием. У нас в Авито вот такой цикл ревью, который повторяется каждые полгода:
- Self-review
- Сбор отзывов от коллег
- Оценка руководителем
- Калибровка оценок между руководителями
Ниже расскажу подробнее про эти этапы.
Self-review. На первом этапе процесса каждый должен оценить собственные результаты. Для этого сотрудник должен перечислить самые значимые проекты, в которых участвовал за последние полгода, описать свой вклад и результаты. Важен именно личный вклад: нельзя писать «мы сделали» и не объяснять, за что конкретно был ответственен ты.
Сбор отзывов. Для каждого проекта, который упоминается в self-review, нужно указать коллег, которые участвовали в нём или заинтересованы в результатах, чтобы получить от них обратную связь. Эти респонденты оценивают взаимодействие в рамках проекта: хорош ли результат, понятна ли была коммуникация. Руководитель выступает модератором: следит, чтобы в отзывах были факты, а не общие слова или личностные оценки.
Оценка компетенций. Руководитель должен оценить сотрудника по всем компетенциям. Для этого он собирает доказательства для подтверждения каждой компетенции: артефакты и обратную связь — мы говорили о них в пункте выше.
Калибровка. Когда руководитель собрал доказательства для компетенций человека и сформировал мнение, оценку нужно защитить перед другими руководителями. У нас этот процесс называется калибровкой. Цель в том, чтобы менеджеры одинаково интерпретировали описания уровней, одинаково подходили к оценкам и доказательствам, не были добренькими или наоборот чересчур требовательными.
Ниже я подробно расскажу, как у нас устроены такие встречи.
💡 Совет
Для небольшой команды калибровки, скорее всего, избыточны, как и прочий формализм. Но если вы понимаете, что руководители не могут по памяти перечислить всех аналитиков и их ключевые проекты и успехи, это значит, что стоит задуматься о калибровке.
Как проходят наши калибровки
Раньше мы проводили такие встречи душевно и демократично: обсуждали каждого человека до тех пор, пока не достигалось полное согласие. Это круто, но занимает слишком много времени. Мы подсчитали, что на калибровку, в которой поучаствует каждый руководитель и полноценно обсудят каждого аналитика, уйдёт пять дней.
Поэтому мы регламентировали процесс и перешли на душные, но эффективные калибровки. Руководители заранее готовят презентации с оценками в общем формате, на встрече работает фасилитатор, а длинные дискуссии и зарубы проходят за пределами встречи. На всё есть лимиты по времени и понятно, кто и когда примет решение, если оно не принимается.
Душные калибровки гораздо экономичнее — на всё уходит два дня. Затраты ресурсов лучше контролируются, а результат в целом тот же. Вот как проходят такие встречи:
Руководитель презентует оценку аналитика. Он показывает табличку, в которой оценивает сотрудника по компетенциям с доказательствами, и говорит финальное мнение: соответствует человек уровню или, например, превышает его. Также он указывает, на какие ключевые зоны роста сотруднику нужно обратить внимание. На это есть 10 минут.
Оценку обсуждают. Остальные руководители должны убедиться, что доказательства соответствуют заявленному уровню компетенций. На этом этапе можно детальнее обсудить какую-то задачу и разобрать, например, почему утверждается, что она сложная. Могут попросить показать обратную связь от каких-то людей или обсудить конкретный случай. На это тоже даётся 10 минут.
Если осталось больше двух несогласных, дискуссия уходит за пределы встречи. Создаётся тред, в котором обсуждение продолжается. Так у участников появляется время вникнуть в сложные материи, а у руководителя — собрать и предоставить дополнительную информацию.
Если через два дня не получилось принять решение, его принимает директор. Этого практически не бывает, но на случай полного тупика в дискуссии эта часть процесса тоже прописана.
Этот процесс бьёт сразу в две цели. Во-первых, благодаря синхронизации руководителей по конкретным оценкам у всех поддерживается одинаковое понимание требований. Во-вторых, в процессе синхронизации обнаруживаются проблемы в требованиях — и это позволяет их доработать.
Подытожим: как устроено ревью в команде аналитики Авито
Мы описываем ожидания от всех сотрудников. Описания построены на компетенциях: выделяем важные навыки и качества, а затем решаем, на каком уровне они должны быть проявлена у джуна, на каком — у мидла и так далее.
Описания должны быть доказуемыми и описывать результат, а не процесс. Например:
❌ Понимает методику АБ-тестирования → ✅ Самостоятельно провёл АБ
❌ Проводит собеседования → ✅ Нанял аналитика уровня X
У нас выстроен цикл ревью, который повторяется каждые полгода:
1.Self-review.Сотрудники оценивают свои результаты.
2. Сбор отзывов. Коллеги, которые участвовали на проектах, упомянутых в self-review, дают обратную связь.
3. Оценка руководителем по всем компетенциям. Для этого он собирает доказательства: артефакты и обратную связь.
4. Калибровка оценок между руководителями. Это встреча, на которой все оценки обсуждают.
У калибровок есть чёткий регламент. Если есть больше двух несогласных, дискуссия продолжается за пределами встречи, для всего есть ограничения по времени. Руководители должны сойтись в том, как ставить оценки, иначе повышения будут давать по-разному.