Цветовая схема
Alex Four
4 сент. 2023

🔢 Что не так с оценкой работы программиста?

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

Обычно это происходит так:

☝️ собирается обратная связь от коллег

✌️ собирается обратная связь от руководителей

🤷 руководители, которые не понимают чем занимается конкретный разработчик, оценивают его работу

Я вижу несколько проблем в этой схеме.

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

Во-вторых, каждому из руководителей приходится в короткий период (1-2 дня) оценить много, очень много людей

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

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

Получил прибавку, значит молодец, все делал правильно! А что все? Догадайся сам!

Можно ли с этим что-то сделать?

Да, нужно просто делегировать. Делегировать оценку каждого сотрудника тому, кто знает как он работает.

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

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

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

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

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

Второй инструмент - это статистика. Можно отслеживать различные аномалии. Но наличие аномалии не должно автоматически означать что решение, которое приняла команда неверное. Нужно уважать решение команды и очень хорошо разобраться прежде чем что-то с ним делать.

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

Разумеется команде заранее нужно объяснить правила игры. Причем рассказать не только правила, но и почему эти правила появились. Например, открытость нужна для того, что бы избежать злоупотреблений. Запись делается для того, чтобы можно было вернуться к обсуждению в случае возникновения аномалии или на следующий ревью. Необходимо так же объяснить, что обсуждение должно вестись в уважительной манере, а обстановка не должна быть токсичной. Возможно, для этого потребуется присутствие человека, который будет фасилитировать беседу в нужном направлении.

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

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

Спасибо, что дочитал до конца. Хорошего дня)