Меня зовут Артём Сусеков, я менеджер разработки в Miro. Расскажу, как мы пришли к справедливой оплате и прозрачному обсуждению эффективности сотрудников команд продуктовой разработки. 

Статья будет полезна, если вы задаётесь вопросами: 

• Как оценить вклад каждого сотрудника в результаты компании?

• Как сформировать понятные ожидания?

• Как оценить грейд сотрудника и понять, что ему нужно сделать, чтобы вырасти в компании?

• Как проводить оценку сотрудника, не перегружая этим процессом всех остальных?

• Как сделать процесс оценки прозрачным?

Поделюсь опытом, который мы получили за год экспериментов и поисков ответов при росте команды в 3,5 раза.

Статья основана на моём докладе «Performance review: инструмент для повышения личной и командной эффективности» на конференции DUMP 2021 в Екатеринбурге. 

Сложности в оценке эффективности сотрудников

Адекватная оценка зарплаты. Как адекватно оценить зарплату? Как сделать так, чтобы при росте команды процесс пересмотра зарплат масштабировался, а не упирался в одного менеджера? Мы впервые задумались об оценке и пересмотре зарплат, когда в компании было 80 инженеров и 3 менеджера разработки. Менеджеры хорошо представляли вклад каждого, могли адекватно оценить его и быть объективными. Но при быстром росте менеджеры быстро стали «бутылочным горлышком» в процессе.

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

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

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

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

Первая итерация: чек-лист hard-skills — неудача

В самом начале пути мы пытались сформулировать всеобъемлющий список требований и ожиданий от инженеров. Мы хотели составить чек-лист hard-skills — навыков, которые позволят оценить уровень инженеров: senior, middle, junior. 

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

Та же ситуация на фронте: есть клиент приложения и есть сайт,  это разные технологии и разные навыки. А ещё есть QA и DevOps компетенции — и это тоже совершенно другие знания.

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

Вторая итерация: отдельно hard- и soft-skills — неудача

Мы предположили, что инженеры одного уровня имеют примерно одинаковые soft-skills, независимо от технической специализации. Но как определить, какие навыки мы считаем действительно важными? Чем обязательно должен обладать senior, а чем middle?

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

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

Третья итерация: примеры поведения, карьерная карта, описания грейдов — успех

В результате мы пришли к процессу performance review, добавив в него модели поведения (behavior patterns), карьерную карту (career map), грейды (grades) и процесс оценивания (scoring).

Модели поведения

Что такое модели поведения в менеджменте? У каждого из нас в резюме описаны наши знания и умения. Например, у меня в резюме в стеке бэкенда — знание SQL, Oracle и Informatica ETL. Но это не помогает понять мою фактическую квалификацию, если я давно не работал с этим стеком. Если коротко: знания есть, но они активно не используются. 

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

Модели поведения на примере ожиданий от первой недели онбординга инженера.

Мы предполагаем, что новый инженер в команде демонстрирует следующее поведение в первую рабочую неделю:

• Выполнил чек-лист первого дня — подписал все необходимые документы и получил основные доступы к внутренним сервисам.

• Знает, что от него/неё ожидает менеджер по итогу периода онбординга.

• Слушает своего наставника и реактивно реагирует на его указания — мы не ожидаем проактивности в первую неделю — новичку говорят, что делать и он/она делает.

• Если чего-то не понимает — спрашивает, а не отмалчивается.

• Участвует во всех командных активностях, но пока тоже реактивно — присматривается и задаёт вопросы.

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

Мы ожидаем, что к концу первой недели у новичка уже будут конкретные результаты работы:

• Довёл минимум одну задачу до продакшена через весь процесс разработки и CI/CD pipeline. В ходе выполнения задачи он получает практические навыки, узнаёт как работают наши процессы от написания кода до продакшена.

• Может соотнести ожидания от него с тем, как работает конкретная команда.

• Явно показал, что воспринимает обратную связь и умеет с ней работать.

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

Модели поведения из карьерной карты разработчика.

Ниже список некоторых ожиданий от разработчика на определённом уровне:

• Способен самостоятельно разобрать продуктовые требования и на их основе разработать технический дизайн. Это реальное применение навыков системного мышления и взаимодействия с владельцем продукта. 

• Способен показать высокое качество результатов: протестировать свой код, уложиться в сроки и так далее.

• При столкновении с препятствиями активно ищет решение проблемы со своей стороны, а не ждёт руководящих указаний.

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

Карьерная карта 

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

Карьерная карта, в отличие от карьерной лестницы, даёт более широкий контекст в профессиональном развитии. Карта показывает возможность реализации навыков в рамках разных веток развития.

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

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

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

Грейды

В нашем случае грейд — это набор необходимых навыков.

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

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

В грейдах две части: общая и специальная. Это немного похоже на hard- и soft-skills. Например, есть общие навыки, которые характерны для всех уровня senior и не зависят от функции: влияние на определённый объем функционала, управление рисками, тайм-менеджмент, работа со стейкхолдерами, проактивность в том, чтобы рассказать о проблемах. И есть часть, специфичная для каждой функции, — в ней мы описываем более технические вещи без привязки к конкретной технологии. Например, способность декомпозировать продуктовые требования и разработать технический дизайн или долгосрочное владение подсистемой/системой. 

Performance review

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

Процесс состоит из четырёх этапов.

Этап 1: рефлексия

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

На картинке — разные части рефлексии. Достижения видят все, кто вовлечён в процесс performance review сотрудника. Остальные пункты видит только менеджер.

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

Как это было достигнуто. Здесь сотрудник рассуждает, как он пришел к результату, как способы его работы соответствуют нашей культуре. Потому что можно достигать результата, но при этом идти «по головам», что для нас неприемлемо. В статье «Культура как основа масштабирования команды х2 каждый год. Про ошибки в найме и culture fit» я рассказывал о том, как у нас работает культура.

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

Области для улучшения. Зоны роста — сотрудник описывает, что не получилось и что он планирует улучшить в каждой области.

На этап рефлексии в performance review мы отводим три-четыре дня, в течение которых сотрудник должен выделить время и написать self-review.

Этап 2: номинация коллег для ревью

Сотрудник выбирает 3–5 коллег (peers), от которых хочет получить обратную связь. Middle-инженерам мы рекомендуем выбирать людей из своей команды. Для senior-инженеров это могут быть сотрудники из других команд, потому что на этом уровне инженеры уже влияют не только на результаты своей команды. Каждый инженер обязательно добавляет в список продакта своей команды. 

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

Через пару дней мы закрываем этап номинации и переходим к performance review со стороны пиров — peer review.

Этап 3: peer review

Во время peer review выбранные сотрудники дают обратную связь по предложенному шаблону. 

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

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

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

Этот этап занимает около недели.

Этап 4: менеджер

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

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

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

Этап менеджерского ревью занимает не больше недели. Процесс ревью на этом заканчивается. 

Скоринг

Скоринг — это формальная оценка результатов работы сотрудника.

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

Выглядит вроде хорошо. Но не тут-то было!

Четвертая итерация: новый скоринг и калибровка — успех

Мы провели несколько циклов performance review и поняли, что нам нужно поменять процесс скоринга.

Новый скоринг

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

Калибровка

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

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

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

Далее мы принимаем решение по повышению грейда для сотрудника.

Итоги

Сделаем краткий обзор результатов.

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

Мы не смотрим, сколько человек проработал в компании. Главное, чтобы он «тащил». Для оценки работы в течение полугода используем performance review.

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