Как происходит performance review в инженерной команде
Я Software Engineer и Tech Lead в компании Railsware уже 8 лет. Последние несколько лет в список моих обязанностей входит найм, аллокации, а также поддержка и проведение performance review процесса для инженерной команды.
Каждой инженерной команде нужен способ оценивания ее участников. Он необходим для поддержки карьерного роста, прозрачности зон развития и справедливой компенсации.
В моей статье речь пойдет о том, как мы строили и продолжаем совершенствовать модель оценки инженеров в Railsware — продуктовой студии с командой в 100+ человек. Нашему подходу уже более 7 лет. Он менялся вместе с развитием компании, усовершенствованием процессов и появлением новых ролей.
Значительная часть дохода компании распределяется на инвестиции в команду и в продукты. Существует связь между доходами бизнеса и компенсацией: чем больше доход, тем выше уровень компенсации. И наоборот, рост экспертизы инженерной команды напрямую влияет на успех и доход всей компании. С годами мы выработали свою модель ежегодного performance review, в основе которой лежит эта взаимосвязь.
Несмотря на сложность процесса и немалые затраты ресурсов, правильно построенная система оценки — это весомый вклад в развитие команды и бизнеса в целом. В Railsware инженеры остаются в компании в среднем 5 лет, а для поддержания этого показателя нужны прозрачные возможности роста.
Процесс
В инженерных компаниях бывает несколько видов performance review процесса. Основные отличия в том, кем проводится review (менеджером или командой), как часто и по какой шкале проходит оценка.
В Railsware мы давно осознали, что оценивание инженеров одним менеджером достаточно субъективно. Один человек может быть предвзятым, не видеть всей картины, не знать фидбэка других членов команды. Исходя из этого решили остановиться на модели peer review, при которой оценка каждого инженера основывается на отзыве других инженеров. Engineering Management команда выступает в этом процессе модератором.
Мы выстроили матрицу основных навыков, компетенций и зон ответственности в Product Engineering командах. Это инженерные команды, работающие без Project Manager’ов и отвечающие самостоятельно за процесс разработки, планирование, скоупинг и архитектуру продукта.
Согласно этой матрице, инженеры оценивают коллег, с которыми вместе работали в прошедший период, указывая насколько каждый навык выше или ниже ожидаемого уровня. Оценка всегда должна подкрепляться фидбэком с описанием конкретных ситуаций: что превосходило ожидания или было ниже, как можно было сделать лучше и почему. Таким образом, любое проявление инициативы в командах не остается незамеченным. Ситуации, когда один из инженеров проактивно настроил CI Pipeline, ускорил test suite или же разобрал все узкие места планируемой фичи и помог разбить ее на детальные задачи отражаются в performance review.
Показатели peer review помогают определить, на каком отрезке шкалы роста находится каждый инженер, соответствующий уровень компенсации и на чем стоит сконцентрироваться в дальнейшем.
Результатом performance review процесса является пересмотр компенсации и регулярный фидбэк по карьерному росту каждому инженеру. Компенсация основана не на субъективном мнении одного-двух менеджеров, а на общеизвестной шкале роста в компании и целостной обратной связи.
Матрица навыков
Система оценки инженеров в Railsware представляет собой матрицу навыков. При ее разработке мы преследовали две цели:
- Показать пути дальнейшего развития и на что стоит обратить внимание для достижения цели;
- Оказать поддержку в карьерном продвижении и создать модель повышения компенсации.
Исходя из потребностей Product Engineering команд и бизнеса, мы пришли к оценке по четырем основным навыкам, каждый из которых включает три категории.
1. Technical Skill — основной инженерный навык, который определяет как широту, так и глубину понимания используемого стека. Сюда входит:
- Основы программирования — понимание и использование структур данных, паттерны проектирования, рефакторинг, тестирование, Test Driven Development, умение работать с техническим долгом.
- Глубина знаний — навык работы с основным стеком, сложность и уникальность решаемых задач, опыт улучшения производительности приложений.
- Широта знаний — знание других подходов, архитектур, баз данных, языков программирования, а также умение их предложить и внедрить в подходящем месте. Одной подписки на Ruby/DBweekly недостаточно, нужно понимать плюсы и минусы каждой предлагаемой технологии, видеть, как она впишется в текущий проект.
2. Productivity. Здесь оценивается продуктивность работы в продукте; как индивидуальная, так и влияние на продуктивность других инженеров в команде. Продуктивность — это далеко не число написанных строк кода в час. Она скорее заключается в качестве и стабильности реализованных решений, следованию принятых в команде практик и ревью кода:
- Скорость деливери решений, попадание в запланированные сроки или реализация быстрее запланированного. Здесь также оценивается навык разбивать задачу на мелкие и атомарные изменения.
- Стабильность решений, количество внесенных изменений после ревью, а также умение разблокировать себя и остальных.
- Скорость входа в новый домен или контекст. Время необходимое, чтобы разобраться с новым стеком или проектом, интерес к новым подходам. Здесь учитывается и помощь другим в изучении нового контекста — написание документации, проактивная работа в паре.
3. Product Contribution. Здесь оцениваются все активности в команде, кроме непосредственно написания кода. В большинстве наших команд нет роли Project Manager. Инженеры, работая напрямую с Product Owner’ом, выстраивают требования задач, проводят планирование и принимают решения о том что, как и когда реализовывать. Инженеры также выстраивают процесс разработки, отвечают за архитектуру приложения, менторинг и онбординг в командах.
Такая структура требует хорошего понимания продукта, пользователей, приоритетов бизнеса и умения управлять техническим долгом. Чем больше инженер берет на себя ответственности и вовлеченности в подобные задачи, тем выше его уровень Product Contribution.
Подробно этот подход описан в статье Product Engineering.
4. Soft skills. Софт скилы — это часто недооцененная или неполноценно понимаемая часть разработки в команде. Многие воспринимают софт скил только как умение договариваться и находить общий язык с другими членами команды. Мы решили разделить его на три равноценные категории:
- Проактивность и проявления лидерства, которые включают в себя принятие решений, владение задачей от уровня требований до релиза, фидбэк по улучшению процессов разработки и так далее.
- Коммуникационные навыки и работа в команде.
- Общий подход к работе, который мы назвали Work Ethic. Здесь оценивается самостоятельность, направленность на результат, надежность, прозрачность в работе. Эта часть софт скила не связана с коммуникационными навыками, но она показывает, насколько инженеру можно доверить самостоятельное решение задачи.
Шкала должна быть понятна всем членам команды с первых дней и отвечать на вопросы: что важно для продукта, для бизнеса, как расти в компании. Поэтому набор скилов и метод проведения performance review детально описываются для всех инженеров в компании, особенно для новичков.
Предвзятость при оценке и фидбэке
В основе объективного review-процесса должна лежать обратная связь, а конструктивная обратная связь требует времени на подготовку.
Фидбэк в процессе performance review должен быть конкретным и детальным. Только в этом случае он будет полезен и пригоден для дальнейшей работы. Поэтому мы выделили две обязательные секции: Goods — что удалось хорошо, To-improves — примеры ситуаций или решений, которые можно было сделать по-другому, с объяснением причин, аргументацией и альтернативным результатом.
При составлении обратной связи и тем более оценке часто возникают предвзятости (Biases), которые мешают объективности. Так проявляется или недостаток информации, или излишняя концентрация на недавних событиях. Дальше я опишу проблемы, которые часто встречаются, и то, как мы их избегаем.
Time Bias
Мы проводим performance review каждые 12 месяцев. Это значит, что принимаются во внимание все результаты, достижения и уровень навыков за прошедший календарный год. Тем не менее часто наблюдается ситуация, когда фидбэк составляется незадолго до самого performance review и в памяти остаются только недавние события последних
Случается и наоборот — peer-фидбэк составляется на основе ситуации, которая произошла раньше, но явно отложилась в памяти. Один неправильный выбор технологии/паттерна или случай спасения дедлайна одним человеком сильно откладываются в памяти и начинают влиять на все оценки скилов и производительности в будущем. В результате оценка выстраивается на основе уровня и навыков 2—3-летней давности.
Излишняя строгость или снисходительность
Некоторые относятся излишне требовательно к остальным участникам своей команды, критически воспринимая менее приоритетные ошибки. Например, если ваш коллега забыл исправить warning-и линтера перед созданием пулл-реквеста, это еще не повод низко оценивать технический скил в целом.
Другие могут, наоборот, быть слишком снисходительными к недоработкам в команде и пропускать критичные вещи, такие как отсутствие тестов или очевидные performance-проблемы, тем самым завышая оценки всей своей команде.
Важно понимать, к какой группе скилов относится тот или иной contribution, и избегать оценки всех навыков одновременно.
Усреднение всей команды
В любой шкале, когда есть оценка со значением average, часто появляется тенденция усреднять показатели. Это случается, когда у ревьювера недостаточно фидбэка для детальной оценки либо нет желания собирать отзывы.
Здесь проблема не столько в усредненных оценках, сколько в недостатке аргументации и фидбэка. Такие оценки не несут пользы конечным пользователям performance review — инженерам. Оценка average должна подкрепляться списком goods/to-improves, а также иметь обоснование, почему этот навык не above/below average.
Кроме примеров и конкретных рабочих ситуаций, избежать усреднения помогает детально описанная шкала навыков и уровней ожиданий от роли инженера в команде.
Как мы избегаем биасов оценивания
Выстраивание шкалы навыков и сам процесс performance review у нас проводится engineering management командой. Эта команда выступает модераторами во время peer review, помогая другим и самим себе избежать предвзятости оценки.
Review происходит в нескольких группах инженеров по
Таким образом, все участники review дополнительно модерируют друг друга, уменьшая предвзятость и улучшая общее понимание шкалы навыков.
В итоге оценка от группы людей по общей шкале становится объективней.
Наводящие вопросы помогают прояснить детали описываемых ситуаций, а фидбэк от нескольких участников команды — рассмотреть ситуацию с разных сторон. К каждому пункту матрицы скилов прилагается список вопросов, помогающий детально оценить уровень этого скила. К примеру, если один член команды предложил провести рефакторинг основного участка кода, надо также понимать, как этот рефакторинг объяснили Product Owner’у, как он был спланирован, кто им в итоге занимался и как его реализовали.
Важно детально описать каждый конкретный случай, понять, к какой категории навыков он относится, когда это произошло и исправилась ли ситуация после.
Вывод
Система оценки помогает определить вовлеченность инженера не только в свои проекты и прямые обязанности, но и в жизнь компании. Например, онбординг новичков, участие в сайд-проектах и в развитии команды. Все это влияет на компенсацию.
Что также важно — каждый инженер видит прямую зависимость своей компенсации от проделанной работы.
Подход Railsware — лишь один из примеров, который можно взять на заметку для построения собственной модели. Каждая компания выбирает то, что работает для нее, исходя из целей и потребностей бизнеса. При этом у каждой системы есть свои плюсы и минусы.
Как бы мы не стремились к совершенству, доля субъективности будет всегда. Тем не менее ее величину можно контролировать. Мы находим плюсы описанной модели в том, что она построена на данных и учитывает мнение кросс-функциональных команд, а также делает весь процесс прозрачным.
В результате растет вовлеченность команды в свои непосредственные задачи и в бизнес в целом. Инженеры ощущают себя полноценными участниками создания продуктов, видят результаты своей работы и личные зоны роста, а также мотивированы развиваться внутри компании.
64 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів