Alex Four
🔢 Что не так с оценкой работы программиста?
Во всех крупных компаниях, в которых я работал, процесс ревью был устроен по-разному, но всегда убого. И по рассказам коллег из других компаний, там тоже не лучше.
Обычно это происходит так:
☝️ собирается обратная связь от коллег
✌️ собирается обратная связь от руководителей
🤷 руководители, которые не понимают чем занимается конкретный разработчик, оценивают его работу
Я вижу несколько проблем в этой схеме.
Во-первых, руководитель должен оценить, но он не знает, чем занимался сотрудник которого оценивают.
Во-вторых, каждому из руководителей приходится в короткий период (1-2 дня) оценить много, очень много людей
Стоит помнить, что любой человек ленив. И в единичном случае готов разобраться, но когда людей много все сводится к какому-то очень простому алгоритму. Поэтому чтобы это было проще, в некоторых компаниях вводят измеримый показатель. Это может быть количество коммитов, количество закрытых тикетов, количество проработанных часов. Что угодно у чего есть цифра. Я это называю индусским подходом. Причем, далеко не всегда параметр оценки известен всем.
В третьих, обратная связь. Я уже достаточно давно на нее не рассчитываю после ревью.
Получил прибавку, значит молодец, все делал правильно! А что все? Догадайся сам!
Можно ли с этим что-то сделать?
Да, нужно просто делегировать. Делегировать оценку каждого сотрудника тому, кто знает как он работает.
Самое очевидное отдать оценку непосредственному руководителю, но это путь к нездоровым отношениям в команде. Я же предлагаю отдать решение за оценку сотрудника команде, в которой этот сотрудник работает.
Представьте голосование, в котором каждый оценивает как поработал его коллега. При этом каждый должен высказаться и как-то аргументировать свою оценку.
Есть три оценки, плохо, хорошо и отлично. По-умолчанию, все работают хорошо, и большая часть получает именно такую оценку. Чтобы получить какую-то другую оценку, необходимо чтобы кто-то поставил ее и аргументировал. И главное, команда должна согласилась с этим решением.
Кто-то может сказать, что это почва для сговора. Да, но это просто решается. Например, в команде не может быть больше 1-й оценки отлично, а еще подобные обсуждения должны проходиться открыто. Другими словами, любой человек из компании может прийти на встречу и послушать. А еще такие встречи можно записывать.
Самые страшные поступки люди совершают, веря что об этом никто не узнает. Поэтому огласка - это отличный инструмент против злоупотреблений.
Второй инструмент - это статистика. Можно отслеживать различные аномалии. Но наличие аномалии не должно автоматически означать что решение, которое приняла команда неверное. Нужно уважать решение команды и очень хорошо разобраться прежде чем что-то с ним делать.
Статистика вещь обоюдоострая. С одной стороны она позволяет выявить аномалии, а с другой цифры могут подгоняться.
Разумеется команде заранее нужно объяснить правила игры. Причем рассказать не только правила, но и почему эти правила появились. Например, открытость нужна для того, что бы избежать злоупотреблений. Запись делается для того, чтобы можно было вернуться к обсуждению в случае возникновения аномалии или на следующий ревью. Необходимо так же объяснить, что обсуждение должно вестись в уважительной манере, а обстановка не должна быть токсичной. Возможно, для этого потребуется присутствие человека, который будет фасилитировать беседу в нужном направлении.
Ну и самое главное, нужно дать возможность сотрудникам полностью погрузиться в процесс оценки. Необходимо освободить людей от рабочих задач. Никто не будет приходить на обсуждение в другую команду, если с этим будет конкурировать горящий релиз.
В результате обсуждения у каждого будет возможность посмотреть на себя глазами коллег, получить адекватную обратную связь. А так же высказаться, и быть услышанным.
Спасибо, что дочитал до конца. Хорошего дня)