Как оценивать производительность программиста в команде

Что проверяют

Умеете ли вы оценивать людей по результату, а не по видимой активности, и понимаете ли, как метрики портят поведение. Вопрос часто задают кандидатам в тимлиды или сеньоры, следом звучит: «Что будете делать с разработчиком, который отстаёт?»

Как отвечать

Начните с тезиса: одной цифры нет, оценка складывается из нескольких источников, и её критерии известны человеку заранее.

• результат: какие задачи доведены до прода и что они дали продукту. Закрытый тикет, который вернулся багом, не результат;
• качество: доля возвратов после ревью и тестирования, инциденты и хотфиксы, замечания SonarQube в динамике. Покрытие из JaCoCo смотрят как тренд, а не как норму;
• командная работа: качество и скорость код-ревью, помощь новичкам, участие в дизайне решений, разбор инцидентов;
• рост: движение по матрице компетенций грейда, например от реализации задач к проектированию сервиса;
• командные метрики: DORA (частота деплоя, время от коммита до прода, доля неудачных изменений, время восстановления) и фреймворк SPACE. Их считают на команду, а не на человека.

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

Если вы не руководили, так и скажите и расскажите, как оценивали вас и что в этом было справедливым, а что нет. Это тоже опыт.

Где спотыкаются

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

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

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