👳♂️ Индусский подход в оценке программиста, все так плохо?
Сразу два дисклеймера. 1. Да, все так плохо. 2. Такое название подход получил, поскольку аутсорсером из индии платили за количество написанных строк. В результате такой код становился излишне много сложный и непонятный.
Я как-то писал о проблемах, которые возникают почти во всех больших компаниях, во время проведения регулярных ревью.
Если коротко, то проблема в том, что оценивает сотрудников человек который ничего не знает о сотруднике, лично не знаком, личный вклад быстро оценить не получается. А нужно, поскольку людей на ревью много, и погружаться в ситуацию каждого разработчика долго и лень.
Логичным решением придумать какие-то исчисляемые показатели. Чтобы свести всех сотрудников в одну табличку отсортировать по грейду, и выбрать самых лучших, и самых худших.
👩💻 Программисты пишут код, давайте оценивать их по его количеству.
На первый взгляд логично, если ты много кода написал, то хорошо поработал, мало - плохо.
Лучший код – ненаписанный код.
⌨️ Хорошо, а давайте мерить код не строчками, а коммитами. Все коммиты будем объединять в один перед релизом. В итоге один коммит - одна фича.
Уже лучше, но только если фича А идентична фиче Б? А я за 10 лет не видел одинаковых фичей. В итоге если разработчик закрыл только одну фичу то результат ревью будет плохой. Даже если эта фича принесла компании денег. Не справедливо получается. И к тому же не мотивирует браться за сложные задачи.
Но может быть еще хуже. Например, компания очень активно растет, и старший разработчик пол года занимался собеседованиями. А потом онбордил новичков. Отвечал на бесконечное количество вопросов. Решал проблемы с доступами. Планировал и нарезал задачи. А вот код не писал - не было времени. Он тоже не пройдет ревью?
💡 Хотя, возможно, руководство, которое его оценивает знакомо с ним, знакомо с его миссией, а значит для него сделают исключение.
А потом еще для кого-то и еще для кого-то, и еще... Так в независимую оценку проникает панибратство. Чем ближе ты к начальству, тем свободнее смотрят на твой результат.
🧒 А что рядовые сотрудники?
Им тоже хочется пройти ревью, поэтому они помимо рабочих задач думают еще и над тем, как обмануть систему. Сделать побольше коммитов. Написать больше строк кода. Сходить на большее число встреч. Завести больше тикетов, чтобы их # доблестно потом решить.
♾️ И что же теперь не оценивать?
Конечно оценивать. Это важно руководству поскольку они понимают кто и что делает. Это важно сотруднику, поскольку можно получить обратную связь.
Но адекватно оценить сотрудника могут только его коллеги, которые работают с ним. Поэтому нужно делегировать эту обязанность на них.
Поддержать меня можно на бусти
А как в твоей компании оценивают разработчиков и менеджеров?