«Вот сейчас проведём performance review, вычислим слабых разработчиков и уволим их!» — заявил мне как-то HR.

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

Вот мой чек-лист, в каком порядке я оцениваю разработчиков.

Efficiency 🚀

Это то, как много задач разработчик закрывает за единицу времени — и больших, и маленьких.

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

Всё это характеризует высокопроизводительного разработчика — high performer 💪

Есть ещё low performer. Он не закрывает много задач за единицу времени, систематически не попадает в свои же оценки, не автономен — постоянно просит помощи и уточняет детали. Не берёт ответственность, тяжело переключается между контекстами, теряет фокус, зависает и уходит в пустые рассуждения.

💡 Как выявить?

Не нужны burn down chart’ы и скрытые механизмы слежки. Достаточно недельку поработать с человеком, послушать, что и как он говорит на daily, — и всё станет ясно. Разбуди ночью тимлида, и он сразу назовёт своих high и low перформеров.

Руководителю разработки с несколькими командами и десятками разработчиков стоит на 1-2-1 с тимлидами спрашивать, кто у него молодец, а кто нет. Если из раза в раз «немолодцы» одни и те же — вот и список low перформеров.

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

Reliability 🦾

Если он high performer, закрывает кучу задач, но вместе с этим создаёт кучу багов и инцидентов на продакшене — то это уже не high, а low performer, который не включая голову выкатывает всё на прод и считает свои задачи закрытыми.

А насколько отказоустойчивы его технические решения — или всё падает при первой же нагрузке? Насколько они расширяемы — или каждый раз приходится рефакторить и разгребать спагетти-код, чтобы вставить ещё одну строчку?

Да, конечно, у всех есть error budget, и high performer в абсолютных значениях может ошибаться чаще, чем low performer, но зависимость между количеством закрытых задач и числом проблем на продакшене не должна быть линейной.

💡 Как выявить?

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

Или сервис только пару недель как запустили в прод, а разработчик уже закладывает рефакторинг в оценку новых фич. Не проходит и двух месяцев, как он заявляет, что неплохо бы вообще-то переписать сервис с нуля.

Loyalty 💎

High performer, который редко ошибается, — но как он работает в команде?

Моментально ли подключается к инцидентам и оперативно катит фикс? Или закрывает ноутбук в 18:00 — и гори оно всё синим пламенем?

Проявляет ли инициативу, предлагает ли улучшения процессов и подходов, делая свою и работу команды эффективнее? Или пассивен, безучастен, сидит на митингах с выключенной камерой и молчит?

Команде и смежникам комфортно с ним работать? Или это токсичный сгусток желчи, разлагающий коллектив?

💡 Как выявить?

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

Вот тут и может помочь perf review и оценка 360°, если, например, разработчик был десантирован на внешний проект и фидбэк к тебе не доходил. Но чудес ждать не стоит — лучше сам иногда заходи к смежникам и спрашивай — всё ли ОК?

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